preventing attacking units from returning

[leviathan221]

How to prevent attacking units from returning to their spawning region?

 

[Mr_Bean]

Advanced -> Gameplay Constants -> Creeps - Guard Distance / Creeps - Guard Return Distance / Creeps - Guard Return Time (sec)

Not too sure which one it is, just try them all.

 

[Chaosy]

it is the guard return distance

 

[Dr Super Good]

It is both, as they will return eithor if distance is exceeded or return time expires.

 

[cohadar]

And how do you make units attack again after they have been stunned and confused?
(rhetorical question)

 

[Dr Super Good]

By ordering them to attack again. Or if they are AI controled you could probably make the AI auto reorder them.

 

[cohadar]

And what if there is more than 200 units controlled by single computer player?

 

[defskull]

Your question can never end cohadar -,-

Machine always has limits, you must understand the concept

Also, it can be done but I bet it will lag heavily (on moderate PC Specs)

 

[Dr Super Good]

You order subsets of them to attack.

A unit standing there doing nothing for even a minute means very little as long as it eventually stops standing there and joins the rest.

 

[defskull]

DGS, tell me, how many units can warcraft 3 engine can withstand before it enters the state of 'heavy lag' ?

 

[Dr Super Good]

Define what you mean by heavy lag?

The movement system can support anywhere between 50 large conjested units and 400 small free units (collision size) moving at once per player. The result of reaching the limit is units nolonger are able to travel at full speed for a certain player and can suffer from responsiveness problems. Massivly exceeding this limit will literally bring all unit movement to a very slow crawl for a certain player during which it is possible to see units moving 1 at a time.

Performance wise, inactive units (like buildings) can reach into the thousands per player without any problem. Active combat units can reach a hundred per player without problems. Units with extreemly large aquisition range in numbers can cause problems when in combat. Units which are triggering script events can cause problems in large numbers (as script events are very slow).

Network traffic wise there is no real way to cause lag unless a client in a multiplayer session has extreemly low speed (dialup) or an illegal thirdparty bot is being used to generate bogus instructions and thus cause network conjestion (lag). Having scripts call too many network syncronized natives will cause lag as well.

 

[HuanAk]

Hi leviathan221,

My map have 400-500 unit fighting at same time with 8 players, and lag seen fine (host by Hostbot or good player).

Just avoid massive trigger/script during massive fight. eg
- don't order all unit at same time, put them into difference group base on difference phase (eg, before fight, after fight, difference region region etc.)
- then use period event to order them with condiction(eg, unit is not attacking, or unit is in region A)

 

[cohadar]

You forgot to mention that you have 4 different computer players.
400-500 / 4 comps = 100-125 units per computer player which is just fine.
Half-truth is the same as lying btw.

 

[HuanAk]

You forgot to mention that you have 4 different computer players.
400-500 / 4 comps = 100-125 units per computer player which is just fine.
Half-truth is the same as lying btw.

What wrong with you ?

I told him the situation, and the possible solution to reduce lag for this situation.

It is truth that i have 400-500 units fighting at same time, all of those 400-500 units are belong to Player 11 & 12 (fighting require minimum 2 players).

 

[cohadar]

I read only the first line and thought that you were trying to imply that having 400-500 units does not lag. (I also briefly checked your map picture and saw 4 computer players)

My bad, sorry.

===========================
PS: "unit is not attacking" condition is proven to fail with too many units.
The best general solution I found for this problem is to SetUnitUserData to random number 1-10
And then periodically order unit only if it's user data number matches with current period counter.