Modding, Mission Design, and Coding > Test Builds
SEXP Argument changes via mod.tbl
Goober5000:
I don't want to trivialize this sexp because I definitely agree it requires careful work to recode. I'd like to take a look at the patch though. My first impression is that you could find a way to toggle between breadth-first and depth-first iteration, but I've been bitten by hidden sexp complexities before.
In most cases, I agree that you'd just set one flag in mod.tbl and then forget about it entirely. But in the rare case where you'd need at least one of each type of iteration, you'd be stuck because mod.tbl affects every sexp in the campaign. Either they'd all iterate one way or they'd all iterate the other way.
Now I could have sworn that Scroll depended on the old way of iteration but I just searched the missions for *-argument sexps and I don't see a case where it's required. So this may not actually be a problem.
Here's one consideration I'm interested in though. What do you do for sexp trees that mix nodes that contain <argument> and nodes that don't?
karajorma:
--- Quote from: Goober5000 on January 30, 2012, 11:26:30 pm ---Here's one consideration I'm interested in though. What do you do for sexp trees that mix nodes that contain <argument> and nodes that don't?
--- End quote ---
I'm not sure what the problem would be there, you can already do that with the current implimentation.
Goober5000:
Yeah, but now the iteration order is different. Let me use an example sexp:
--- Code: ---$Formula: ( when-argument
( any-of "SFr Molech" "SFr Ba'al" )
( <
( distance "Alpha 1" "<argument>" )
1300
)
( ship-visible "<argument>" )
( change-iff "Hostile" "<argument>" )
( turret-lock-all "<argument>" )
( send-message-list
"Alpha 3"
"High"
"contact confirmed"
100
)
( ship-invulnerable "Narandum" )
( set-object-facing-object
"Narandum"
"Departure path:1"
)
)
+Name: Freighter reveal
+Repeat Count: 1
+Interval: 1
--- End code ---
Hypothetically, if Alpha 1 were to be within range of both ships at precisely the same time, then ship-visible would execute twice, followed by change-iff twice, turret-lock-all twice, send-message-list once, and ship-invulnerable once.
Now suppose we use mod.tbl. Would it be ship-visible, change-iff, turret-lock-all, send-message-list, ship-invulnerable, ship-visible, change-iff, turret-lock-all? Or would the send-message-list and ship-invulnerable execute twice? Would it be any different if ship-invulnerable came immediately after ship-visible?
karajorma:
Oh, I see the issue but I'd already considered it.
--- Quote from: Goober5000 on January 31, 2012, 11:01:30 pm ---Hypothetically, if Alpha 1 were to be within range of both ships at precisely the same time, then ship-visible would execute twice, followed by change-iff twice, turret-lock-all twice, send-message-list once, and ship-invulnerable once.
--- End quote ---
Now you'd get then ship-visible, followed by change-iff, turret-lock-all, send-message-list, and ship-invulnerable. Then ship-visible, followed by change-iff, turret-lock-all and ship-invulnerable with the other ship as the argument. You'll only get the message sent once since that SEXP contains no use of the <argument> option. If you need the message twice you should use do-valid-argument-times same as you would without the mod.tbl flag since that's what it was created for.
Goober5000:
I was expecting that I'd only get send-message once, and I hoped that would still be the case. But I was also wondering at what point send-message would be invoked. If it's only on the first iteration through the list of arguments then that answers my question.
(Also, ship-invulnerable doesn't contain <argument> either, so I'm guessing you just misread the sexp.)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version