Page 1 of 1

Protect game tables and Lua libraries during data stage

Posted: Tue May 07, 2019 6:19 am
by eduran
Not really an interface request, but I did not know where else to put it.

Would it be possible to prevent mods from overriding built-in game tables and Lua libraries during the data stage? If one mod does something stupid like "math = 0", all following mods are in trouble. Ideally the responsible mod should throw an error, not the mod trying to access "math". You can even do stuff like settings = 0 or data = 0.

I know it will result in an error either way, but it would be nice if reports like this were directed towards whoever overrode debug, instead of my mod.

Re: Protect game tables and Lua libraries during data stage

Posted: Wed May 08, 2019 2:04 am
by Nexela
Seconded! for debug at least.

Re: Protect game tables and Lua libraries during data stage

Posted: Wed May 08, 2019 8:36 am
by eradicator
Thirded.
And for table/string at least, so ppl don't inject their own shitty code.

Re: Protect game tables and Lua libraries during data stage

Posted: Wed May 08, 2019 5:10 pm
by Rseding91
I'm not against the idea but Lua includes no such "protection" system so I would have to add it and then it's going to incur a performance overhead for every single global assignment for the rest of time.

Re: Protect game tables and Lua libraries during data stage

Posted: Wed May 08, 2019 6:14 pm
by eradicator
I welcome our new local variable overlords. :D
Would it make *reading* globals slower too?
(And just for the record, the protection is only needed for settings/data stage, so in control everybody could still be free to shoot themselfs in the foot?)

Re: Protect game tables and Lua libraries during data stage

Posted: Wed May 08, 2019 6:18 pm
by eduran
Maybe something along those lines, for data stage only?
eradicator wrote:
Wed May 08, 2019 6:14 pm
so in control everybody could still be free to shoot themselfs in the foot?)
No problem with that. But during the data stage, everyone's feet are at risk :D

Re: Protect game tables and Lua libraries during data stage

Posted: Wed May 08, 2019 8:09 pm
by Rseding91
eduran wrote:
Wed May 08, 2019 6:18 pm
Maybe something along those lines, for data stage only?
eradicator wrote:
Wed May 08, 2019 6:14 pm
so in control everybody could still be free to shoot themselfs in the foot?)
No problem with that. But during the data stage, everyone's feet are at risk :D
That doesn't protect if someone does math = nil. It only protects if someone does math.random = nil.

Re: Protect game tables and Lua libraries during data stage

Posted: Thu May 09, 2019 6:56 am
by eradicator
Rseding91 wrote:
Wed May 08, 2019 8:09 pm
eduran wrote:
Wed May 08, 2019 6:18 pm
Maybe something along those lines, for data stage only?
eradicator wrote:
Wed May 08, 2019 6:14 pm
so in control everybody could still be free to shoot themselfs in the foot?)
No problem with that. But during the data stage, everyone's feet are at risk :D
That doesn't protect if someone does math = nil. It only protects if someone does math.random = nil.
Or against setmetatable(_ENV,nil) or rawset(_ENV,math,nil). :twisted:

Re: Protect game tables and Lua libraries during data stage

Posted: Thu May 09, 2019 7:07 am
by mrudat
Perhaps a sanity check after a mod is run that the expected globals are still there?

Re: Protect game tables and Lua libraries during data stage

Posted: Thu May 09, 2019 7:17 am
by eradicator
mrudat wrote:
Thu May 09, 2019 7:07 am
Perhaps a sanity check after a mod is run that the expected globals are still there?
I like that vector. No need to do expensive checks. Just reset all global libraries to default after each mod. That way they can still shoot their own feet, but won't affect anyone elses.

Re: Protect game tables and Lua libraries during data stage

Posted: Thu May 09, 2019 7:26 am
by darkfrei
Why we cannot just insert tables to data.raw? It looks like read-only table.

Code: Select all

data.raw = {new_type = {type = "new_type", name = "new-name"}}
Or

Code: Select all

table.insert (data.raw.inserter, {type = "inserter", name = "new-inserter"})