Well after a few days of trying, I feel I have run up against a limitation on the physics abilities of GS. I have applied the blocks which were recommended, and that does static attach one actor to another but again, I am looking to tow a trailer and the kinetics involved with that, GS just is not built for it. I have tried several variations and attachment methods, but even with an offset 'hitch' the needed rotation does not occur as the effected item's center is not changed, so basically if the hitch gets bumped from the bottom, the entire trailer moves up as if hit from the center.
I have created also 4 small 'bumpers' on the rear of the truck where the 'hitch' sits in the middle, but the same effect occurs.. basically no rotation of the trailer other than on the axis of the hitch itself.. (
I can imagine that the game you showed had allot of keyboard pounding for the jumps and for the rolling of the carriage over the terrain. I even went so far as to produce a counter rotation by the trailer (at the hitch) for 'simulated' joint movement.. that works great for forward.. simple.. but the real challange is Reverse.. thats whats killing me.
One of the aspects from my game is (like most others of it's type) the maneuvering of a vehicle to a specific point to perform an action. Because I want to be able to make it challenging for the player, sometimes they have to back into a location. which is not to difficult for 3 of the 4 cars they can use, but the Semi would add the extra challenge of a trailer which turns up the difficulty when it needs to be used. and this under time pressure.. That is why I have burnt so much time on this.
@sparkania -- before this thread goes stone cold (and you give up thinking "GS just is not built for it"), I would like to make a suggestion. Perhaps we are not looking at the relationship of the "cab" to the "trailer" correctly. For example, you are concerned about the rotation of the cab/trailer between the "hitch". But instead of looking at the cab and trailer, it seems to me that you should be modeling the relationships between the front (cab) and rear (trailer) wheels instead. The way I'm seeing it, both the cab and trailer are simply boxes that are attached to the front and rear wheels. And the rotation about the hitch is simply an artifact of the relationships between the two sets of wheels, the cab, and the trailer.
Do you want to pursue that line of reasoning?
Note: Oh... and I want to make it absolutely clear that GS can easily handle this kind of stuff. The relationships just needs to be conceived and modeled correctly.
I had written a much larger response about an hour ago, but in my response, I THINK I found the problem.. I found myself complaining about the inability to move the center of an actor as 3 would be in play for this to work. I believe I solved two centers and now I am hammering to solve the third.
you see, the constraints in the Mouse and Tail setup cleverly relate the positioning of an actor's X/Y/R with another's. but 3 are needed to make a functioning trailer. the XYR of the Peg (hitch), the XYR of the Trailer image and then the XYR of the Trailer Wheels.
First I create my Trailer actor with a great deal of transparent space to it's front, making the visible image for the trailer's roof about 2/3 of the complete image. This creates the 200px long trailer image, but since the image is really 300px long, the Center of the image has moved 'forward'. so when I constrain the Peg simply to the Center of the Trailer image, it is located 'forward' on the trailer. so that made 2 XYR's in the same place. (I felt a little stupid when I figured that one out) So now the solution is how to use drag to orient one side of a Propeller as opposed to a towing a Trailer. The XY of the Peg and the R of the Wheels.
I seem to be caught in a loop.. If I constrain the Peg XYR to the wheels, then the Peg becomes ineffective when colliding with the socket actors on the Truck as it is taking it's commands from the Wheels. When I constrain the Wheels to the Peg, the any thoughts of the Drag or Friction on the wheels are gone for the same reason.. Cannot seem to connect the Leg bone to the Leg bone..
You are saying that there are three 'things' to take into consideration; cab wheels, trailer wheels, and hitch. But it is modeling the relationship of the hitch to the other two 'things' that is is the issue for you. Yes?
To paraphrase your comments above, you see the hitch as a rotating joint between the cab and trailer and is not modeled the same way one would model two actors welded together (like the mouse and tail example).
You also mention that there is a difference in the way a vehicle works when its acting to drag (or tow) a trailer and when it is acting as a propeller. I assume you mean the forward/reverse issue. That is, a truck towing a trailer is a completely different kind of vehicle than a truck backing up a trailer.
If I understand the situation -- I would suggest doing something like the following example. In the example, use the up and down arrow keys to put the cab wheels into forward and reverse. Use the cursor to 'steer' the cab wheels. (Its a very crude steering mechanism, but functional for this purpose.)
The idea is to model the relationship between front and rear wheels. This relationship is the third 'thing'. It is the hitch (the joint) between the two sets of wheels.
I added the extra controls for Left and Right to the Front Wheels actor but it didnt want to turn, after reviewing the blocks.. the constrain self.rotation to vta was blocking the turn.. so I turned it off.. and whammo!!
I am not cool enough yet to attach files so if You want to see the light graphic version of what you sent me..
Now that you know the 'joint' relationships between cab and trailer (wheels), a next big challenge will be to translate them into a usable physics system. For example, you just found that constrain behaviors override just about anything. That means that because the XYR of the cab and trailer are created with constrain behaviors, they are hardwired and they will not respond to the physics within your game. If you want to bounce, collide, or use any other physics behaviors, you will need to carefully consider how to use those relationships/equations in behaviors that don't override stuff.
Comments
New to GameSalad? (FAQs) | Tutorials | Templates | Greenleaf Games | Educator & Certified GameSalad User
I have created also 4 small 'bumpers' on the rear of the truck where the 'hitch' sits in the middle, but the same effect occurs.. basically no rotation of the trailer other than on the axis of the hitch itself..
He told the fourm it required 'wicked math' to get the effect you describe. Are you ready to step up to a little trig?
In the meantime, I really like the 'bumpers' idea you are experimenting with. You should continue to explore that!
One of the aspects from my game is (like most others of it's type) the maneuvering of a vehicle to a specific point to perform an action. Because I want to be able to make it challenging for the player, sometimes they have to back into a location. which is not to difficult for 3 of the 4 cars they can use, but the Semi would add the extra challenge of a trailer which turns up the difficulty when it needs to be used. and this under time pressure.. That is why I have burnt so much time on this.
Do you want to pursue that line of reasoning?
Note: Oh... and I want to make it absolutely clear that GS can easily handle this kind of stuff. The relationships just needs to be conceived and modeled correctly.
you see, the constraints in the Mouse and Tail setup cleverly relate the positioning of an actor's X/Y/R with another's. but 3 are needed to make a functioning trailer. the XYR of the Peg (hitch), the XYR of the Trailer image and then the XYR of the Trailer Wheels.
First I create my Trailer actor with a great deal of transparent space to it's front, making the visible image for the trailer's roof about 2/3 of the complete image. This creates the 200px long trailer image, but since the image is really 300px long, the Center of the image has moved 'forward'. so when I constrain the Peg simply to the Center of the Trailer image, it is located 'forward' on the trailer. so that made 2 XYR's in the same place. (I felt a little stupid when I figured that one out) So now the solution is how to use drag to orient one side of a Propeller as opposed to a towing a Trailer. The XY of the Peg and the R of the Wheels.
I seem to be caught in a loop.. If I constrain the Peg XYR to the wheels, then the Peg becomes ineffective when colliding with the socket actors on the Truck as it is taking it's commands from the Wheels. When I constrain the Wheels to the Peg, the any thoughts of the Drag or Friction on the wheels are gone for the same reason.. Cannot seem to connect the Leg bone to the Leg bone..
You are saying that there are three 'things' to take into consideration; cab wheels, trailer wheels, and hitch. But it is modeling the relationship of the hitch to the other two 'things' that is is the issue for you. Yes?
To paraphrase your comments above, you see the hitch as a rotating joint between the cab and trailer and is not modeled the same way one would model two actors welded together (like the mouse and tail example).
You also mention that there is a difference in the way a vehicle works when its acting to drag (or tow) a trailer and when it is acting as a propeller. I assume you mean the forward/reverse issue. That is, a truck towing a trailer is a completely different kind of vehicle than a truck backing up a trailer.
If I understand the situation -- I would suggest doing something like the following example. In the example, use the up and down arrow keys to put the cab wheels into forward and reverse. Use the cursor to 'steer' the cab wheels. (Its a very crude steering mechanism, but functional for this purpose.)
The idea is to model the relationship between front and rear wheels. This relationship is the third 'thing'. It is the hitch (the joint) between the two sets of wheels.
sorry.. gotta play.. er.. I mean.. Gotta go implement that into my game design.. back later!!!
I am not cool enough yet to attach files so if You want to see the light graphic version of what you sent me..
http://sparkania.com/items/trucktrailer.zip
Now that you know the 'joint' relationships between cab and trailer (wheels), a next big challenge will be to translate them into a usable physics system. For example, you just found that constrain behaviors override just about anything. That means that because the XYR of the cab and trailer are created with constrain behaviors, they are hardwired and they will not respond to the physics within your game. If you want to bounce, collide, or use any other physics behaviors, you will need to carefully consider how to use those relationships/equations in behaviors that don't override stuff.