Epic Lag movement bug

[Shayoo]

Hi, my map project is a rpg : the file size is quite heavy, but i'm sure this bug is not related to the size but a trigger which somehow fu***** all of my movement capacity.
The file size is : 147mo

Tested with some friends we can pick our character and all effects & environements animation around us is fluid* YET :

when we click to move to a position our character either : don't move or is stuck or dashes in a random directions, sometimes even backwards, as if it collides with an invinsible air block...

My knowledge in maps stops to this bug, which i can't find the cause inside my coding as a GUI users.

If anyone wishes to help me or take a look inside the map please contact me on discord so i can give you a private link since this game is not released yet.

Faithfully
A fellow map maker.
Shayoo#5739

 

[A]mun]

Well, did you import any movement systems?
Are there any large numbers of units that continually receive orders to move?
Check the pathing for all areas in doubt, maybe you left some blockers behind.
This dashing backwards sounds weird, not sure i've heard about it so far.

 

[Shayoo]

Hi,
Thanks for your advices yet no i didn't import any movement systems & beside a miners orders to animation attack, i don't have any loop for large amount of units. the pathing is only done by usin block pathing 2 unit around my doodads & thats all nothin in the beginning area. Also all regions seems to be broken like no triggers of simple entering unit gets triggered...

 

[HerlySQR]

Is not because the size map?, because in older versions the max size was 8 MB and in recent versions is 128 MB and you said it has a size of 147 MB.

 

[Ravager16829]

Be mindful that RPG maps have a great chance of crashing due to the insufficient memory usage (probably because of the bigger map size).
Some people said there is a great chance they will get disconnected upon joining the lobbies on Reforged.

 

[Shayoo]

like i said, it could be this problem, yet even in singleplayer the bug occur. Also the map doesn't lag, the environement is fluid, but the players units suffer from this movement bug.

 

[Xonok]

I'd need to see the triggers, but I am 90% sure I know what's going on.
Large RPG maps often use many region events, if they're made in GUI.
Regions in GUI(rects) are just rectangles and that's cheap, but when you make a region event, it apparently converts it to a list of tiles(region). There is a limit on how many of these tiles there can be. When you cross this limit, the pathing goes crazy.

Try disabling triggers that start with "unit enters... ". If that helps, then my guess was correct and the solution is to use fewer of those events and/or reduce the size of these regions(rects).

 

[Dr Super Good]

Two possible causes I can think of.

• You are ordering too many units to move around per player. This can include units that are invisible such as dummy units. The limit is per player so the units must be owned by the player and moving to count towards it. Technically it is because Warcraft III only issues a finite number of movement updates per player per unit time so with too many units moving it cannot keep all of them moving fluidly. Since you say the units act stupid this is unlikely to be the cause.
• You have too many map cells mapped to too many regions. As Xonok explained. With enough such mappings this breaks the path finder completely causing units to randomly walk into walls and act "drunk". Most common cause is using multiple A unit enters (Playable map area) events, especially on very large maps. Each such event generates a new region that it populates with as good as every cell in the entire map, so on very big maps even a few such events can start to break the path finder. Ideally only 1 such event should exist, which should then be used to run other triggers which also need the event using either custom events (changing the value of a variable) or by directly running one or more triggers as part of the actions. This has nothing to do with GUI "regions" which are internally rects, it is entirely to do with native regions which are not directly available/interactable in GUI.

 

[Shayoo]

Yes i have alot of regions with enter triggers...
so what your saying is that i should have only one triggers and multiple single instance condition to enter triggers and that could solve it ?

Ex :
Unit enter regions
---Conditions None---
---Actions---
-> IF then else : entered regions = XXX
-> TP to XXX center.
-> IF then else : entered regions = XXX
-> TP to XXX center.
-> IF then else : entered regions = XXX
-> TP to XXX center.
-> IF then else : entered regions = XXX
-> TP to XXX center.
-> IF then else : entered regions = XXX
-> TP to XXX center.
-> IF then else : entered regions = XXX
-> TP to XXX center.



Like this to simplify each triggers ?

 

[Dr Super Good]

Yes but that is not supported by GUI as GUI does not track the region objects for you to test. Since the regions are approximations of rects (GUI regions), you cannot assume that just because a unit entered a region made from the rect that it is actually in, or not in, that rect.

A lot of small rect based regions is not an issue. It is almost always a few huge rect based regions, such as repeatedly using "playable map area" or for some reason user defining dozens of rects which are most of the map playable area.

 

[Xonok]

Putting them all in one trigger is unlikely to make a difference.
Rather it's a question of how many of these events you have and how big the regions are (I assume).
It all depends on why you need them. What do those triggers actually do?
For example, if you're making an RPG and you want to do stuff in response to people entering an area, you could use smaller rects at the entrances rather than a big one for the whole area. In that case more events can actually be better. It depends.

 

[Shayoo]

most of my bigs areas were used for visibility triggers as the map is quite large. in 400x300. i will try to reduce all of my entering unit triggers and comeback with a feed if it doesn't fix it. Thanks guyz for your advices.

 

[Shayoo]

Hi guyz, the bug is still there, it seems like removing most of my entering map triggers worked slightly yet it's still there... If you want to take a look inside the map i can give you a private link to the trigger text files or the inside code too.

Mh.

 

[Dr Super Good]

In a copy of the map remove all triggers to verify the issue is fixed. If there are not any triggers and the issue still persists then regions are not the cause. Logically you do this to a copy of the map that can be thrown away after and continue editing the original with all triggers.

 

[Shayoo]

Hi, i have done as proposed and removed the triggers of a sample map copy, yet the bug is still present... could i be because i reached a maximum amount of something ?...

 

[Dr Super Good]

There must be some other obscure cause. You will need to provide the editable map so people can poke and investigate it. If you are not comfortable uploading it to the public feel free to private message it to me or others offering help.

 

[Dr Super Good]

@Xonok was spot on. After looking at the map and bisecting triggers the issue is caused by too many cells being mapped to regions by the Unit - A unit enters (Playable map area) event being overused, as they and then I described.

 

[Shayoo]

Thanks for the help i can considere this case Solved thanks you i will work on that. +rep guyz thanks to all of you !!

 

[A]mun]

@Xonok was spot on. After looking at the map and bisecting triggers the issue is caused by too many cells being mapped to regions by the Unit - A unit enters (Playable map area) event being overused, as they and then I described.

So how many are we talking?
Several hundreds?

 

[Dr Super Good]

So how many are we talking?
Several hundreds?

In the topic creators case, it seemed to be up to 4 of those events too many.

I think the number is larger for smaller sized maps. For 480x480 it is likely a dozen or so max.

In any case the solution is to use only 1-2 copies of the event and then have one of those triggers run all the other triggers that need to use the event. This can be done in a maintainable and easy to use way by using a custom event approach. Custom events are usually implemented using the event that monitors a variable for a value change, as seen in most standard GUI compatible Damage Detection Systems operate.