#1875 Incorrect egg and trap behavior

[Marzo Sette Torres Junior]

In the wake of the bugs from the altar of the Temple of Discipline (SI) and the trapped button room in the Abandoned Outpost (SS), it has once again come to light that eggs and traps work very differently in Exult than in the original. Dominus asked me to document these in a bug report, so here it is.

The first time that the inner workings of eggs came to light was in a message I sent to the Exult mailing list: https://sourceforge.net/p/exult/mailman/message/18581220/. I am gathering this with the results of some further analysis here. The results:

(1) eggs and traps seem to work based on usecode scripts without the "nohalt" opcode (but see below): calling UI_in_usecode on an egg returns true, while calling UI_halt_scheduled on an egg causes it to stop working on the original games. Running a new script with the 'hatch' opcode after calling UI_halt_scheduled on an egg shows that this opcode sets the 'hatched' flag for non-auto-reset eggs; it also causes 'button', 'missile' and 'monster' egg types to do their thing. All other egg types (usecode, music, SFX, voice, teleport, weather) do nothing else, hence it is likely that they use the other script opcodes to do their actions. It is worth investigating if there are side effects to the Exult behavior for 'hatch' or not, and keeping it if there aren't.

(2) The "party near" and "avatar near" criteria, when combined with auto-reset, makes traps keep hatching over and over again. Eggs other than traps seem to wait for the condition to fail (e.g., the avatar go out of range then back inside) before hatching again. Also, both of these criteria seem to work identically in the original -- they both wait for the avatar.

(3) Eggs with the "something on", "avatar footpad" and "party footpad" criteria seem to be immune to UI_halt_scheduled and UI_in_usecode returns false. Working on the assumption that these eggs also work based on scripts to avoid replicating code, it is likely that their scripts are generated/executed only when something is dropped on them (but I haven't tested this hypothesis yet). These eggs only fire once when the condition is met, even if they are auto-reset; for them to execute again, you need to drop something on them again.

(4) I have reached no firm conclusions about "cached in" eggs. They don't seem to ever repeat like "party near" and "avatar near" eggs. It is likely that they just run their scripts when cached in and don't do anything further.

(5) "avatar far" criteria does not seem to work in the originals, and there seem to be no script commands that do the required condition check. Fiddling with the distance, it seems that the originals use a script opcode that should have one parameter, but is interpreted as either an invalid opcode or as a nop. I don't think it is worth breaking the behavior of this criteria to match the original.

(6) "party near" and "avatar near" music eggs that continuously loop music stop repeating the music when their condition stops being valid.

(7) Weather eggs reset the weather after their duration expires or when they cache-out; this later would imply that weather eggs use the "finish" opcode in their scripts.

(8) Trap eggs seem to always be considered as being auto-reset if they have a nonzero delay.

Note that while eggs in Exult don't NEED to use the script system like the originals do, general egg behavior should be identical to the original.

[Dominik Reichardt]

[#1865] is probably caused by this (anti magic rain problem)

[Dominik Reichardt]

[#1848] is the abandoned outpost trap bug - including savegame for Exult and the original

[Marzo Sette Torres Junior]

Recent commits fixing bugs #1848 and #1865 fixed a good deal of the issues. Remains the music egg issue. This one will require many changes in audio code to request the various drivers to stop looping the music.