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