Not sure if bug-fixing is really a priority (these end up being pretty niche), but I figure it's my duty to give back a little and report what I find, given how helpful people have been:
Bug 1:
the following script produces tempvar="cardbleachcard"(wrong) instead of tempvar="cardbleach" (right)
tempvar=0//I set this to zero for debugging; in the program it would be either 0 or the name of a card.
if tempvar==0 then
tempvar="cardbleach"
else
tempvar="{tempvar}card"
end
I thought maybe it runs both conditions sequentially (also a bug), but actually it's worse than that, because this produces the same thing:
tempvar=0
if tempvar!=0 then
tempvar="{tempvar}card"
else
tempvar="cardbleach"
end
It looks like instructing an if-then statement to alter the variable referenced by the if-condition causes the function to run twice. I changed it to this and it fixed the problem:
tempvar=0
if tempvar!=0 then
tempvar2="{tempvar}card"
else
tempvar2="cardbleach"
end
tempvar=tempvar2
Bug 2:
My program told a 0fps tile to
frame 2
When the tile had only 1 frame (i.e. "frame 0"), this caused no problems, even though the tile obviousy couldn't switch to the non-existent frame 2.
I subsequently added a second frame to the tile (i.e. "frame 1"). Telling a tile with 2 frames to "frame 2" caused massive visual glitches. The tile turned black, but instead of staying black it copied whatever was drawn on top of it last, causing the classic "curser trails" phenomenon seen since Windows 3.1 when your computer freezes but the mouse keeps moving.
This one could honestly be a VERY cool effect for some games, but it did cause massive slowdown on my PC, at least for the moment when I told the tile to "frame 2."
I fixed this by duplicating frame0 to create a frame2 that looks exactly like frame0 for that tile.
Bug 3 (from the discord, not my discovery):
Normally, using multiple "goto" instructions in a single cycle produces proper behavior, e.g.:
goto 3,5
x=22
x+=47
goto 4,9
This code correctly leaves the player at 4,9, not 3,5.
However, telling the player to go to two different rooms only executes the first room-change and ignores any subsequent goto-room commands.
goto 3,5 in "room1"
goto 4,9 in "room 2"
If the player starts outside room1, the above code improperly leaves the player at 3,5 (not 4,9) in room1. If the player starts in room1, it sends the player first to 3,5 in room1(you can see it happen onscreen), then sends the player to room2. This means that if you run the above code two separate times (e.g. "on confirm" with two separate button presses) then the code will first send the player to 3,5 in room 1 and then send the player to 4,9 in room 2.
This bug does not affect goto commands sending the player to the room they are already in. So, if the player is in room1, then:
goto 1,1 in "room1"
goto 2,2 in "room1"
goto 3,3 in "room2"
goto 4,4 in "room3"
the above code would execute the first three goto functions, then ignore the last one. I'm pretty sure that's not intended behavior. It definitely would go against the intentions of the person writing the code, since it is not documented. You could imagine a long series of if-conditions or event-calls that should leave the player in a certain place, but seem to randomly work or not work based (unknow to the dev) on where the player starts when the code is run.
Anyways. Anyone else have bugs to share?
