> 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?
> > > 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.
_______________________________________________________
Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting
http://www.doteasy.com
_______________________________________________
Ohrrpgce mailing list
[email protected]
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
