InitialPayload can't always work well with map actions

[ZeroFanker]

When i am using map action 80 or 7 to create a group of taskforce , who have set of initial payloads , the payloads can't always be created , i tested many times , fond that ： if the team is created later during the game , not when the game just started , the payloads will fail to be create , i guess the FootClass_Put function is not called in such occasion ;
but if i use the condition of 13 , and present the value of zero , which means to create the team when the game just started , the payloads are created normally
I hope someone can check the game logic and the map action , though i can find other way to avoid such problem , those ways are a bit troublesome ,thank you for reading this

[mevitar (mevitar)]

The game apparently has issues spawning units with InitialPayload, and it applies not only to map actions, but AI scripts. Probably because the game thinks that it should put all the units from the taskforce inside the one with InitialPayload tag.

Also, the order of units in the taskforce might play a role here, because certain scripts with such units never fire for me, while others do it without any issues. Or it's simply limited to one unit with InitialPayload per taskforce.

This issue was discussed in this thread:
https://ppmforums.com/viewtopic.php?t=41516

[ZeroFanker (zcyfksn)]

Infact , i fixed this issue by myself in a folk version of Ares , i notice there is a method leading to such result , which is mark the varible TechnoExt::InitialPayload as true by force after the game starts for all technos , which happens when a new techno instance just inits . i have no idea why such method is applied , but you mentioned problem of AI taskforce , even after i added tags to prevent such issue , AI still works normally for me .
Maybe you can give me more instances for understanding ?

[AlexB (alexander-b)]

The comment above that line reveals it's for supporting deploying and undeploying units and "external" logics that remove and put back units onto the map again. Otherwise, it could happen that initial payload passengers are put into the unit more than once.

This is a workaround for the design problem that initial passengers aren't put into the unit when the unit is actually created, but when put onto the battlefield for the first time. As units can be put multiple times, there has to be this bool checking whether initial passengers were created once already.

I chose that design despite its obvious flaw requiring the workaround because putting in passengers into the unit when it is created would have had a bigger flaw: passengers aren't destroyed (uninitialized, deleted) when a unit is deleted right after being created. This happens if a unit can't be placed, for example. And it would create not only a memory leak, but also a potential exploit like the Invisible MCV one.