[Ohrrpgce] .rsav in .ohrkey ?

[James Paige]

On Fri, Jul 14, 2017 at 8:28 PM, Ralph Versteegen <teeemcee at gmail.com>
wrote:

>
>
> On 14 July 2017 at 11:58, James Paige <Bob at hamsterrepublic.com> wrote:
>
>> I know we had discussed improvements to recording and replaying input,
>> and I can't remember what we said about saving and loading, but here is
>> something I was thinking about.
>>
>> How about if we add the ability to embed entire .rsav files into .ohrkey
>> files?
>>
>> Suppose if we had a new .ohrkey format which was a reload document.
>>
>
> I was actually thinking of doing the opposite: embedding .ohrkey files in
> .rsav files. I think either way could potentially work.
>
> I don't think we ever discussed details of a new ohrkeys format, but I've
> been thinking about some big extensions, to record joystick, mouse, and
> non-deterministic script commands and other inputs (possibly certain things
> returned from the OS or backends), sanity checks to detect desyncs, and
> metadata like the engine version and game used in the recording.
>
> Regarding recording of non-deterministic stuff, my idea is to add a
> "command stream" to the file, so that extra key-value pairs on each tick
> can be embedded. The key can be script command ID, but other IDs can be
> assigned for other purposes, for example some non-deterministic commands
> have side effects, so rather than recording their return values and
> skipping them we need to record something else.
>

I think those are great ideas. I like the command stream. I really like the
idea of having more robust playback and record support.


>
>> It could have a node that includes the recorded input stream, but it
>> could also have a node that stores .rsav files
>>
>> When recording, any .rsav you load from would be embedded into the
>> .ohrkey file. When the replay happened, .rsav files from the .ohrkey would
>> be used in preference to the ones in the normal gamename.saves file, so
>> replays could be independent of save-state.
>>
>> It would also make sense that saving your progress while in replay mode
>> would write to the same location (in the in-memory reload document) and
>> subsequent loads would use that, so you could safely create and use a
>> replay that loaded and saved multiple times, and at the end, your
>> non-replay save slots would be untouched.
>>
>
> I think your idea to embed rsavs in the ohrkeys sounds a lot more
> practical and flexible than my idea.
>
> This sounds pretty good. I had imagined that a new replay would start
> every time you loaded a save, so that the player picking a save from the
> menu wouldn't be the start of the replay. It's also useful to be able to
> jump to partway into a replay. (If ohrkeys is embedded in rsav that would
> mean a bunch of separate files, which isn't nice, if rsav is embedded in
> ohrkeys they would all be one file. Potentially the replays could split
> into several reload nodes, or there could be a table of contents.)
> Either way, we're going to need some special handling of the save/load
> menu, such as recording the visible state of all save slots in the replay.
>

That is a good point. We could save a minimal subset of the rsav files for
all displayed slots that is just big enough to reproduce the slot preview
planks (not that that they have been converted into a plank yet)



>
>
>>
>>
>> _______________________________________________
>> Ohrrpgce mailing list
>> ohrrpgce at lists.motherhamster.org
>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>
>>
>
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20170715/8e33239b/attachment.htm>