They do not burrow or attack despite enemies walking past or attacking them.
(Except Lurkers; they burrow, but don't attack)
I have not found any similar threads which attempt to resolve this phenomenon and so I am posting my own findings here to anyone that may find it useful.
My apologies in advance if this thread is inappropriate.
I am also attaching an example map which I hope illustrates the problem and a potential solution.
______________________
* * * The Glitch * * *
______________________
The glitch occurs when a computer player is given more than 1000 regular units[men] to control.
Unique units such as heroes are exempt from this since computer players usually do not exert any kind of command or control on them.
The first 1000 units given to the computer behave normally and as expected. They burrow or attack when appropriate. They are "active".
However, any regular units given to the computer after these first 1000 are no longer managed by the computer. They do not burrow or attack even in the presence of enemy forces or under fire.
If given an order via triggers, such as "Order:Attack" or "Send All Units on Random Suicide Mission", they will behave as expected until their order is complete.
Once they return to their "idle" state (standing), they resume their "passive" behavior and do not react to stimuli.
This poses a problem to UMS maps which potentially spawn thousands of computer units over the course of the game. Once the first 1000 computer units have spawned and died, any computer units afterward will be "passive".
There is a notable exception, however: "Active" units which are dead/removed can be "reused" if another of the same unit is spawned in the exact same location as the original.
Thus, maps which consistently spawn the exact same units in the exact same location may remain unaffected by this phenomenon.
This describes the general "rules" for computers receiving units via Trigger:CreateUnit().
Computers receiving units via Trigger:GiveUnit() seem to follow similar rules/restrictions.
GiveUnit() is treated as CreateUnit() in a manner where the given unit is "created" for the computer at wherever the unit happens to be located.
________________________
* * * Example Map * * *
________________________
The attached map illustrates this phenomenon by allowing the player to spawn their choice of 1300 computer infesteds/zerglings/lurkers.
Burrow is pre-researched to allow the player to see which computer units are "active" or "passive".
Only the first 1000 computer units will burrow.
The difference in behavior can be seen simply by approaching or attacking them.
As described before, "active" units which are dead/removed can be "reused".
Removing/Spawning the same type of unit will always yield 1000 "active" units since they are spawned at the same spot and of the same unit type.
However, spawning any other unit type results in 1300 "passive" units.
The Reset beacon is the proposed solution to this glitch. It will attempt to reset the AI, thus forcing the computer to "recycle" any dead/removed/non-existant active units.
These "recycled" entries can then be applied to any unit of any type spawned in any location as it originally was at the start of the game.
However, the 1000 unit-cap is still present. The computer will not "manage" more than 1000 idle units.
___________________________________
* * * Explanation of Solution * * *
___________________________________
After experimenting with various ways of "reusing" active units that have died, I found that running a typical melee AI script "recycled" the active-unit entries, allowing the computer to control brand new units.
I have chosen to use the AI script: [Brood Wars - Terran 2 Town B] for this purpose since the script doesn't appear to do anything besides filling nuke silos and gathering resources.
It would have minimal impact for any situations in which the computer actually possesses buildings/factories.
Edit: The AI requires several milliseconds to operate before it can fully perform a "recycle".
If using, hyper triggers, you must wait for an entire new hyper-trigger cycle to pass after calling the AI before newly spawned units can use the recycled slots.
Area-Town scripts which are solely for mining do not appear to work.
As long as the computer owned at least one unit, the AI script would "recycle" when called.
However, calling the AI script only works once.
As an example, one could create 1000 "active" infesteds, kill them, call an AI script, and then spawn 1000 "active" zerglings. But if one were to kill those 1000 zerglings, call the AI script again, and spawn 1000 lurkers, the lurkers would be "passive".
The 1000 zerglings have not been "recycled".
The last part of the solution attempts to "terminate" the script before calling it again.
My reasoning is that by tricking the script into believing it is defeated in melee, it will "end" the script and allow the next script to run anew.
To simulate this, the computer must own a regular building if it does not already have one. Then all buildings belonging to the computer are taken away.
Once this is complete, the new script can be called.
I am not sure if Starcraft actually operates this way, but it does seem to have an affect as shown in the attached map.
The Reset beacon provided performs this operation and should allow the player to continually "recycle" and respawn different unit types.
Edit: All computer players seem to share from the same pool of 1000 active units.
It is possible for a single computer player to use up all 1000 and leave none for other computer players.
Each computer player should "recycle" their dead active units on their own.
A computer player cannot "recycle" for another computer player.
Any structure, including beacons, owned by the computer must be taken away to "terminate" the AI.
Edit#2: There is a memory address at 0x00685100 which appears to be directly related to this phenomenon. It seems to be a pointer of some kind.
This address has a starting value of 6804480 and increments by 32 for each active unit assigned.
Once all 1000 active units are created, this address zeroes out.
This address is not a counter. Its value corresponds to the next available/empty active-unit slot to be created.
Thus, if one were to create a unit, if the next slot is already in use, the address will not simply increment by 32. Its value will match the first empty slot in the array of active-units.
Edit#3: Tested how many hyper trigger cycles must pass before AI completes "recycle".
Must wait for a full hyper-trigger cycle after calling the AI script before new spawns can use recycled slots.
Attachments:
Post has been edited 3 time(s), last time on Jan 7 2014, 7:24 am by ArcticCerebrate.