[HN Gopher] Bytecode Breakdown: Unraveling Factorio's Lua Securi...
___________________________________________________________________
Bytecode Breakdown: Unraveling Factorio's Lua Security Flaws
Author : memcorruption
Score : 302 points
Date : 2024-06-29 12:35 UTC (10 hours ago)
(HTM) web link (memorycorruption.net)
(TXT) w3m dump (memorycorruption.net)
| gjsman-1000 wrote:
| At this point, I have serious doubts whether bytecode and JIT
| systems, whether it be Lua in Factorio or JavaScript in Chrome,
| can ever be verifiably secure. I think we would all be better off
| if, like Apple's Lockdown mode, we can disable anything JIT on a
| high stakes system.
|
| I don't blame Factorio though - this (anonymous?) researcher is
| 100x developer material.
| stavros wrote:
| How is JIT relevant here? Unless I missed something, the attack
| uses straight-up malicious byte code, it doesn't exploit the
| JIT compiler.
| gjsman-1000 wrote:
| JIT and Bytecode are two sides of the same coin, in my head.
| JIT also uses bytecode in some languages like Java.
| fwsgonzo wrote:
| It's much worse than that because of the complexity around
| JITs, behavior of hardware and speculative execution.
| Proper sandboxing is really hard, and I suspect that if
| people really want security they would disable JIT in
| general. Even simple ones like pcre2. Personally I have
| disabled Firefox's JIT (I believe it's called ion in the
| settings, but correct me if I misremember) for a few years
| now. I've never had any trouble with any websites so far.
| It's not instant loading, but it's close enough.
|
| ... but I don't know if I would lump bytecode with JIT.
| Bytecodes don't need or use RWX execute segments, for
| example. Lots of your favorite JITs do, for speed.
| nanidin wrote:
| In this case someone generated malicious bytecode that the
| JIT compiler would not generate.
|
| I would argue JIT is dangerous because it requires dynamic
| memory without the NX bit set, so if you manage to smash
| the stack (find an exploit) you can execute arbitrary code
| easily (leverage the exploit). That's a different dangerous
| than running malicious bytecode.
| colejohnson66 wrote:
| JITs can still function with an NX bit; You just have to
| halt execution to modify it.
| axoltl wrote:
| This doesn't generally apply but Apple has a bunch of
| hardening in place that means you don't just have an RWX
| mapping hanging around:
|
| https://developer.apple.com/documentation/browserengineki
| t/p...
|
| On top of that they're working on (I haven't checked in a
| bit) having the JIT compiler be entirely Out-Of-Process.
| I don't think a lot has been written about that publicly
| but there's a few breadcrumbs like https://developer.appl
| e.com/documentation/kernel/oop_jit_con...
| pjmlp wrote:
| All modern compilers use bytecode, in one form or the
| other.
| binary132 wrote:
| I would take a look at BPF.
| olliej wrote:
| The issue here isn't things being "verifiably secure".
| languages like js and lua run in a sandboxes environment where
| the only functions and operations that are permitted are those
| explicitly added by the host environment. Those sources
| languages are easily validated as correct _code_.
|
| [edit: I realize I should clarify something "correct" and
| "verifiable" here do not mean "bug free", it means 'cannot
| interfere with or violate language or environment state,
| memory, or other invariants']
|
| The issue here is that the hosting environment is allowing the
| user/attacker to provide the bytecode that is generated from
| the provably correct code. That byte code is not itself
| verifiable statically, and is not verified at runtime (and it
| might not even be possible to).
|
| This is not to say that bytecode is not verifiable - Java,
| .NET, or even WASM (which is intentionally very low level) are
| verifiable bytecode environments. The issue is that a byte code
| must be _designed_ to be verifiable (and early Java bytecode
| was not due to JSR or similar iirc). Lua's bytecode is designed
| for execution, and so allowing arbitrary bytecode execution is
| not too dissimilar from a JS engine allowing a website to
| provide direct access to their bytecode interpreter which would
| be similarly catastrophic.
| dfox wrote:
| The issue is not really about the verifiability of the
| bytecode but about the interpreter checking the invariants.
| JVM bytecode is intentionally designed to be verifiable so
| that the inner loop of the interpreter does not need to care
| about whether the operation is executed with correctly typed
| operands (which in the JVM case would be highly impractical
| and would essentially mean that you need twice the amount of
| memory). You can design a system where the bytecode is not
| verifiable, but instead the checks are done at runtime,
| CPython works that way.
| cedws wrote:
| JIT has not been secure since Spectre and Meltdown.
| est31 wrote:
| In general, verifying programs is extremely hard, not just
| because of rice's theorem but because it's so easy to miss a
| spot, especially for non-trivial bytecode languages like lua's.
| wasm has no concepts of for loops for example.
|
| It's strange that after upstream has given up on the problem as
| it was too hard, factorio devs have chosen to try to fix the
| verifier/write their own (not sure which of the two they did).
|
| Minetest's loadstring function forbids bytecode entirely:
| https://github.com/minetest/minetest/blob/9a1501ae89ffe79c38...
|
| I wonder why factorio mods need the ability to execute raw lua
| bytecode. If they don't have it, there would be no need for a
| verifier.
|
| It's quite dangerous in the first place to execute lua code
| downloaded over the network. JS execution environments have gone
| through decades of cycles of discoveries of exploits and fixes.
| Lua gets those as well but on a smaller scale, and with less
| staffing to improve security. The main protection is I guess that
| there is fewer people running malicious game servers.
| marcosdumay wrote:
| Factorio has stuff like this:
|
| https://mods.factorio.com/mod/Moon_Logic
|
| Besides, it's quite limiting to create software that can't just
| execute in a Turing complete environment.
|
| Anyway, we really need interpreters that include a strong
| capability system.
| gjsman-1000 wrote:
| "If I ran the business" (TM), I would just put it in Factorio
| settings as a toggle switch called "Reduced Security Mode -
| Allow Lua Bytecode." By default, it's turned off. People who
| really want those mods can turn it on, as long as they are
| informed (UAC prompt style) that they better trust the mod
| authors. I'd also add an API for mod authors to detect if
| bytecode access is enabled; so they can make their mods
| compatible with either environment.
|
| Or maybe, down the road, Factorio could enable mods with
| greater privileges, as long as they are open source, and do
| an App Store-style review process with the community.
| Approved mods get not just bytecode, but perhaps even some of
| the typically forbidden modules like filesystem access.
| Unapproved mods using those enhanced privileges won't run
| without a startup flag.
| hypeatei wrote:
| > By default, it's turned off. People who really want those
| mods can turn it on
|
| This works until a popular mod requires it (for legit
| reasons) then enabling the option becomes the de-facto
| standard for people who install mods.
| grogenaut wrote:
| It's possible to make it so you enable it on a per mod
| basis, like app permissions
| TylerE wrote:
| Because that's never ever been a total usability disaster
| that just encourages people to enable every one because
| they don't feel like fighting it. It's also not
| effective, given how tightly tied mods are to the core
| API.
| vsuperpower2020 wrote:
| When you're talking about security, adding a bunch of
| config flags for users is never a good idea. Most users
| aren't going to understand what it does, and like others
| mentioned, there's too many reasons to turn it on.
| dividuum wrote:
| OP only refers to bytecode. There's nothing wrong with
| executing Lua when provided to the VM via source code. The
| only reason to allow the VM to load bytecode directly is 1) a
| very minor improvement in loading time, as the interpreter
| then doesn't have to parse Lua code into bytecode itself 2)
| allowing obfuscation of logic running within Factorio. Both
| seem rather irrelevant, so I'm not sure why they allow
| loading bytecode directly.
| Therenas wrote:
| Factorio disabled bytecode loading in response to this.
| Bytecode did allow for some cool stuff like writing mods in a
| preprocessor language that spits out Lua bytecode, but
| ultimately the security issues were more important to address.
|
| Almost all of the debug library was made unavailable to mods as
| well, for similar security reasons.
| gjsman-1000 wrote:
| Citation?
|
| Factorio 1.1.101 (which the blog post says included the fix)
| does not list any changes regarding the disabling of bytecode
| or restricting the debug library. This would have been
| notable news, even without admitting the security risk.
| Factorio 1.1.107 does mention disabling the debug library,
| but it doesn't seem this article had anything to do with
| that.
| Therenas wrote:
| I work on the game. The debug library was disabled for
| other security holes that were brought to our attention, so
| it wouldn't be related to this, but I thought it was
| interesting to mention.
|
| I believe the change was not mentioned in the changelog as
| an attempt at 'security through obscurity', trying to avoid
| people getting any ideas before the update is wide-spread.
| Not sure that helps any, but still.
| deely3 wrote:
| Sorry, but thats just a perfect example why 'security
| through obscurity' is wrong. I have zero idea about
| security risks, but if fix does not mentioned anywhere,
| then for people that use previous version there no rush
| to upgrade.
| Therenas wrote:
| I don't disagree.
| ethbr1 wrote:
| Arguments either way. Generic "security vulnerabilities
| addressed" in release notes is a nice balance.
| TillE wrote:
| > no rush to upgrade
|
| I suspect the overwhelming majority of Factorio players
| are using Steam, which auto updates.
| magicalhippo wrote:
| Factorio is special though, because it actively uses the
| beta version functionality in Steam to not only provide
| betas but also older stable versions. This allows the
| devs to move fast and break things.
|
| I know I've held back my copy of Factorio due to some
| concern over changes in newer versions, preferring to
| letting the dust settle before upgrading to the latest
| stable version.
| kevincox wrote:
| Due to the need for perfect synchronization all users
| need to be using the exact same version. Mods can also
| break between versions. It is therefore very common for
| public servers to stick on one version for extended
| periods of time. It is common for people to use the Steam
| "betas" functionality to pick an exact version or
| download an exact version from the Factorio website.
|
| I would say that servers only tend to update when large
| features are released. So announcing a security
| vulnerability would likely push some servers to update.
| wruza wrote:
| Loading raw bytecode is known to be unsafe, and iirc that is
| mentioned in lua_load/luaL_load* documentation.
|
| A preprocessor could spit out Lua code with the same effect
| and less complexity. Really interesting why and how these
| decision were made.
| mananaysiempre wrote:
| For what it's worth, Metalua also generated PUC-Lua
| bytecode directly instead of source code, making it
| incompatible with LuaJIT (which might have been part of the
| reason why it died).
| JustAPerson wrote:
| Eventually every game developer learns the hard way that they
| must remove the bytecode ability from lua's loadstring()
| function.
|
| E.g. here's a 12 year old blogpost on the topic from the ROBLOX
| developers: https://archive.is/oXPyM
|
| To be honest, it would probably be better off disabled by
| default. Its legitimate uses are pretty niche.
| wruza wrote:
| Yep, its place is in luaconf.h really.
| tialaramex wrote:
| > not just because of rice's theorem
|
| I don't think Rice is relevant at all. I guess Rice is a useful
| first screen. Do you believe you can "just" Decide this
| correctly? If so, Henry Rice got his PhD half a century ago for
| proving you can't do that, stop.
|
| But assuming you've made your peace with accepting only a
| _subset_ of the inputs that would actually meet your
| requirements, Rice is done. And you 're right - now instead of
| an impossible task you've just got an _extremely hard_ task.
| This means when you fail (which you will) at least nobody will
| tell you it was impossible, if that helps?
|
| Factorio should not have done this.
| dfox wrote:
| This idea of accepting some kind of subset is exactly what
| JVM does. There is a set of rules (IIRC 29 of them) that the
| JVM bytecode have to follow to be accepted, the one important
| rule is "stack entries should always be used as a same type",
| the rest of the rules are there so that this can be
| statically checked.
| Dylan16807 wrote:
| > rice's theorem
|
| That doesn't apply here. By the broad definition of "syntax"
| that Rice's theorem takes, the things you want to verify on the
| bytecode are syntax.
| josephcsible wrote:
| IMO, Lua bytecode should never be usable anywhere outside of
| embedded systems that don't have enough resources to run the Lua
| source code parser. Besides security vulnerabilities, the only
| other thing it seems to be useful for is closed-source programs.
| BeefySwain wrote:
| Unless I missed it (I admit I skimmed towards the end) The author
| does not discuss at all the actual remediation that was taken. I
| would love to hear more about that.
| duskwuff wrote:
| The remediation was:
|
| 1.1.104: https://github.com/Rseding91/Factorio-
| Lua/commit/4d924b69808...
|
| and
|
| 1.1.107: https://github.com/Rseding91/Factorio-
| Lua/commit/ce12474c7fc...
|
| The most relevant part was the change to luaB_load in 1.1.104
| which simply disabled bytecode loading.
| hypeatei wrote:
| Factorio has a really good dev team behind it so I trust that
| they're doing their best to fix these issues. Though, gamedev in
| general seems to be more of a creative endeavor which puts things
| like code practices and security on the back burner. I wonder how
| many zero day exploits are lurking in game clients / servers.
| gjsman-1000 wrote:
| Most likely, it's not very good. Why do you think every console
| manufacturer, from Xbox to Sony to Nintendo, does not allow
| connecting to arbitrary server IP addresses or modding support?
|
| It's not merely a business decision (like some believe) to
| force people to use official Online services. Think about it:
| Restricting connecting to third-party server IPs means that any
| bugs in the network code, or in the rest of the game, even
| atrocious ones, will never be exploited. Restricting mods (even
| "safe" mods like Lua) further prevents exploits. This makes
| sense - buggy network code has tanked multiple consoles's DRM
| historically.
|
| And not just exploits - these consoles pride themselves on
| doing their review process before the code becomes available
| (despite oversights). Allowing executing of Lua, from a remote
| system, basically means a game could be reconfigured remotely
| after approval potentially from the developer themselves - not
| something any console manufacturer wants to permit without very
| close inspection.
| cedws wrote:
| Yeah, best to keep a separate computer for gaming for this
| reason. Definitely don't put important documents or work stuff
| on it. It would be ideal to isolate it in a VM, but setting up
| a gaming VM can be a massive pain in the ass and exclude you
| from some games that use anticheat.
| kevincox wrote:
| Yup. Intend to assume that any game with remote interaction is
| completely insecure. It is best to run Steam and all games in
| some sort of sandbox.
|
| Flatpak is probably a helpful start. While containers aren't a
| strong security boundary at least simple exploits won't work.
| vsuperpower2020 wrote:
| Code practices? Factorio is one of the most well programmed,
| stable, and consistent piece of software I've ever seen. It's
| almost a shame to see skilled people work in games because of
| how desperately other fields need people who are good at
| programming.
| hypeatei wrote:
| See my comment: > Factorio has a really good dev team
|
| I wasn't talking about the Factorio devs specifically but
| about the gamedev industry as a whole.
| CapsAdmin wrote:
| I wish this was more defined or documented somehow. You're kind
| of left on your own to figure out whether a language is
| reasonably guaranteed to be safe or not.
|
| Some example scenarios:
|
| - Code is static and is executed directly by a user, the default
| case languages care typically care about. Including Lua.
|
| - Code is dynamically fetched and executed through some update
| process, hopefully only through official channels. Here you can
| get away by making the process secure, but who knows.
|
| - Code can be added by the user through plugins, this can be made
| easier through stores with the click of a button. You can review
| plugins, but this is hardly done. Here you need to consider if
| the code should be sandboxed or the user should be careful.
|
| - A multiplayer game where a server can be extended with custom
| code via plugins, but not the clients. Here you need to consider
| that the users/gamers who are hosting servers are eager to try
| many different plugins. The plugin community (gamers) can also be
| a lot more dangerous.
|
| - A multiplayer game where the server can execute arbitrary code
| on clients, just like a browser. Here you need to be very careful
| about sandboxing, especially on clients as gamers will just join
| random servers without thinking about the security implications.
|
| The last point being Factorio's case. I'm not necessarily
| disagreeing that it's the developers job to evaluate this, but
| sometimes it's not obvious that for example the load function in
| Lua can run arbitrary bytecode which is unsafe.
|
| To be honest, I wasn't aware that Lua's bytecode is unsafe, but I
| am aware that LuaJIT's bytecode is unsafe. But as far as I know
| this fact is just stated randomly in the mailing list and github
| issues as an obvious fact.
|
| There is another thing about servers being able to crash clients
| (just run some infinite loop on them), but this much harder and
| maybe pointless to avoid.
| hypeatei wrote:
| > A multiplayer game where a server can be extended with custom
| code via plugins
|
| A game called Mordhau (based on Unreal engine) had a built-in
| "message of the day" feature where server owners can put in a
| URL that loads an in-game browser when the player connects. No
| client side option existed to disable the browser and I believe
| the devs eventually disabled it completely but I'm not sure the
| status of it now.
|
| Just shows how complex games / game engines are getting where
| you have an embedded web browser for seemingly no good reason.
| zachrip wrote:
| A lot of games have web browsers embedded nowadays for ui
| dfox wrote:
| Unreal Engine has something that can be called embedded web
| browser since the day one. The original Unreal Engine is this
| thing that has its own implementation of "something not
| entirely unlike JVM" and refers to various things by means of
| URLs.
| ooterness wrote:
| The game "Tabletop Simulator" allows you to spawn various
| objects into a VR playspace. One of the objects is a tablet
| PC, which displays a little web browser on its virtual
| screen. It's handy to look up rules or whatever without
| leaving VR.
|
| The last time I tried this, the browser had a notification
| that it was out of date and needed updates.
|
| Thinking about this broke my brain a little. I have no idea
| how to apply software updates to the virtual browser on the
| virtual tablet running in a virtual room simulated by my
| (hopefully real) PC.
| fwsgonzo wrote:
| The first thing to look for is if the solution states clearly
| that it is a speculation-safe sandbox. I do think that not many
| will do that, but there are some. And go from there.
| chc4 wrote:
| You should never assume any method of executing any attacker
| controlled code is safe, unless something explicitly calls that
| out and also has put Google-level amounts of effort into
| supporting that.
| ec109685 wrote:
| Is it impractical to employ firecracker vm like separation to
| isolate untrusted code, severely reducing the impact of any bugs?
|
| Browsers split their various components across multiple processes
| to provide isolation. VMs would provide even more isolation.
| fwsgonzo wrote:
| That's what they do. They add additional layers on top of the
| sandbox like jailing. You can jail your sandboxes, but it's not
| so easy to make that a multi-platform solution for gaming. I
| think for games I would just stick to a fast interpreter and
| apply some generally appropriate measures to discourage timing
| attacks.
| cedws wrote:
| We are seriously lucky such capable people are on the good side.
| bbor wrote:
| As a non-security dev, I'll drop the obligatory "wow this is
| incredibly impressive!" I can't believe how clear and logically
| you'd have to think to track down these intricate failure cases.
| Definitely not my strong suit! I'm much more of an "ideas guy" ;)
|
| Content-wise: Wow... We are totally, completely, utterly screwed
| once people start putting together ensembles of AI SWEs equipped
| with 10,000 blog posts like this one on finding weird memory
| exploits. Ultimately I think we're gonna need a whole new
| paradigm for security, or at least some new element in the stack.
| It's my potentially naive opinion that all the modern talk about
| "trusted" clients and DB roles and all that is trying to patch
| holes in swiss cheese; hopefully, we can find a new stack of LLM-
| maintained swiss cheese to add on instead!
| saagarjha wrote:
| People are doing it. The results have yet to be promising.
| therobots927 wrote:
| I literally just downloaded a factorial demo to my work laptop.
| Is this something I need to be concerned about if I don't play
| online?
| IggleSniggle wrote:
| No.
| therobots927 wrote:
| Thanks
| vessenes wrote:
| Yes, but only because you might lose your job from playing too
| much factorio. :) the exploit was not a risk for vanilla
| unmodded single players, and has been patched in any event.
| therobots927 wrote:
| Awesome! Yeah we'll see I may not be able to start playing
| until I get moved to a boring / less intensive project. I
| started playing and it felt identical to my day job which is
| why I wanted to try it but after a day of coding I just
| wasn't up for it haha
| davikr wrote:
| Never enable in your Lua apps:
|
| a. Bytecode
|
| b. Debug, Io, Os libraries
|
| ...
|
| Also, be very careful with sandboxing. It can be deceptively easy
| to break out of.
|
| Everyone eventually learns this lesson, see: Roblox (removed
| bytecode almost a decade ago after, if I recall correctly, an
| exploit exfiltrated their server tokens), Company of Heroes
| (bytecode bug leading to RCE)
|
| Luau should come with safe defaults, from what I've been told.
| chc4 wrote:
| Yup. I'm the one who did the Roblox bytecode exploit that lead
| to it being disabled: the specific attack there was that
| getmetatable internally leaves the metatable value on the Lua
| value stack even if it ends up returning the __metatable locked
| message, which you could retrieve with a crafted bytecode
| chunk. I leveraged that into getting the metatable for the
| global environment, which was the entire Lua standard library,
| and crucially the _same_ table across Roblox 's script
| permission levels. Roblox used "context levels" for seperating
| priviledge Lua scripts, which interacted with the server API
| endpoints, and normal game logic. By poisoning the priviledge
| context's metatatable with my own functions I was able to
| capture the server endpoint URLs and accesskey, along with
| things like send arbitrary HTTP requests to their CDN from the
| server to steal any place file. This easily could have been
| arbitrary RCE on their servers instead: the crafted bytecode
| chunk attack for getting a r/w primitive from for loops was
| published a little bit before this attack happened, IIRC, but
| there was a lot of less CTF style writeups about Lua internals
| and I was, like, 15 and an idiot.
|
| In practice it's really hard to sandbox arbitrary user
| controlled scripts. Even after this I found a half dozen other
| bugs in their Lua<->C++ bindings that you could leverage into
| server code execution. V8 and other browser engines still
| having JIT bugs and DOM manipulation exploits every other week
| should terrify any developer who thinks "oh I'll let my users
| do a bit of scripting".
| bhk wrote:
| So... this demonstrates an exploit that relies on a feature that
| is advertised as exploitable: loading byte code. What am I
| missing?
| tsujamin wrote:
| That advertised features can still cause harm to end users,
| particularly those who don't know what Lua or bytecode are?
| armchairhacker wrote:
| It's possible that the bytecode interpreter has a bug that lets
| one run arbitrary bytecode, even in environments where
| `loadstring` is disabled.
| josefx wrote:
| The interesting takeaway I got was how badly the Lua developers
| failed on their bytecode veryfier. Not some complex issues, but
| simple ones like of by one errors when modelling basic
| instructions like jmp or the issue that the Lua interpreter
| would try to interpret anything it got its hands on as
| instructions, even data sections the veryfier would not touch.
| JonChesterfield wrote:
| Unexpected!
|
| Since lua interprets bytecode, it can check the arguments to the
| bytecode are meaningful. Point to memory lua allocated, things
| like that.
|
| Turns out it doesn't do that. Feed it bytecode with invalid
| arguments passed to the instructions and it executes it anyway.
| The rest of the compromise follows.
|
| Further, instead of fixing their interpreter, the game plan is to
| statically analyse bytecode. Which turns out to only work in
| simple cases.
|
| For a sandbox friendly interpreted language this is pretty
| disappointing. I wonder if they'd take patches to stop the
| interpreter trusting the input - presumably performance
| regression is the fear there, which seems dubious when luajit is
| the fast option anyway.
| AHTERIX5000 wrote:
| Sandbox friendly?
|
| It's not exactly a simple task to make safe interpreter for
| bytecode as some other languages have shown. It's a trade-off
| which also simplifies the reference implementation.
|
| I wouldn't trust most of these interpreters when it comes to
| third party code execution, I barely trust my browser even with
| all the R&D money and attention web browsers receive.
| JonChesterfield wrote:
| Sandboxed in the sense that things like file i/o or network
| access can be easily removed and selectively reintroduced,
| e.g. to give an interpreter which can trash it's own heap but
| can't do anything to the host.
|
| Bounds checking on instruction opcodes can absolutely be
| implemented in an interpreter. I suppose it's more
| complicated than just trusting the integer - but then the
| thing doesn't fall over on malformed bytecode which seems
| like a feature.
| haberman wrote:
| > I wonder if they'd take patches to stop the interpreter
| trusting the input
|
| The stance of the Lua developers AIUI is that processes that
| execute arbitrary Lua code should only accept source, and
| disable direct loading of byte code.
|
| This seems reasonable to me, as it preserves the option of
| directly loading trusted byte code, while avoiding putting
| dynamic checks into the interpreter that would affect all
| users.
| quenix wrote:
| I'm confused about one thing.
|
| It doesn't follow to me, that since all clients are running their
| own simulation, Lua scripts must run on every client too.
|
| If a client runs a Lua script, why can't we just run it on their
| machine and propagate any game state changes (if the script adds
| an inserted, for example,) as if the player made those changes
| themselves?
| nmeofthestate wrote:
| If clients don't run the same code they will desync the moment
| their state diverges. I haven't played multiplayer factorio but
| I expect you can't even join a server unless you're running the
| same factorio version and mods as other players.
| duskwuff wrote:
| > If a client runs a Lua script, why can't we just run it on
| their machine and propagate any game state changes (if the
| script adds an inserted, for example,) as if the player made
| those changes themselves?
|
| The game already has to run Lua scripts as part of the
| simulation, potentially as part of in-game events which aren't
| directly triggered by players. A player running a script from
| the console is handled by that same interpreter -- making it
| run in a completely different operating mode where any changes
| to game state are replicated would be much more complicated and
| prone to error.
|
| Or, from the other direction: the game's multiplayer model is
| all based around a replicated simulation where player inputs
| are fed into the simulation. Treating a player running a script
| as a special kind of event involving the text of that script is
| the simplest and most obviously correct way to implement that.
| armchairhacker wrote:
| The mechanism Factorio uses is to sync user inputs, not game
| state changes (the reason isn't explained, but I strongly
| suspect it's because user inputs are less data; small inputs
| can cause big game state changes, but not vice versa).
|
| If the user types a command, in order to preserve
| synchronization, the game must:
|
| - Run the command on all other clients.
|
| - OR it could sync changes made to the game for just commands;
| in other words, the other clients apply the changes caused by
| the command instead of running the command directly. But that
| would be an unreasonable amount of extra work just for a small
| feature and to make exploits harder.
|
| - OR the server simply disallows clients from running Lua
| commands, which is the case for some servers.
|
| I don't get the second part though: why a map can store
| arbitrary Lua code that runs when the map loads.
| BlueTemplar wrote:
| Scenarios that don't require a mod ?
|
| (Some time ago, Factorio did not have a built-in mod
| synchronization system for multiplayer, with the result that
| the most popular servers did not run any mods, but rather
| used complicated scenarios instead.)
| bamba2012 wrote:
| Hello
___________________________________________________________________
(page generated 2024-06-29 23:00 UTC)