View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001878 | FSSCP | FRED | public | 2009-01-28 01:07 | 2009-05-14 18:53 |
| Reporter | FUBAR-BDHR | Assigned To | karajorma | ||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 3.6.9 | ||||
| Fixed in Version | 3.6.11 | ||||
| Summary | 0001878: Has-arrived-delay <argument> only evaluating 1 of simultaneous arrivals | ||||
| Description | That'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 Information | 3.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. | ||||
| Tags | No tags attached. | ||||
|
2009-01-28 01:07
|
|
|
|
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. |
|
|
Same problem exists using every-time-argument. |
|
|
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. |
|
|
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
|
|
|
|
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. |
|
|
Changed to feature to remind me that there are still some improvements that need to be made to this code. |
|
|
Added the changes I want to. They're already in my branch and will be in trunk soon. |
| 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 |
