I wrote this simple function to Activate the armos statues. If you bump into one it comes to life and moves around the screen.

In Sphere 1.5: You walk into a statue, it comes to life and moves around the screen.

In miniSphere: You walk into a statue, it comes to life and moves around the screen. If the now activated statue touches another statue, that statue comes to life and moves around.

In Sphere 1.5 that does not occur. if a statue touches another statue that statue does not come to life.

Hehe, I can answer this one right away.

Interestingly enough, you're relying on a bug in the Sphere 1.x map engine: the engine only calls the touch script if the input person touches the NPC.  miniSphere fixes the bug and calls the touch script any time any person touches the NPC, which is the intended behavior.  That gives you more flexibility for collision detection.

In order to work correctly in both engines, the Armos Statue touch scripts should look like:

Code: [Select]

if (GetVersion() < 2.0 || GetActingPerson() == "Link")
    ActivateArmos();

The version check is needed because Sphere 1.x doesn't have GetActingPerson().

By the way, what's up with that Foo() function?  Sphere has a function to set person X/Y simultaneously: SetPersonXYFloat().

Code: [Select]

if (GetVersion() < 2.0 || GetActingPerson() != "Link")
    ActivateArmos();

I added in that line of code and in Sphere 1.5 ActivateArmos runs, in miniSphere when I bump into an Armos nothing happens.

By the way, what's up with that Foo() function?  Sphere has a function to set person X/Y simultaneously: SetPersonXYFloat().

I was unaware of that when I first started using Sphere, before I discovered api.txt. Now, I use it because it's just more for consistency of code.

Code: [Select]

if (GetVersion() < 2.0 || GetActingPerson() != "Link")
    ActivateArmos();

I added in that line of code and in Sphere 1.5 ActivateArmos runs, in miniSphere when I bump into an Armos nothing happens.

Yeah, sorry, that should have been GetActingPerson() == "Link" and replace "Link" with whatever you named the player character in its CreatePerson() call.

replace "Link" with whatever you named the player character

In the code the PC is actually called "UrNoLink".

is there a way to keep the NPCs from walking off the maps that does not involve using map layers?

In an early npc town test I did i wound up having 2 layers. When you entered the town all of the npcs were on the second layer with an obstructed transparent tile bordering the map. When the player went to leave the map there was a trigger set swapping the player to the unobstructed layer.

Hm... I'm not sure there is, actually.  At least not while still letting the engine handle input for you.  You would have to DetachInput() and then handle all the movement input yourself.  There's no way to "plug in" to the collision detection system with the 1.x map engine that I'm aware of.

Did my fixed code work?

Did my fixed code work?

ActivateArmos now functions properly in Sphere 1.5 & miniSphere. Thank you.

Yet another difference between Sphere & miniSphere.

The message box was created using the fademessage system script.

Fun fact: It's equally broken in Sphere 1.5 when using the OpenGL video plugin.  A possible workaround is to call RenderMap before displaying the menu, but I can't promise that will work.

tl;dr: Known compatibility issue, contemplating how to fix.

This is a very interesting case where technically the Sphere 1.5 behavior is a bug, but so many games depend on it that it's probably worth emulating anyway.  There's a perfect storm of circumstances that allow things to work in a default 1.5 configuration:

• Sphere 1.5 map engine doesn't clear the backbuffer between frames.  This is a bug: Backbuffer contents are undefined after a flip, so you're always supposed to clear.
• standard32.dll doesn't clear the backbuffer post-flip; it relies on the engine to do so.  sphere-gl apparently does, presumably because GL documentation stresses that you MUST clear the backbuffer between frames.
• Since standard32 is the default, a lot of old menu code ended up calling GrabImage() during menu activation with no ill effects.  Since sphere-gl is buggy to begin with, pretty much nobody tests against it.

As luck would have it, miniSphere is in a perfect position to emulate the bug, even under OpenGL, as the engine uses an intermediate backbuffer that isn't required to be cleared every frame.

So I'll see what I can do in miniSphere 4.8.

Update: I "fixed" it.

Fix will be in miniSphere 4.8.0.

Whoa.... What the....?

miniSphere on the left, Sphere 1.5 on the right.

The map is smaller than the screen.

miniSphere centers and letterboxes small maps, because it's usually more aesthetically pleasing than Sphere 1.5 which aligns them to the top-left.  It seems you found a use for the "bad" behavior though, so maybe I could change it back

Yeah, the player_info() is not part of the map but drawn in a space below it.