Messages

1

Programming Questions / Re: GM 8.1 to Studio: colliding with playerKiller inside solid block

« on: April 23, 2015, 09:35:06 PM »

Thanks for your reply.

You're looking at the frame where the collision event fires, right? I wouldn't expect a big difference in the time the event takes, but in my understanding, the step event fires every frame, whereas the collision event fires only when collision is detected.

I don't know the way this is implemented; I'm just going by hearsay around the Internet.

Side note:

I have tried transplanting the code from collision events to the End Step event, as you describe, but have had difficulty reproducing the correct behavior.

When I work on this tomorrow I'll post code to illustrate the changes I made in transplanting it; maybe then we can debug the resultant behavior.

UPDATE:

This is the (relevant) code I'm currently using in the player's End Step event. It more or less produces the desired behavior, but I'd rather find a more optimized, more exact refactor (more on this below).

Code: [Select]

var blockInstance = instance_place(x, y, block);
var collidingWithSolid = false;

while (blockInstance != noone)
{
    if (blockInstance.solid)
    {
        collidingWithSolid = true;
        break;
    }
   
    ds_stack_push(reactivationStack, blockInstance);
    instance_deactivate_object(blockInstance);
    blockInstance = instance_place(x, y, block);
}

while (!ds_stack_empty(reactivationStack))
{
    instance_activate_object(ds_stack_pop(reactivationStack));
}

if (!collidingWithSolid)
{
    if (place_meeting(x,y,playerKiller))
    {
        killPlayer();
    }
}
As you can see, I'm deactivating block instances in a loop (storing them on a stack for reactivation after the loop) so that successive calls to instance_place return unique instances IDs.

I've left the events for collision with block and platform alone.

The above is almost a true refactor, but completely ignores collision with a playerKiller on the frame where the player intersects a solid block. The original code running in GM 8.1 wouldn't ignore collision on this frame - instead, the end step code was running after x & y were set to xprevious & yprevious and after the collision events were processed (i.e., after the solid block had pushed the player out and the player had been moved up against the edge of the solid, and appropriate speeds zeroed). I've tried reproducing this in the End Step event with no success thus far; this is an approach I continue to consider.

Another possibility I'm considering (and will try next) is to wrap the end step logic to the next frame by putting it in the Begin Step event. This would guarantee it come after the collision events of the prior step, with the (small) downside that the player's death will occur one frame later, which I expect will be difficult to discern; I'll give it a go and see if it adversely affects the engine in other ways.

UPDATE:

Moving the playerKiller End Step logic (as it originally existed) into the Begin Step event, surprisingly, did not prevent the player from being killed by a spike embedded within a wall.

I had expected it would fix the issue, albeit perhaps creating new ones, since it would rectify the relative order of the position update, the block collision processing, and the playerKiller collision check.

2

Programming Questions / Re: GM 8.1 to Studio: colliding with playerKiller inside solid block

« on: April 23, 2015, 01:22:29 PM »

Thanks for the response. Sorry I didn't see your reply until now - when I posted this I didn't realize that email notifications are off by default.

According to the docs, the event order is only guaranteed to conform to a few rules:

https://docs.yoyogames.com/source/dadiospice/000_using%20gamemaker/events/index.html

Even if you figure out an order in more detail, subsequent updates to the software can change it, so it shouldn't be relied upon. In any case, the image you posted for Studio's event order does not represent the order of events - it's just a list of the events.

EDIT:

Looking at your work-around:

This ensures that the player will not die when clipping inside a block.

I needed to additionally check that the block is solid, since platform is a child of block, before preventing death.

UPDATE:

My current understanding of the problem is as follows:

In GM 8.1, playerKiller collision check happened in player's End Step because it was known to happen after other Collision events. The engine relies on this for proper function.

In GM Studio, the only order guaranteed each step is that of the 3 Step events and that of the Draw events.

Unless we want to muddy up one of our draw events (gross!) the only way we can ensure one collision check happens before another is by performing the checks in one or more of the 3 Step events.

E.g., we could do both checks in End Step, or do one in Step and another in End Step.

The downside of this is, we incur overhead when we perform a collision check in a Step event instead of using a collision event. (We also might have to rewrite the collision logic due to the change in locale.)

Ideally, we'd have a way to tell GM Studio something about collision event order dependency, but I don't know if this is possible with the way events are implemented.

For now, I'll put the checks in End Step, but if someone knows a way to indicate collision resolution order among objects, I'd much appreciate a reply.

3

Programming Questions / GM 8.1 to Studio: colliding with playerKiller inside solid block

« on: April 22, 2015, 05:37:11 PM »

Hi, first time posting.

I'm in the process of porting my fangame from GM 8.1 to GM Studio. I've noticed a difference in behavior: the player can sometimes collide with a playerKiller that is embedded in a solid block.

My code is built on a version of Lemon engine, which I've made modifications to as I go.

The player object checks whether it's touching a playerKiller in an End Step event, which I believe should come after the player has been moved out of the solid object - at least, that's how it seemed to work in 8.1. I know the order of events is not as transparent in Studio, and am wondering if there's a way to make this check somewhere with 100% certainty that the player will be pushed out of solid objects beforehand (thus keeping the player from exploding when touching a solid block that houses a spike, for example).