[Trigger] system only lagg in multiplayer

[chasin225]

Hi, im using a cool movement system with arrows i made. Units can walk over any doodad which has set walk over = True in object editor and it looks good. In single player it all works fine, but i tried it online and it started lagging as hell. Also sometimes the height of units were messed up.

It looks like the triggers runs for the second unit, even before the first unit has all his actions done.


I uploaded the map and the trigger below is the trigger from which i think is the bugged trigger.

Could anyone please help me fix this??

• quickchecker
  • Events
    • Time - Every 0.03 seconds of game time
  • Conditions
  • Actions
    • Unit Group - Pick every unit in group_living_units and do (Actions)
      • Loop - Actions
        • Set temp_unit = (Picked unit)
        • Set pnr = (Player number of (Owner of temp_unit))
        • Set temp_loc1 = (Position of temp_unit)
        • Custom script: set udg_temp_zloc1 = GetLocationZ(udg_temp_loc1)
        • Set temp_height = (Current flying height of temp_unit)
        • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
          • If - Conditions
            • And - All (Conditions) are true
              • Conditions
                • temp_zloc1 Less than 1.00
                • temp_height Less than 1.00
          • Then - Actions
            • Unit - Explode temp_unit
          • Else - Actions
            • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
              • If - Conditions
                • temp_height Greater than 1.00
              • Then - Actions
                • Set fall_speed[pnr] = (fall_speed[pnr] + 1.00)
                • Animation - Change temp_unit flying height to (temp_height - fall_speed[pnr]) at 0.00
                • Set temp_height = (Current flying height of temp_unit)
                • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
                  • If - Conditions
                    • temp_height Less than or equal to 1.00
                  • Then - Actions
                    • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
                      • If - Conditions
                        • fall_speed[pnr] Greater than (25.00 + jump_strenght[pnr])
                      • Then - Actions
                        • Unit - Set life of temp_unit to ((Life of temp_unit) - (Square root(((fall_speed[pnr] - 25.00) - jump_strenght[pnr]))))
                      • Else - Actions
                  • Else - Actions
              • Else - Actions
                • Set fall_speed[pnr] = 0.00
            • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
              • If - Conditions
                • moving[pnr] Equal to True
              • Then - Actions
                • Set temp_loc2 = (temp_loc1 offset by run_speed[pnr] towards (Facing of temp_unit) degrees)
                • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
                  • If - Conditions
                    • (region_heightblok1 contains temp_loc2) Equal to True
                  • Then - Actions
                    • Set temp_max_lenght = global_heightblokker1
                  • Else - Actions
                    • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
                      • If - Conditions
                        • (region_heightblok2 contains temp_loc2) Equal to True
                      • Then - Actions
                        • Set temp_max_lenght = global_heightblokker2
                      • Else - Actions
                        • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
                          • If - Conditions
                            • (region_heightblok3 contains temp_loc2) Equal to True
                          • Then - Actions
                            • Set temp_max_lenght = global_heightblokker3
                          • Else - Actions
                            • Set temp_max_lenght = 90000.00
                • Custom script: set udg_temp_zloc2 = GetLocationZ(udg_temp_loc2)
                • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
                  • If - Conditions
                    • And - All (Conditions) are true
                      • Conditions
                        • (temp_zloc1 + temp_height) Greater than or equal to (temp_zloc2 - 20.00)
                        • (temp_height + lenght[pnr]) Less than temp_max_lenght
                  • Then - Actions
                    • Set tempX = (X of temp_loc2)
                    • Set tempY = (Y of temp_loc2)
                    • Custom script: call SetUnitX(udg_temp_unit, udg_tempX)
                    • Custom script: call SetUnitY(udg_temp_unit, udg_tempY)
                    • Animation - Change temp_unit flying height to (temp_height + (temp_zloc1 - temp_zloc2)) at 0.00
                  • Else - Actions
                • Custom script: call RemoveLocation(udg_temp_loc2)
              • Else - Actions
            • Camera - Set (Owner of temp_unit)'s camera Rotation to (Facing of temp_unit) over 0.00 seconds
            • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
              • If - Conditions
                • temp_height Less than 1.00
              • Then - Actions
                • Camera - Set (Owner of temp_unit)'s camera Height Offset to (temp_zloc1 + 200.00) over 0.00 seconds
              • Else - Actions
        • Custom script: call RemoveLocation(udg_temp_loc1)

 

[Maker]

• If (All Conditions are True) then do (Then Actions) else do (Else Actions)
  • If - Conditions
    • And - All (Conditions) are true
      • Conditions
        • temp_zloc1 Less than 1.00
        • temp_height Less than 1.00
  • Then - Actions

->

• If (All Conditions are True) then do (Then Actions) else do (Else Actions)
  • If - Conditions
    • temp_zloc1 Less than 1.00
    • temp_height Less than 1.00
  • Then - Actions

'

You could use a unit array, not a unit group.

You are potentionally checking if temp_height < 1 and temp height > 1. Reorganize the checks.

When you set height = flying height the second time, you should use set height = height + 1 instead.

 

[Tal'Rarity]

Here's some suggestions to fix your lag or at least reduce it...:

Use a unit array as Maker suggested.
Use less BJ's.
Recycle and Re-use dummy units instead of killing/removing/exploding and creating new ones.
Make the trigger less complex.
Creation of points and cleaning them up are costly in memory.
Use coordinates instead of points.
Use regions instead of group checks to detect stuff otherwise maybe phoenix fire with no model and a damage detection system/DDS to deal damage and interact with dummy unit as well to remove the buff before human eyes can see it.
Use a proper timer or/and check less often.
Tell players to get better computers.
Use less dummy units.
Remake the entire game and rename it as something else other then WC3 TFT: Your custom map.
Request Blizzard to fix their game's code and the game itself.
Pay Blizzard to upgrade the code/engine.
Edit the main game's code and improve/reinvent the craft. ( Edit hard-coded stuff and stuff. )

Hope at least one of my suggestions help you, I faced this problem so many times myself. Not much you can do about it because the scripting/jass language is so slow not to mention the games main code itself.

 

[Arhowk]

here's some suggestions to fix your lag

remake the entire game

a+ 10/10

 

[Zwiebelchen]

I'd say screw the whole idea. This will desync in any long game, as you use the return value of GetLocationZ() for gameplay elements.

GetLocationZ() depends on the render state of walkable destructable objects and is likely to cause inconsistencies between different machines, so you can only use it for visual effects.
As you use GetLocationZ() to determine the falling height of a unit (and thus, the falling damage a unit receives), the system will create a desync if the render state of the walkable destructable under the feet of a unit is different for a single player.

 

[Tal'Rarity]

I'd say screw the whole idea. This will desync in any long game, as you use the return value of GetLocationZ() for gameplay elements.

GetLocationZ() depends on the render state of walkable destructable objects and is likely to cause inconsistencies between different machines.
As you use GetLocationZ() to determine the falling height of a unit (and thus, the falling damage a unit receives), the system will create a desync if the render state of the walkable destructable under the feet of a unit is different for a single player.

So yeah like he said, get rid of GetLocationZ for two reasons... One to stop desync's/server splits/ruining the game and Two to reduce lag. Use your own height system to monitor units, you can do this by many ways... The most commonly used one is regions. Use flying height instead as your only Z-height. It'll make it easier on the game and you and your players. Pretty much the same amount of work both ways while one wields more problems then the other.

 

[Zwiebelchen]

So yeah like he said, get rid of GetLocationZ for two reasons... One to stop desync's/server splits/ruining the game and Two to reduce lag. Use your own height system to monitor units, you can do this by many ways... The most commonly used one is regions. Use flying height instead as your only Z-height. It'll make it easier on the game and you and your players. Pretty much the same amount of work both ways while one wields more problems then the other.

GetLocationZ() is not the cause of this lag. It's lightning-fast. There is no other way to get the Z value of a terrain point or destructable, so he pretty much has no other option.
He only needs to get rid of the net traffic operations like dealing damage to be protected from desyncs. (Of course, if falling damage is a core gameplay element of his map, then he is pretty much doomed).

The real cause for his lag might be the sheer number of destructables, as they are extremely taxing on game performance.

Check out this for reference HOW taxing they are:
http://www.hiveworkshop.com/forums/jass-resources-412/system-destructablehider-219569/

 

[Tal'Rarity]

GetLocationZ() is not the cause of this lag. It's lightning-fast.

The cause for his lag might be the sheer number of destructables, as they are extremely taxing on game performance.

Check out this for reference HOW taxing they are:
http://www.hiveworkshop.com/forums/jass-resources-412/system-destructablehider-219569/

Actually it causes a short-sometimes long freeze to the people that get desync'd therefore causing lag. If only the other two point methods were as fast.... Besides if he plans to use walkable destructibles he has to get rid of it anyways.

 

[Zwiebelchen]

Besides if he plans to use walkable destructibles he has to get rid of it anyways.

I don't see why. As long as he uses GetLocationZ() purely for visuals like flying height, it's fine. He just has to get rid of the falling damage.

 

[Tal'Rarity]

I don't see why. As long as he uses GetLocationZ() purely for visuals like flying height, it's fine. He just has to get rid of the falling damage.

Won't it cause problems if everyone has a different flying height?

 

[Zwiebelchen]

Won't it cause problems if everyone has a different flying height?

Nope. Flying height does not cause net traffic by default.
You can set Flying height locally for a unit without any desyncs at all (even in combat).

Flying height is only a problem if you actually use it for gameplay elements.

 

[chasin225]

thanks all for the replies! I wasent experianced with desync yet. Im searching the site for tutorials about it as soon as i got the time.

Do you guys think i should screw the idea?

makers idea of the unit array instead of unit group, will that solve the desync problem?

don't see why. As long as he uses GetLocationZ() purely for visuals like flying height, it's fine. He just has to get rid of the falling damage.

if i find another way to get falling damage will it all be fine?

The real cause for his lag might be the sheer number of destructables, as they are extremely taxing on game performance.

I think thats not the problem. I tested the map single player with 20times as much destructables, dident cause any problems. So im pretty sure the problem is causing something that has to do with multiplayer things.

So yeah like he said, get rid of GetLocationZ for two reasons... One to stop desync's/server splits/ruining the game and Two to reduce lag. Use your own height system to monitor units, you can do this by many ways... The most commonly used one is regions. Use flying height instead as your only Z-height. It'll make it easier on the game and you and your players. Pretty much the same amount of work both ways while one wields more problems then the other.

Using my own height system means that i have to use regions and stuff for every height. If I manage to get this system working for multiplayer to, then i want to make the map much bigger and add lots of destructables (not overdo'ing it ofcourse). So that would suck

 

[Tal'Rarity]

Make sure to make good use of http://www.hiveworkshop.com/forums/jass-resources-412/system-destructablehider-219569/ then so you can counter lag from destructibles outside your screen. You could use set values to do damage like if flying height/Z is 100 or below it deals 50 and 200 or below it deals like 100.

 

[chasin225]

Make sure to make good use of [System] DestructableHider then so you can counter lag from destructibles outside your screen

very usefull thanks!


I have done some research about desync, but as far as I learned it doesent cause lagg, but disconects players. Is that correct?

 

[Zwiebelchen]

You could use set values to do damage like if flying height/Z is 100 or below it deals 50 and 200 or below it deals like 100.

As long as he uses FlyingHeight derived from GetLocationZ() for dealing falling damage, it doesn't matter how he calculates it.