[Ohrrpgce] .rsav in .ohrkey ?

Ralph Versteegen teeemcee at gmail.com
Sun Jul 16 18:27:45 PDT 2017


On 15 July 2017 at 14:59, James Paige <Bob at hamsterrepublic.com> wrote:

>
>
> 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.
>

I see that I did actually already write this stuff up on the wiki years
ago.

As a bonus, the stream of script commands called would make desyncs easier
to detect. But I'd be interested in a couple special markers like "entered
battle 5", "entered map 2" mainly for the purpose of desync detection (and
therefore desync debugging)

>
>
>>
>>> 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)
>

This sounds pretty straightforward to implement.

We also will want the recording to start at the moment that the .rpg is
loaded rather than the very beginning.

I also wanted to always record input while you're playing a game. So that
it can be used to report a game or engine bug after the fact, and other
potential uses like rewinding! (E.g. autosave every 30 seconds). We could
put a recordings folder inside the .saves folder, and store the last couple
recordings there.

(Although, I'd love to get rid of empty .saves folders if you never save,
and it'd no longer be possible if we did that.)

>
>
>
>>
>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
> _______________________________________________
> 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/20170716/2c2e3191/attachment.htm>


More information about the Ohrrpgce mailing list