DeepCopy

[NoriSilverrage]

Does anyone know why this works:

local lr1 = util.table.deepcopy(data.raw["transport-belt-to-ground"]["basic-transport-belt-to-ground"])

But this doesn't?

local lr1 = deepcopy(data.raw["transport-belt-to-ground"]["basic-transport-belt-to-ground"])

I setup a few deepcopy entries and they were working fine with the modlist I had. However, I discovered that if I removed every mod, all of a sudden the above didn't work (erroring on deepcopy) and I had to add the util.table. part to it.

[Choumiko]

Not sure how sandboxing in data.lua works, but this sounds like some mod added a deepcopy() function

[orzelek]

Not sure how sandboxing in data.lua works, but this sounds like some mod added a deepcopy() function

Original function is table.deepcopy. Other one is added by one of mods loaded before your mod - all those are visible to all lua users unless they have local specifier (AFAIK).

[Adil]

Nope, it just cannot be so. It'd be a total wreck with nameclashes. Also, there is a reason modders have to use remote.-module to communicate between the modules.
I won't be able to track a quote but someone from the devteam said that every mod is sandboxed in its own confinement. As I've tested right now, even commonly required files are loaded for mods as independent copies.

@NoriSilverrage
I just cannot understand what situation exactly is happening in the op.
Can't you just find out which mod exactly allowed that code to work?

[NoriSilverrage]

Hmm, I'm not really sure. If I remove boblogistics it errors. But I see no reference to deep copy in any of his files... But oddly if I have that mod plus boblibrary, it still throws a error.
Oh well. At least I know the proper deep copy.

@Adil - Name clashes? That deepcopy command doesn't show the rest of the file which renames that local variable. So no duplicates.

Thanks for the answers

[Adil]

@Adil - Name clashes? That deepcopy command doesn't show the rest of the file which renames that local variable. So no duplicates.

That refers to function names. If every mod did put it's stuff into shared environment, they'd might have quite a bunch or same named functions and global variables. Then those would be overwritten and only last mod would be functional at best.

[orzelek]

@Adil - Name clashes? That deepcopy command doesn't show the rest of the file which renames that local variable. So no duplicates.

That refers to function names. If every mod did put it's stuff into shared environment, they'd might have quite a bunch or same named functions and global variables. Then those would be overwritten and only last mod would be functional at best.

Please take a look at how bob's library mod works - it simply defines the functions and mods that load after it can use them.
There is no 100% sandbox - each mod has it's own global table but funciton space is the same.

[DaveMcW]

data.lua is global.
control.lua is sandboxed.

[bobingabout]

There's a reason I use the bobmods. prefix, it's so that I can keep my variables and functions organised so they don't conflict with other mods.

Though, some of my older functions that are included directly in the mod just have a bob_ prefix. Same reason, but not as secure.

Still... None of my mods add a deepcopy() function, I can't be sure if I've ever even used it (Yet. Though I do see why it would be useful), in most of the situations I've seen deepcopy() being used, I either just use a = (Because being a copy, or referencing the original doesn't matter, it's usually done in cases where the original is discarded), or use a function that returns the table (A table defined in raw data, meaning it is constructed every time the function is called, meaning every instance is a unique copy of the table)