Another request for something like game.read_file()

[Versepelles]

There has been previous discussion on the topic (viewtopic.php?f=28&t=16824&hilit=read_file), but I would like to show more interest in simple file i/o.

The motivation behind this is to have mod history persistent beyond a single game, like this thread requests, where a player wants a chest that could save its contents between saves. This requires output, which is currently available in the form of game.write_file(...), and input, which is currently unavailable.

[aubergine18]

What if there was a persistent settings folder (separate to script output directory), where each mod can read/write a JSON file through a very strict API? The file name would be based on mod name with extension '.json'.

API could be something like:

Code: Select all

Script.set(key[,value]) -- nil value deletes key

local val = Script.get(key[,default]) -- optional default if key not found

Script.reset() -- reset (delete?) settings file

File creation, etc., is automated within the API.

Note: This wouldn't replace any of the existing file I/O stuff in the script output directory.

[prg]

Now what if different people in a multiplayer game have different settings?

[aubergine18]

Once an MP game starts, the API methods (.get(), .set(), .reset()) could be disabled.

[Mooncat]

Seems there is still no read_file in 0.15, I want to have a small bump for this request.

Sorry if this has been discussed, but what if read_file only reads the file on server if it is run in MP?
The current write_file allows writing file only on server, so I think it is already possible to make file IO only occurs on server?

[Rseding91]

Currently it's not possible because it would break determinism (replays and MP).

[steinio]

Currently it's not possible because it would break determinism (replays and MP).

I wonder who really uses replays. Nice but abandoned feature.

Greetings steinio

[BenSeidel]

Why does noone just suggest that the file reading, date/time reading etc be placed on the player script object? Then when you read a file you have already specified who you are reading it from. I don't see any difference between reading a file and reading the console input. Both are non-deterministic and are associated with a player. As for the replay, just save the file contents? Just as if a mod saves too much data to a table and the file gets too big, if you read a file that is big you will get a save that is big.

[Mooncat]

Currently it's not possible because it would break determinism (replays and MP).

Thanks for re-reviewing this request!

About MP, as I said, just read the file on server so everyone has the same file to read?

About replay...

I wonder who really uses replays. Nice but abandoned feature.

I think someone will find it useful, since there is a replay mod in Minecraft.
And I have just tried it the first time, I think it is quite good. Though it shouldn't quit immediately when the replay ends.

Anyway, about read_file in replay...
Normally, after reading a file, we use the data to do actions, like creating a GUI, placing some entities on the map.
How about just record those actions? That way you don't even need to record the whole file in replay.
i.e. only record the visible actions. "Reading a file" is hidden, so there is no need to record it. The only things that need to be recorded is the visible actions after reading a file. And that should have already been done in the current APIs?

[quyxkh]

I think replays would get used more if there was an option to decouple/recouple the replay and recorded view -- so you could e.g. load a replay, set the speed to x64, bring up the map, and watch. Having replay save checkpoints so you could skip back would awesome.

[rater193]

ugh, i really wish there was a way to read files