On 9 November 2010 07:11, Jay Tennant <[email protected]> wrote: >> From: James Paige <[email protected]> >> Sent: Monday, November 08, 2010 11:39 AM >> >> On Mon, Nov 08, 2010 at 08:33:52AM +1300, Ralph Versteegen wrote: >> > I've been thinking about this too. There's an in-progress file IO >> > abstraction system (lumpfile.bas) that's not yet used (also, >> > implementing your own polymorphism in FB is really unpleasant). I've >> > recently been looking into how IPC could be used to allow Game and >> > Custom to run on the same file, sending notifications to Game when >> > something is edited. >> > >> > On 7 November 2010 18:45, David Gowers (kampu) <[email protected]> wrote: >> > > On Sun, Nov 7, 2010 at 2:07 PM, James Paige <[email protected]> >> > > wrote: >> > >> On Sat, Nov 06, 2010 at 05:16:03AM -0700, Jay Tennant wrote: >> > > managed by the >> > >>> backend, but doing so would allow edits in Custom to be immediately >> > >>> visible in Game. >> > >> > Even if you want to do this only for graphics, I don't think the >> > grpahics backend is the place for this. There already is a sprite >> > cache which handles that kind of stuff (we already have a function to >> > instantly reload all in-use palettes from the RPG file. There's no >> > function to do the same for sprites, because it's not needed yet). >> > >> > >>> I'm not sure of the practicality of that, but it's an idea. >> > >> >> > >> While I can see the appeal of being able to test in real-time, I think >> > >> the complexity of that task is waaay to large in comparison to the >> > >> benefit it would provide. >> > >> > I think it would be a great deal of benefit. For example, being able >> > to test battles is a pretty frequent request. Simply being able to >> > open working.tmp in Game would already be quite useful. I think it >> > would be enormously easier to read lumps out of working.tmp, and have >> > the next spawned battle loaded from that, than to import the battle >> > system into Custom. >> > >> > >> And remember, it is not just about updating graphics. What about maps >> > >> updates? Hero enemy attack and item updates? Running scripts? Displaying >> > >> of text boxes? >> > >> > Would we want to be able to reload a textbox or shop or battle, etc., >> > while inside? I say no: those would all be a lot of work to support, >> > and simply exiting and reentering the textbox, shop, or battle to see >> > updates sounds useful enough to me. We could always add code to handle >> > reloading attacks in the middle of a battle, for example, as we see >> > the need and find the time to do so. >> > >> > Incidentally, when it comes to running scripts: I am going to attempt >> > an in-game console which allows you to type and run statements, and >> > also to reimport (selected?) scripts from your .hss file. I was going >> > to do this soon, but maybe I should wait for the better organisation >> > that the new interpreter should have. >> > >> > > I think Jay was talking about graphics because (providing their size >> > > does not change, as is currently implicitly enforced) they have no >> > > side effects -- if a graphic changes, reloading it doesn't require >> > > anything else to be reloaded. >> > > I haven't dug into the OHR sprite caching code recently, but IIRC this >> > > should be true (unsure what the situ is regarding tilemaps). > > I was thinking about graphics primarily, but it wouldn't make > sense anyway, because 'Game' would somehow need to recognize > that a resource in 'Custom' is the same. It doesn't make sense > nor is it practical through the graphics backend. > > However, TMC's ideas are much better, using working.tmp, and > allowing some forms to be refreshable. And the in-game console > for script running would be fantastic. Did you intend > plotscript commands to be called directly, such as placing > a hero or npc in an exact location for testing purposes?
Yes. That's more convenient that having to wrap everything in a script. I've already started: FB's builtin functions for piping allow only redirecting either a process's input or its output, not both. That's one reason that I wrote all that process code to fix the import bug. I want to keep hspeak running (after loading in the existing script files) and have it compile statements one at a time. Also, I just remembered why I was looking into IPC instead of David's much simpler and saner suggestion of just storing hashes for lumps: it's because I'm eager to get rid of working.tmp, and run both Game and Custom straight from lumped RPG files, through the lumpfile abstraction. >> > > Anyway I agree it's inappropriate to implement merely *some* >> > > refreshing -- if there is refreshing at all it should be on all >> > > possible data types, which is exceedingly complex even with a good >> > > framework (like recording an md5sum for each record so you can tell >> > > when it actually changes) >> > >> > As you say, making everything refreshable would be exceeding >> > difficult, which is why I disagree. Rather, I propose just working >> > towards that goal incrementally. Let people know that not everything >> > will work, and make it clear what does and doesn't. I was imagining >> > manual options (in some debug menu) for reloading data for which we >> > support doing so, rather than having everything immediately and >> > automatically refresh. If there's no option for it, and it's not >> > something which you can exit and reenter like a shop, then it's not >> > supported. >> > >> > We could also have an option to do immediate and automatic refreshes >> > which are just equivalent to running the manual refresh when a >> > relevant lump changes. >> > >> > >> > Another possibility would be to make an RPG refresh equivalent to >> > saving and loading parts of the game state corresponding to lumps that >> > have changed, by actually calling some of the RSAV save/load routines. >> > That'll help us test that we add save/load functionality in a robust >> > way. >> >> Hmmm... Actually, I can't think of a single solid objection to the >> incremental approach. >> >> Your arguments here make this idea sound a lot better to me. Cool :) OK then, that's another thing I'll slowly work towards, like resolution independence. _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
