Morph Gadget causing sync errors

[Forboding Angel]

Anytime the player RSAStudioGames is in a game and someone morphs a unit, he starts sync erroring. Halp plox?

RSAStudioGames' (team 0) pastebin
http://pastebin.com/KDX09Ug2

9000r's (team 1) pastebin
http://pastebin.com/vgdqZ4HT

My pastebin (spectator)
http://pastebin.com/iL3Y3HBu

Morph Gadget:
https://github.com/EvolutionRTS/Evoluti ... _morph.lua

Edit: Doesn't happen with anyone else other than RSA that I have seen.

[abma]

this error only happens for RSAStudioGames:

[f=0005445] Error: LuaRules::RunCallIn: error = 2, GameFrame, [Internal Lua error: Call failure] [string "LuaRules/Gadgets/unit_morph.lua"]:374: [GetUnitCommands] called too often without a 2nd argument to define maxNumCmds returned in the table, please check your code!
Especially when you only read the first cmd or want to check if the queue is non-empty, this can be a huge performance leak!

stack traceback:
[C]: in function 'GetCommandQueue'
[string "LuaRules/Gadgets/unit_morph.lua"]:374: in function 'ReAssignAssists'
[string "LuaRules/Gadgets/unit_morph.lua"]:544: in function 'FinishMorph'
[string "LuaRules/Gadgets/unit_morph.lua"]:580: in function 'UpdateMorph'
[string "LuaRules/Gadgets/unit_morph.lua"]:897: in function 'GameFrame'
[string "LuaRules/Gadgets/hotfixes.lua"]:32: in function <[string "LuaRules/Gadgets/hotfixes.lua"]:29>
(tail call): ?

very likely thats the cause of the desync. RSAStudioGames has no shaders / a lot of shader related errors.

[abma]

mantised, you hit an engine "feature": https://springrts.com/mantis/view.php?id=5335

regardingless of that, you must fix the usage of the function, then it won't desync, too.


basicly you should fix all errors before wondering when stuff goes wrong.

[Forboding Angel]

basicly you should fix all errors before wondering when stuff goes wrong.

You don't need to be a jerk about it. I got that infolog link 2 seconds before I posted this thread. I was lucky enough to be able to get it. Maybe in your world people just offer up infologs immediately when they have issues. Everywhere else, we have to ask them for it, explain where to find it, and explain how to copy and paste them into notepad.

Thank you for looking at it. I wonder why zk doesn't seem to have these issues as it's the same gadget iirc. Time to do some sleuthing.

[abma]

You don't need to be a jerk about it. I got that infolog link 2 seconds before I posted this thread. I was lucky enough to be able to get it. Maybe in your world people just offer up infologs immediately when they have issues. Everywhere else, we have to ask them for it, explain where to find it, and explain how to copy and paste them into notepad.

there are other errors (also lua related) in your infolog.txt, thats why i wrote this.

[Forboding Angel]

Code: Select all

[f=-000001] Error: Failed to load: chickens_unit_spawner_defense.lua  ([string "LuaRules/Gadgets/chickens_unit_spawner_defense.lua"]:11: 'end' expected (to close 'function' at line 1) near 'd')

Intentional. If you ever looked at the file you would know why. Doesn't cause an issue and it's there to cause it to break on purpose:

Code: Select all

function gadget:GetInfo()
	return {
		name		= "BA Chicken Spawner",
		desc		= "Spawns burrows and chickens",
		author	= "TheFatController, quantum",
		date		= "16 November, 2008",
		license	 = "GNU GPL, v2 or later",
		layer	 = 0,
		enabled	 = true
	}
d

Why you ask? Because that error serves to remind me that I need to decide whether I want to make it better or not. If It is just disabled then I don't have a constant reminder.

Code: Select all

[f=-000001] Error: Failed to load: lups_thrusters.lua  (Include() could not load 'LuaRules/Configs/lups_thruster_fxs.lua')

You understand that this is a custom config added by ZK, yes? It is also optional, especially since I, like everyone else except zk, have all my shit in the unitfx config. Unfortunately, you guys won't update the source repos, so we have to resort to unfucking someone else's mess in order to use things.

Moving on...

Oh wait, those are the only lua related errors.

Perhaps you should look at a clean infolog before you assume things (like my infolog from above).

[abma]

thats VERY bad coding style. It makes it very difficult for others to look into the code/issues/etc.

don't wonder when you will get similar feedback again / nobody looks into issues.

[Forboding Angel]

thats VERY bad coding style. It makes it very difficult for others to look into the code/issues/etc.

don't wonder when you will get similar feedback again / nobody looks into issues.

You know damn well that a gadget like chickens spawner of all things crashing is no big deal as long as it isn't taking the handler down with it. Don't act like you don't know what that gadget is/does. And if you know what it is/does, then you are also acutely aware that it is inconsequential. You can try to make a mountain from molehill out of it as much as you want, but that doesn't change the fact.

FWIW, that "style" isn't mine. It so happens to be the style of someone that was working with me on something unrelated, but I'd prefer not to start shit out of something so petty as this bullcrap. It also doesn't excuse you from being a jerk about it in the first place.

[Forboding Angel]

Back on topic, thank you for your help Abma. If it wasn't a sync error and was just a lua error I would have been better prepared to handle it. The info you provided me led me to this:

https://springrts.com/wiki/Lua_SyncedRead -> Spring.GetCommandQueue

The way it was getting called was Spring.GetCommandQueue(unitID) and in spring98 a count was added to fix performance issues related to this call. So essentially it just returns x number of results. So since I don't really give a fuck about the morph command happening at a specific spot in a unit's queue, I used Spring.GetCommandQueue(unitID, 1) which combined with the following loop will cause the morph command to happen right after the current command finishes, which works for me.

Thank you for the help, Abma.

[Silentwings]

Fyi abma is not asking anything unusual - its normal to ask that all lua errors from synced code are fixed before a sync error is looked at engine side. See many mantises from ZK & others (including me).

It's precisely because (as was, happily, the case here) desyncs are frequently caused by failing lua code within the game and its much easier to fix that than it is to search out the cause of a C++ desync.

Also fyi, in some circumstances a gadget crashing and/or failing to load could result in a sync error without bringing its handler down.