hyiltiz

For those who are wondering, the image has no secret invisible data hidden in it (using steganography). Would be awesome to see some QoL (quality of life) update, using LuaJIT such that the game runs more smoothly and ideally taking less RAM (and disk space).

This led to my dedicated server getting stuck while starting (it shows full screens of "Could not find anim build FROMNUM" and the VPS no longer responds to any key presses. Had to restart the VPS from the online web interface.

CPU, RAM, OS version, hard disk I/O speed, size, network I/O speed and network load per second of average gameplay per player etc.

You forgot to say ... Notorious

I am asking [1] for a method to do this on client/user side but it seems (almost) impossible. If only Klei would compile DST against LuaJIT and see how it went. [1] https://stackoverflow.com/questions/59893657/overload-inject-the-lua-runtime-of-a-compiled-program-with-custom-lua-luajit?noredirect=1#comment105915502_59893657

LuaJIT official site says [1] running lua 5.1 (DST runs lua5.1) compatible code with LuaJIT should require no changes to the source at all; that may not have been true a few years ago. [1] http://luajit.org/status.html

That was LuaJIT 3 years ago. Assuming LuaJIT got more feature complete over these years, it may be possible to migrate with minimal effort? As I understand, it is quite common to hack lua the language, aka its interpreter, for lrge lua apps to expose or adjust some internal behavior. If Klei also uses those methods, I wonder if those are still possible to apply to LuaJIT.

Been over 3 years since [1], so what are the roadblocks? Arguably LuaJIT got more mature but the game got richer so even more justifies aiming for performance.

I've been looking into saving game state to file system. Specifically, serialize all the lua tables relevant to the game state into json. This will pose two obvious challenges: a) some game objects may be recursive; b) functions cannot be sensibly serialized in general. There are quite a few libraries and methods to go about this [1]. And the game already uses a few methods (namely `./scripts/json.lua` and `./scripts/inspect.lua`). The idea is that we can iterate over the common game tables such as `TheWorld`, `ThePlayer`, `TheNet` etc. recursively, and convert each key-value pair into string, indenting appropriately. This is already implemented in `debugtoosl.lua:dumptable()` as well as `table.inspect()` both of which can serialize/convert a `lua_object` into `String`, which can then be printed or saved into a file. The issue is, when I tried `table.inspect(ThePlayer)`, or `table.inspect(ThePlayer.components)` or even `table.inspect(ThePlayer.components.Builder)`, the game simply ate all my 8G of RAM and got killed by the OS. I wonder if it would be possible to write to a file incrementally instead of creating the whole representation in RAM, holding the string in RAM then writing it to a file. Using common tools to inspect (deeply nested) `json` data, it would make it easier for Modders to learn about how this game works in general and would prove to be a very good mental model and guideline for reading and modding the game source code. In the end, I'm looking to get something like this (after loading the `json` into some `json` inspector; heck even Chrome can inspect `json` files with tree-like inspection support): _G ├── TheNet ├── ThePlayer │ └── Components │ └── Builder └── TheWorld └── SeasonManager p.s. This would also make tools like DSTed [2] very powerful, enabling users to traverse game state that was stored during game play. [1] http://lua-users.org/wiki/TableSerialization [2]

Is it possible to have a nested tree of the lua tables (maybe based on static analysis or dumping game state during gameplay into json etc.)? A tree-like structure nested that developers can then later navigate and reason about what to do. Mostly to be used for exploring source code, rather than editing game state. For example: _G ├── TheNet ├── ThePlayer │ └── Components │ └── Builder └── TheWorld └── SeasonManager

Suppose you/someone can program and fulfilled all your wishes. You'll find an even more unbalanced game...

So all those gold that went into the pots are lost forever!?!?!?

As described. This also gives a perk for other players to move his portable pots around without wrecking them. Also makes possible some interesting set pieces for Bearger.

I wouldn't think this is intended unless stated so by a developer. To me it seems more like a convenient implementation (just write something up that runs and won't break the game) rather than intended design.

And I can make a claim that the same player is behind both characters. Besides, it is just very inconvenient to re-learn all the recipes again. It is not that you are lack of resources for them; by the time you can merge worlds etc., you are probably mid- or late-game where you can have pretty much any resources. So it ends up becoming a pointless grind that wastes player's time. I don't really care about "game logic" in DS/DST anymore (ask Maxwell).