Modding, Mission Design, and Coding > The FRED Workshop

How do I invalidate arguments for ships that have left the mission?

(1/5) > >>

General Battuta:
I've got an event.

I want it to look at ships on an argument list. I want it to pick out ships that are still in the mission. I want it to check those ships' class, and, depending on the class, run a series of sexps on them.

How can I do this without resorting to LUA?

Spoiler:it's apparently much, much more difficult than you'd imagine?

General Battuta:
Unless I'm missing something obvious here, the problem is that every means I can find to detect that a ship is not in the mission will - once it finds a ship not in the mission - declare that ALL SUBSEQUENT SHIPS on the argument list are also not in the mission, ruining everything forever.

General Battuta:
Turns out that this problem will not occur as long as you are checking the argument ships for departure in the PARENT conditional (the outermost in any group of nested conditionals). That one is flushed properly, but nested conditionals are not.

This is all very cursed

Goober5000:
Can you post the event in question?

Phantom Hoover:
The general problem is hopefully something I can communicate: when you have (when-argument (any-of <some ships...>) <condition> <body...>), each of the body nodes will be evaluated for each valid argument for which the condition is true, right? The thing is, a lot of sexps short-circuit by returning NAN_FOREVER or KNOWN_TRUE when called on destroyed or departed ships, and the short circuiting is never reset when the argument changes. It is for the condition node, which is basically how we worked around Battuta's problem, but the fact that nodes in the body can get 'stuck' like this is a massive footgun and requires FREDders to know far too much about the guts of the SEXP evaluator to understand and avoid. I think when-argument should really just flush the tree between runs, although I'm somewhat concerned that someone has somehow made missions that rely on this bizarre behaviour.

Navigation

[0] Message Index

[#] Next page

Go to full version