Hivespawn System: Advanced No Lag Spawn System For AoS Maps

Sick of fighting the lag beast in your AOS maps? Much of the lag in that type of map is caused by the spawn system. It sucks up memory like a pig and eventually lags. This is a system we designed to combat the lag beast. It uses standard no lag, no memory leak spawning. Whats new is the way we avoid the lag from the Create Unit command. Create Unit itself causes much of the lag you see in AoS maps.

So how do we avoid the lag from Create Unit? Simple, We dont create them. We recycle dead units instead of creating new ones. We also start with a pool of units to use before units start to die. This reduces the number of units created by a huge factor. How much? Take a look.......

This system is designed for people who already know how to create AoS style spawning. You need to understand how the system works to implement it into your map. Each map will have different conditions that will require different settings.

It is currently set up to to show what it can do. The spawns are super fast and units die quick. A hero was added so you can see that there is no lag. Run him around and blast things. You should have no lag at all. Even when the map is run for a hour. Deload times are almost nil even after spawning thousands of units.

Do not use hide unit. It will prevent respawn. Use invis or vertex coloring instead. We suggest using more than one recycle center for most maps. We made this for our Nexus map and we use 4 recycle centers in that. One for each team. We hide them in the choose hero rooms.

We are using a custom version of resurrect to bring the dead back to life. If anyone knows a way to directly change the unit state from dead to alive in Jass please let us know. It would make it even better and easier to implement.

Anyone can use this in their maps. We only ask you that give credit. Saying you are using the Hivespawn system is credit enough for us. Dont give us points. We dont give a rats *** about points. Enjoy your new lag free mass spawn maps.
8))

Edit: There may be a simpler way to get the same effect. Read latter posts. We will leave this up so ppl can use it to test with or just look at.

Wow, recycling dead units is an idea and a half! You coudl use this for tons of other map types, not just AoS though. Gj :D

Technically another better improvement would be to use the CreateUnit jass function instead of the CreateUnitLoc function. Locations are notorious memory leakers, and its better if possible to always avoid them.

This is very clever, earlier I had tried to implement the same idea, but hadn't thought of using the paladins ressurection to bring the corpses back to life.

When I ran it however I noticed it was leaking a lot of memory according to Win2K task manager. So I went on a memory leak hunt and found this serious leak in Spawn:

No effort here is made to clean up the memory leak, and the comment: indicates a lack of understanding. Unit variables cant leak, it's the unit group, in this case, (units in region matching condition), which is leaking.

Such a leak can be fixed in one of two ways:
by adding a custom script action:
set bj_wantDestroyGroup = true
right before the line with the leaking unit group

or by using a unit group variable and the custom script command
call DestroyGroup
in exactly the same way as call RemoveLocation

There is also a location leak when a unit is created, but so few units are created that it is minor indeed. or

I'm fairly sure that ressurection doesn't work on hidden units, indeed most the triggers wont work if units are hidden - adding the hide and unhide where suggested would thoroughly break the system, altough anyone with understanding of how the system works shouldn't have much problems fixing it - hidden units can only be aquired through existing unit group variables, or "units of type""units owned by player".

To get an idea of memory saved by using ressurection I made a custom map with about a hundred units constantly dying and fighting, and made one version using ressurection, and another version using "replace unit", the ressurection version leaked far less memory, altough I do wonder how much additional memory may be leaked by the extra triggers involved in a real ressurect system (ie the unit dies trigger...)

We dont know a lot of Jass. Can you give us a example of how to use the CreateUnit function?


Hehe ops. We thought that assigning it to a non-group unit var would prevent the leak by the pick unit group. Didnt think BJ_WantDetroyGroup=True was needed there. Thanx for pointing this out. The comment was to explain why it was used not the actual cause of the leak. We know its the local group that causes it. We just tried to use the wrong fix is all.


That does not prevent the leak? We thought it did. If you are referring to the Set TempPoint=Target that should be removed by the last line in the trigger. If we are using this incorrectly let us know.


Havent tested that. Was planning on using vertex coloring on our map since we use Locust/Chaos combo. We will test it with hidden and if it stops working we will remove the comments.


We wondered about that too. In our tests (up to 5000 spawned units) we saw no lag at all even with the existing memory leak. Exit times where minimal as well. In our experience create unit is more of a memory killer than even the unit group leaks. We did test the map using only create unit and it lagged out quick. We are confident this system will be a large improvement over simple create unit systems.

Edit: We tested it with hide and it worked half way. You can res a hidden unit. But you have to create a temp group to unhide it. You can use hide but its easer to make the unit invis or use vertex coloring. We changed our comments. We cleaned up the memory leak (we hope) and uploaded a new ver to our second post.

Any action involving two locations must use two temporary variables, altough in this case the "Create unit facing angle" can be used instead.

I'm suprised res works on hidden units... it shoudn't.

Just because you cant get to hidden units with "Pick units in region" doesn't mean you can't get them... the best way would be:
"Units of type (typeArray[TempInt]) matching unit (is hidden)"
Made especially easy by the the spawn types already being in an array.

I would agree that the ressurect recycling system leaks far less memory than creating new units

Ok, the units facing angle is a easy fix.

Actually after checking our test with resurrect on hidden we made a mistake. We had actually resed before we hid. No it doesnt work. You could work around it several ways. Res before its hidden, vertex it or give it invis. Invis would prob be the easiest.

We will tweak it a little and post a new ver.

The createUnit function is just like the createUnitLoc function only instead of giving it a starting location you would give it two real coordinates. You can see common.j for its usage. I swore off locs myself.

And then we would need to figure the coords for each spawn building. Think it might be easier to just remove the location.

We finished testing and optimizing. We removed the death trigger in favor of pick dead units - remove group. This shaved a few megs of memory usage at 2600 spawns.

This ver has some changes on the way the system works. For some maps you may want to use the other ver. This ver removes all dead units during a spawn. In some maps that may cause a problem with some spells.

Our tests seem to indicate that this ver uses 10-30% less memory than standard spawn systems depending on the map conditions. Thats a big improvement since the spawn system takes up a huge chunk of your total memory usage. The older ver uses about 10-15% less but is more versatile.

It actually seems to me that the results you are getting is because your corpses are only there for a max of 10 seconds, and the amount is nearly the same.

Edit:
Tested systems at 5 second periodic triggers

409MB - ~2500 Units, Recycled units
407MB - ~2500 Units, 5 second corpses
431MB - ~850 Units, Default length corpses
I deleted the condition to recycle for the 5 second corpses test, and for the default length corpses test as well. And the framerate in the default length corpses was actually around half a frame/second when it got to 850 units for me.

We did a new test to check this. We changed the spawn to 8 sec and removed the hero. We set the spawn system to stop at 2000 total units. We placed the camera where no units go. We arnt trying to test graphic issues.

The memory results-

Hivespawn - 85.2 meg
8 sec corps removal - 87 meg
Normal - 94.6 meg

Changing decay time does seem to make a big difference. Our guess is that the game holds a unit in memory only until its corpse is removed. If that is true then that is new. This has been tested before and the game used to hold units for around 90 sec no matter what. Further tests need to be done. No decay and explode unit might work now if the units are actually removed. It is possible that the game holds exploded and removed units in memory for the full 88 sec of the corpse decay. This may be why memory tests with explode/remove unit showed little difference.

Edit: More tests-

No Decay - 85.4 meg
Remove unit - 85 meg
44 sec corpse removal - 90.8 meg

It looks like Sage might be right. There seems to be a direct connection between decay time and memory use. Our system still does a little better than reduced decay time. Prob not enough to make it worth implementing unless you are doing some kind of very rapid spawn. Especially since you can get almost the same effect by changing bone decay time in gameplay constants.

The new super optimized Hivespawn System...

Decay Time (sec) - Bones 10.0
:Heh:

If anyone wants to duplicate our tests here is the way we set it up. We didnt move the camera at all since graphics may effect memory use and thats not what we where testing. It can be used to test that kind of thing as well. Just move the camera to center to see what effect mass units on the screen has on memory.

One question,
If this suppose to be used in AOS type of map, does it works when the corpse is being used/removed by Raise Dead and alike spells?

Good ol stuff being deleted :)
The system creates new units in case they are removed via some thing.