When changing ACTION -> 'FLAG ON' to 'FLAG OFF' or vice versa, it wipes out the previously set Flag Name back to a number '1'.

[TEMPEST.114]

This doesn't (thankfully) happen when changing the CONDITION -> 'FLAG IS FALSE' to 'FLAG IS TRUE' and vice versa.

Seems to be localised to the ACTION only.

[Flappie]

I'm sorry, I don't understand how to reproduce this bug. Can you please provide a .miz file demonstrating the issue?

[TEMPEST.114]

3 hours ago, Flappie said:

I'm sorry, I don't understand how to reproduce this bug. Can you please provide a .miz file demonstrating the issue?

It's not a .miz - it's a Mission Editor bug.

1. Create a trigger with an action of FLAG IS ON

2. Name the Flag.

3. Realise you didn't mean ON and wanted OFF instead.

4. Change the action FLAG IS OFF

5. Notice the M.E. obliterates the name of the flag and returns it to a name of '1'.

6. Give it the correct name again.

7. Realise you actually did want ON instead of OFF.

8. Change the action to FLAG IS ON.

9. Notice the M.E. Resets the name back to '1' again.

 

NOW.... before the devs say this is 'correct'....

 

10. Create a CONDITION - FLAG IS TRUE

11. Give it a name.

12. Realise you actually wanted FLAG IS FALSE

13. Change the CONDITION.

14. NOTICE HOW THE NAME PERSISTS!!! THIS IS CORRECT BEHAVIOUR. 

The wiping out of the name for the ACTIONS is a bug.

 

 

[Flappie]

Oh right, I see it now. Thanks!

I see FLAG INCREASE/DECREASE are also affected.

Issue reported.

[TEMPEST.114]

3 minutes ago, Flappie said:

Oh right, I see it now. Thanks!

I see FLAG INCREASE/DECREASE are also affected.

Issue reported.

Yes, it seems EVERYTHING in ACTION related to flags does it but NOT the CONDITIONS, thankfully.

 

Thanks @Flappie

[TEMPEST.114]

@Flappie Just found out this exact same bug is happening for ALL ACTIONS within the same 'context.

 

i.e. all RADIO MENU Add/Remove do this bug.

All Picture To (Unit/Group/Coalition) do this bug.

There seems to be a bug when changing ACTION  from one option (within the same context) to another, it resets everything.

 

Do you need this as a new bug or because it's related but now a LARGER issue, that is common to all ACTIONS it's okay here?

Edited May 7, 2024 by TEMPEST.114

[Flappie]

No, I'll edit the existing report, thanks.

[Flappie]

Believe it or not, I was told the Conditions behaviour is not a feature but a bug. The same "bug" got fixed in Actions a few years ago because it was messing with other parts of the sim.

I've just asked not to fix the Conditions "bug", as long as it does not break anything, so we can keep enjoying its benefits.

[TEMPEST.114]

/smh...

[virgo47]

14 hours ago, Flappie said:

Believe it or not, I was told the Conditions behaviour is not a feature but a bug. The same "bug" got fixed in Actions a few years ago because it was messing with other parts of the sim.

I like this "bug" a lot when changing conditions... it's a small but nice life-quality feature. Hopefully, they can make it work in actions as well without "messing with other parts".

[TEMPEST.114]

7 hours ago, virgo47 said:

I like this "bug" a lot when changing conditions... it's a small but nice life-quality feature. Hopefully, they can make it work in actions as well without "messing with other parts".

It's changing an ACTION for a specific TRIGGER... there is nothing I can think of that would affect ANYTHING else in the back end. They know something we don't or something is lost in the Chinese whispers, 'cause that doesn't make any sense...  but if it's the former, then the 'architecture' is f***ed. 

Edited May 9, 2024 by TEMPEST.114

[virgo47]

15 hours ago, TEMPEST.114 said:

It's changing an ACTION for a specific TRIGGER... there is nothing I can think of that would affect ANYTHING else in the back end. They know something we don't or something is lost in the Chinese whispers, 'cause that doesn't make any sense...  but if it's the former, then the 'architecture' is f***ed.

I fully understand why it can't may be nontrivial really. Just because we see virtually the same set of parameters (sometimes some go away, e.g. between FLAG IS TRUE or TIME SINCE FLAG there is additional time) it doesn't mean the dialogs are designed to share the info, it can even be programmatically a different piece of input (and perhaps if it isn't, that's what caused the problem, just speculating here).

Also, if I first chose a wrong action/condition accidentally (non-flag) and then another one with the flag, it would be nice to see the original values - and it works this way in conditions. E.g. after going through a few completely different actions, if I return to FLAG EQUALS FLAG, both flag name inputs are preserved. The UX question then is: If I switch from condition FLAG IS TRUE with 6 to FLAG IS FALSE and change it to 5... what should happen after I change the type to FLAG IS TRUE? Currently, the new 5 stays there, which is probably what we want when working with flags. But if we looked at each set of parameters for each TYPE as a separate subdialog, then seeing 6 would also make sense. Finally, these are not even dialogs, it's just a bunch of inputs, no confirmation, whatever you do is applied. I guess all this affects what is possible and what is difficult to implement in ME.

I'll not comment on the architecture of ME.

Edited May 10, 2024 by virgo47

[TEMPEST.114]

6 hours ago, virgo47 said:

I fully understand why it can't be nontrivial really. Just because we see virtually the same set of parameters (sometimes some go away, e.g. between FLAG IS TRUE or TIME SINCE FLAG there is additional time) it doesn't mean the dialogs are designed to share the info, it can even be programmatically a different piece of input (and perhaps if it isn't, that's what caused the problem, just speculating here).

Also, if I first chose a wrong action/condition accidentally (non-flag) and then another one with the flag, it would be nice to see the original values - and it works this way in conditions. E.g. after going through a few completely different actions, if I return to FLAG EQUALS FLAG, both flag name inputs are preserved. The UX question then is: If I switch from condition FLAG IS TRUE with 6 to FLAG IS FALSE and change it to 5... what should happen after I change the type to FLAG IS TRUE? Currently, the new 5 stays there, which is probably what we want when working with flags. But if we looked at each set of parameters for each TYPE as a separate subdialog, then seeing 6 would also make sense. Finally, these are not even dialogs, it's just a bunch of inputs, no confirmation, whatever you do is applied. I guess all this affects what is possible and what is difficult to implement in ME.

I'll not comment on the architecture of ME.

From looking at the code for the the ME dialogs and panels and input fields, the suggestion that keeping the same variable in the input box in the ME dialog will break something in the back end is nonsense. We're just talking about a UI facing box. This is the problem with the 'architecture' of the ME. Everything is so tightly coupled, that there is little to no separation of the data model, from the UI logic to the View (software engineering terms). This is what I meant about the architecture of the M.E. and game engine.

Either way, what we are shown in the M.E. when we change FLAG ON to FLAG OFF, should keep the name of the flag variable. If they need to do something else in the background to not break the back end when changing from one to the other - then that's their issue to deal with in the data model. It shouldn't affect the actual model logic, because we can just change the variable name again and everything is fine. There is no reason why the VIEW/VIEW MODEL can't do that for us.

I wonder how much of this is tech debt and spaghettification and no-one wants to touch anything for fear of unknown consequences?

There shouldn't and I really can't believe there are ANY consequences for this. Otherwise when we change the name back, things should break right?