So as many of you know, I am working/worked on a map called Mini-Game Party but lately there's this major bug/glitch that's been bothering me for a while. In some of my mini-games I had it so that there are preplaced (or trigger created) enemy units across the arena/map and that if you human players' units go near them they will sense you and attack (so in short, no order or AI script actions have been implemented.) But the problem is, they don't; they freeze up and sit there. Even when we have our units literally rubbing their asses, they don't even flinch.

So why was this happening?

After tiring hours and hours of research and testing, I've came to the conclusion that t is because of the "Give unit" actions.


One particular Mini-game, #11 Exploding archons, uses it a lot. The mechanics behind that game is that Archons will be spawning for either player 7 or 8 (two computer players). and that the triggers will go through each and every P7 Computer owned archon (depending on the cycle), create an explosion for it, give it to p8, and then have that newly given p8 archon junkyard dog. Once all p7 archons are gone, this process repeats only that it gives p8 back to p7, and so on.
If this game lasts long enough (which in many cases, it goes waaaay beyond the desired game length) then this "give unit" action will have fired as much as over 500 times.

And then there's another mini-game called #70 Flag Capture where during the mini-game briefing the arena is set up by creating 80 zealots for p7 along the perimeter, have them junkyard dogged, and then 2 seconds later give them all back to P8 by manually going through each and every zlot and have a location centered on one at a time, give it to p8, and then force it to stop by moving it to the location I just centered on it (and to have this all done in one trigger cycle, i made multiple triggers for this).
And the thing is if I play this directly after #11 Exploding Archons, there will be some zealots that work normally, but then some that are simply frozen.


I have several other mini-games that involve giving between the two computer players but these two are the biggest culprits in glitching up mini-games like the Lurker Dance one where the lurkers don't burrow (and the reason for this isn't because they're allied to us, but that they're simply frozen due to overuse of the "give units" action).


So now I ask you people, why does this happen? Why is it that when the units are given to and fro computer players that eventually the computer units freeze up? Or if this happens to be one of those known flaws or wahtever, what exactly is the limit or condition to this? Or should I find alternatives to my mini-games and limit the use of these "give unit" actions?

Do they move after you attack them with a unit? (After this freeze up occurs, obviously.)
If not, then I've seen something similar in rpg's where people place a lot of units, which I have yet to see a way around. (Besides using triggers to attack or something.)

While I was making my thing map, I found that even player-owned units (I've seen this happen only to melee units, haven't tested for ranged) can freeze in some situations (when running after an enemy unit was the most common). When frozen, he will attempt to attack any nearby enemy as usual and even turn in the required direction, but won't be able to walk at all for a couple of seconds. I don't know if our glitches are related, but if they are, your theory about the give commands should be rehauled, because my map wasn't give-intensive at all.

JaFF, that is not the same bug.

Yeah, it's a bug. I'm not sure if "clear previous combat data" will work, but it might be worth a try. Merrell and I have seen this bug in our test map.

The bug is: Computer player has no control over its units. The units will not attack, will not move, will not follow any AI Scripts or directives. I'm not sure if the unit will follow the "Order" trigger action.

With the new hero for TS.. I have been messing with Recall..

It seems that if you recall a ground unit to a place where it is unplacable MANY TIMES for a long time.. they freeze.. but they do attack if you attack them (I think).. but the order and all that gets overwritten by the recall...

Similarly, if you continually move a unit to smwhere else which it is unplacable.. it'd just stand there and do nothing.

It could be that you have two counteractive triggers on the units... making them freeze in place.

No, the bug is AI related.

The bug you mentioned happens when moving units(Move trigger and Recall are nearly the same when it comes to this).
It interrupts orders, but not completely.
For example, a worker will harvest resources from anywhere on the map if they are in the process of going there.
- Zerg Queens will teleport to infest command centers.
- Protoss units will recharge their shields from anywhere.
- Terran SCVs will fly over invalid terrain to finish constructing a building. A second time will force them to finish constructing it, a third will cause them to halt in position while constructing it from somewhere else(building looks like it's building on its own).
Possibly others.

Mining minerals from a distance, and returning them, and you can also teleport to vespane geysers this way.


Perhaps the computer begins to glitch up after being given so many AIs to perform, and having its units thrown around so oddly.

If it has to do with AI scripts I'd ask a modder for more information about them.

This glitch is only happening to me because of "give unit" actions. Every time inbetween mini-games I run the "Clear previous combat" AI at "anywhere" and I don't seem to have a problem as far as AI's go.

MA, you say you've done a lot of testing. Have you made a map solely for this purpose? At least then we'd know for sure if it was the give thing, right? If you happen to have it, could you post it for tweaking?

edit: ahh, so do they still freeze up if no AI is applied though?

Clear previous combat data might not be able to run because of maximum AI scripts queued??

A map needs to be made specifically for testing the real cause.

*Resurrect*

I have this same issue in my map with lurkers eventually failing to burrow/attack, has anyone done any further investigation into the exact cause or possibile mitigation/cure for this issue?

Interestingly after several minutes the lurkers dramatically drop off their rate of burrowing/attacking (say out of 15 lurkers, 1 or 2 will still attack), but a couple of minutes after that it will cease completely. The lurkers will still respond to the order action, but they simply won't burrow when idle/in enemy range.

My map has a lot of "give unit" actions in it. I will be able to refactor it to use "create unit" instead, but there will still be a few give unit actions that are unavoidable, so it seems that at best this will be delaying the issue, rather than solving it completely.

I have tried running "clear previous combat data" at an appropriate point (every 8 seconds, before lurkers are given new orders), but that had no impact on the issue at all.

Further testing has been a bit inconclusive Under 'normal' conditions for this specific test, the glitch wouldn't occur until after about 7:20.

I modified my map in a couple of different ways regarding 'give':
1. Set up an area where I created 5 carriers for P1 and gave them to CPU every cycle when the CPU had at most 6 carriers. They were above a patch of enemy photon cannons that destroyed them quickly. Testing with this gave about 5:45 until the 'no burrow' glitch struck. I tested this 3 times with the same kind of results each time.
2. Used the same setting as above, except gave the carriers from P1 to P9. I tested this twice, and go times of around about 7:20, so this didn't seem to contribute to the problem.
3. Used the above settings, except the cannons were owned by P9, and I simply gave a fixed number of carriers between P1 and CPU every trigger cycle. Tested this twice with different numbers of carriers, and go times of about 8:30 each time, so seemed to be a slight improvement.

With these results, I then modified the map to remove the principal forms of 'giving' for my unit spawns - they are created directly for the CPU instead of being given by the human player. First test of this gave a usual ~7:20 glitch time. I then modified it again to remove *all* unncessary giving (only a small amount left for my lurker AI), and this time it glitched after just ~5:45, like in test #1.

So it seems that 'give' may have an impact on the glitch, depending on the players invovled, but it's not thoroughly conclusive in my testing. It also seems that this glitch will occur regardless of how many give triggers are being run; certainly having huge numbers of gives doesn't seem to accelrate it any further than about the 5 minute mark. So I think mitigation of the issue is probably not going to be sufficient; we need a way to either completely avoid it, or reset whatever it is that is getting messed up to totally alleviate the issue.

Right, I've gotten to the bottom of this problem!

Ignore the results presented in my previous post, because they're all more or less meaningless (bad test procedure - I had missed some 'give' actions), however my new results do inform as to what was going on with those tests.

First off, it seems that this bug only occurs when you give units between P9-11 and a CPU player. I have done some new tests with giving units between P1 (human) and my CPU players, and have not seen the issue arise. A few of the lurkers seem to get a little dumbed-down over time, in that they won't burrow to attack until they have been attacked by an enemy (vs the glitch, where they will never burrow), but the majority of the lurkers will burrow correctly, even after some 50 minutes of game time. I need to do a longer test-run of giving units between CPU and P12, my last test I did didn't have all of the triggers properly set, but current indications is that it acts the same as giving units to P1 and back.

Anyway, findings:

• Repeatedly giving units between P9-11 and CPU players will eventually screw up innate unit AI for the CPU players. This is most obvious with lurkers, where they will fail to burrow/attack, but will still respond to patrol/move/attack orders. MilleniumArmy's first post in this thread indicates it happens to other units like Archons as well, where they will fail to attack.
  
• The threshold seems to be about 400-600 give actions - perhaps 512 is the magic number? It seems that P9-11's self-blindness settings are somehow tainting the CPU players into not using proper unit AI.
  
• Giving units between a CPU and P1-8 or P12 is sufficient to avoid the glitch. A handful of lurkers (1-2 out of 15) seem to not want to attack, but will burrow when attacked by another enemy, which is a vast improvement on the glitched state (only 13-14 out of 15 wouldn't burrow under any circumstances, other 1-2 only when attacked).
  
• Once the threshold is reached, it appears that all units owned by the CPU will become stupid: eg if you give a single lurker to P9 and back, then all lurkers owned by the CPU will now fail to burrow/attack, not just the single lurker. The glitch will then apply to all new lurkers created/given to the CPU (did not test lurkers the AI may morph from larva itself) and killing/removing existing lurkers will not remove the glitch.
  
• Not definitive, but it appears that the corruption is cumulative and shared by all CPU players, eg if you give units only between CPU P4 and P9, then CPU P4 and CPU P8's lurkers will all be glitched, not just P4's.
  
• Giving the CPU player vision to itself using the "Set vision for player x" seems to mostly fix the glitch, although a few units seemed to be unresponsive (maybe 3-4 out of 15 lurkers), even to "order" commands. I was running this vision script every 36 seconds or so, rather than waiting for the glitch to fully develop. I also tried giving units between P3 and CPU P4, with P3 having vision to themself turned off once (at the beginning of the map), but this worked just the same as if I had given the units to any other P1-8, without any glitch issues at all. Perhaps P9-11 have vision disabled in a more fundamental way, or are running a 'disable vision' script constantly? I haven't really experimented too much in this area as my problem can be solved by using P12.
  
• I have not tested giving buildings between P9-11 and CPU players.
  
• It appears that giving units/buildings between P9-11 and human players does not affect the CPU AI.
  
• "Create unit" action for the CPU does not have this issue, only with units given between the CPU(s) and P9-11.
  

Hopefully this information will be of use to others. Of course, your mileage may vary, and I suggest doing some thorough testing around this area if this could be an issue for your map. I will make further updates to this thread editing this post, unless someone else replies.

Updates
I've updated the above list with the latest information: running vision triggers for the CPU seems to mostly fix the glitch, Giving units to P12 works just as well as giving them to P1-8.

Post has been edited 1 time(s), last time on Apr 16 2010, 8:34 am by Lanthanide.

Well, it seems you've gotten to the bottom, but now we've gotta find a way out of the hole.

Thanks for your contributions to Mapping.

Awesome, I'll try if that fixes my lurker issues in desert strike.
Now if you could find a way to reliably make tanks siege, that'd be even more awesome.

Just an update on this thread. I use the method of giving units between P4/P8 (cpus) and P12 in my map extensively and have never had any more lurker problems, even though I also very frequently give buildings between P1-3, P5-7 and P10 (and back again) without issue. So it would seem that giving buildings to P9-11 will not induce the issue, just units.