My read of your other topic was that it was the Delay that wasn't working, not the QueuePersonScript

CollectTriforce();
QueuePersonScript("Triforce", "LevelComplete(x,y,map)", false);

Upon much testing in both sphere & minisphere, the queued LevelComplete does function. It has something to do with CollectTriforce. In sphere the sound plays and levelcomplete() gets called but it isn't changing the location of the triforce and the player. In minisphere it functions sporadically, sometimes the location will be updated, sometimes it won't.

Set a breakpoint at the top of CollectTriforce() (press F9) and then start the debugger.  Then you can step through it line by line to see where it goes wrong.

Interestingly, I set the breakpoint, run the debugger and tested it in the Triforce rooms for Levels 1 thru 5. It functioned correctly each time.

I tested each individual Triforce room currently created 10 times each. CollectTriforce() functioned each time in miniSphere. In sphere, however, the function would skip past relocating the Triforce and the player but process playing the sound and the rest of the function.

I tested each individual Triforce room currently created 10 times each. CollectTriforce() functioned each time in miniSphere. In sphere, however, the function would skip past relocating the Triforce and the player but process playing the sound and the rest of the function.

OK, So either before the Delay or before the Queue person script call put in:
UpdateMapEngine();
RenderMap();
FlipScreen();

Or actually to make it simpler forget queue person script for that one just do:

CollectTriforce();
UpdateMapEngine();
RenderMap();
FlipScreen();
LevelComplete(x, y, map);

Looked it over and it seems clear that with Sphere 1.5 what's happening is that your queued person script executes before the mpa gets redrawn after moving the people as in the internal logic works like this (for every cycle of the map engine):

1. Update Map including running any person scripts
2. Draw the Map
3. Return to 1.

In this case your function to move your people and then queue a script gets called BUT the queued script then gets called as well still in step 1 and so the map is not drawn after the movement.

executes before the mpa gets redrawn

mpa? Motion Picture Association?... I know you meant map though.

Also, The player collecting the Triforce now functions in Sphere & miniSphere.

In general if you need something to happen on the map before your script continues you have to stick in those 3 lines to guarantee it, unless instead you have it queued as a person script where the person script contains a condition OR the thing you want to wait for is that person to move (as their queued script won't execute until they've finished moving - note "moving" in this context is not the same as having a function set their x and y I'm talking about queued movements)

I read somewhere about how comments, formatting and trailing spaces can affect frames per second. I went through a few of my major *.js files, removed unneeded comments, reformatted some of the code and removed all trailing spaces. I then tested in Sphere and miniSphere. One notable difference was the scrolling inventory function. Before I did this the inventory would move at a stead pace up and down the screen. Now, in Sphere it was at the top of the page in a blink of an eye. Below are the frames per second while performing the scrolling inventory. Can the comments, formatting and trailing spaces really affect the code that much to have the frames per second go so high?

It looks like miniSphere is getting locked at 60fps due to vsync.  Sphere is software rendering so that doesn't come into play.

Don't fall into the cargo-cult trap though: the reason stripping comments etc. sped up Sphere is that old SpiderMonkey was purely interpreted, so cutting down the amount of text speeds things up.  All modern JS engines including Duktape (used in mS) compile to bytecode first so there would be no runtime gain at all from stripping comments and whitespace.

I just dropped in 2 lines of code to the InvScroll() that made it scroll at a steady pace again. Now looking at the frames per second in Sphere, they fluctuate between 60 & 65.

If you want to guarantee a steady framerate in your menu (assuming your code can keep up), call SetFrameRate(60)

@Miscreant : you can slow down your 1.5 code to an appropriate rate by passing a framerate limit when making your MapEngine call. MapEngine(name_of_first_map, framerate);

@Fat Cerberus SetFrameRate is only meant to control out of map engine drawing - render scripts are called by the mapengine fps (per the api documentation anyway)

And yeah repeating what Fat Cerberus said - removing detritus from your scripts will speed up 1.5 but the only thing it would change in miniSphere is the time to open the script in the first place so unless you have noticeable loading times removing comments and white space is largely irrelevant for miniSphere. (Well if it was a MB or more worth of comments it could be enough to cause an actual noticeable load time but that's about it)

If you run a sepearate FlipScreen loop for your menu, even in the map engine, you need to call SetFrameRate.  I assume that's what @Miscreant is doing since there's no way he could get 220fps otherwise (map engine framerate must be nonzero)

@Rhuan I do that at the beginning of the game already. MapEngine("Start.rmp", 60);

@Fat Cerberus The InvScroll() does use a FlipScreen() but I have no SetFrameRate in it at all. Should I?

I just went through several maps in game with the frames per second turned on . In some areas it remained between 56 & 65. Transitioning between the overworld and underworld or the overworld and entering a dungeon the frames per second jumped as high as the mid 700's.

@Fat Cerberus The InvScroll() does use a FlipScreen() but I have no SetFrameRate in it at all. Should I?

If at any place you're calling FlipScreen() in a loop, then you should have the primary framerate set.  It's enough just to call SetFrameRate(60); once, on startup.  No need to call it again unless you're changing the framerate.

Another benefit of setting a framerate is that (in miniSphere at least), leftover time that you didn't use for a frame won't steal CPU cycles from other programs which is more battery-friendly for laptops.