On 12 November 2016 at 01:36, Ralph Versteegen <[email protected]> wrote:
> James had suggested that it should check for both .rpg and .rpgdir, but it > sounds as if he might have already forgotten :) > > I'm not sure whether to: > - only accept the filename without extension > - accept with valid extension and check that extension first before trying > others > - accept with a valid extension, but discard it and check in predefined > order > > I was planning to do the third one. > > As for .zrpg, I guess that's one alternative. I had been thinking about > doing lump-by-lump compression instead using zlib/gzip, indicating a > compressed lump with a .gz extension. (All three default to exactly the > same algorithm, DEFLATE, but .zip also supports a number of other > algorithms in recent versions.) For example, there's no point compressing > .ogg files. > Note that there's no compression benefit to zipping the whole .rpgdir > folder, because .zip files compress each file individually. On the other > hand if you .zip an .rpg file (in the existing lumped format), you can't > efficiently seek to any of the lumps, you would be forced to unlump it to > play it. We're very close to supporting playing .rpgs without needing to > unlump them, which will be great for Android. > > Advantages of .zip format: > - can use different compression methods for different file formats, > including no compression for audio files > Should have gone in the "Both" category, since both can do this. > - possible to use better compression algorithms supported by .zip, like > LZMA, if we find a zip library that supports it; we won't care about these > formats only being supported by a subset of .zip implementations. > - no need to check for multiple lump names with different extensions > > Advantages of explicit per-lump compression: > - possible to just keep using .rpg extension while showing an appropriate > "unsupported version" error message in old versions instead of "corrupt > .rpg", by not compressing .GEN and ARCHNYM.LMP lumps > - zlib is a small, very popular and very stable library to read/write > gzip/zlib streams > - we can switch to any better compression algorithm in future (e.g. LZMA, > brotli) by changing an internal lump name, and with a single library for a > specific purpose instead of a possibly bloated zip library supporting many > algorithms > > Both good or bad: > - deprecating the lumped-file format (at least for .rpg files) and > switching to a standard one, vs. continuing to use our existing lump and > unlump tools > > I don't even know what the popular libraries for reading/writing .zips > are. A little searching suggested Info-ZIP, libzip and 7zip. zlib was > actually split off Info-ZIP. Info-ZIP supports DEFLATE and bzip2 only. > libzip supports DEFLATE only. > > > On 11 November 2016 at 07:10, Michael Kidder <[email protected]> wrote: > >> yeah, i mostly bring it up because i was thinking about it and "best >> practice" would always to be to write a check for both .rpg and .rpgdir - >> so might as well push it up into the engine so it's done automatically >> every time, and if the extention changes later for new games then it just >> keeps working. >> >> On Thu, Nov 10, 2016 at 10:27 AM, James Paige <[email protected]> >> wrote: >> >>> 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-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
