Hard Light Productions Forums

Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Test Builds => Topic started by: karajorma on January 11, 2012, 07:42:14 pm

Title: SEXP Argument changes via mod.tbl
Post by: karajorma on January 11, 2012, 07:42:14 pm
Here's one that probably will only affect the more advanced FREDders amongst you. The big problem with the way the argument SEXPs work for many FREDders is that the inner and outer loops are the wrong way round. The game will execute each action SEXP for all the valid arguments first and then move on to the next one. Most users are expecting the exact opposite, All of the action SEXPs for each argument and then move on to the next argument.

This build uses a argument in the newly added mod.tbl to switch the loops around. Since this problem only affects the more advanced FREDders usually, here's a little test to show exactly what I mean.

When-argument
-any-of
--Ship 1
--Ship 2
--Ship 3
-true
-modify-variable
--StringVariableName
--<Argument>
-self-destruct
--StringVariableName

Which ship blows up?

Spoiler:
Normal builds will blow up Ship 3 because they loop through the modify variable SEXP 3 times and then move on. This build will modify the variable to Ship 1, blow it up and then modify the variable to Ship 2 and then Ship 3.


http://fs2downloads.com/Misc-Downloads/Builds/Mod_Table_SEXP_Build.7z

EDIT : At the moment, mod.tbl only contains a couple of features but the basic idea is to make it the place for all those settings you set once for a mod and then never want to change again.
Title: Re: SEXP Argument changes via mod.tbl
Post by: mjn.mixael on January 15, 2012, 03:12:06 pm
Seems to work as expected.
Title: Re: SEXP Argument changes via mod.tbl
Post by: Goober5000 on January 26, 2012, 12:11:40 pm
Oh well done.  This will come in handy.

...On second thought, this would be better as an additional sexp.  There are rare instances where one needs the current behavior, and Scroll contains a few of them.  Yet the mod.tbl behavior is preferred in most cases.  Since mod.tbl would affect all sexps in the game without exceptions, could you make a new sexp so that we could have one or the other as needs demand?

Not sure what the new sexp should be called.  For-argument might be a good candidate.
Title: Re: SEXP Argument changes via mod.tbl
Post by: Fury on January 26, 2012, 12:27:47 pm
EDIT : At the moment, mod.tbl only contains a couple of features but the basic idea is to make it the place for all those settings you set once for a mod and then never want to change again.
Not in trunk yet apparently? Regardless, this has to be the best thing since porn.
Title: Re: SEXP Argument changes via mod.tbl
Post by: karajorma on January 29, 2012, 09:58:38 am
Oh well done.  This will come in handy.

...On second thought, this would be better as an additional sexp.  There are rare instances where one needs the current behavior, and Scroll contains a few of them.  Yet the mod.tbl behavior is preferred in most cases.  Since mod.tbl would affect all sexps in the game without exceptions, could you make a new sexp so that we could have one or the other as needs demand?

Not sure what the new sexp should be called.  For-argument might be a good candidate.

No, this really shouldn't be a SEXP. If you turn on the feature every single SEXP in the mission will suddenly start being processed the other way. It would be horribly confusing.

Basically this was designed the exactly the way it was so that a FREDder could set it once for a mod and then forget about it forever. Since it's just there to fix a design flaw but maintain backwards compatibility there's no reason it should be swapped around.

But what the **** are you doing that actually needs the old way round to work?
Title: Re: SEXP Argument changes via mod.tbl
Post by: Tomo on January 30, 2012, 12:45:27 pm
I think Goober means it ought to be a new SEXP that works the other way around, so existing missions that rely on the current functionality are unaffected.

I think "for-each-argument" is a better name than "for-argument", but either is good.
Title: Re: SEXP Argument changes via mod.tbl
Post by: The E on January 30, 2012, 01:21:45 pm
Existing missions are unaffected as long as this mod.tbl flag is not set. Methinks you have not understood the problem.

If you are setting this flag, it is assumed that you do so while being aware of the consequences.
Title: Re: SEXP Argument changes via mod.tbl
Post by: MatthTheGeek on January 30, 2012, 01:30:17 pm
I think Goober meant that he could use both functionalities in Scrolls, and hence that the mod.tbl setup is inconvenient.

Which brings us back to square 1 : what are you doing in Scrolls that requires the old way around.
Title: Re: SEXP Argument changes via mod.tbl
Post by: Aardwolf on January 30, 2012, 04:57:46 pm
If you are setting this flag, it is assumed that you do so while being aware of the consequences.

Haha, no. Someone will want to play X mission with Y mods, they'll drop the X.fs2 file in the Y mod folder, and they'll create all kinds of havoc in the support board.

There should be two separate sexps: one that works the old way, and one that works the new way.
Title: Re: SEXP Argument changes via mod.tbl
Post by: karajorma on January 30, 2012, 08:20:25 pm
If you want two separate SEXPs I suggest you look at the code first and then refactor the entire SEXP argument code in order to allow it. Cause coding this at the SEXP level is not a trivial problem.

But this is not "an additional SEXP" This is making new versions of every single conditional SEXP from now on. Furthermore if you use one version of the conditional inside the other version, I have no idea what would happen. Probably a crash of some sort. The whole point of the mod.tbl entry is to avoid that kind of nonsense.

The FREDder decides at the start which version of the SEXPs he wants to use. It's basically a backwards compatibility thing to make sure the change doesn't break existing missions. Unreleased mods can go through and fix their missions to work correctly. New mods should always be setting that flag. Given that I still don't know why Scroll needs the old version it's hard to see why I should change things.

Haha, no. Someone will want to play X mission with Y mods, they'll drop the X.fs2 file in the Y mod folder, and they'll create all kinds of havoc in the support board.

How is that any different to most situations where you drop a mission into a mod it's not supposed to be part of. If you're doing that, you're an idiot or you're clueless enough about how to install a mission that you're going to be a support nightmare anyway.
Title: Re: SEXP Argument changes via mod.tbl
Post by: Goober5000 on January 30, 2012, 11:26:30 pm
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?
Title: Re: SEXP Argument changes via mod.tbl
Post by: karajorma on January 31, 2012, 01:41:15 am
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?

I'm not sure what the problem would be there, you can already do that with the current implimentation.
Title: Re: SEXP Argument changes via mod.tbl
Post by: Goober5000 on January 31, 2012, 11:01:30 pm
Yeah, but now the iteration order is different.  Let me use an example sexp:

Code: [Select]
$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

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?
Title: Re: SEXP Argument changes via mod.tbl
Post by: karajorma on February 01, 2012, 04:29:33 am
Oh, I see the issue but I'd already considered it.

 
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 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.
Title: Re: SEXP Argument changes via mod.tbl
Post by: Goober5000 on February 01, 2012, 04:53:59 am
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.)
Title: Re: SEXP Argument changes via mod.tbl
Post by: karajorma on February 01, 2012, 06:39:16 am
Yeah, I wasn't looking carefully and assumed that was why you asked about swapping those two round. :)

To be honest the main time you're really going to see much of a difference is in cases like the example at the top of the page. Anything to do with variables is going to have a different result. But that's kinda the point of the change. :)
Title: Re: SEXP Argument changes via mod.tbl
Post by: Goober5000 on February 03, 2012, 02:36:57 am
Cool. :)

I'm going to tentatively assume this won't be a problem for Scroll, and if any problems come up in the future I'll just find a way to work around them.  I'd like to take a look at your patch before you commit it though.
Title: Re: SEXP Argument changes via mod.tbl
Post by: General Battuta on November 26, 2020, 11:51:05 am
Think I'm going to have to switch all of BP to this :negative:
Title: Re: SEXP Argument changes via mod.tbl
Post by: karajorma on December 09, 2020, 10:20:40 am
Did you run into a problem because of it? Or just pre-emptively.
Title: Re: SEXP Argument changes via mod.tbl
Post by: General Battuta on December 09, 2020, 11:40:34 am
I was working on an event that relies on variables to hold argument names, so yeah, the old way definitely would've broken.

I guess that's pre-emptive. I haven't actually tested whether our missions still work after the swap...