[karajorma]

But I don't care cause those who will are likely to be very happy. While trying to fix a bug in the argument SEXPs I noticed that it should be possible to make this work.




The <Argument> being used will always be the first one encountered when working up the chain from the <argument>. You can not use an <argument> from the first SEXP in the 2nd or 3rd argument SEXPs unless you use SEXP variables to pass them downstream. You can however use them in anything else still (and that now includes when and every-time, both of which would crash the game previously).

Here's the build for those who want to play with it. If you haven't understood a word I've been on about then this probably isn't for you.

[Colonol Dekker]

Funky

Just when i get my head around Variables... Arguments throw me off agin
I'm sure this will help me get to know em.

[Topgun]

huh? so beta will self-destruct if one of the fenris's subsystems are destroyed?

[karajorma]

The SEXP itself isn't exactly doing anything interesting as such. What's interesting is the way it's working. I'm using when-argument within a when-argument. FS2_Open used to crash if you tried that sort of shenanigans before. 

[chief1983]

So is that's essentially just a when-then-when?  I'm not so amazed that you fixed it, as that something which seems fairly intuitive didn't work before.  I hope I'm understanding it, and good job for catching that, regardless.

[karajorma]

Doing the following has been possible since retail

When
-x
-When
--Y
--Do something
-When
--Z
--Do something else

In coding terms it's equivalent to

Code: [Select]


if (x) {
   If (y) {
      Do something
  }
   if (z) {
      Do something else
   }
}

As you can see that's both perfectly legal but also something coders often want to do. That has always worked. The problem was with the new -argument SEXPs Goober added. An analogy for when-argument isn't as simple but lets say using one allows us to declare a variable inside the if statement (It isn't really like that but just to keep things simple). What we had in FS2_Open would be equivalent to this

Code: [Select]

if (x) {
   int a;
 
   If (y) {
      Do something
  }
   if (z) {
      Do something to a    <-----------------------------------   a can't be accessed here so the game crashes
   }
}

As you can see it's something you might expect to be legal and is definitely something I wanted fixed.

[chief1983]

Ooooh.  Yes, very good catch indeed.

[Deckard]

Nice one!

[karajorma]

http://www.freespacefaq.com/Misc-Downloads/Builds/Argument-Changes.7z

I need someone to download and test this build in a mission or two which uses the argument SEXPs heavily. BtRL would be a good choice but anything that uses them a lot will be fine. I want reports of any reproducible crashes which don't occur in other builds (WMCoolmon's build here would be a good choice to test against if you do get a crash).

I need this tested whether or not you care about the argument stuff above as what I'm most concerned about is that the changes in this build broke something.

[Colonol Dekker]

I'm still getting to grips with SCP extras in general Karajorma, :ashamed: wish i could help.

[Zacam]

BtRL is completely unplayable with this build. The first mission alone drags on the FPS so bad, it,s like flying through syrup once the furball is on. The waypoints do not update properly, I loose targeting and any attempt to target anything gives me a "Disengaging Targeting System", so I have to eyeball it....which would be fine if it wasn't for the molasses effect.

At least it doesn't crash. I will give it that much. But then, I cannot get through the first mission.

BtRL was just installed and updated. No modifications to anything: I copied in the posted EXE from here and executed it directly.

All other builds (including the built in one) work fine.

[karajorma]

Hang on a sec. You get bad FPS in this build but get good FPS on any other recent 3.6.10 builds (for instance the one I linked to)?

[Zacam]

Yes.

_Especially_ in the first mission past training. Everything is fine up until you split to follow the waypoints.

Additionally, this build falls under Mantis 1759

[karajorma]

EDIT : Nevermind. I think I see what I did wrong.

Okay, can you redownload and test this one.

[Zacam]

Much better. Waypoints update as they should, and everything is smooth. No failures so far. Anything specifically other than BtRL I should test?

[karajorma]

BtRL was a good choice cause both myself and Axem used the argument SEXPs heavily. For instance the problem you were seeing was due to a mistake in the way the new code was handling the in-sequence SEXP and Axem's mission is probably the only released mission using that one (I don't think I even used it in my missions).

Anything with heavy use of argument SEXPs is good. Use of nested arguments like in the first post is better but obviously you'd need to build missions that do that yourself.

[Zacam]

Ka-Oh. I've got some ideas.

BTW, still affected in BtRL of jumped out ships still being targeted. I think WMC has a fix pending that. Refer to either last post on his or the above linked Mantis.

[Black Wolf]

How is this different to chaining sexps? Just more efficient in terms of sexp node usage?

[Colonol Dekker]

What would normally take fifteen sexps can now be done by one.

[karajorma]

How is this different to chaining sexps? Just more efficient in terms of sexp node usage?

It's a lot more powerful. For a start chaining events wouldn't let you do this if you wanted the event to repeat since chaining repeating events together has always been fraught with problems.

If you've ever had to do this you'll see the use

Event 1
when-argument
-list of ships
-condition
-modify variable
--variable name
--<argument>

Event 2

when
-condition
do-something to the ship in the above variable

You'll see what this change can do. Now you can avoid messing around with variables and simply have the second check inside the first event.