Staredit Network > Forums > SC1 UMS Mapmaking Assistance > Topic: Peculiar bug in my Desert Strike map
Peculiar bug in my Desert Strike map
May 19 2011, 11:55 am
By: Lanthanide  

May 19 2011, 11:55 am Lanthanide Post #1



This is quite a strange bug, and I'm not sure what would cause it. The symptoms are unusual. I think probably I won't come up with any solid cause, but maybe someone might have an idea what is going on.

This map is very complex, 1228 triggers, just shy of 20k lines in trigedit text. I've never seen this particular bug before after playing probably over a hundred games of various versions of this map, but I've now seen it twice in 3 games.

In DS, units spawn for each team at the bottom left or top right of the map. In my version, the bottom CPU is player 4 and is teal coloured, and the top CPU is player 8 and is tan coloured (identical to P11 colours). Units are initially spawned in holding pens and then moved to the field when room permits, to prevent unplacable unit errors and ensure that your army fully spawns. There are several triggers that govern this behaviour (since it's timed, and the units spawn for P1-3 and must be given to P4 for example), but the one that finally moves units onto the filed for each player, moves the units and then has an Order action like this:
Issue order to all [men] owned by [Current Player] at [move to field mine]: [patrol] to [temple target enemy]
This trigger is owned by Force 2, which contains CPU players 4 and 8.
There is another set of triggers that periodically (every 15 seconds or so) re-issues orders to all CPU units on the map to attack towards the enemy temple, because CPU units can sometimes get lost or lose their targets and sit around doing nothing. There are actually multiple actions for each specific type of unit, because some units are ordered to Move or Attack instead of Patrol, and air units are triggered in a different interval to ground units, but in general they all look like this:
Issue order to all [men] owned by [Current Player] at [My side of map || enemy side of map]: [patrol || move || attack] to [temple target enemy]

Now the actual bug that happened is that suddenly, all of the units owned by Player 4 on the battlefield (probably about 80+) stopped moving - they all just stood still in their tracks. The periodic attack timers did nothing. There was a big big group of protoss units sitting in the [move to field mine] location not moving at all, even though they should have immediately been given the order to patrol. The really odd thing is that the next player, who was zerg, had their spawn turn, and so there was then a big swag of zerg units sitting in the spawning pens. Very very slowly, these zerg units were moved to the field around the protoss units, as evidently there was a smidge of room for them to be placed. As soon as the zerg units arrived, they began patrolling towards the enemy temple, like they should, but all of the protoss units simply stood there motionless.

The obvious explanation for this is that the order triggers were now not firing for those protoss units that were frozen, neither the periodic ones or the single order to patrol when they are first moved to the field, that also fired when the zerg units moved to the field. This would easily happen if the units were no longer owned by Player 4, but were owned instead by any other player. However the units were still Teal on the main screen, and Teal on the minimap. If they had been given to P1-3, P4-8 they would have changed colour on the field and the minimap, and if they were given to P9-12 they would remain Teal on the main screen but turned a different colour in the minimap. And this specifically did not happen.

This motionless non-order state stayed in place for 2 or 3 spawn cycles, during which new units were moved to the field and patrolled correctly, but the protoss units sat in a big lump not moving - other units further out in the field were quickly massacred by the P8 CPU units. Interestingly, these units did not fight back in any way at all, so it seems like it wasn't just a lack of orders, but a complete lack of any action at all that suddenly afflicted these units - I'm not even sure if they were doing their normal idle animations where they slowly rotate around and face different directions.

Eventually a player on the P1-3 team (my team) used the zerg Infestation special. Suddenly all of the protoss units began moving again, as they were supposed to. The infestation special does end with an order trigger:
Issue order to all [men] owned by [Current Player] at [anywhere]: [patrol] to [temple target: enemy]
So it seems that this order action was properly executed for the protoss units, whereas the other periodic ones were not?


Now this happened again, although much more briefly, in my 3rd game. Except this time it was the P8 zerg units (my enemy) that froze, and it was only a few of them. They stayed frozen for about 30-40 seconds, and came right all by themselves - there was no special, or boom, or any other special event that happened. Again, they remained Tan colour both on the main screen and on the minimap. I made a test version of my map to see what happened when players were given to P11, who is also tan - in that case the Photon Cannons at the top team base begin firing on the units, as they are now considered enemies. In this game with the zerg units, several of them froze right next to the photon cannons, but the cannons did not attack them, so this is a strong sign that they were not given to player 11 inadvertently.

Does anyone have any clues what might be going wrong? I think I can rule out the units being given to another player in error because the unit & minimap colours didn't change. I think I can also rule out the locations being incorrectly moved around, because in the first game the zerg units were still being correctly moved to the field and correctly ordered to patrol, and the periodic triggers have locations that cover the entire field and should not be being moved by any other triggers. However it is a bit suspicious that the order for men in [anywhere] at the end of the Infestation special did make the protoss units move. But in the 3rd game, there wasn't any special event that happened, the units just seemed to 'snap out of it' after a while.

:???: :curse:



None.

May 19 2011, 7:38 pm Roy Post #2

An artist's depiction of an Extended Unit Death

This is indeed strange. I haven't really heard of something like this happening before, although I had a similar issue with actions not firing properly in an old project of mine (~1700 triggers).

  • Can you think of any trigger or event (i.e. a player leaving some time in the game) that these two occurrences have in common when the units stopped moving?
  • How is your system set up in regards to waits and death counters? Do you have a lot of triggers with waits? (I'm not suggesting this is a wait block, as your order trigger probably runs on a DC timer and therefore wouldn't be affected; I just want to know for reference).
  • Does this occur at a certain time frame or stage of the game?
  • Do you have any AI actions running for the affected computers when this occurs?

If you see this occurring frequently and/or can reproduce the effect reliably, you should have a player sit in the computer slot and see if the units are actively receiving some order command when they freeze. I suggest this because you noted that they didn't respond even when they were being attacked, which would be the default response when a unit has no orders and is in contact with an enemy unit.




May 19 2011, 10:27 pm Lanthanide Post #3



Quote from Roy
  • Can you think of any trigger or event (i.e. a player leaving some time in the game) that these two occurrences have in common when the units stopped moving?
  • How is your system set up in regards to waits and death counters? Do you have a lot of triggers with waits? (I'm not suggesting this is a wait block, as your order trigger probably runs on a DC timer and therefore wouldn't be affected; I just want to know for reference).
  • Does this occur at a certain time frame or stage of the game?
  • Do you have any AI actions running for the affected computers when this occurs?
Thanks Roy.
  • No, there was no obvious correlation between the two instances. In the first game, there were various hero units which have extra trigger effects, some of which do involve giving units from P4/P8 to neutral, and then back again. However these hero powers only occur in the small location surrounding the hero unit - the freeze affected multiple units across the whole map. In the 2nd game, there were not heroes at all.
  • Waits are used only in hyper triggers. Absolutely everything else uses DCs. There are no transmissions, either.
  • Unknown. I've only had it 2 times, and I would say that the progress through the game was a bit different - maybe 20 minutes the first time, and 15 minutes the 2nd. First game was 3v3, 2nd game was 1v1. The 2nd time it happened, the units were frozen for much shorter time period.
  • The only AI action in the game is running the Protoss expansion custom AI at the start of the map for the two CPU players which are both Zerg for their race - the protoss script is to help encourage use of protoss unit spells as they're more crucial to that race than the others. After that, all CPU behaviour is controlled via Order actions (move, attack or patrol) and the natural unit AI present for all CPU players.

Quote
If you see this occurring frequently and/or can reproduce the effect reliably, you should have a player sit in the computer slot and see if the units are actively receiving some order command when they freeze. I suggest this because you noted that they didn't respond even when they were being attacked, which would be the default response when a unit has no orders and is in contact with an enemy unit.
Only seen it twice, just recently, after playing the map probably over 100 times. No idea how to reproduce it, hence fishing for any ideas here. I have made a variety of changes in my latest map, but none of the changes are particularly new or different mechanics to those that already existed in the map: eg I added a new hero, but it's similar to previous ones. I fixed up a few spawning bugs, rebalanced unit stats etc - there aren't any major new systems in place, and certainly nothing that seems like it should have this sort of affect.

I am also not 100% sure that the units were completely frozen, in that they didn't play idle animations (but that might be a clue if anyone has seen it before), or 100% sure that they were not retaliating to attacks, but it did appear that that was the case. I don't think any Order action would be sufficient to cause this anyway - since there is no Stop order, to get units to 'freeze' you have to move them to themselves, which requires moving to centred locations, and therefore doesn't really neatly for multiple units at once, and they still play their walking animations, and that didn't look like what was happening.

Post has been edited 1 time(s), last time on May 20 2011, 12:52 am by Lanthanide.



None.

May 20 2011, 1:13 am Roy Post #4

An artist's depiction of an Extended Unit Death

I'm almost positive the issue is not related to the "Give" action from the details you provided.

Also, I'm fairly certain that the "Order" action by itself would not fail (as you may recall in some bound maps, the map creator places himself in an isolated bound area and dodges explosions for the length of the map; I've sat in one of those games for 2+ hours without the unit failing to move, which would kill it), especially since you mentioned new spawning units were not affected by the anomaly.

You probably don't have triggers trying to teleport the units to unwalkable terrain, but this effect most closely resembles what you experienced.




May 20 2011, 1:22 am Lanthanide Post #5



Hmm, yes, moving to unwalkable terrain does seem like the closest well-known phenomenon. I would expect that that should not be happening with any of my triggers; but of course *something* is causing this bug, and it is likely to be some aspect of the triggers or we would have seen this bug crop up in other maps/melee games as well. Unfortunately I do not recall if the issue affected flying units as well, or only ground units.

The real difficult part is trying to explain while the existing protoss units just sat there in a bunch, while newly spawned zerg units acted correctly. Moving to unwalkable terrain would probably have screwed up the zerg units too :/

Only thing I can really think of is some bug with the unit scanning/location scanning code. As in, for some reason the game treated these units as though they weren't inside the locations they were supposed to be. The infestation "anywhere" trigger then fixed it, because 'anywhere' is treated specially compared to other named locations? I guess Heinnerman's input would be useful, here, to scope out what is feasible and what isn't.



None.

May 20 2011, 4:43 am Heinermann Post #6

SDE, BWAPI owner, hacker.

Running a different race script doesn't encourage spellcasting more than another script afaik.

Have you tried...
Execute AI script 'Clear Previous Combat Data' at 'Location'.
?

Not sure if that will work or not. If not, try giving it to another player, then back to the computer player.
Or you could try the AI Patrol
Execute AI script 'Make These Units Patrol' at 'Location'.




May 20 2011, 6:13 am Lanthanide Post #7



Thanks Heinermann.

Unfortunately the bug is not yet reproducible in any reasonable fashion, so I don't know if either of your suggestions will make any difference. I will try and experiment this weekend and see if it happens again, or more often, or whatever. I don't really want to go and put arbitrary 'clear previous combat data' actions all around the place if I don't have to, especially if they have a chance of causing further issues (eg I'd probably end up running that action every time units spawned, so it'd happen about 100-200 times in an average length game).



None.

May 20 2011, 8:00 am Ahli Post #8

I do stuff and thingies... Try widening and reducing the number of small nooks and crannies to correct the problem.

Quote from Heinermann
Execute AI script 'Clear Previous Combat Data' at 'Location'.
?
Do you know what that script does in detail?




May 20 2011, 7:40 pm Heinermann Post #9

SDE, BWAPI owner, hacker.

Looks like it causes the AI to "re-assign its military units to nothing" to interrupt AI-specific attack commands (Like 'Send All Units on Strategic Suicide Missions').
Note: It's possible that the script itself could be causing issues (by running opcodes like "attack_prepare" etc).

The only AIScript opcode you actually need the computer to run is start_town, and start_campaign if you want it to behave differently. I'm not sure how different start_areatown is.
The custom level scripts don't run start_campaign, so running a campaign script will make your AI behave differently.

Here are some examples where the AI behaves differently when the script runs start_campaign:
  • Defiler
    • Dark Swarm target acquisition range increased from 1024 to 2048 when idle.
  • Queen
    • Cast Parasite behaviour changed from Max Energy to 1/256 chance. Will parasite anything that doesn't have parasite from any other players instead of only parasiting what it doesn't have vision of. Instead of following a strict set of rules, it will parasite everything and ignore status ailments and hitPoints/Shields requirements.
    • Spawn Broodling behaviour changed from less than Max Energy to 255/256 chance.
    • Ensnare behaviour changed from Max Energy to 255/256 chance. Target acquisition range increased from 1024 to 2048 when idle.
  • Arbiter
    • Stasis target acquisition range increased from 1024 to 2048 when idle.
  • High Templar
    • Psi Storm target acquisition range increased from 1024 to 2048 when idle.
  • Ghost
    • Lockdown target acquisition range increased from 1024 to 2048 when idle.
  • Science Vessel
    • Only targets Workers, Overlords, and Medics when idle.
  • Corsair
    • Disruption Web target acquisition range increased from 2048 to 4096 when idle.
  • Dark Archon
    • Feedback target acquisition range increased from 1024 to 2048 when idle.
    • Maelstrom target acquisition range increased from 1024 to 2048 when idle.


Extra notes:

Hallucination is rigged so that it will only hallucinate Carriers, Scouts, Arbiters, and Archons regardless of stats.

Mind Control is rigged so that it will always MC only loaded Shuttles/Dropships, as well as Tanks, Science Vessels, Battlecruisers, Medics, Ultralisks, Overlords(empty too), Queens, Defilers, Devourers, Dark Archons, High Templars, Dark Templars, Arbiters, Carriers, Reavers, Lurkers, and ANY unit whose mineral and gas costs are both greater or equal to that of a Protoss Dark Templar. You can essentially change what the computer mind controls outside of the scope by changing the cost of a Dark Templar. Making it cost 0 minerals and 0 gas will cause it to Mind Control everything, including Zerglings, Marines, etc. Making it cost 10000 will only cause it to mind control the units listed above. It won't Mind Control heroes.

For example, if you don't want the computer to Mind Control Wraiths, but want it to Mind Control Ghosts, then you would decrease the mineral/gas cost of the Wraith and increase the mineral/gas cost of the Ghost. If the computer does not Mind Control Guardians or Archons, then you may want to increase their cost as well. Same goes for Infested Terrans, Corsairs, Workers, Critters, Eggs, Powerups, etc.

Dark Templar normally costs 125/100.


Maelstrom is rigged so that it has a lower chance of being cast if the unit has as much energy as both the energy costs of Mind Control +(plus) Maelstrom. This makes the cost of Mind Control influence the rate at which Maelstrom is cast as well. So for example, if Maelstrom costs 20 and Mind Control costs 30, then it will NOT cast maelstrom if it has 50 energy or more. The availability of Mind Control is ignored and it will read the energy cost anyway.

EDIT: This info applies to the following:
  • Idle burrowed units [Burrowed (Idle)] (Checked every 8 frames)
  • Idle units [Computer Guard] (Checked every 16 frames)
  • Medic Idle [Medic Order] (Immediately)
  • Hit with a bullet (includes from spells too) (Immediately)
  • Computer AI Idle (Special case; every 4 frames)

BIG NOTE: I DID NOT TEST THESE!

Post has been edited 10 time(s), last time on May 20 2011, 8:32 pm by Heinermann.




May 20 2011, 11:05 pm Lanthanide Post #10



Wow, very useful, Heinermann.

Could you clear up a few details, though?
Quote
The only AIScript opcode you actually need the computer to run is start_town, and start_campaign if you want it to behave differently
Do you in fact mean start_town OR start_campaign?

What is the difference between the custom level scripts and the other campaign ones - it sounds like nothing, apart from the spell effects you've listed?

Your extra spell info says "idle", what does that mean? Units that are not currently moving? At the bottom you have the edit list, which implies that when a unit is attacked, it will go into 'idle' and the new spell behaviour (ranges) will take efffect?

Also, could you clarify on the Queen more? It seems that without these scripts running, it will only ever cast any spells when it has max energy? So if it was on 200 energy, it would cast 1 spell, and then immediately it would no longer be on max energy, and therefore fail to cast anything else until it regenned back to 200?

Looking at these behaviours, I think I might actually prefer all of the spell ranges to remain at 1024, as it'll stop units from going out of their way (and dying) to try and cast things, and make it more of an immediate battle, which is what DS is about. Also the existing range of 1024 is 32 tiles, which is pretty big already.

I assume the extra notes apply to these spells regardless of what scripts you're running? Is there any way to manipulate what Hallucination can be cast on? Expanding the set, and/or removing Arbiters would be useful for me.

Is there any way to get Hero units to cast spells? At the moment it seems only hero ghosts and wraiths will cast cloak, but no other hero units will use their spells at all.



None.

May 20 2011, 11:30 pm Heinermann Post #11

SDE, BWAPI owner, hacker.

Quote from Lanthanide
Wow, very useful, Heinermann.

Could you clear up a few details, though?
Quote
The only AIScript opcode you actually need the computer to run is start_town, and start_campaign if you want it to behave differently
Do you in fact mean start_town OR start_campaign?
I mean start_town and OPTIONALLY start_campaign.

Quote from Lanthanide
What is the difference between the custom level scripts and the other campaign ones - it sounds like nothing, apart from the spell effects you've listed?
There are many script-wise differences as well but most of it is either unnoticable or unrelated to what you're doing.

Quote from Lanthanide
Your extra spell info says "idle", what does that mean? Units that are not currently moving? At the bottom you have the edit list, which implies that when a unit is attacked, it will go into 'idle' and the new spell behaviour (ranges) will take efffect?
Yes, units that aren't doing anything. When a unit is attacked it does not go to idle, instead it will run the spell loop using a different parameter (1 for immediate casting, 0 if idle). The parameter specifies the target acquisition radius, immediate casting being within range so the unit does not move to a target.

Quote from Lanthanide
Also, could you clarify on the Queen more? It seems that without these scripts running, it will only ever cast any spells when it has max energy? So if it was on 200 energy, it would cast 1 spell, and then immediately it would no longer be on max energy, and therefore fail to cast anything else until it regenned back to 200?
Spawn Broodling would occur when it has less than max energy, the others would occur if it has max energy. I could have misinterpreted it though.

Quote from Lanthanide
Looking at these behaviours, I think I might actually prefer all of the spell ranges to remain at 1024, as it'll stop units from going out of their way (and dying) to try and cast things, and make it more of an immediate battle, which is what DS is about. Also the existing range of 1024 is 32 tiles, which is pretty big already.
This only applies to the idle units, however the changes with the Queen apply to both idle and attacked.

Quote from Lanthanide
I assume the extra notes apply to these spells regardless of what scripts you're running? Is there any way to manipulate what Hallucination can be cast on? Expanding the set, and/or removing Arbiters would be useful for me.
Yes, those notes apply always. There's no way to manipulate what it will hallucinate because it's hardcoded.

Quote from Lanthanide
Is there any way to get Hero units to cast spells? At the moment it seems only hero ghosts and wraiths will cast cloak, but no other hero units will use their spells at all.
There's no way to do this. Cloak is just a default maneuver when a unit is attacked, it's not really treated as an ability as much as the others are.




May 21 2011, 12:14 am Lanthanide Post #12



Thanks Heinermann!

I found and fixed the bug as in the original post, as well. I created a test-map that had about 50 probes spawning for each team, so pretty quickly there would be large numbers of probes on the field. There was also the Warp Prism hero that created other units, like zealots, dragoons and archons. After about 2-3 minutes, the bug would take affect, but not always for the same team. Sometimes it would last 10-20 seconds, other times it lasted for 3+ minutes, with all of the probes simply sitting at the starting area. When the bug occurred, they would all sit with exactly the same alignment, and would not fidget at all. Also when the bug occurred, it would sometimes affect the archons etc - there was one instance where an archon had enemy targets directly in range, but it simply sat there, doing nothing - didn't appear to fidget. It seems that the bug would affect certain units, and continue to affect those units, while other units (especially newly created ones) were free to move and attack as normal. In one case, the enemy probes stopped moving/spawning for a very long time, and my probes managed to kill all of their mobile units - but instead of attacking the prison cell, they just sort of milled around and moved a lot.

So what was the solution? Simple - I removed the Protoss Expansion Custom Level AI! That was all!

The units now seem to be more aggressive overall, for example even when the probes were moving around freely, they seemed to have trouble acquiring targets and attacking. But now they have no such problems at all!


Heinermann - when you get some time, could you please investigate all of the other unit abilities, in the same way that you investigated Hallucination/Mind Control/Maelstrom? Knowing the details behind irradiate, lockdown and EMP could be quite useful, for example. I recently changed the energy cost for EMP in my map from 135 to 145, and it appears that science vessals might be casting it a little more often now? (not the effect I wanted!).

Also I confirmed your note about MC working on units that were >= dark templar costs. I tested it with marines, and it worked.



None.

Options
  Back to forum
Please log in to reply to this topic or to report it.
Members in this topic: None.
[02:02 pm]
Corbo -- Suicidal Insanity
Suicidal Insanity shouted: I had thought it loads it from the MPQs and parses it, so I was working on re-implmenting that with the MPQ code changes, and then noticed that it does grab the MPQ interface but then ignores it :X
nice
[09:23 am]
Suicidal Insanity -- I also still could use spec sheet for the formats to make sure I am using them correctly - it appears BWscript doesn't have string names? Or they are in a different spot?
[09:22 am]
Suicidal Insanity -- I had thought it loads it from the MPQs and parses it, so I was working on re-implmenting that with the MPQ code changes, and then noticed that it does grab the MPQ interface but then ignores it :X
[09:03 am]
Pr0nogo -- ok, i'll explore that when you have that changed
[08:54 am]
Suicidal Insanity -- if trigedit has such things
[08:54 am]
Suicidal Insanity -- Or maybe change it to a warning
[08:54 am]
Suicidal Insanity -- I just need to disable the verification, then it would allow arbitrary characters
[08:48 am]
Pr0nogo -- would be nice to change that and see if that allows arbitrary characters
[07:24 am]
Suicidal Insanity -- Pr0nogo
Pr0nogo shouted: trigedit won't compile or throw errors, i'll try with the custom aiscript files imported to the scmd mpq
Ya trigedit has the aiscript.bin file added to its resource - it doesn't load it from the MPQs
[06:13 am]
Pr0nogo -- agreed
Please log in to shout.


Members Online: Roy, Nekron