http://gilgamesh.hamsterrepublic.com/cgi-bin/bugzilla/show_bug.cgi?id=430





------- Comment #19 from [EMAIL PROTECTED]  2007-11-02 18:23 -------
(In reply to comment #18)
> (In reply to comment #17)
> > Lately, I've been thinking that I don't really see a reason why 
> > teleporttomap
> > should cause a wait anyway. It could load the map, and then resume 
> > executing.
> > If the map load causes a map autorun script to trigger... then it should get
> > control (I think we have a suspend command to stop it, if not, we should)
> > 
> > What does everyone think: Is it too late to 'fix' teleporttomap? I've been
> > noticing bugs in games caused by it lately. The only way to work around it 
> > is a
> > fade out (if you want to immediately change the map on teleporting, that 
> > is).
> > 
> 
> If I recall correctly, the wait is (or was) a technical limitation based on 
> the
> way new map data gets loaded... *checks* Yep. "preparemap" is still a GOSUB
> block, which makes it unavailable directly to the script interpreter subs. The
> one-cycle wait implicit in teleporttomap is there to allow control to flow 
> back
> to the main loop where the GOSUB to preparemap can take place.

*rollyeyes* the script interpreter is still in a set of GOSUBs itself!

> 
> The only objection I have to changing it is the risk of breaking old games 
> that
> depend on that one-cycle wait in obscure ways.
> 
> Here is what I would propose:
> 
> * SUBify preparemap (no small task!)
> * create a new command "teleport" that lacks teleporttomap's wait
> * Try remapping telporttomap->teleport
> * make a testing build, and get a bunch of people to test old games with it
> * If breakages occur, document telporttomap as deprecated, but leave it 
> alone. 
> * If no breakages are found, remove teleporttomap entirely.

I approve of this new philosophy of only worrying about breakages that actually
occur. Anyway, we don't need to test too many old games, since plotscripting
hasn't been around for that many years, right... right?


The other commands which imply a wait are usedoor, fightformation, usenpc,
loadfromslot. (I had forgotten that the menu commands didn't imply a wait)
Of those, only usenpc looks iffy to me: showtextbox doesn't induce a wait. But
I suppose it's not much of a problem, and could be left alone.


-- 
Configure bugmail: 
http://gilgamesh.hamsterrepublic.com/cgi-bin/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

_______________________________________________
Ohrrpgce mailing list
[email protected]
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org

Reply via email to