View Issue Details

IDProjectCategoryView StatusLast Update
0001878FSSCPFREDpublic2009-05-14 18:53
ReporterFUBAR-BDHR Assigned Tokarajorma  
PrioritynormalSeverityfeatureReproducibilityalways
Status resolvedResolutionfixed 
Product Version3.6.9 
Fixed in Version3.6.11 
Summary0001878: Has-arrived-delay <argument> only evaluating 1 of simultaneous arrivals
DescriptionThat's a mouthful. Breaking it down I'm using when-argument to see how many ships have arrived out of a group that may or may not arrive like this:

when-argument
-->any-of
---->Beta 1
---->Gamma 1
---->Delta 1
-->has-arrived-delay
---->0
----><argument>
-->modify-variable
---->ships
------>+
-------->ships
-------->3
-->invalidate-argument
----><argument>
repeating 9999999
delay 0 (also tried 1)

The problem occurs when the 3 wings of fighters arrive at the same time. It only evaluates 1 of the 3 and ignores the rest. If I change the arrival to be 1 second apart then it will evaluate all 3. That's not a real solution since the same thing could happen for other waves.
Additional Information3.6.10 r5052. Attached mission has 3 wings arrive at 10 seconds. It just sends a message with the lead ship of the wing that has arrived. If you change the arrivals to 9, 10, and 11 seconds then it works.
TagsNo tags attached.

Activities

2009-01-28 01:07

 

1878.fs2 (8,009 bytes)

FUBAR-BDHR

2009-01-28 01:08

developer   ~0010617

Last edited: 2009-01-28 06:41

Forgot to add this may be happening with is-destroyed-delay but I haven't confirmed that yet.

I have now confirmed that 2 ships destroyed at the same time cause the same issue with is-destroyed-delay. Not only that but I've confirmed that it can happen in normal game play and I just had it happen 3 times in one mission.

Seems that as long as there are 2 log file entries in the same second it will only process one of them.

FUBAR-BDHR

2009-01-29 04:18

developer   ~0010624

Same problem exists using every-time-argument.

karajorma

2009-02-01 17:45

administrator   ~0010633

The test mission is different from what you wrote here. You have this

$Formula: ( when-argument
   ( any-of "Beta 1" "Gamma 1" "Delta 1" )
   ( has-arrived-delay 0 "<argument>" )
   ( modify-variable
      "@arg[<Default Value>]"
      "<argument>"
   )
   ( send-message
      "#Command"
      "High"
      "test"
   )
   ( invalidate-argument "<argument>" )

Which results in the message being sent once with Beta 1 as the value of the variable. This is exactly what I would expect to happen. Only SEXPs that contain <argument> will occur 3 times. Everything else will happen once. Being able to get them to occur multiple times was actually one of the major reasons for making nested arguments.

Similarly if you change the arrival times the SEXP will trigger 3 times not just once and you'd get all 3 messages sent.


For the initial report the value of Ships is important. It should be 3 if all the ships arrive at the same time. If they arrive separately then it will be 9.

FUBAR-BDHR

2009-02-01 18:41

developer   ~0010634

Last edited: 2009-02-01 18:45

Maybe I'm just not understanding something correctly then. If you have when-argument and it's repeating shouldn't it evaluate "Beta 1" "Gamma 1" and "Delta 1" even if it only sends the message once?

The actual idea is to have it count the wings that arrive and add the number of ships to a variable. Then do the same with is-destroyed-delay to determine when all ships are wiped out.

So basically it's

when-argument
--any-of
----Alpha 1
----Alpha 4 (3 ships per wave)
----Beta 1
----Beta 4
etc with the first ship in each wave listed.
--has-arrived-delay
----0
----<argument>
--modify-variable
---->enemy
---->enemy + 3
--invalidate <argument>
repeating 999999

Are you saying that even though has-arrived-delay Beta 1 is true it will not add 3 to enemy because argument isn't listed in that sexp?

I uploaded the mission with the actual events. The messaging is just there for testing. It is a TBP mission but you don't have to actually run it.

2009-02-01 18:44

 

pob01b.fs2 (94,836 bytes)

karajorma

2009-02-02 12:22

administrator   ~0010639

Last edited: 2009-02-02 13:27

Yep. It will add three for the first ship it encounters but the others won't add any more this time the SEXP triggers.

The way that the SEXP works is this. In eval_when() the SEXP check to see if it is triggered. It then starts working out what to do with the action operators. It checks each node to see if they contain <argument> using special_argument_appears_in_sexp_tree() and if it does it then calls do_action_for_each_special_argument(). That function then makes the SEXP occur once for every valid argument.

If special_argument_appears_in_sexp_tree() returns false eval_sexp() is called instead. This means that the SEXP only happens once. Mantis 1867 (Your problem with string-equals) was due to the SEXP only being called once even if you used <argument>. Talking about this has made me realise that a better solution for when and when argument within an argument is really needed. I think I'll post on the FREDding forum and get opinions.

But as your SEXP as written it is doing exactly what I'd expect it to do.

karajorma

2009-03-01 19:53

administrator   ~0010700

Changed to feature to remind me that there are still some improvements that need to be made to this code.

karajorma

2009-05-14 18:53

administrator   ~0010904

Added the changes I want to. They're already in my branch and will be in trunk soon.

Issue History

Date Modified Username Field Change
2009-01-28 01:07 FUBAR-BDHR New Issue
2009-01-28 01:07 FUBAR-BDHR File Added: 1878.fs2
2009-01-28 01:08 FUBAR-BDHR Note Added: 0010617
2009-01-28 06:41 FUBAR-BDHR Note Edited: 0010617
2009-01-29 04:18 FUBAR-BDHR Note Added: 0010624
2009-02-01 14:38 karajorma Status new => assigned
2009-02-01 14:38 karajorma Assigned To => karajorma
2009-02-01 17:45 karajorma Note Added: 0010633
2009-02-01 18:41 FUBAR-BDHR Note Added: 0010634
2009-02-01 18:44 FUBAR-BDHR File Added: pob01b.fs2
2009-02-01 18:45 FUBAR-BDHR Note Edited: 0010634
2009-02-02 12:22 karajorma Note Added: 0010639
2009-02-02 13:27 karajorma Note Edited: 0010639
2009-03-01 19:52 karajorma Severity major => feature
2009-03-01 19:53 karajorma Note Added: 0010700
2009-05-14 18:53 karajorma Status assigned => resolved
2009-05-14 18:53 karajorma Fixed in Version => 3.6.11
2009-05-14 18:53 karajorma Resolution open => fixed
2009-05-14 18:53 karajorma Note Added: 0010904