47 posts
Location
Canada
Posted 07 August 2015 - 03:54 PM
As it happens, I am working on
a program which does what it needs to do by controlling redstone signals along bundled cable - code at the link.
I am having a peculiar problem where one of the cables (yellow on the left side) energizes unexpectedly when the program initializes. This is in fact the opposite of what should be happening (everything on the left should be shut off at the start), so I'm wondering how in the hell I went wrong.
The bundles on the left side and the right side are the not the same colour of bundle from Project:Red, though I do "re use" colours on the left side and the right side. Every other call to the various wires works as expected, except this one. Unfortunately this one happens to be a critical function.
ETA: Minecraft 1.7.10, ComputerCraft 1.65, ProjectRed 4.5.15.75
Edited on 08 August 2015 - 01:12 AM
33 posts
Posted 07 August 2015 - 05:17 PM
Could you post the code?
122 posts
Location
gps.locate()
Posted 07 August 2015 - 05:50 PM
Could you post the code?
He has. Where he says "a program" the Pastebin link is there.
122 posts
Location
gps.locate()
Posted 07 August 2015 - 05:58 PM
Okay, I read through your code. Have you tried using the number version of the color? I know the colors API converts it into numbers, but I just want to clarify that the RS API just straight up requires numbers for this method.
Okay, scrap that.
EDIT: If you look on the Redstone (API) Page, there is a bundled cable code snippet under the RS API functions. Read that and you will find that if you set orange to true on the side right, then try to set magenta to true on the side right, it will disable orange.
Edited on 07 August 2015 - 04:00 PM
957 posts
Location
Web Development
Posted 07 August 2015 - 07:07 PM
you will find that if you set orange to true on the side right, then try to set magenta to true on the side right, it will disable orange.
That's why they have
colors.combineYou get the input from a side, then combine the current input with the color you want to add
To OP:
Looks like your 'hold' function is the only one that should be turning on 'colors.yellow'.
Why don't you stick a 'print("test")' in that function, so that you know when it's been activated?
122 posts
Location
gps.locate()
Posted 07 August 2015 - 09:20 PM
-snip-
That's why they have
colors.combineYou get the input from a side, then combine the current input with the color you want to add
Mmkay. Maybe I need to read through the Wiki a lot more then ;)/> Thanks for the advice!
Edited on 07 August 2015 - 07:21 PM
47 posts
Location
Canada
Posted 07 August 2015 - 10:12 PM
As it turns out, I discovered using the printing method that it was wrongly triggering hold() when the signal blocks populated on world load. If you give the computer a swift kick and add a sleep before the os.pullEvent trigger it fixes it.
Now to tackle the rest of the functionality problems. A full rewrite seems to be in order
47 posts
Location
Canada
Posted 08 August 2015 - 03:18 AM
Sorry to doublepost. There is a freshly-reworked version of the code, and while I think I've purged all the typos out of the program, it doesn't run correctly just yet.
Code from pastebin here.The problematic areas are the local functions checkDepartures() and switch() which don't seem to operate as intended. I think there's a commonality there, probably in the functions they're dependant on.
checkDepartures SHOULD change the state of any empty platforms the program is watching to "Vacant" if I coded it right, but clearly I didn't, as when the variables it alters later print, they print as the default state ("Unknown").
Likewise, switch() should turn a number of redstone bundled wire outputs on, but likewise doesn't.
They both have a dependancy in any of 4 "sig functions", which are thus defined:
local function segExample()
rs.testBundledInput(rSide, relevant colour)
end
I feel as though I must be missing some fundamental piece of information that everybody else knows but I've genuinely hit wits end on this.
212 posts
Location
Somewhere in this dimension... I think.
Posted 08 August 2015 - 04:45 AM
sig() doesn't return anything so sig1() = nil not true.
local function segExample()
return rs.testBundledInput(rSide, relevant colour)
end
47 posts
Location
Canada
Posted 08 August 2015 - 04:50 AM
I knew it had to be something hopelessly basic like that. Thanks.
47 posts
Location
Canada
Posted 08 August 2015 - 07:35 PM
And that totally worked.
I am now down to what I believe to be the final bug - after squashing a few typos and bad calls, I've gotten as far as identifying the code responsible - my locally-defined park() function:
local function park() -- where's the train going?
if sig1() == true then
p1 = incoming
local bypass = false
elseif sig2() == true then
p2 = incoming
local bypass = false
elseif sig3() == true then
p3 = incoming
local bypass = false
elseif sig4() == true then
p4 = incoming
local bypass = false
else
local bypass = true
end
"incoming" sets correctly - I have it print immediately for debugging.
However, after park executes, when the program loops back around to the print block (line 125 onward), the variable for wherever the train was sent (determined by park()) has become nil.
Anyone know why I borked something as simple as an if/else tree?
957 posts
Location
Web Development
Posted 09 August 2015 - 12:20 AM
It looks like you made making 'bypass' local to the function.
In the function, it has the value you want, but outside of that, it doesn't exist.
Define your variables as local at the top of your program, to keep things organized.
Anything that is only used in a single function or loop can be made local to that.
Also, you don't need to put 'local' every time you set the value of a variable, just the first time you define it.
47 posts
Location
Canada
Posted 09 August 2015 - 01:15 AM
Thanks. As it turns out, that was the problem - both in the park() function and in the unfunctioned if/else tree that proceeds it. After moving the definition of incoming elsewhere in the program and excising all other localizations the software now works fully as intended.