Ah, OK. Once dicts/hashmaps/tables are implemented you could put all your session variables in one table, and pass that back and forth, either by putting it in a global, or passing it as an argument to the other game's newgame/loadgame script. Your scheme is definitely more elegant than those two alternatives, but right now would require either modifying hspeak/file formats/the interpreter and matching up session variables by name (to make them look like globals), or alternatively accessing them only via get/set commands. In future you would probably be able to implement "load/save session variables" as scripts.
On 7 November 2016 at 03:53, Michael Kidder <[email protected]> wrote: > I guess you could also call them meta variables, or cache variables.. > > On Sat, Nov 5, 2016 at 5:16 AM, Ralph Versteegen <[email protected]> > wrote: > >> I didn't really understand what you meant by session variables. Sort of >> an 'overlay', that while active causes commands to read data from the save >> instead of the current game? That would be a possibly practical way to read >> data from a different rpg file (but can't deal with interdependencies >> between files, and you have to watch out for caches). Applying the same >> idea to saves sounds like what I suggested for loading only part of the >> data from a save, because that data needs to go into the relevant game >> state globals to be accessible, overwriting the previous state. >> >> One thing to think about is that it would be nice not to require the game >> 'sending' the data to cooperate by encoding the data into globals or >> whatever. For example, if you later publish an expansion or sequel to an >> earlier game, you might want to be able to pull stuff out of the save files >> without having to have planned ahead. (Plus, hijinks like save file >> inspection tools (but if you want that, you can use )) >> >> On 5 November 2016 at 03:01, Michael Kidder <[email protected]> wrote: >> >>> That's why I like the idea of session variables or globals that you can >>> customize what data they transport and read it, since chainloading games >>> would definitely be an advanced feature in the first place, and what each >>> game wants to 'transport' would also be custom in the first place, so it >>> wouldn't be that far of a stretch to ask the scripter to make their data >>> transport on their own >>> >>> Also as a random idea, I could do a tech demo of this for April Fools.. >>> do a parody of Sonic & Knuckles but with Bob or someone else in a bunch of >>> other games if you "lock" them on to Wandering Hamster (&Knuckles) >>> >>> On Thu, Nov 3, 2016 at 10:58 PM, Ralph Versteegen <[email protected]> >>> wrote: >>> >>>> Yes, you could and would only transfer a save file to another game >>>> based on the original .rpg with largely the same data, a sequel or extended >>>> version basically. I don't see many other cases in which you would want to >>>> transfer a save file. You can remove and replace some parts of the original >>>> .rpg, though. >>>> >>>> Not long ago I fixed a crash that occurred when loading a save from a >>>> different game (which I did by accident, and didn't realise until >>>> afterwards) that put you on a non-existent map. It shows a visible error >>>> when that happens, but we could add a bitset to handle it silently. Then as >>>> long as you have a loadgame script to put the hero in a sensible starting >>>> location, you can just delete all the maps from the original game and >>>> replace them. >>>> >>>> Don't forget that NPCs still aren't saved/loaded (actually, they are >>>> loaded, but not saved). >>>> >>>> You also missed slice lookup codes, sprite and palette ids in the hero >>>> data, and gameover/loadgame script triggers. >>>> >>>> So the things you should preserve are mainly tags, items, spells, hero >>>> walkabout/battle sprites and palettes, shops, sprites palettes and lookup >>>> codes for any saved slices, and heroes. >>>> >>>> But you can easily replace (if you wanted to reduce the file size) >>>> maps, almost all graphics, enemies, formations, music and sound effects, >>>> and scripts. That seems quite practical to me. >>>> >>>> Alternatively we could have a command to load a saved game, but not end >>>> the current game (so the script continues running), with a bitmask to >>>> select certain data: >>>> -tags >>>> -globals >>>> -map data (currently just location; the normal settings for what gets >>>> loaded could just be respected) >>>> -heroes >>>> -maybe some bit to recompute certain hero data, e.g. stats or spell >>>> lists, from the current hero definitions >>>> -inventory >>>> -shop inventories >>>> -slices >>>> That should be very easy to implement. If you want to load heroes from >>>> another game there are quite a few dependencies on other data. >>>> But as far as I can see, the only use of this command would be when you >>>> want to transfer a save from an earlier version of the game, >>>> but want to wipe some of the data that's no longer compatible. >>>> >>>> On 4 November 2016 at 07:18, James Paige <[email protected]> >>>> wrote: >>>> >>>>> I think the biggest issue with loading from other games save slots is >>>>> that saves have a lot of fixed id numbers, and those can't be expected to >>>>> be the same for other games >>>>> >>>>> I went through the RSAV documentation, and tried to make a list of all >>>>> the id numbers >>>>> >>>>> * current map state stores map id number, and stores NPC definition id >>>>> numbers >>>>> * tag state is all id number based, so are onetime npcs >>>>> * saved hero party state saves both slot id numbers and hero >>>>> definition id numbers >>>>> * spell lists are full of attack id numbers >>>>> * inventory state is full of item id numbers >>>>> * shops are also full of both shop slot id numbers and item id numbers >>>>> * saved slices might be full of sprite id numbers. >>>>> >>>>> Unless the other game that you are importing a save from is an almost >>>>> exact copy of all these things, I don't really see how loading a save is >>>>> going to be useful. >>>>> >>>>> a version of import globals that can read stuff from other games will >>>>> be very useful for scripting fun... and commands for importing more >>>>> specific data from other game's saves (or other save slots in the current >>>>> game) are reasonable (and wouldn't be too terribly hard to do) >>>>> >>>> >>>> Well aside from globals would other data would you want to load? >>>> There's a huge amount of possible data that could be loaded, translating to >>>> a huge amount of possible script commands. >>>> I guess the main things you might want to transfer another game are >>>> tags, heroes and inventories. If your new game isn't save compatible then >>>> you can't >>>> import any of those anyway, and we would be stuck creating individual >>>> commands to read hero level of party slot X of save Y of game Z... >>>> Quite a lot of stuff (who is in the party, what items you have) would >>>> be covered by reading tag data. >>>> One solution is to just (eventually) let people load an .rsav as a >>>> reload document directly, since loading from other saves is an advanced >>>> feature anyway. >>>> >>>>> >>>>> I think we need to look more carefully at how this should work-- >>>>> especially at exactly what game authors want to accomplish with a >>>>> save-import feature. >>>>> >>>>> Just importing and loading some other game's rsav file is going to be >>>>> messy, and it isn't clear to me that it will be very useful. >>>>> >>>>> >>>>> >>>>> --- >>>>> James >>>>> >>>>> >>>>> >>>>> On Thu, Nov 3, 2016 at 10:39 AM, Ralph Versteegen <[email protected]> >>>>> wrote: >>>>> >>>>>> Yes, we need a way to share saves. A fancy way would be commands to >>>>>> load/save a save from/to some other game, >>>>>> which would allow the sort of one-time conversion you suggest, >>>>>> but a simpler solution is just a setting to specify the name of the >>>>>> saves folder. (That sounds a lot like >>>>>> the packagegame for the game (used when distributing)). However I >>>>>> guess that would be bad >>>>>> if you went back to the original game and tried to load a save from >>>>>> the sequel/expansion; ideally you'd want saves >>>>>> to be marked as incompatible or something. Maybe this isn't a simple >>>>>> solution afterall. >>>>>> >>>>>> There are also some config files associated with each game (hidden >>>>>> away in the OHR's settings folder), and maybe those should be shared too. >>>>>> There's >>>>>> almost nothing stored in those settings currently, AFAIR just in-app >>>>>> purchases and whether to fullscreen. >>>>>> >>>>>> On 4 November 2016 at 01:53, Michael Kidder <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> This actually makes "DLC" / expansions more feasible now since if >>>>>>> you wanted to do it before, you have to tell people "oh yeah, just go >>>>>>> in, >>>>>>> copy the file... rename it to gameexpansion.r .. okay, enable >>>>>>> extensions, >>>>>>> and then go to.." >>>>>>> >>>>>>> Now you could just run a check to see if the user has installed the >>>>>>> .rpg file and modify an in game menu or NPC's dialog or whatever >>>>>>> seamlessly, that'd be pretty cool. >>>>>>> >>>>>>> Only thing i can think of is power users may want the ability to >>>>>>> bring the save from the original game to the called game. It would be >>>>>>> up to >>>>>>> the developer to make sure both games stay compatible save wise. If this >>>>>>> causes too many issues, then making "session variables" that GAME >>>>>>> preserves >>>>>>> only for the duration of being loaded would likely be enough for people >>>>>>> to >>>>>>> bring data over from one game to another. Something to think about, >>>>>>> anyway. >>>>>>> >>>>>>> On Tue, Nov 1, 2016 at 7:00 PM, Ralph Versteegen <[email protected] >>>>>>> > wrote: >>>>>>> >>>>>>>> Yes, I was planning to add a command like "check game exists" to >>>>>>>> work around this problem. >>>>>>>> >>>>>>>> Checking for both .rpg and .rpgdir is a good idea too. >>>>>>>> >>>>>>>> On 2 November 2016 at 04:26, James Paige <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> I was looking at the run game implementation. >>>>>>>>> >>>>>>>>> I saw this comment in the source: >>>>>>>>> >>>>>>>>> PRIVATE SUB run_game () >>>>>>>>> ' Not being able to load the game should always show an error >>>>>>>>> (use serrError for everything) >>>>>>>>> >>>>>>>>> I would definitely like to have the option of running a game with >>>>>>>>> the error silenced. >>>>>>>>> >>>>>>>>> For example, At the end of Quest.rpg I might have code that runs >>>>>>>>> Quest2.rpg even though the sequel does not even exist yet. >>>>>>>>> >>>>>>>>> One way to get this effect would be an argument to run game to >>>>>>>>> make it silent. (I don't really like this one.) >>>>>>>>> >>>>>>>>> Alternatively another command "run game if exists" that just does >>>>>>>>> the same thing without the error >>>>>>>>> >>>>>>>>> Finally, maybe an "is other game available($0="othergame")" check >>>>>>>>> that returns a boolean. >>>>>>>>> >>>>>>>>> Next, I was wondering if you do: >>>>>>>>> >>>>>>>>> run game($0="gamename.rpg") >>>>>>>>> >>>>>>>>> and gamename.rpg does not exist, should it automatically check for >>>>>>>>> "gamename.rpgdir" and nice-versa >>>>>>>>> >>>>>>>>> --- >>>>>>>>> James >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Ohrrpgce mailing list >>>>>>>>> [email protected] >>>>>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherh >>>>>>>>> amster.org >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Ohrrpgce mailing list >>>>>>>> [email protected] >>>>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherh >>>>>>>> amster.org >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ohrrpgce mailing list >>>>>>> [email protected] >>>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherh >>>>>>> amster.org >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Ohrrpgce mailing list >>>>>> [email protected] >>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherh >>>>>> amster.org >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Ohrrpgce mailing list >>>>> [email protected] >>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Ohrrpgce mailing list >>>> [email protected] >>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >>>> >>>> >>> >>> _______________________________________________ >>> Ohrrpgce mailing list >>> [email protected] >>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >>> >>> >> >> _______________________________________________ >> Ohrrpgce mailing list >> [email protected] >> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >> >> > > _______________________________________________ > Ohrrpgce mailing list > [email protected] > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > >
_______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
