Hello, I’m trying to make a tank with semi-realistic tracks. That is, they don’t move around, but they can deform based on the terrain the tank is driving on, like in Armored Patrol: https://gyazo.com/a1dcb7c790074dab1f0d8833d2643aac
The only solution I can think of is having each track section connected to a part between the next track section and it with hinge constraints. Then, connect that part to the corresponding wheel to translate up and down movement to the tracks. Obviously the tracks would be uncancollide, so that the wheels would actually be moving the tank. Here’s some progress I’ve made on this solution: https://gyazo.com/85d4316d3d34438fe75fc343c2bdfc90
The problem is, I can’t find a good way to connect that part to the wheel while still allowing the wheel to rotate. I’ve tried some things, but they always end with either the wheel not being able to rotate, or, when the up and down movement from the wheel is translated to that part between the two track sections, only one of the track sections actually moves.
Is this the right way to go about it? How else could I achieve semi-realistic tracks like Armored Patrol? I know I could just make the tracks fully physics based, and I’ve already done that, but it’s a little too unrealiable for me and from what I’ve seen, Armored Patrol’s tracks never break.
I would approach this by creating parts between the bottom of each wheel and the one behind it and then setting the CFrame and size of those parts each heartbeat, but you will end up with a gap (can be filled but possibly expensive to do every heartbeat, will have to run tests on that) between the segments and you will not be able to have 3D detail on the tracks. You can make use of texture offsets to give the illusion of a moving track though.
I’m not sure that I understand what you mean. Are the parts you’re talking about the track segments themselves? I don’t know what the purpose of the parts would be and how they would allow the tracks to deform.
I’ll attempt to provide a solution. Basically the attachments for the tracks are attached to the wheel. Because the wheel is mounted to a sliding pillar suspension, as it moves up and down, the constraints move with the wheel up and down as well. The tracks have no collision physics themselves.
I’m already aware of how to make the tracks fully physics based with them going around the wheels and such and actually providing propulsion – I’m asking about how to make armored patrol style kills.
That is exactly what I was trying to do with my proposed solution, but I couldn’t figure out a good way to attach the track segments to the wheels to allow for the up and down movement.
This is what I mean when I say sometimes one of the track segments doesn’t move. If I could get this track segment to move every time, it would mean that I could indeed connect it to the wheel and have them both move up and down with it. If anyone knows why this is happening/has any ideas for an alternate rig I’d love to hear it.
The track on the left does not move, it only moves when I move it with the move tool. When moving it by editing the prismatic constraint (to simulate being attached to a wheel moving up and down), it does not move.
I’ve noticed it doesn’t move when you set the upper limit. I think that’s an expected behavior since neither of the objects are “moving” when you do change the constraint settings. Is this in pause mode or run mode?
Is this roughly what you meant? I had to move it to a localscript and use RenderStepped because on heartbeat the track segments would lag behind a lot.
I still think that there’s a way to do it with constraints, because on Armored Patrol everyone can see the tracks moving just as smoothly as for the person controlling the vehicle. Perhaps I could attach a hinge to each track segment as before, but just move the proxy part every step instead of the track segments themselves.
Edit: I assumed before that the tracks I showed in the gif above do not replicate to other users. The track segments are created in a localscript and edited in a localscript, but I tested on an actual server (not play solo) with my brother, and they do indeed replicate to other users just fine. This place is FilteringEnabled. Not a bad thing, but just curious as to why they do replicate when they are created in a localscript. The only thing the script does is create the parts, then edit their properties every step in RenderStepped based on the position of parts beneath each wheel. The parts beneath each wheel are anchored and are also moved every step in the same localscript. If anyone knows why the tracks replicate, I would love to know because I am obviously missing something.
If anyone knows why the tracks replicate, I would love to know
BasePart
While part properties do not technically replicate, there are a few exceptions. If the part is created by a client and that client simulates physics (the part falls, hits other objects, moves by constraints, etc.), the resulting changes will get copied to the server.
The description is not complete or specific not enough to know for sure, but your client 1) simulates physics and the the parts being simulated 2) hits other objects - the CFramed tracks.