Scripting Enviroment method .createDelayedClientGroup, and some general improvement to the scripting environment

[esb77]

If making a multiplayer mission with a client delayed activation group, if you call .activateGroup it can't activate the client group because the group table doesn't exist yet.

There are workarounds, but the amount of workaround needed to perform a fairly basic mission function, spawning a player controlled group at a specified time or condition, is pretty ridiculous.    If you're asking a mission maker, "What's a fairly challenging scripting task," I would argue that, "Spawning a player controlled unit in a multiplayer mission," should absolutely not be an answer to that question.

Ideally, .activateGroup would just work when fed from Group.getByName(groupname) with no other intermediate steps needed, but there are legitimate reasons one might not want to create a group table for a group that may never be occupied.   A method to look up a delayed activation unit placed in the Mission Editor and take its name to generate a group table that .activateGroup can take as input would be a reasonable intermediate solution.

 

More generally, the biggest criticism I have of the Mission Editor and DCS Scripting Environment is inconsistent behavior across single player and multiplayer missions, and limitations of methods where the limitations are obscure and difficult to figure out.

Using delayed activation and .activate as examples, if they were called SinglePlayerAI_UnitDelayedActivation and .activateSPDelayedGroup, then I'd have less of a problem with them.   They'd then consistently and reliably do what they say they do, and instead of generating grumpy mission coders wondering "Why does this method not work," you'd instead get requests along the line of, "Hey, that's a nice function, do you think you could make a multiplayer version too?"   I know that there's good reason not to change names of existing methods to avoid, so making an effort to upgrade existing methods that aren't general in how they act across SP an MP to be general would be good, and then going forward, if new limited use methods are created, reflect that in the naming.  Then if they are later upgraded the upgraded version can be named without an indication that it's limited scope.