http://gilgamesh.hamsterrepublic.com/cgi-bin/bugzilla/show_bug.cgi?id=430
------- Comment #18 from [EMAIL PROTECTED] 2007-11-02 08:35 ------- (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. 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. -- 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
