Starting this thread to address the issue in which newly spawned computer units with no orders (idle/standing) behave abnormally.
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.

This sounds like a broader but related issue that I describe in this post here: http://www.staredit.net/topic/5902/#221693

Specifically for my purposes, it is impossible to 'order' lurkers to attack because they can only do it while burrowed, and it's impossible to order them to burrow. All you can do is 'let' them burrow, at which point they will automatically attack. I found that giving units between the P9-11 'blind' players and then to genuine CPU players seemed to eventually 'corrupt' the CPU players and the units would behave as if they were blind and couldn't attack.

Note that I focussed solely on lurkers (because all other units in my map are managed by the Patrol order) and that I found the error occurred at approx 400-600 units being given to the CPU, rather than 1000 as you've identified with your issue.

I think the issue you've identified probably does affect my map (Desert Strike Night Fixed) but not in generally obvious ways. However one particular bug-bear is that the Arbiter (mothership) very seldom actually attacks enemies; although it will use stasis a lot. It also tends to shoot less over time, so this could be the root cause of that problem.

The thread you linked to was actually one of the first I read when the "unconscious" problem began affecting my own map.
Unfortunately, none of the solutions in that thread could resolve the issue in my own tests and so I created this thread after discovering what I believe could be a viable solution to this phenomenon.
However, I have yet to receive verification whether the example map and the included solution works on other Starcraft clients besides my own, so I am still in-the-dark whether this is a genuine fix.

* * * * *

For your situation, I think I should re-word what I wrote earlier: the computer appears to reserve 1000 "active-unit" slots which it assigns to any "regular" unit it receives.
Giving these regular units orders such as patrol will not "free up" the slot.
Killing these regular units does not "free up" the slot either.
The only time the slot can be re-used is if the unit has died and is respawned with another of the same type in the exact same location as the original.
Because of this, even if all other units besides the lurkers are on patrol-order, if any of them are regular units (marines, hydras, etc.) they will use up "active-unit" slots regardless. There would be fewer slots available for your lurker-spawn to utilize.

* * * * *

But to fully test the issue, I have created a second test map, this time specifically using just one lurker and utilizing give-unit(). The "blind" players are not used in the give-unit() swaps.
Instead [Neutral], player12, is used for the give-unit() swap as was suggested in the older thread you linked.

The map starts with one lurker spawned for the computer. This uses one "active" slot.
This lurker is never removed from the map during the course of the test unless killed by the player.

After game-start, p2 triggers will swap ownership of the lurker between the computer and p12[Neutral] for 1000 rounds.
Thus, after 1000 rounds of swapping, the remaining 999 "active" slots will be used.
The final swap leaves a frozen lurker.

It should be noted that the lurker's position is changed to a unique spot after each individual swap. This is to prevent the computer from "reusing" an "active" slot occupied by the lurker during the previous swap.
Disabling the unit-move() should prove that the lurker is not frozen after 1000 swaps if it is not swapped at 1000 unique locations as well.

It should also be noted that the lurker becomes frozen after exactly 1000 swaps.
1(initial spawn) + 1000(swaps) = 1001. The 1001th lurker becomes frozen.
Reducing the swap count to 999 will yield an "active" lurker.

Lastly, the reset beacon provided uses the same solution I posted in the original example map. It successfully recycles the "active" unit slots occupied by the previous 1000 spawn/swaps, and after swapping one last time, it yields an "active" lurker.

* * * *

At the moment, I still don't have verification whether the fix proposed works on anyone else's Starcraft client.

Attachments:

I'll clarify, then, because the test map I used to find and then fix my lurker problem involved spawning 40-50 lurkers only, and no other units, every ~60 seconds.

Do you still remember the original design for your test map?
I might try and replicate it if you no longer have the original test-map file.

Other info I am interested in, if you can remember,
is there only one computer used in the test?
Are the lurkers always spawned in the same places each spawn cycle?
Do the lurkers interact with anything during the test?
When is GiveUnit() used?
Did the fix only require changing the swapping player from a "blind" player to p12, or were there additional modifications?

Thank you! I'm glad someone has finally done some research into this. This was a gamebreaker for longer games of Hungry Hungry Hydras and a way to reset the AI would have been useful. The map spawns lots of Hydras in 8 different locations, so it makes sense why the AI broke down but inconsistently. (Now I might have an excuse to update it, because that map was fun.)

As a simple way to circumvent this, would it work to spawn all units in the same location and immediately move them to wherever they normally spawn?

I recommend calling the units active and passive.

The mechanisms behind this likely involve index IDs, but more research is warranted.

This method appears to work. To ensure that all 1000 slots are re-usable, every hydra should spawn in the exact same spot.
As a counter-example, if you spawned four hydras unburrowed at Location0, the slots would be divided amongst 4 spots since the hydras cannot stack without burrow. Depending on which hydras die first, it opens the possibility that another hydra spawned is not actually "reused" (ex: all hydras spawned at position#1 are still alive).

A simple method would be to spawn/move hydras one by one as needed.
You would have to go through the additional step of ordering the hydras to order:attack to the ground below them once they are moved, else the hydras will attempt to walk back to their birthplace.

Edit: Forgot to mention, I am assuming the hydras never change ownership via GiveUnit() while they are out in the playing field.

I think you're right. I shall re-edit my posting to "passive".



__________________________

* * * General Update * * *
__________________________

I have managed to find a memory address which appears to be directly related to this phenomenon.
The memory address at 0x00685100 might be a pointer of some kind.
It has a starting value of 6804480 and increments by 32 for each "active" unit the computer receives.
Once all 1000 active units have been created, the memory address zeroes out.
Thus the largest value this address ever holds is 6836448. (6804480 + 999*32)
The active units can be counted via simple math:
(CurrentValue - 6804480)/32
Upon a "recycle", the memory address will once again hold a non-zero value dependent on which slot has been freed.

Monitoring this memory address may help mapmakers with numerous spawns identify the presence of a "runaway" spawn system.
Additionally, this memory address can be read by EUD/EPD, allowing the map itself to monitor how many active units have been issued and react if desired.

It should be noted again that this memory address appears to be a pointer of some kind, not a counter.
For example, if one were to create 1000 active units, kill the first 200, kill the last 200, and perform a "recycle", the memory address should return to the original starting value of 6804480 despite the presence of 600 active units.
If the first 200 are created again, the address will not equal (6804480 + 200*32).
It will jump to the next available slot, skipping the surviving 600 active units:
(6804480 + 800*32)

Post has been edited 1 time(s), last time on Jan 3 2014, 10:21 pm by ArcticCerebrate.

The test map was whatever the latest version of Desert Strike Night Fixed was at the time, with pre-placed lairs to spawn lurkers. I wanted to keep everything at close as possible to the live map, so that any fix I discovered would carry through to the actual game.

So:
There were two computers, P4 and P8.
Lurkers were spawned in the same place each cycle.
Lurkers interact with each other in standard DS behaviour - they walk to the centre of the map and attack each other if they have vision, or they will walk to the enemy silo and attack that.
In current versions of the map, units spawn for each human player (1-3, or 5-7) and are then given to the CPU player 4 or 8 as appropriate per team. I can't recall exactly what happened in earlier versions of the map, but I presume the units were first given to P9/P10 and then to the CPU player, resulting in the 'blindness' problem.

I spent a significant amount of time (at least 5 hours, probably 10+) on the problem, so I did investigate it fairly thoroughly; however only far enough to find the solution that I came up with.

The fixed version you uploaded (http://www.staredit.net/?file=2203) is at version 2.63, so I should be looking for a version prior to that. I still DLed your upload in-case.

I have not played Desert Strike before, but hopefully it won't be an issue if I only need to build lurkers.

Thank you for your analysis.