What do you mean States.UnitPositionX and States.UnitPositionY are nasty for the Remake? They should just be simple commands that tell you where the unit is. Or did you mean UnitAt is nasty?
For example, I had this script that decreased the hunger level as a function of their movements, so much moving units get hungry more quickly than units that stand still. This implies looping through all units, store their x,y and compare and update this regularly. However, with the mentioned 2400 units and a check every 4 seconds this is unbearable. I've tried to find out what is actually so CPU-intensive; I've found that things like adding some hunger to 2400 units is much less CPU-intensive than, for example, querying a position of a unit. So, thats what I meant with 'nasty'
a) Use UnitAt to scan each tile in the area.
b) Scan through GetAllUnits and check their positions.
As told, I tried both. In the current form in my script they are both causing lags when upscaled, so I need to do smart stuff. I already have lots of 'continue' and 'break' in my loops to avoid any calculations whereas possible, but that is not sufficient so far. PlayerGetAllGroups is unsufficient, as I need citizens to be detected as well.
It is also possible to spread out processing of a) over multiple ticks. You can use tricks like processing every 2nd row of the map (e.g. Y=2,4,6 one tick, then Y=1,3,5 next tick).
I will probably do something like this. Did already tricks like this to this script that puts back the fog of war at places where units haven't been for a while. Initially VERY cpu intensive for big maps, because it needs to figure out which places of the map haven't been within the 'seeing' range of units for some period of time. I got it more efficient in three ways: 1) reducing the interval to perform calculations, 2) calculate just a part of the map each time, 3) reducing the calculations with a factor 16 by 'translating' the unit / fog data onto a virtual twodimensional array which is 4x4 as small as the map, and treating it as if it contains actual fog of war data.
For the detection of units, I am now thinking about this:
- every large interval, loop through all units and calculate any units that might come within proximity soon (like 20x20 tiles maybe) and store those into a private array for this detector
- in short intervals, only loop through the private detector array, and the first unit which is within circular range...well has a problem
