Replay Mod Forums

Suggestions to improve long replays
    • User
    • 4 forum posts
    User10139
    #1

    Oct 06 15, 09:32 PM | Last edited: Oct 07 15, 11:11 PM

    Hello,

    Recently I have used the replaymod, to make 48h+ of replay recordings into a small 3minute video, during this i had to deal with replay recording of up to 25h and smooth camera paths between different recordings. therefore I have a couple of suggestions/feature requests to make stuff easier.

    1. Save the replay recordings the same way how compressed video is saved. as far as i know the replaymod already only saves changes to the world but unlike video files, it doesnt save a 'snapshot' every X minutes.
    this can improve multiple things in the replay viewer, stuff like
    * faster render time when you are rendering a 10s clip which is 24h into the replay recording.
    * faster jumping times forwards (from 4h in to 5h in) but even more backwards (from 5h in to 4h in)
    2. add support for more keyboard shortcuts.
    shortcuts for when editing a keyframe, like when pressing (shift + )[tab] you go to the next box when for example the keyframe edit window is up.
    3. save the replay whilst playing.
    when the server crashes you keep your replay but if your client crashes as well, you are basically out of luck and you may have lost a couple of hours of replay recordings.
    4. Eternal day/ wheater options for in the video render.
    to be able to turn off wheater/turn on fixate the sun to a particulair time.
    5. options to save a replay path globally.
    currently you need to manually write all keyframe points down for transitions from a world w/ trees to a world w/o trees whilst the camera is moving. If we would be able to save a camera path globally we can render out the same camera path in different replay files (that were recorded before and after the trees were removed) and use video editing software to fade from the one clip to the other

    I hope you find these suggestions useful

    -Niels


    • Developer
    • 1883 forum posts
    User10
    #2

    Oct 09 15, 03:37 PM

    1. This should indeed increase performance for jumping a lot (won't have an effect on render times, except the initial jump to the start). However there are currently three problems which have prevented us from adding it (it is definitely worth implementing at some point as all those problems can be solved):
    - File size would increase dramatically (this can be prevented by not saving snapshots when recording but allowing the use to decide afterwards which replays to 'optimize')
    - RAM usage / waiting time. When doing these optimizations on the fly, RAM usage will definitely increase which isn't ideal. If they are done all at once there'd be a waiting time before saving / opening the replay. (Solution is the same as above, letting the user consciously choose which files to optimize)
    - While replaying is pretty straightforward, creating snapshots is not and is prone to errors (we had worlds combining, blocks duplicating and the game just outright crashing in some very special edge cases only happening on a few highly custom rarely visited servers). Adding it would make it more difficult to reproduce specific scenarios and might break lots of stuff under very specific conditions. This point however isn't a problem with the idea itself but is just a matter of 'doing it right'.
    (Added to suggestions list)

    2. Sure just tell us which one you'd like to have.
    (Shift) tabbing between input fields is natively supported by every GUI using the new GUI API (e.g. the Login and Register GUIs). We're rewriting all GUIs to use the new GUI API eventually, at which point shift-tab will be supported in all of them and adding new keyboard shortcuts should be pretty easy. If there is something you'd like to have added to those GUIs already using the new GUI API, just let me know and I'll probably add it. For all GUIs that aren't yet using that new API, you'll just have to wait until they're rewritten (I'm currently rewriting every GUI I touch, so eventually they should all be done).

    3. Packet data is actually written to disk as it comes in (well, with a slight delay to not induce gameplay lag). Be warned though: it'll be deleted when you start the mod the next time. We will probably add a way to recover this data upon startup at some point (added to TODO list). If you're willing to tinker a bit you can recover it yourself. All you need is another replay (preferably one you no longer need or a copy) and the '.tmcpr' file which contains the packet data. You can then copy the .tmcpr file into the existing replay (.mcpr file), replacing the recording.tmcpr entry. You should also modify the duration of the replay (it's saved in the metaData.json file) to be somewhat close to the duration of the actual recording (in milliseconds).

    4. I believe keyframable time was suggested somewhere (at least there's a trello card for it). It will probably be implemented at some point after reworking the keyframe system. For now I pretty sure there are compatible client side mods allowing to do this (though when downloading them be careful to receive any malware free of charge packaged with them).

    5. Such a feature would find less use than the space required for the buttons to access it. You can do just that by manually copying the 'paths.json' file from one replay (.mcpr file, just open it with something like 7zip) to the other (to be safe do that with minecraft being closed).


    • User
    • 2 forum posts
    User117938
    #3

    Mar 01 18, 01:17 AM

    for the first one it can be optional and users can turn it on if they prefer


    • User
    • 31 forum posts
    User53293
    #4

    Mar 05 18, 02:09 PM

    For the snapshots idea, I think the best option is to let the player add these snapshots in post, by clicking a button or pressing a key while in the Replay Viewer or something like that. This way, there are never any unnecessary snapshots.


    • User
    • 1 forum post


    1. This should indeed increase performance for jumping a lot (won't have an effect on render times, except the initial jump to the start). However there are currently three problems which have prevented us from adding it (it is definitely worth implementing at some point as all those problems can be solved):
    - File size would increase dramatically (this can be prevented by not saving snapshots when recording but allowing the use to decide afterwards which replays to 'optimize')
    - RAM usage / waiting time. When doing these optimizations on the fly, RAM usage will definitely increase which isn't ideal. If they are done all at once there'd be a waiting time before saving / opening the replay. (Solution is the same as above, letting the user consciously choose which files to optimize)
    - While replaying is pretty straightforward, creating snapshots is not and is prone to errors (we had worlds combining, blocks duplicating and the game just outright crashing in some very special edge cases only happening on a few highly custom rarely visited servers). Adding it would make it more difficult to reproduce specific scenarios and might break lots of stuff under very specific conditions. This point however isn't a problem with the idea itself but is just a matter of 'doing it right'.
    (Added to suggestions list)

    2. Sure just tell us which one you'd like to have.
    (Shift) tabbing between input fields is natively supported by every GUI using the new GUI API (e.g. the Login and Register GUIs). We're rewriting all GUIs to use the new GUI API eventually, at which point shift-tab will be supported in all of them and adding new keyboard shortcuts should be pretty easy. If there is something you'd like to have added to those GUIs already using the new GUI API, just let me know and I'll probably add it. For all GUIs that aren't yet using that new API, you'll just have to wait until they're rewritten (I'm currently rewriting every GUI I touch, so eventually they should all be done).

    3. Packet data is actually written to disk as it comes in (well, with a slight delay to not induce gameplay lag). Be warned though: it'll be deleted when you start the mod the next time. We will probably add a way to recover this data upon startup at some point (added to TODO list). If you're willing to tinker a bit you can recover it yourself. All you need is another replay (preferably one you no longer need or a copy) and the '.tmcpr' file which contains the packet data. You can then copy the .tmcpr file into the existing replay (.mcpr file), replacing the recording.tmcpr entry. You should also modify the duration of the replay (it's saved in the metaData.json file) to be somewhat close to the duration of the actual recording (in milliseconds).

    4. I believe keyframable time was suggested somewhere (at least there's a trello card for it). It will probably be implemented at some point after reworking the keyframe system. For now I pretty sure there are compatible client side mods allowing to do this (though when downloading them be careful to receive any malware free of charge packaged with them).

    5. Such a feature would find less use than the space required for the buttons to access it. You can do just that by manually copying the 'paths.json' file from one replay (.mcpr file, just open it with something like 7zip) to the other (to be safe do that with minecraft being closed).

    (only for the first point)
    Save only Snapshot when there is changing between worlds(jumping between worlds like to nether or to other server).
    My idea is:
    1. with every world change a MetaData will be saved as a "new start".
    2. and after saving the file(from temp to compressed one) the byte where the "new start" will start all over again as Snapshot.
    3. The exact byte position where world change (Snapshot) would be saved in MetaData or at the start of the record_file)

    This will help:
    1. back and forth faster on some servers (e.g Hypixel minigames)
    2. help other situation when there is at least some performance(when the person jump to other server and come back).

    Other ideas.
    @User10139 said "save a 'snapshot' every X minutes".
    well what if: save a 'snapshot' every X bytes.
    means if the player didn't hub between worlds and the file is getting larger, an automatic snapshot will be saved.
    [And if the player was afk and no world change happened then it doesn't need]

    as mentioned from @User10:
    File size? it won't change a lot if it saves only every 60 minute of (hard fast building).
    RAM usage? Save one time as snapshot and it may be possible to let the person "press a button" to save snapshot
    waiting time? it doesn't need waiting time... only MetaData where is it right now and then in "optimization" save it as a new start on the same file.

    Don't forget: the main idea is only when jumping between servers.

    [Don't forget. you can always do it(in other way) or improve it but the main idea is still the same]