[IPAndrews]

I have some code that looks like this:

every of
    "capship 1"
    "capship 2"
    "capship 3"
    true
    modify-variable @Temp ( rand 0 1 )
   when ( = @Temp 0 ) ( change-ship-class <argument> "NR Bin'tak" )
   when ( = @Temp 1 ) ( change-ship-class <argument> "CR Primus" )

The idea is that each of the 3 capships is randomly changed to either a Bintak or a Primus (a silly thing to do but it's just test code, if it works I'll do something more useful with it). What happens in reality though is all the ships get assigned the same class! Anyone know how to get it to work?

Regards,
Ian

[karajorma]

The problem is not with Every-Of. The problem is that the modify-variable only gets executed once. Only SEXPs which actually include < Argument > execute more than once. Everything else executes once.

I don't think this is a bug. I think the idea is so that you can do

every of
    "capship 1"
    "capship 2"
    "capship 3"
    true
    do-something (argument)
    Send-message

If you didn't do things this way the message would be sent 3 times as well. What is needed is a new SEXP that you can plug other SEXPs into that makes them execute as often as the argument is valid. Then you could do this.

every of
    "capship 1"
    "capship 2"
    "capship 3"
    true
    Do-argument-Times (Something else)  <----------------------- Executes 3 times
    do-something (argument) <--------------------------------------- Executes 3 Times
    Send-message <----------------------------------------------------- Exeecutes once.

Furthermore I've always had real problems trying to use < argument > within a when like you are using it. I'll need to rerun the mission to see what happened but I've noted down that I got erratic behaviour when I tried it.

This is actually one of the next things on my list of SEXPs to look at, along with a proper working version of random-of and the new random-multiple-of.

[IPAndrews]

That's what I figured. Nice to have a 2nd opinion though just so as you don't know you're going insane. Back to using temporary string variables and numeric counter variables then . Messy, messy, messy.

[karajorma]

I know. I had something I wanted to do in SoR scuppered by this and it simply wasn't worth the hassle of fixing it cause it was just a minor element of the mission.

Like I said it is on the list but there are a couple of other things I want to investigate first. The fact that someone else wants it bumps it up a couple of places though

[IPAndrews]

    Do-argument-Times (Something else)  <----------------------- Executes 3 times
    do-something (argument) <--------------------------------------- Executes 3 Times
    Send-message <----------------------------------------------------- Exeecutes once.

Wow. That is so pointless .

[CP5670]

I ran into this same problem with every-time a few days ago. I guess you can get around this by simply not using every-time and just sticking with a bunch of separate events, although I have 66 arguments in one of these so it would be a little clumsy to split it up into that many.

[IPAndrews]

I ran into this same problem with every-time a few days ago. I guess you can get around this by simply not using every-time and just sticking with a bunch of separate events, although I have 66 arguments in one of these so it would be a little clumsy to split it up into that many.

Spare a thought for me. What I have presently is (in pseudo code) is:

when start of mission then capshipname = "None"

when capship 1 arrives and capshipcount = 0 ) then capshipname = "capship 1"

when capship 2 arrives and capshipcount  = 1) then capshipname = "capship 2"

when capshipname != "None" then...
  1. do a huge list of stuff for the capship
  2. capshipname = "None"
  3. capshipcount = capshipcount + 1

Now imagine this for 10 capships  . I think the problem is that when-argument/every-time-argument, and every-of don't really know what they're trying to do. Either than or the default behaviour is less than useful as it is. As I simply cannot imagine and circumstance where the default behaviour would actually be useful.

Don't get me wrong, the <argument> idea is a great one. I could use it in conjunction with a condition to say... check a huge list of ships to see which have low hitpoints and then have them send a distress signal message. Saves having to do the check for every, single ship in a seperate event. Or you can just give "true" for the condition and run some set code with a different argument each time. both of which are really useful things to be able to do but you can't do either with the sexps as they stand. So what's the point?

Kara might chew me out for labouring the point here but in all honest I'm just baffled that's all. I'd love to know who came up with these things and what they were thinking .

[karajorma]

Goober is responsible and to be honest I think he made the right call. The argument SEXPs can do both of the things you describe.

Let me give you an example

Every-time-argument
-any-of
--Ship A
--Ship B
--Ship C
--Ship D
-is-disabled-delay
--< argument >
-do-something
--< argument >
-do-something-else
--< argument >
-send-message

Quite frankly there is no easy way to send the message if the SEXP would have all nodes execute 4 times. You can't use event-true because I'm using every-time. You can't chain. The only way is to go back to modifying a variable to do a psuedo-function call.

The argument SEXPs are frequently going to be used as triggers for events too where they don't actually use the argument at all with regards to changing anything. Like this


When-argument
-any-of
--Ship A
--Ship B
--Ship C
--Ship D
-is-disabled-delay
--< argument >
-send-message
-change-iff
--Ship E
-Protect
--Ship F

etc.

In this case we haven't used the argument to change anything at all. We were just using when-argument to save having to use a giant or function to figure out when the time had come to do something. This is especially true with the number-of conditional as it is a pain in the arse to set up something like that where you want something to hapen when say 7 out of 10 ships have done something more complicated than simply being disabled.

Like I said the best way to solve this is to have another SEXP that simply triggers any nodes below it < argument > times.

[IPAndrews]

In the example you cite above wouldn't the solution be two events:

1) An event that goes true if any-of the <argument> ships become disabled... or whatever it is you're trying to achieve there.
2) A "when" event that fires off if event 1) goes true and sends the messge.

Provided event 1) goes true if any-of the <argument> related conditions go true you'll get your one message. Once again I'm baffled. I must be missing the point or something.

[karajorma]

In the first example? Nope. I'm using every-time-argument. Events using every-time or every-time-argument will never ever be true. They will always evaluate as incomplete. The only thing I can do to have a second event which is dependant on the first one setting a variable to tell it whether to trigger or not.

[IPAndrews]

Then use when-argument.

[karajorma]

Can't always do that. If you're using key-reset for instance you're buggered unless you stick it in every-time.

[IPAndrews]

Can't always do that. If you're using key-reset for instance you're buggered unless you stick it in every-time.

  Well okay put key-reset inside every-time then! Not that I have any idea what you're talking about. Look honestly. Never mind. Forget it. I'll just waste the rest of my life pissing around with stupid flag variables and numeric counters because when-argument and every-argument are stupid. I don't care. It's fun. I've been doing it for the last two hours because the latest game engine build is too smart for it's own good an  d is throwing out my last class change system. So I'm having to rework it again. It's FUN,FUN,FUN!        

[Goober5000]

Can't always do that. If you're using key-reset for instance you're buggered unless you stick it in every-time.

That point will be moot when you add key-reset-multiple.

[Roanoke]

Do you chaps find yer selves rebuilding missions when the lastest sxeps are released ? 

[karajorma]

I've never rebuilt a mission but I've occassionally built missions that I couldn't build before

[IPAndrews]

I rebuild the BHX missions every time I figure out a way to shave off a few SEXP tree nodes. It's a bit frustrating sometimes, which is why I bit Kara's head off earlier. Sorry bout that dude.

[CP5670]

I have some FS2 retail-era missions with quite a bit of legacy stuff that could be made cleaner with the new sexps, but they work just fine so I don't bother.

[IPAndrews]

Why create needless work? On that score never start making a campaign. You'd think I'd have learned from last time 

[karajorma]

I rebuild the BHX missions every time I figure out a way to shave off a few SEXP tree nodes. It's a bit frustrating sometimes, which is why I bit Kara's head off earlier. Sorry bout that dude.

That's okay. I've had days like that when programming so I recognised all the symptoms