• 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!

SOLVED physics_joint_delete NOT deleting in this case GM 1.4.9999

C

CruelBus

Guest
I did a forum search and did not find anyone else having this problem.
Gamemaker 1.4.9999

Truck and trailer connection.

I have a truck object that has a fixture for its body, and creates a front and rear object that each have their own fixtures. The truck creates a distance joint between the front and rear objects.
Then the truck creates a trailer object.
The trailer object performs the same procedure as the truck : creates 2 objects with fixtures and a joint between them.
Finally, the truck creates a distance joint between its rear object and the trailer's front object.

I can delete the joint between the truck's front and rear, and the trailer's front and rear, but for some reason the system refuses to remove the distance joint between the truck and the trailer.
I have tried rope and revolute joints with the same failure to delete.

The joint between the front and rear within each object is required.

SOLVED: (USER ERROR) physics joints were being created every step, so deleting one of them made no difference.

Any ideas?
Simple diagram:
--- joint I can delete
=== joint I can't
trailer . . . truck
O --- O === O --- O
 
Last edited by a moderator:
C

CruelBus

Guest
So, a slight workaround:

The delete command works from within the truck object: physics_joint_delete(TRAILER.CUPjt);
IF the joint between the two is created within the TRAILER object:
Code: 
// in step event of TRAILER object
if(!SETUP){
    if(IS_TRAILER){
        CUPjt=physics_joint_distance_create(PIN2,LEADER.PIN1,PIN2.x,PIN2.y,LEADER.PIN1.x,LEADER.PIN1.y,false);
    }
SETUP=1;
}
It won't delete if the truck creates it. I have tried reversing the objects in the create statement, but it doesn't seem to matter:
Code: 
// in step event of LEADER object
if(SETUP==2){
    CUPjt=physics_joint_distance_create(PIN1,TRAILER.PIN2,PIN1.x,PIN1.y,TRAILER.PIN2.x,TRAILER.PIN2.y,false);
}
 
Last edited by a moderator:
Tyg

Tyg

Member
Hello, ill try to recreate this, is it a top down view?
could be the step event is re-creating the joint :)
 
Last edited:
N

Nidoking

Member
It looks like you're assigning a variable at instance scope. When you try to call the delete function from an instance other than the one that holds that variable, how are you addressing the variable in the other instance?
 
C

CruelBus

Guest
The truck has:

TRAILER=instance_create(x,y,OB_TRAILER);
PIN1=instance_create(x,y,OB_PIN);

The trailer creates its own PIN1 and PIN2.

The truck then creates the joint between
PIN1 and TRAILER.PIN2

The joint is only created in a "SETUP" event that fires once.
 
Last edited by a moderator:
C

CruelBus

Guest
Tyg said:
... is it a top down view?
could be the step event is re-creating the joint :)
Click to expand...
For testing purposes, yes, but will be isometric later.
Actually, Tyg, that "if(SETUP==2)" might be keeping the value of 2 and doing what you said: creating the link over and over every step, since I can't remember if I did a SETUP++ after it. There is a SETUP++ at the end of the STEP event but it's inside an else{}. I didn't notice a performance hit though. I'll definitely check that out.
 
Last edited by a moderator:
Tyg

Tyg

Member
Sorry but i need a little more info,
Is the idea that the truck picks up trailers and then drops them off?
or drops multiple trailers off?
I managed to get the truck object with a pin to connecct to a trailer(which would be a gereric object)
the parented trailers would carry the same code then connect
but i understand its tricky as to where the actual joints should exist and how to connect and disconnect them
is that the idea you have or am i offbase?
the reason i asked about the view is because the physics may have to be changed , overhead the trailer angle will be x,y based
and front view it would have to be more scale based
but the imoprtant thing is to connect and disconnect the trailers
so i dont see you ever assigning the setup var to 2
 
Last edited:
C

CruelBus

Guest
I won't be home for another day, but am pretty sure my "if(STEP==2)..." is firing every step.

The truck picks up and drops off trailers as needed, with 2 trailers possible. The main focus for me is a proof of concept on connecting and disconnecting multiple trailers, only using the truck as the controller, since the user will be in charge of the truck. Later, as the user progresses, the trucks will drive themselves.

To make things more complicated, this experiment is for when a truck and trailer combo is spawned, already connected. There's a separate state for a truck picking up and dropping off a trailer that: by sensors, create and by touch, delete, the joint.
Here's how the step event is for the truck and trailer (from memory, not copy-paste)
Code: 
if(!SETUP){
    // create pin1, pin2 and the distance joint between them
    if(TRAILERS){
        TRAILER=instance_create....
        TRAILER.TRAILERS=TRAILERS-1;
    }
    else{SETUP=1;ACTIVE=1;}
}
if(SETUP==2){
    // create joint between truck and trailer
    ACTIVE=1;
}
if(ACTIVE){
    //do movement of truck
}
else{SETUP++;}
It looks like a crazy way to handle it, but a step event has to fire on the trailer and truck, since both are passed additional info from a "dispatcher" object that will affect number of trailers, weight, destination, etc. that can't be assigned in the create event (unless you CAN do that and the passed info will be present BEFORE the step event fires for the first time. I had an issue with this type of thing, passing data before a step event, 5 yrs ago on my other game and this was my solution.)The object order is truck, then trailer, so the truck has to wait until the trailer has had its setup confirmed before making the joint. Each trailer must know what it is connected to at either end, and it's all way more complicated than I am letting on. If I can get the joint to break from the truck (or leading trailer) then it's a successful proof-of-concept and I can continue. Otherwise, I have to find a different way. (which I found by having the trailer make the joint to the truck)

The critical points are the pins, which follow predetermined paths, must maintain their length from each other (they represent axle centers) and are used as an angle reference to both slightly rotate the actual trailer object (that just follows the pins), and load the proper isometric rotated image for the angle, since I'm combining physics and paths in an isometric game.

I know that all probably sounded like a hot mess, but I think you have already found the issue with my code and I will verify late tomorrow and will post the relevant code. PIN1 and 2 are both created eventhough I didn't show it.

Right now actually, my biggest issue is that I just discovered I can no longer publish to Google Play using GM 1.4, so will have to migrate my main project to version 2. The issue presented here is me trying to work out if such a thing was possible (physics + fixed paths for tractor-trailer combos) for my next game, after I publish the one I'm working on.
 
Last edited by a moderator:
Tyg

Tyg

Member
So how are you attaching your joint making 2 fixtures then the joint then deleting the fixtures?

Heres what i was thinking and correct me if im wrong
i have a truck object a pin object and a trailer object (top down to show rotation then can be easily changed for iso)
the trucks sprite is anchored on its fifth wheel for easy rotation and spawns a pin on the trucks creation and follows that phy_position
the pins sprite is anchored in the center
the pin creates a fixture that is anchored to the truck
the trailer sprite is anchored at the front or slightly in a bit
the trailer creates a pin at the front
the pin creates a fixture to the front of trailer and bind it
when the 2 pins collide they create a revolute joint and follow each other and a rear trailer pin is now created
a connected var is set on the front pin
the rear trailer pin creates a fixture to the rear of trailer and bind it
the next trailer is created which creates a front pin which creates a fixture again
if the rear trailer1 pin collides with the front trailer2 pin they create another revolute joint between the 2 pins
a connected var is set on the front pin of trailer 2 and so on
a max trailers var could be set on the truck also

Thats connecting them and ill try to make a demo for dropbox

To disconnect im hoping that setting the connected var will work, keeping the pins and fixtures intact
and maybe destroying the rear trailer pins

Just the start but here is a pic



I managed to get the trailers to connect, havent added the revolute joints or disconnect and ill have to fix the movement when we go around
but its a start :)

I managed to get the trailers to disconnect by holding the mouse button over the connection and moving the truck away
arrow keys move the truck. Im sure there is a better way to do it, but im just tring to get the physics working right now
i think the next step would be to get it to follow a path :)
i got the truck to follow a path, because physics obects would not folow a path
i used a trick of making an invisible dummy object to follow the path the step the phy_position of the truck with it
 
Last edited:
C

CruelBus

Guest
I checked my code and you were correct from the start. The SETUP var was held at 2, causing the joint to be created every step. I have decided I like making the joint from the trailer better anyway, since I don't have to wait the additional step and can drop the else{} at the end. Thanks for your help!
 
You must log in or register to reply here.
Top