| 4 | | I'm warming to the hypothesis that it's not really a condition to 'check'. The OR is a micro-optimizing hack to sneak a void func into the middle of a list of conditions for an if block. |
| 5 | | \\ |
| 6 | | {{{ |
| 7 | | if (register && (SetNowSeen(horror) | 1) && (boundary tests)) { |
| 8 | | register = 0 // Got a hit, stop checking. |
| 9 | | g188_egoSpell::cue() // Advance the spell Script's state to disappear? |
| 10 | | } |
| 11 | | }}} |
| 12 | | \\ |
| 13 | | * If "register" is 0, short-circuit. |
| 14 | | * doit() runs frequently, I imagine. Every optimization helps on slow hardware. |
| 15 | | * Script objects in script 855 tend to set their own "register" property occasionally when changeState() wants to toggle the frequent collision detection. |
| 16 | | |
| 17 | | * The func is there to update boundary properties so that collision tests always have current data, but only when "register" deems it necessary. |
| 18 | | |
| 19 | | * The author may have been acting out of a general sense that the truth evaluation of void funcs is erratic. |
| 20 | | * In the specific case of what I disassembled above, SetNowSeen() could exist as a pseudo-condition unaided, always non-zero. This is only because its stack was pushed immediately before the callk, with an object arg. |
| 21 | | * Wrapping a void func in a bitwise OR ensures that however it compiles, it will evaluate to non-zero. |
| 22 | | * [EDIT: Removed bad speculation about null handling that would absolutely explode.] |
| 23 | | \\ |
| 24 | | \\ |
| 25 | | Why not this? Dunno. Brevity? |
| 26 | | {{{ |
| 27 | | if (register) { |
| 28 | | SetNowSeen(horror) |
| 29 | | |
| 30 | | if (boundary tests) { |
| 31 | | register = 0 |
| 32 | | g188_egoSpell::cue() |
| 33 | | } |
| 34 | | } |
| 35 | | }}} |
| | 4 | EDIT: Never mind my pseudo condition hypothesis. Protracted speculation about the intricacies of torturing if blocks won't help this ticket. |
