[Crash] Players being disconnected. Filesize too large?

[Gumberbunbder]

Ive been creating my own version of Lotr Builder. since a recent update, players, including myself, are being disconnected frequently. This started happening ever since i added a bunch of new structures around the map which can be captured. I feel like there may be a correlation between the map size and the disconnects as well. I have 8,949 kb worth of models and icons. could this cause disconnects?

I've downloaded all of the models from the hiveworkshop, so i don't think it would be problem with one particular model. If you could take a look and give me some advice i would greatly appreciate it. Thanks!

 

[Tickles]

You might want to consider learning about memory leaks. As you can see from the first section of that post, they can cause exactly what you're trying to fix. And the fact that cleaning them up can reduce expontentially growing lag makes it even more worth it. I noticed you have a massive amount of leaks in your triggering.

But no, file size and imports have nothing to do with it if all of your models are from the models section here. There's a small chance that older models from here weren't tested properly and could cause people to crash/disconnect when they're viewed, but it's very unlikely since none of the models you've imported crashed my editor or Warcraft client when I went through all of them.

 

[Dr Super Good]

The disconnects are likely caused by out of sync errors. They are usually caused by GetLocalPlayer and such non deterministic functions but can also be caused by GetLocationZ. Mac clients are also inherently prone to OOS with Windows clients due to some difference in determinism between the two.

 

[Gumberbunbder]

okay, thank you for the help. I am, however, a very modest noob at all matter regarding triggers. Could you perhaps show me a specific example of where my triggers are leaking. I have looked at hat leak guide before and have tried my best to implement functions to reduce memory leaks.

 

[Tickles]

Unit Group Leak Example

In your Defeat Free Play trigger, you have a unit group leak:

Defeat Free Play

• Actions
  • Unit Group - Pick every unit in (Units in (Playable map area) matching ((Owner of (Matching unit)) Equal to (Owner of (Dying unit)))) and do (Actions)
    • Loop - Actions
      • Unit - Change ownership of (Picked unit) to Neutral Extra and Change color

To fix it, you need to set units in playable map area matching the condition to a temporary unit group so that you can remove the group after you've used it.

Defeat Free Play - Leak Fixed

• Actions
  • Set TempGroup = (Units in (Playable map area) matching ((Owner of (Matching unit)) Equal to (Owner of (Dying unit))))
  • Unit Group - Pick every unit in TempGroup and do (Actions)
    • Loop - Actions
      • Unit - Change ownership of (Picked unit) to Neutral Extra and Change color
  • Custom script: call DestroyGroup (udg_TempGroup)

Point Leak Example

In your Isengard Gold Ore trigger, you have a simple location leak. Location leaks are probably the smallest and most common leaks, but they add up quickly and can actually lead to lag later in the game once they've added up considerably.

Isengard Gold Ore

• Isengard Gold Ore
  • Events
    • Destructible - A destructible within Isengard Gold Ore <gen> dies
  • Conditions
  • Actions
    • Item - Create Gold Coins at (Position of (Dying destructible))

You need to set the point to a variable so that you can remove it like the unit group. Otherwise, the point leak will just exist endlessly until the current game is closed. Using periodic or looping triggers can make those add up into the hundreds, thousands, millions, etc., and reduce gameplay performance.

Isengard Gold Ore - Leak Fixed

• Isengard Gold Ore
  • Events
    • Destructible - A destructible within Isengard Gold Ore <gen> dies
  • Conditions
  • Actions
    • Set TempPoint = (Position of (Dying destructible))
    • Item - Create Gold Coins at TempPoint
    • Custom script: call RemoveLocation (udg_TempPoint)

You do a pretty good job about cleaning up special effects by destroying them immediately, but you should keep an eye on those as well. You can refer to the memory leaks link from my other post if you need more information about dealing with them or anything else that causes leaks.