That is true! We probably do want to have rungame take the filename without extension-- either that or make it check all alternative supported extensions if the requested one doesn't exist. ".zrpg" might indeed be a thing someday.
--- James On Thu, Nov 10, 2016 at 7:10 AM, Michael Kidder <[email protected]> wrote: > Also, this may be running a bit far ahead, but would it be a good idea to > make some sort of futureproofing by only having scripters call the game's > filename minus it's extension? > > To use WH an example, just call it in via checking for "wander". The > engine would internally look for the .rpg first and then the .rpgdir . This > would futureproof for future extension changes or engine branches without > having to add logic catches later. For example, if someone wanted to add > .zip loading support, they could make the engine check .zip then .rpg then > .rpgdir and every game would immediately be made compatible without > backwards compat shims . This would also let people easily change between > .rpgdir and .rpg without having to recompile scripts or litter scripts with > an OR check for both. > > It would be consistent with the OHR abstracting most gritty system details > from the end user, as well, and has other benefits down the road that would > leave the engine code cleaner and easier to maintain. > > On Sun, Nov 6, 2016 at 9:08 PM, Ralph Versteegen <[email protected]> > wrote: > >> 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-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
