Not desync safe!

Replaces resource spawning system, so that the distances between resources are much bigger. Railway is needed then.

Moderators: orzelek, Dark

Post Reply
User avatar
Mylon
Filter Inserter
Filter Inserter
Posts: 513
Joined: Sun Oct 23, 2016 11:42 pm
Contact:

Not desync safe!

Post by Mylon »

So I was trying to play some multiplayer with a modpack using RSO 3.5.7 when it started desyncing like crazy.

Using the trusty power of meta tables, I added this to control.lua and started a fresh map:

Code: Select all

--Time for the debug code.  If any (not global.) globals are written to at this point, an error will be thrown.
--eg, x = 2 will throw an error because it's not global.x or local x
setmetatable(_G, {
	__newindex = function(_, n, v)
		log("Desync warning: attempt to write to undeclared var " .. n)
		-- game.print("Attempt to write to undeclared var " .. n)
		global[n] = v;
	end,
	__index = function(_, n)
		return global[n];
	end
})
And as a result, I got this in the log file:

Image

There's a lot of vars not properly being declared as local!

orzelek
Smart Inserter
Smart Inserter
Posts: 3911
Joined: Fri Apr 03, 2015 10:20 am
Contact:

Re: Not desync safe!

Post by orzelek »

Do you have any idea why it would suddenly become a problem?

It's been like that from quite some time and there were no desync reports. So either people are not reporting the desyncs or there is something else happening.

I can fix those but I'm not sure if it will help with your desync problems.

User avatar
eradicator
Smart Inserter
Smart Inserter
Posts: 5206
Joined: Tue Jul 12, 2016 9:03 am
Contact:

Re: Not desync safe!

Post by eradicator »

I don't see why using globals would be any more or less desync prone than using locals. Care to explain?

orzelek
Smart Inserter
Smart Inserter
Posts: 3911
Joined: Fri Apr 03, 2015 10:20 am
Contact:

Re: Not desync safe!

Post by orzelek »

eradicator wrote:I don't see why using globals would be any more or less desync prone than using locals. Care to explain?
I think it's because global context is not synchronized in multiplayer - so any connecting client will have it clean. And local guarantees that variable won't be reused in other location (even by accident) since it won't exist there.

I did found an actual bug thanks to that debug code.

orzelek
Smart Inserter
Smart Inserter
Posts: 3911
Joined: Fri Apr 03, 2015 10:20 am
Contact:

Re: Not desync safe!

Post by orzelek »

I fixed all the issues I could find with your debug code in new version.

I have one question - if I use rso-regenerate command from console this debug code will write that regenerateCommand global is used before being defined. But it's a name of defined function so I have no idea why it writes that. Any idea what would be causing this?

User avatar
Mylon
Filter Inserter
Filter Inserter
Posts: 513
Joined: Sun Oct 23, 2016 11:42 pm
Contact:

Re: Not desync safe!

Post by Mylon »

orzelek wrote:I fixed all the issues I could find with your debug code in new version.

I have one question - if I use rso-regenerate command from console this debug code will write that regenerateCommand global is used before being defined. But it's a name of defined function so I have no idea why it writes that. Any idea what would be causing this?
The debug could should be called as the last thing before the game starts. So at the end of control.lua. Unless you have some strange logic that calls a "require" after the game starts, you might just be setting up your meta table too soon.

orzelek
Smart Inserter
Smart Inserter
Posts: 3911
Joined: Fri Apr 03, 2015 10:20 am
Contact:

Re: Not desync safe!

Post by orzelek »

Mylon wrote:
orzelek wrote:I fixed all the issues I could find with your debug code in new version.

I have one question - if I use rso-regenerate command from console this debug code will write that regenerateCommand global is used before being defined. But it's a name of defined function so I have no idea why it writes that. Any idea what would be causing this?
The debug could should be called as the last thing before the game starts. So at the end of control.lua. Unless you have some strange logic that calls a "require" after the game starts, you might just be setting up your meta table too soon.
That explains it - I moved it up top. I'll leave it at the bottom (it's commented out anyway since I don't intend to keep it running other then for dev testing).
And thanks for the code - metatables are a bit magic for me that I don't intend to learn for now - I'm more of C++/C# person :D

Post Reply

Return to “Resource Spawner Overhaul”