4 posts
Posted 16 April 2014 - 06:36 PM
Hi,
This is a bug that was reported fixed in 1.63pr5, but seems to still exist. Calling 'redstone.setOutput("left", true)' does not take effect until the red stone connected to the output is removed/replaced or modified in some way. setAnalogOutput also behaves the same.
Steps to reproduce:
- Place a redstone to the left of a basic computer
- Call: redstone.setOutput("left", true)
7083 posts
Location
Tasmania (AU)
Posted 16 April 2014 - 11:32 PM
It was reported fixed in 1.6pre5 - there wasn't a 1.63pre5. ;)/>
Since the release of 1.6, a few more builds have been put out there. Maybe try the
latest one.
16 posts
Posted 17 April 2014 - 08:07 AM
I know at least as of 1.62 this was still not working. I see nothing in the changelog indicating it was fixed. I'd have to shoehorn it into the pack I've been using to see if it did change in some way, but I was hoping for the official word on it. It looks like somebody pointed it out in the 1.60 release announcement and dan200 noticed it.
Outside of a mining turtle early on when first starting out in a game, I use computers to strobe signals to things at set times, so this takes a lot of the experience out of it for me. :(/>
7083 posts
Location
Tasmania (AU)
Posted 17 April 2014 - 08:47 AM
The long and short of it is that if I follow your instructions, the redstone lights up immediately. I've also tested this under a number of other builds, but have only seen it occur once (in one of the 1.6pre-s).
I'll take another stab at it later and see if I can't work out a way to trigger it, assuming you don't figure out the other factors yourself. I recommend you start out by making a new creative world, plonking down a computer and some redstone, and testing to see if that has issues.
Edit:
Whoops, I was thinking of a different bug - where the output was set correctly, but the computer failed to read the resulting input. Can't seem to replicate either way.
Edited on 17 April 2014 - 09:02 AM
34 posts
Posted 17 April 2014 - 01:14 PM
Confirmed this bug on both Singleplayer AND multiplayer. It sucks, because this computer is supposed to protect my base, but I guess I don't need to leave anytime soon… :P/>
16 posts
Posted 17 April 2014 - 09:49 PM
It looks like right now the NST Diet pack is using ComputerCraft 1.62. It looks like in single player it was able to work fine, but in multiplayer, the redstone API stops working. I don't know if they're up for trying 1.63 without knowing up front if it would take care of it, but I'll ask. If I can get a server pack from them, I could try a local multiplayer, but it isn't the easiest and quickest thing for me to double check.
Generally we tried a loop to turn the various sides on and off with a sleep delay, and we can't get anything to change the redstone next to it. Beyond that, we know from parking these computers next to things taking signals that they don't get any kind of pulse from the computer when doing all this. These were programs that were working fine in their stations before the updates.
1 posts
Posted 18 April 2014 - 03:44 PM
I can confirm this bug in 1.63 Multiplayer (it works fine in Singleplayer for me).
EDIT: I used MCPC+ when I got this bug, with the standard forge server it works fine for me.
Edited on 21 April 2014 - 07:54 AM
11 posts
Location
England
Posted 23 April 2014 - 05:27 PM
Can confirm in 1.63 Multiplayer, MCPC+ server only.
8543 posts
Posted 26 April 2014 - 06:08 AM
If the bug is only showing up on MCPC+ servers, it is likely that any fix would need to be on their end, if past trends regarding support for MCPC continue to hold.
16 posts
Posted 29 April 2014 - 05:13 AM
I don't know if I have the spunk to be able to change server stuff like that. I will double check with the server admin, who also makes the pack we're using.
If it matters, I have more to add. It looks like setting bundled I/O also doesn't work. It was my first attempt at it, but there were some people used to the API that mucked around. They went back to some old rigs they set up and found the bundled I/O wasn't working on their stuff either anymore. The interesting thing I found was I could get redstone.setOutput to work if I used rednet cables:
1. Connect one side to lamp.
2. Run program to do a setOutput call on that side.
3. Cycle through all the colors on the computer all the way through, like from white all the way back to white.
At the end of that, the lamp turned on and stayed on. If I then changed the script to turn off the signal, it was still stick on. I couldn't get a similar effect with any bundled cables.
I could get ProjectRed bundled cables to work at all even in single player.
8543 posts
Posted 29 April 2014 - 05:31 AM
If you're having trouble with bundled cables in CC 1.6+, ensure that the mod that adds the bundled cable has updated to include support for CC's new bundled cable API. As of 1.6, ComputerCraft no longer includes built-in support for any bundled cables, instead providing an API that any other mod can use to interact with the computers.
1 posts
Posted 01 May 2014 - 11:13 AM
I reported this issue on
MCPC forum.
7083 posts
Location
Tasmania (AU)
Posted 05 May 2014 - 04:41 AM
A few days on, looks like you've got a reply: A link leading to
this report.
45 posts
Posted 18 June 2015 - 02:43 PM
Downgrading to ComputerCraft 1.58 with the same version of MCPC fix the bug for me. But ComputerCraft 1.60+ adds too many things to be ignored.
7083 posts
Location
Tasmania (AU)
Posted 18 June 2015 - 04:25 PM
The other day I noticed that calling term.setCursorBlink() seems to trigger block updates around computers. Due to the MCPC-related nature of the bug you're experiencing, it may not work, but just try toggling blinking on/off and see if that's sufficient to get your redstone states to correct themselves.