Could someone please explain how a trigger works in the MapEngine?

I've never used them, and there isn't a whole lot to go on from the new wiki about it.

A trigger is an entity that activates and runs code whenever the player's sprite enters its space. If you're asking about actual implementation details/specific mechanics behind it, that I couldn't say as I haven't really done much with the map engine yet.

Ok...so like both a zone and an entity.

Yeah, I am only curious about what it does for the user.

Here's my text-book definition of a trigger.

A trigger is like a zone, but it is triggered only once while you are in the vicinity of the region. Once you leave and then re-enter it'll re-trigger, therefore a trigger has spatial awareness. Unlike a zone it doesn't re-trigger for n amount of steps taken by the player (a step being a pixel of movement). Also unlike a zone it is precisely the size of one square tile, it does not carry the width and height data, it is assumed. A trigger carries JS code, which is what's executed when I say 'the trigger was triggered'. A trigger is triggered regardless of the layer despite Sphere's API requesting a layer to execute a trigger. It is likewise placed on the layer set, despite the fact the layer data as of v1.6 has no direct use. A trigger does not support the GetCurrentPerson() call. A trigger is ran in a JS context outside it's own - the global context, so you can run global user-defined functions from external files. It is saved with a map given the pixel x/y coordinates of it (not the tile coords as one might imagine). The word trigger start's with a t, is followed by an r, then an i, two consecutive g's, an e, and ends with an r.

A trigger has but one bug in the vanilla engine. Placing two triggers together creates a 1px gap such that if the player walks right at that edge, neither trigger is triggered. Do not fix this for full emulation, but please fix this (dammit).

OK, so it's pretty much what it looked like. Normally I'd use the wiki for this...but you know...new site.

A trigger has but one bug in the vanilla engine. Placing two triggers together creates a 1px gap such that if the player walks right at that edge, neither trigger is triggered. Do not fix this for full emulation, but please fix this (dammit).

You know, I actually just hit that bug in my first experiment with triggers only minutes ago.

That bug has been the bane of existence for my Blockman game. I had my brother playtest the game and he ran right between two triggers, and I had to explain to him something was supposed to happen there. I must say, it's actually a very serious bug and cripples any game that has it. So I've created a workaround that basically just executes the trigger by using it's tile coords instead of it's pixel coords.

I think the Sphere C++ implementation suffers from this:

Code: (cpp) [Select]

if (px > x && py > y && px < x + tw && py < y + ty) {
    // trigger the trigger.
}

Notice the first two > symbols will skip that beginning edge. The fix would be to add >= x and >= y checks to include the starting lines of a trigger.

A trigger triggers when the center of a sprite is inside the trigger tile. Plus that bug that Radnen described (though I have never, ever encountered it).

Well I commonly found that bug when placing two triggers next to each other for teleporting to another map and the doorway is two tiles wide.

You are right though. The center of the sprites base is whats checked against. Which is also used for zones.

Checking the center of the sprite's base is also likely the reason for the "two triggers next to each other" bug: rounding error. Also, I highly recommend that a Trigger or Triggers article be created in the wiki's API subspace for future Sphere implementations to reference.

I make an official recommendation as the remaining active senior maintainer that all future versions of Sphere should fix this bug by default, letting scripted behavior override it as usual. I also officially recommend that all currently active Sphere implementations (TurboSphere, Sphere-SFML, Web Sphere, casiotone's Sphere, any other current Sphere, AND as soon as the next official version of vanilla Sphere) fix this as soon as possible. Any objections?

Agreed.

I already planned on being sure this bug did not occur in TurboSphere. I don't plan on replicating any obvious bugs or highly unintuitive behaviour in TurboSphere.

Damn, I forgot about this issue. Can anyone test whether this bug exists in minisphere?  I followed the Sphere 1.x source when implementing a lot of the map engine, so I may have accidentally replicated it...