Problem (bug or voluntary situation ?) in unit scripts

[welk]

Working on a "unit script" in my modding work, I noticed that editor script does refuse absolutly the value 2 in this line:
#TYPE=
Each time I set 2, it reports an error
Each time I set 0,1 or 3 : no any problem

To be sure, I opened the vanilla campaign Storm Europe, I registered it under a new name, then I opened the unit script of the campaign and in the first script (reproduced below), and I changed 1 to 2 for #TYPE=

My unic modification was to change "1" in "2" for the line #TYPE= , I did not change anything else

Result was same like in my own campaign : Editor did report a script error and did not accept "2"

I noticed that in all vanilla units scripts, the line #TYPE= has never the value = 2

Is it a bug or a voluntary situation ? I don't know, I report it in case of utility
Perhaps, is it not a bug, but a voluntary decision to exclude 2 as value for unit scripts ? In this case, It should be good to inform users about this restriction

The actual documentation for unit scripts do not give any alert about that : the doc text is that (like all other scripts):
#TYPE= Values range [0, 3];
; With all other fields satisfied will this be:
; 0 = Single check regardless if #TRIGGER is satisfied
; 1 = Multiple check until #TRIGGER is satisfied
; 2 = Reoccuring check until end of game
; OR
; Once the #DATE field is satisfied:
; 3 = Event fires once if all other fields are satisfied, else it will not fire. Either way, event will be removed never to be looked at again



REPRODUCTION OF VANILLA UNIT SCRIPT (The first in UNITS SCRIPT)
This version has no any problem
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; UK Decision Events
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
;REMOVE1941
{
#NAME= DE 100 - The Large Destroyer Triomphant Serves As A Light Cruiser In The UK
#POPUP= <<TAG_1>>
#IMAGE= triomphant.png
#SOUND=
#FLAG= 1
#TYPE= 1
#AI= 0
#LEVEL= 0
#GV= 1[1,100]
#LINK= 100[1]
#COUNTRY_ID= 112
#TRIGGER= 50
#PRIVATE= 0
#DISPLAY_TURN= 0
#FULL_RESEARCH= 0
#DATE= 1940/09/01
#FAILSAFE_DATE= 1948/01/01
#DESTINATION_RESOURCE= 136,69
#DESTINATION_RESOURCE= 137,80
; UK politically aligned with Allies and not surrendered
#VARIABLE_CONDITION= 112 [2] [100] [0]
; Dummy condition position (always satisfied)
#CONDITION_POSITION= 0,0 [0,0] [0,0] [0] [0]
#UNIT= 39 [5] [0] [FNFL Triomphant]
}

But if I just change 1 to set 2, I obtain a error report in editor, with this below version (that is exactly the same, except I set 2 in place of 1 in the concerned line #TYPE= )
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; UK Decision Events
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
;REMOVE1941
{
#NAME= DE 100 - The Large Destroyer Triomphant Serves As A Light Cruiser In The UK
#POPUP= <<TAG_1>>
#IMAGE= triomphant.png
#SOUND=
#FLAG= 1
#TYPE= 2
#AI= 0
#LEVEL= 0
#GV= 1[1,100]
#LINK= 100[1]
#COUNTRY_ID= 112
#TRIGGER= 50
#PRIVATE= 0
#DISPLAY_TURN= 0
#FULL_RESEARCH= 0
#DATE= 1940/09/01
#FAILSAFE_DATE= 1948/01/01
#DESTINATION_RESOURCE= 136,69
#DESTINATION_RESOURCE= 137,80
; UK politically aligned with Allies and not surrendered
#VARIABLE_CONDITION= 112 [2] [100] [0]
; Dummy condition position (always satisfied)
#CONDITION_POSITION= 0,0 [0,0] [0,0] [0] [0]
#UNIT= 39 [5] [0] [FNFL Triomphant]
}

[BillRunacre]

It is news to me that this does not work, though on the other hand, it might be hardcoded to prevent the script from firing every turn, i.e. under what circumstances might a unit deploying every turn be desired?

[welk]

I wanted to use that because I will implement air drop of supply units in the game (for my ASL Tactical Command mod).

It would have been interesting to have some regular air drops on map without to have to create lot of scripts. But it's a minor detail, I just wanted to know if it was a bug or a voluntary situation, I will use specific scripts to avoid the problem

[Hubert Cater]

Thanks for the report and you are correct, UNIT scripts support #TYPE values 0, 1, and 3 only.

Type 2 is deliberately disabled because unit events consume their unit list when deploying units, making repeated execution unsafe, e.g. can lead to crashes.

The header section for UNIT events just needs to be updated on our end to reflect this.

[welk]

Ok, thanks Hubert.

As paranoïac, I have now the definitive proof that you are a Vietminh agent, because you have made all in SC to block air drop reinforcement units in Dien Bien phu and Koera : Everything was premeditated since 1939

[Hubert Cater]

I have to admit, that actually made me laugh, well done

[Ason]

Thanks for the report and you are correct, UNIT scripts support #TYPE values 0, 1, and 3 only.

Type 2 is deliberately disabled because unit events consume their unit list when deploying units, making repeated execution unsafe, e.g. can lead to crashes.

The header section for UNIT events just needs to be updated on our end to reflect this.

Oh that is scary... I thought surely the script would give error if having 2 units with the same name in there was a problem..
I think it would be a good idea to have the script check for this and give error instead of finding it out on turn 40 via a crash

But maybe I misunderstand and having 2 units with the same name spawned by unit script isnt an issue ?

[El_Condoro]

; Unit names are optional but if entered and a duplicate name is found to exist for #COUNTRY_ID it
; will be skipped. Othwerwise if no name is specified, i.e. [], then appropriate names from the
; existing unit build lists will be used instead.

So there won't be two 'Rommel's on the map by there can be multiple unnamed HQs spawned up to the build limit, for example.

[Hubert Cater]

To clarify, naming is not the issue as noted above, it is just how the event is structured by the game code/engine, e.g. a list is created/stored at event creation time with the units to be deployed by script, and this list is emptied as the units are deployed... so a subsequent pass would be on an empty list as the units have already been placed.

It would just need a re-design/re-think as a type=2 would have to handle it differently

[welk]

One simple solution could be the following, keeping the same system (no any obligation to change all) :

When the first initial list is empty, due to the reiteration of the type 2 script, the script simply re-take the same first initial list and does apply it.
And when this "second" list is also empty, the script re-takes the initial first list, and so until end.

In this perspective, would be better to implement a "end date" for the script, to allo the user to give a "limite date" for script apply if he wants.

In general matter :
1°/ I think that all scripts should have a "end limit date" (a "fail date" line), would be great
2°/ I did never understand why lines commands of scripts are so dispersed in different scripts types
In my opinion, ecah script would should contain all command lines, with that the script system would have more flexibility. And when user does not want to use a specific command line, a special sign (by example : "= %!" or other same) could exist and could be used by users to "cancel" this command line (to order to the script program to ignore the concerned line)

[Hubert Cater]

The initial design had much more similarity in terms of functionality, then some scripts were found lacking and new features/options were added, that were not necessarily needed elsewhere... at first.

Over time it has indeed become a bit disjointed, and aligning all of the script options just takes time, and there is the concern of backwards compatibility, and the inconvenience to modders to constantly have to update their scripts as features are added and the compiler complains about things missing etc.

Not saying this is a reason to not do it, that is just the history over time sort of thing

[welk]

The solution could be perhaps to do a specific version for each modder

[Hubert Cater]

Ummmm.... lol

[Hubert Cater]

I've worked out a draft to allow for Type=2 for the next updates

[welk]

Nice new, thanks
It will be very usefull in battles scenarios (example : to provide reinforcements with some regularity, without to have to create lot of scripts)