Using multiple transports with repeat load/unload

[Dragon45]

... over the same area leads to problems. I just had a game where I had several factories sending units all to the same area. I had exactly 9 transports on a group load/unload over that area to drop them, as they came, into another area. I expected that I could leave that area alone for ten minutes and return to see 50 units halfway across the map.

I saw about five. Basically, the transports were stuck. They kept trying to land on same unit or something, and as result, were stacking on top of eahc other and jamming and not getting anything done.


I think it is a problem with way engine assigns area commands to units general - similar problems exist with reclaiming trees over area if you select multiple con units and give them same command at same tim; but it gets very annoyingly pronounced with many many many units; the system doesnt scale.

I'm wondering if this might best be solved with a "multi-task assignation" Group AI. Simply changing the way the engine assigns individual commands based on an area specification would not scale well, and especially if sometihng like 6 units trying to be picked up by 10 transports happened.

AA btw; but problem is common on XTA too from what I've seen. Prolly problem across all mods

Posted here because it sorta doesnt fall into exactly one category.

[Myg]

Dragon, my clan and I looked into solving this problem and we came up with the workaround (if your interested). I do understand that your talking about the AI also, but this is the only answer I can provide, concerning.


This is how you do it:
(for newbies to understand too)

- Turn repeat on for all Transports

- Assign the area for loading as waypoint 1

- Assign the area for unloading as waypoint 2

- Assign a "standby" area, using the line command, near to the loading area, as a 3rd way point. (This avoids the problem you describe)

[Pxtl]

I see this too often: stupid behaviour = we need a new option. We don't need a new option - we need the default behaviour to work intelligently. If a unit has two modes "be stupid" and "don't be stupid" it should automatically be on "not stupid" and the "be stupid" code should be eliminated. Likewise, if group load/unload misbehaves, the solution is not new groupAI, but to fix the main AI.

[Dragon45]

The "AI" as it exists right now simply assigns each individual unit the same pattern (some sort of counter clockwise pattern) of units the designated area for ANY command, AFAIK. It's not even an AI per se; i l lhave to get latest source and see what is actually is to see how it literally works.

Well that's an intersting workaround for time being, and it does work - BUT

ultimately problem still remains that when multiple units are assigned to same task simluatneously over area, engine assigns them all exact same carry-out sequences for objects in that area.

This isnt something that can be fixed by anything *other* than a real AI to sort out uniuque assignations for tasks per unit that is present to carry out that task - it has to make sure that transports dont collide trying to take same unit, basically. A basic, stupid AI it would be, but it would have to be an AI nonetheless.

The bigger problem would come in having to manually assign each transport to a group and then assign that local group to an AI. it gets ugly and cumbersome and becomes useless micro very quickly. I think AF wanted this earlier (and still wants this too); change in AI interface so AIs can be dynamically assigned upon event occurence

(unit creation - metal makers automatically assigned to metal maker AIs;

one flavor of area-command-with-group AI assigned if noncumulative command is present, like transport or reclaiming;

another flavor of area-command-with-group AI assigned if cumulative command is present, such as repairing or rezzing).

[mongus]

area load, if you have selected several transports, or even if you added them manually, does not assign 2 transports to load the same unit.

Something else must be happening.

[j5mello]

i have not had this problem yet. I use transports in E&E a lot and they respond as they should:

Each one gets assigned a unit within the "loading Zone" and goes on their merry way.

the method Myg mentioned is the premier air taxi method i use.

[Felix the Cat]

This would be fixed if mod makers were able to create a DLL to override the default core unit behavior with custom behavior on a per-unit basis.

[Dragon45]

A super scripting language, not a DLL... DLL means solid programming knowledge. LUA means easier.

[jcnossen]

This would be fixed if mod makers were able to create a DLL to override the default core unit behavior with custom behavior on a per-unit basis.

Then we break mods almost every release because of C++ ABI changes, just like we do with AIs now.

[Felix the Cat]

This would be fixed if mod makers were able to create a DLL to override the default core unit behavior with custom behavior on a per-unit basis.

Then we break mods almost every release because of C++ ABI changes, just like we do with AIs now.

Oh.

That sucks.

Any way to work around that? I suppose with a scripting language?

@Dragon, I know full well what a DLL is, thank you.