Staredit Network > Forums > SC1 UMS Mapmaking Assistance > Topic: Known causes of EUD crashes
Known causes of EUD crashes
Mar 25 2018, 1:46 am
By: Lanthanide  

Mar 25 2018, 1:46 am Lanthanide Post #1



With SCR supporting EUD editing, we have new abilities that has not been widely used before, so there is limited knowledge about the things that will cause crashes in SCR. So this thread aims to consolidate any discoveries made about EUD changes that will cause SCR to crash or freeze.

Setting unit vision to 12 or greater
The maximum vision distance for any unit is 11. Setting it to 12 or greater will result in a crash.

Changing unit size for units already in the map
This occurs for pre-placed units, and perhaps also units that you create, then subsequently change the size of (untested). This, along with the crash below, was one of the infamous freeze/crash bugs in the map I was working on, that I bored many people in Discord with. I spent about 45 hours testing to get to the bottom of this problem.

The actual crashes/freezes seem to be with the Unit Finder code, which is what is used to determine if units are at a particular location, for any of the unit-location based trigger actions and conditions (move unit from location to location, kill unit at location, bring unit to location etc). There are two algorithms used for the unit finder depending on the size of the location being referenced. Small locations (8x4 tiles or smaller) are vulnerable to a variety of freeze/crash issues, eg if you pre-place a unit X on the map and change the size of that unit via EUDs, then bring that unit to a small location that is being used for other trigger purposes (moving unit Y to that location), the presence of unit X at that location can cause SC to freeze.

Units that are newly created after the unit size is changed are not affected. It also seems that if you create a new unit of the same type after changing the size, that the original units of that type will no longer cause freezes. This needs to be confirmed with more testing though.

Setting any unit dimension to 0
Similar to the above, a unit which has a dimension of 0 can interfere with the unit finder algorithm and result in a crash or freeze in Starcraft. I don't have a 100% clear understanding of what is required for this to cause freezes, but it was definitely happening in my map.




I have a test map that demonstrates the freezes you get with small size locations when a pre-placed unit has its size changed. The map also demonstrates a freeze that seems to be related to a unit having a dimension of 0, but the mechanics behind this freeze are a little weird.

Download link for 0-dimension freeze example map: http://www.staredit.net/sc1db/file/4041/

See the map description for how to reproduce the freezes and how to edit the map to see some more weird behaviour.

Post has been edited 5 time(s), last time on Mar 26 2018, 4:23 am by Lanthanide.



None.

Options
  Back to forum
Please log in to reply to this topic or to report it.
Members in this topic: None.
[05:17 am]
Oh_Man -- Like it doesnt even bother to build a comsat unless it sees a lurker or dt, etc
[05:15 am]
Oh_Man -- Hope that makes sense. Also artosiscast just dropped a 1 hour vid he analayses a bunch of its games. The TLDR is the maphack is responsible for a large percentage of its wins because its just hard countering zerg rushes
[05:14 am]
Oh_Man -- It's EMULATING the behaviour of a control group select and move without having the actual functionality to do that
[05:13 am]
Oh_Man -- Vrael
Vrael shouted: yeah but it looks like pluto's eAPM is still 6000 based on issuing all those orders
k the APM is inflated because it issues 12 identical orders individually. Its not 12 unique orders
[03:02 am]
Vrael -- which does reduce down to the same tradeoff I mentioned below, aka trading APM for time, but still interesting
[03:01 am]
Vrael -- and while the reaver was reloading it used that time to aggregate enough marine/tank to fend it off
[03:01 am]
Vrael -- like its micro vs one of the in-base reaver drops was pretty insane, basically it made the reaver spend 1 scarab per unit instead of 1 scarab for many workers/units
[02:58 am]
Vrael -- all the stuff I've said below is based on the actual gameplay vs some strong human performers, seems like the bot just has unfair advantages, but its also doing some cool stuff
[02:57 am]
Vrael -- NimoStar
NimoStar shouted: If its any consolation, the human brain would still mop the floor with this bot if it wasn't limited by the mechanical interface
I mean human brains trained the bot too, its not completely infeasible for the bot to actually be strong in certain scenarios
[10:13 pm]
Oh_Man -- No APM in chess. Computer just outthinks the human by seeing more moves ahead and more permutations
Please log in to shout.


Members Online: RIVE, l)ark_ssj9kevin