[FR] Show folder and safe game size in web overview

[Kariton]

Would be nice if the startpage would list the save game size
as well as the total size of the generated script-output/mapshot/save/d-* directory
next to the Played info.

[Palats]

The size of the game file would be relatively straightforward to get when rendering from the CLI (impossible when rendering using /mapshot in game, but it is fine to have different behavior there I think). The information would have to be obtained in the CLI (it copies the save file anyway) and have the mod add it in mapshot.json. From there the UI can easily display it.

The size of the generated content is a bit trickier (well, mildly). The game does not have access to it at all, so it would be up to the mapshot binary to do it. From there, there are 2 options:

1. Have the render command do it. It would need to do it after triggering the rendering, and update the mapshot.json content. Right now, the CLI never modifies the content of mapshot.json, so we would need to change the behavior. But that's not outlandish either, it is basic json edition.
2. Do it on the fly when opening the UI. It would mean that the serving path would have to scan the whole tree on startup. That would generate a lot more disk access than I want on startup. Scanning files always has some risk (symlink to weird places and the like), so that would make starting the server at risk each time.

Oh well, I guess that means there is just one option, and that is option 1 :)

[I have no plan for now to work on that]

[Kariton]

Thanks for considering and giving feedback.

option two would be absolutely insane considering how big some mapshots can get. :P

mine is currently at ~150GB (8h-10h rendertime with our 80MB save on my kubernetes cluster; space exploration, all surfaces, jpgquality 95 with tilemin 16)
just making some tests. will see how lower jpgquality affects the quality and disk usage.

[Palats]

The mapshots are big, but the scan time is largely dependent on the number of files, not the size; though there are also a lot of files :) But yeah, in any case, not a good approach.

Thanks for the number btw, I don't have a good picture of what people do there. I was not expecting that long of rendering time I must admit. For the disk usage, the biggest contribution is the render zoom level - switching to tilemin 32 would probably about half the disk size and render time I imagine.