<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 14 July 2017 at 11:58, James Paige <span dir="ltr"><<a href="mailto:Bob@hamsterrepublic.com" target="_blank">Bob@hamsterrepublic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>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.<br><br></div>How about if we add the ability to embed entire .rsav files into .ohrkey files?<br><br></div><div>Suppose if we had a new .ohrkey format which was a reload document.<br></div></div></blockquote><div><br>I was actually thinking of doing the opposite: embedding .ohrkey files in .rsav files. I think either way could potentially work.<br><br></div><div>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.<br><br></div><div>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.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>It could have a node that includes the recorded input stream, but it could also have a node that stores .rsav files<br><br></div><div>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.<br><br></div><div>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.<br></div></div></blockquote><div><br><div>I think your idea to embed rsavs in the ohrkeys sounds a lot more practical and flexible than my idea.<br></div><br></div><div>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.)<br>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.<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div></div>
<br>______________________________<wbr>_________________<br>
Ohrrpgce mailing list<br>
<a href="mailto:ohrrpgce@lists.motherhamster.org">ohrrpgce@lists.motherhamster.<wbr>org</a><br>
<a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" rel="noreferrer" target="_blank">http://lists.motherhamster.<wbr>org/listinfo.cgi/ohrrpgce-<wbr>motherhamster.org</a><br>
<br></blockquote></div><br></div></div>