There is nothing wrong with them there just seems to be differences in the way they work.
For example with wing beta:
when-argument
--in-sequence
---beta 1
---beta 2
---beta 3
seems to process differently then
when-argument
--any-of
---beta 1
---beta 2
---beta 3
when wing beta arrives. Just a little clarification on how each one processes might be useful.
Yes. I would expect those two to act slightly differently. In-sequence, random-of and random-multiple-of can only be true for one argument on the list at a time. Only one item can be evaluated every time the event triggers. So if I had this.
when-argument
-in-sequence
--Ship 1
--Ship 2
--Ship 3
-true
-self-destruct
--<argument>
-invalidate-argument
--<argument>
The event would need to trigger 3 times before all three ships would be destroyed. You can easily see why this is true for random-of. If it wasn't you'd ask it to pick a random ship and they'd all blow up!
Any-of, every-of and number-of work in a different way. For them, multiple arguments can be true at the same time. The code goes through the list, tests the number that are true based on the trigger and sticks the names of all the ones that are true onto a new list. Then it looks at the action part of the SEXP and processes each SEXP in order making it occur once for each argument if need be.
Internally all the argument SEXPs work the same. It just that with in-sequence and the random ones the list only ever has one item so they appear to work differently.
If they do process differently then wouldn't having the one-of do the individual processing of in-sequence but out of sequence (if that makes sense) a possibility? Or is that what you are talking about requiring major code changes to do?
It's not actually that major a change. But it would involve changing the way the loops work and that could very easily add bugs. I might as well think my way through the code publicly as that might help you understand what's going on if you look at the code itself.
If you have this SEXP
When-argument <--------------1)
-any-of
--Ship 1
--Ship 2
--Ship 3
-has-arrived-delay
--0
-self destruct <----------------2)
--<argument>
-Send-message <-------------3)
--#Command
-invalidate-argument <-------4)
--<argument>
What happens is this. Enter eval_when() at point 1. Call eval_sexp() to check if the trigger is met and the event should fire. If it is we then loop through the action SEXPs. do_action_for_each_special_argument() is called for the self-destruct SEXP to blow up all 3 ships. Eval_sexp() is then called to send the single message, then finally do_action_for_each_special_argument() is called again to invalidate all three arguments.
Now to make the one-of-any SEXP work I'd have to rewrite the order that happens in. If you look at the code that means rewriting this loop
// loop through every action
while (actions != -1) If I did that I could make all the conditionals work that way, thereby making the one-of-any SEXP unnecessary, However it would screw over any SEXP you were counting on to work the old way round. Modify-variable would be the biggest victim of this. The way the old loop worked you could modify a counter by +1 three times and then output it in a message. Changing the way things work would result in you modifying the variable once, outputting the message and then looping twice more to modify it again.
It's fixing that behaviour so that it remains consistent with what currently happens that would most likely cause bugs. It can be done but it makes things a lot more complicated because it means you have to make something happen the final time through a loop and not the first. And it still wouldn't solve the original problem.
In fact it might actually make it harder to solve.
