Can someone explain Flags to me?

[lskovlun]

Code: [Select]

(if z ...) ; will execute if z is 1 or higher

You mean non-zero. Whether an integer is treated as signed or unsigned depends on the opcode. That is why we have > versus >u (or was that u>).

[NilG]

Now I'm going crazy.

A month or so ago, I set up flags all around and they all seemed to work without a problem.  I foolishly reverted to globals, but recently began to switch back to flags after figuring out a way to work with scripts to keep them positive heapwise.

But one's giving me trouble now that I can't figure out, and that's only after editing one room script.

Code: [Select]

(procedure (Btst flagEnum)
;Test a boolean game flag
(return (& [gameFlags (/ flagEnum 16)] (>> $8000 (mod flagEnum 16))))
)


(procedure (Bset flagEnum  &tmp oldState)
;Set a boolean game flag
(= oldState (Btst flagEnum))
(|= [gameFlags (/ flagEnum 16)] (>> $8000 (mod flagEnum 16)))
(return oldState)
)

(procedure (Bclr flagEnum  &tmp oldState)
;Clear a boolean game flag
(= oldState (Btst flagEnum))
(&= [gameFlags (/ flagEnum 16)] (~ (>> $8000 (mod flagEnum 16))))
(return oldState)
)
They are as copied directly from this thread, other than I added the return statements to bypass warnings.

But for example, if I run this:

Code: [Select]

(if (Said 'nudge/bag,trash')
(if (not (Btst fTrashMoved)) (Print 6 23) (theTrashPile ignoreControl: ctlWHITE setMotion: DPath 138 148 loop: 0) (Bset fTrashMoved)
else (Print 6 28))
)

I get the correct Print statement and theTrashPile moves, BUT it will just let me do this repeatedly and subsequent Btst fTrashMoved indicates it's false.

I have another flag, fAlleyLightBusted, that seems to stick after I throw a rock at the light... until I nudge the trash, at which point it seems to go false. Enter and leave the room multiple times, no problem, until the nudge.  Neither flag even has a related Bclr; once they're set once, they should be set forever.  They're also completely unrelated actions; the only Bset for fTrashMoved is the one above and, again, everything in the "if" statement happens except the flag set.  fAlleyLightBusted doesn't even get set in the RoomScript, it's in a different Script (although same script doc) altogether.

Basically, it all seems fubar, at least when it comes to this damn bag.  I tried setting up a test:

Code: [Select]

(if (Said 'what')
(FormatPrint "Trash Moved: %d" (Btst fTrashMoved))
(FormatPrint "Lights Out: %d" (Btst fAlleyLightBusted))
)

and find that fAlleyLightBusted does go from false to true (or, more accurately, a very large negative number, is that good?) when the rock is throw.  fTrashMoved remains 0 when the nudge script kicks in.  And fAlleyLightBusted goes back to 0 when the nudge script is run. 

Should the test above accurately reflect flag settings, as I feel like it should?

I've double and triple checked that all previously global variables have been correctly renamed to flags (and these flags/variables only apply to this single room).  The flag names match the enums given in game.sh.

Is there a way to flush print the contents of gameFlags all over so I can check if the wrong bit is getting set for the bag?  I wouldn't even know how to go about fixing that, but I really just can't see anything that would cause this behavior and it's the only thought I'm having.

[troflip]

You're sure you're recompiling all files? And you're not relying on a saved game or anything?

[lskovlun]

Also make sure that your enum declarations don't have duplicate numbers. It's easy to do this by accident.

[NilG]

I do Compile All each time before a test run and almost always rebuild just to kill the redundancy, but I just went through and compiled both Main and rm006 specifically to be sure.  Still no luck.  No saved games; I've largely relied on the debugging shortcuts, but even when I do save, I crush any save files to be safe.  There aren't any currently.

In game.sh, I just have the enum in a list format:

Code: [Select]

(enum
fAlleyLightBusted
fArtBoxFirstOpened
fArtifakeSwapped
        …
        fStinkySandwichKickout
fTrashMoved
fWearingCoveralls
)
No numbers specified, so I don't *think* that's the case, but is it possible?

[Charles]

Is there a way to flush print the contents of gameFlags all over so I can check if the wrong bit is getting set for the bag?  I wouldn't even know how to go about fixing that, but I really just can't see anything that would cause this behavior and it's the only thought I'm having.

Try using %x instead of %d for the formatting. That'll display the hex value, instead of the signed number.  That'll make it easier to paste into your favorite hex calculator (I love Win10's calculator with it's Programming mode, for seeing hex and binary values).

How many bytes is your flag array?  It sounds like your Bset procedure isn't limiting itself to the specified bit. The code looks fine to me though, so to debug and see exactly what's in the flag arrays try: (so if your flag array is 5 bytes long)

Code: [Select]

(FormatPrint
    "gameFlags: %04x %04x %04x %04x %04x"
    [gameFlags 0]
    [gameFlags 1]
    [gameFlags 2]
    [gameFlags 3]
    [gameFlags 4]
)

Then convert that number into binary, and see the state of each flag.

[troflip]

• How many flag enums do you have?
• How big is your gameFlags array
• What global variables are listed after gameFlags array in Main.sc?

[NilG]

I've currently got 71 flags enumerated and a 10 item gameFlags array.  gameFlags is itself the final global variable.  I've got 73 other globals before that I've added, though the ones related just to this screen are commented out, bringing that to 71.  None of the other three global variables which were previously associated with this screen, which are also used in other rooms, should be in play here.

(FormatPrint
    "gameFlags: %04x %04x %04x %04x %04x"

dump for gameFlags 0 - 9:

Starts out:
0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
which is fine.  A couple will get set to true initially, but not implemented, so all false is good.

Nudge bag:
0400 0000 0000 0000 0000 0000 0000 0000 0000 0000

Throw rock:
8400 0000 0000 0000 0000 0000 0000 0000 0000 0000

Nudge bag after throw rock:
0400 0000 0000 0000 0000 0000 0000 0000 0000 0000

fAlleyLightBusted is the very first flag enumerated, so my understanding's fuzzy, but the addition there is expected?  fTrashMoved is the second to last of 71, so that one looks to be in the wrong place as far as I understand.  It's resetting the whole first byte or maybe array element altogether maybe when it flags what seems to be the wrong bit anyway?

[troflip]

So fAlleyLightBusted corresponds to throw rock? That looks correct.

But your "Nudge bag" is definitely not setting fTrashMoved, if trashed moved is 69. It appears to be setting the 5th one (i.e. 4).

What happens if you do:

Code: [Select]

(FormatPrint "Trash Moved flags: %d" fTrashMoved)

69?  Or 4?

[NilG]

Yeah, throwing the rock corresponds to the alley light bustage.

Huh.  It does say it's 69, so that seems a good thing.  I guess it's Btsting the right one, since it keeps treating it as false, instead of switching to the else Print statement.

The fifth flag is for an event taking place on another room altogether, and one that isn't even in use yet outside of the enumeration (all events still utilize the original global variable).  Search confirms that it doesn't pop up in any of the other files...

[troflip]

Show us the code that sets fAlleyLightBusted

[NilG]

RoomScript event handler:

Code: [Select]

(if (Said 'throw>')
(if (Said '/rock/light')
(if (not (gEgo has: INV_LIEVENROCK)) (Print 6 57)
else (self setScript: lightsOut)))
(if (Said '/rock/window')
(if (not (gEgo has: INV_LIEVENROCK)) (Print 6 57)
else (Print 6 93)))
)

and then it's actually set in the lightsOut script:

Code: [Select]

(instance lightsOut of Script

(method (changeState newState)
(= state newState)
(switchto state
(
(ProgramControl)
(Print 6 58)
(theLight loop: 2 cel: 0)
(= seconds 1)
)
(
(= cycles 1)
(gEgo view: 002 loop: 1 cel: 0)
)
(
(= cycles 1)
)
(
(if (!= (gEgo cel:) 5) (gEgo cel: (+ (gEgo cel:) 1)) (self changeState: 2)
else (= seconds 1))
)
(
(= cycles 1)
)
(
(if (!= (theLight cel:) 2) (theLight cel: (+ (theLight cel:) 1)) (self changeState: 4)
else (= cycles 1))
)
(
(= gDefaultPalette 1)
(Rm drawPic: 6)
(theDoor cel: 1)
(theFirstDumpster cel: 1)
(theLight loop: 3)
(thePuddle cel: 1)
(if (not (Btst fGreaseJarInTrash)) (theSecondDumpster cel: 1)
else (theSecondDumpster cel: 3))
(theTrashPile loop: 1)
(theTrash1 cel: 1)
(theTrash2 cel: 1)
(theTrash3 cel: 1)
(theTrash4 cel: 1)
(theWallLine show:)
(Bset fAlleyLightBusted)
(gEgo put: INV_LIEVENROCK)
(theGlint dispose:)
(= cycles 1)
)
(
(gEgo view: 0 loop: 1 cel: 7)
(Print 6 59)
(= seconds 2)
)
(
(PlayerControl)
(Print 6 60)
(= cycles 1)
)
)
)
)

[Charles]

I’m leaning towards there being an error in the Bset procedure.

Try doing some methodical testing:

Code: [Select]

(Bset 0)
(FormatPrint ... the game flag print code)
(Bset 1)
(FormatPrint  blahblah)
(Bset 69)
(FormatPrint ...)

Incidentally, the 8400 from the earlier output translates to binary 1000 0100 0000 0000, i.e. flag 0 and flag 5 are true. An easy way to convert is just ask google (or DuckDuckGo) for “0x8400 in binary”. With 0x#### being a common shorthand for “hex number”.

[troflip]

Bset looks fine to me, but just doing some simple testing like Charles suggested should narrow down if that is the case, or you have something else going on.

Of note, setting flag 69 should result in a 0400 in the 4th gameFlags array spot instead in the 0th. Kind of suspicious that it's setting the same bit just in the wrong array index.

[NilG]

Most telling, I guess, is that this:

Code: [Select]

(if (Said 'what')
(Bset 0)
(FormatPrint "Bset 0: %d" (Btst fAlleyLightBusted))
(Bset 5)
(FormatPrint "Bset 5: %d" (Btst fBrokenSandwichThrown))
(Bset 69)
(FormatPrint "Bset 69: %d" (Btst 69)))

shows that 0 and 5 get set, but the last printout still says "Bset 69: 0"  Moreover,

Code: [Select]

(Bset 0)
(FormatPrint "Bset 0: %d" (Btst fAlleyLightBusted))
(Bset 69)
(FormatPrint "Bset 5: %d" (Btst fBrokenSandwichThrown))
(FormatPrint "Bset 69: %d" (Btst 69)))

shows that Btst fBrokenSandwichThrown (which is the element 5) is getting set in this latter case as well, even with the number specified.  So 5 seems to be getting set in either case, which I guess may point to the issue being in selecting the array element, as troflip noted?  I checked setting 70, as well, and find that 6 gets set instead.

I'm not sure why, yet, though; I've gone back and recopied the Bset from this script again, and have experienced the same even when I leave it as is (allowing for the no return warning to pop-up).  I've run a search and verified that there isn't some other Bset procedure I've added somewhere else that's getting called in lieu of the one in Main.sc (and there's only the one there).  It does seem strange.