• Hey Guest! Ever feel like entering a Game Jam, but the time limit is always too much pressure? We get it... You lead a hectic life and dedicating 3 whole days to make a game just doesn't work for you! So, why not enter the GMC SLOW JAM? Take your time! Kick back and make your game over 4 months! Interested? Then just click here!

Check if player will collide with ANY PHYSICS OBJECT before moving?

I got my movement code AGES ago from this video by HeartBeast:

The reason why I'm wanting to check for these collisions is because the hspd and vspd are NEVER zero if the player is pressing a movement button, EVEN IF they are running into a wall.

This is causing a hiccup in displaying my quests screen, which adds the hspd/vspd to the quest object's coordinates. Basically, in order to make sure a portion of the quests screen is drawn in the right spot, I have to add the player's hspd/vspd to the quest object's coordinates, otherwise it "slides" into place rather than being in place already.

How I have the quests menu set up is too complex to dive into. All I need is one of these two things:

A.) Some way to detect if there is another physics object in the way before the player tries to move that direction, so I can set hspd/vspd to zero then.

B.) Some way to save the player's coordinates as a variable every second, then compare their current location to that variable to see if it has changed.

Code:
/// @description scr_move_state
scr_get_input();


//Get direction
dir = point_direction (0, 0, xaxis, yaxis);

//Get length
if (xaxis == 0 && yaxis == 0) {
    len = 0;
} else {
    len = spd;
}
  
//Get the hspd and vspd
hspd = lengthdir_x(len, dir);
vspd = lengthdir_y(len, dir);


//if text appears
if global.tboxActive = true {
spd = 0;
}

if instance_exists(obj_save_popup){
spd = 0;
}

//Move

phy_position_x += hspd;
phy_position_y += vspd;
 

Joe Ellis

Member
Rather than saving the player's coordinates every second, You could do a simpler thing where it saves it every step, I often use this with collision things, set ox & oy at the start of the step to its coords, then at the end of the step, or anywhere during the step event you can check if it has moved.
As for the actual question I don't know cus I don't use the physics system.
However for the thing your talking about where you want the game to freeze while a popup is there, I use a global pausing system:

Code:
with all
{
if object_index < obj_popup //put all menu and popup things after normal objects in the resource tree
{
obj = object_index
instance_change(obj_paused, false
}
}

//and with unpausing:
with obj_paused
{instance_change(obj, false}
Also for checking to see if it will collide with any objects before moving, its hard to determine cus of the speed being set normally just before it does collision checks, but you could alternatively temporarily move the object to the position it would be in after moving, check if it collides with anything, if not, keep it at that position, and if it does move it back to ox & oy
 
Maybe you have learnt this already, and its not entirely helpful because you've already built your game, but setting the phy_position_x and y manually is not recommended, it can break the physics simulation.

That's why the heartbeast tutorial is not generally recommended as it teaches a way to use the physics system that goes against the whole physics system and can lead to problems like you're having.

That said, I'd like to know how are the quest object, the quest screen and the player object are all linked so that they are affecting each other? Is the location of the quest screen based on the in-game position of the quest object?

I would suggest having the quest screen display on the GUI Layer, which is independent of the where the current view is in the world, and it will remain in place without being affected by what is happening in the world.

Don't know if that is possible with your current setup, but without knowing more, that's the direction I would try to take.
 
That said, I'd like to know how are the quest object, the quest screen and the player object are all linked so that they are affecting each other? Is the location of the quest screen based on the in-game position of the quest object?

I would suggest having the quest screen display on the GUI Layer, which is independent of the where the current view is in the world, and it will remain in place without being affected by what is happening in the world.
The quests screen is drawn according to the view camera, which follows the player. But there's a delay for some reason which is causing the quest menu to "slide" into the correct position if the player is moving when it is opened. To fix that, I add the player's hspd and vspd to the coordinates of the quests screen, and this works... unless the player is walking into something (not actually moving, but the hspd and vspd ARE being changed).

Example of the menu coordinates:
Code:
x = camera_get_view_x(view_camera[0]) + 160 + obj_player.hspd;
y = camera_get_view_y(view_camera[0]) + 120 + obj_player.vspd;
Right now I have a temporary fix that hides the menu for .05 seconds until everything is in the correct position. It's a little annoying that the menu can't pop up INSTANTLY, but it's so quick it's hardly noticeable.
 

Yal

šŸ§ *penguin noises*
GMC Elder
Change the camera in the End Step event, then it's guaranteed to be updated after all normal movement for that step is done.

You can also use the Draw GUI event to draw things relative to the screen, making them stay in place even as the view and objects inside it are moving.
 
Top