1. Hey! Guest! The 36th GMC Jam will take place between February 27th, 12:00 UTC - March 2nd, 12:00 UTC. Why not join in! Click here to find out more!
    Dismiss Notice

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

Discussion in 'Programming' started by OblivionSkull21, Nov 2, 2019.

  1. OblivionSkull21

    OblivionSkull21 Member

    Sep 26, 2017
    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.

    /// @description scr_move_state
    //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;
    phy_position_x += hspd;
    phy_position_y += vspd;
  2. Joe Ellis

    Joe Ellis Member

    Aug 30, 2016
    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:

    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
  3. IndianaBones

    IndianaBones Member

    Jul 5, 2016
    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.
  4. OblivionSkull21

    OblivionSkull21 Member

    Sep 26, 2017
    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:
    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.
  5. Yal

    Yal GMC Memer GMC Elder

    Jun 20, 2016
    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.

Share This Page