I hope you're not serious. If you are, my condolences. ☹️ On a somewhat Freebuild-related note, I just found some notebooks where I planned out the first Cemetech City including its subways! Elfprince, I really am chomping at the bit to implement my train functionality into the game.

I am serious, and what worrys me more is that you haven't answered the question but instead moving on... not suspicious or anything.

No, I'm serious. Didn't hit the bone or anything, but I'm laying low for a couple days.

Do you have any free coding time? I'd love to at least get you looking at the Torque physics code.

I'm pretty busy at least until Thursday if not until Sunday, but I think we should start with some brainstorming. Major points:

1) How to connect cars
2) How to disconnect cars
3) How to differentiate powered and unpowered (but spinnable-wheeled) cars
4) How to resolve inconsistencies, like two powered engines pulling in opposite directions (coupling disconnect threshold?)
5) How to follow tracks
6) How to implement things like switching tracks or X's where one or more tracks becomes more than one track.

While your working on CemetechCity you might want to remake the roads, it's almost impossible to drive on them.

Not impossible, but it might be good to have some smoother roads 🙂

You could even package the map with some already placed road plates.

Initializing/deinitializing point to point or hinge constraints. See Page 26


I *think* that we want kinematic MotionStates for our powered cars and dynamic motionstates for our unpowered cars. With a btRaycastVehicle Controller we can treat each car as a single rigid body and approximate the wheel location and just apply a spin animation. (See Pages 24/25/29



Good idea. Or just show them stalling out/or the more powerful engine dragging the other one, but at a slower than usual pace. Or all of the above.


Some variant on a slider constraint? See Page 26



For this, I'm actually not entirely sure.

Looks to me like a point-to-point would be the way to go. Hinge wouldn't be good for things like going up and down hills, or leaning into high-speed curves. 🙂

Based on reading the documentation, it looks to me like every car, powered or unpowered, should be a Dynamic Rigidbody. Kinematic rigidbodies have no mass and cannot be influenced by Dynamic Rigidbodies (although they can indeed influence Dynamic Rigidbodies).

Sounds good to me.

[quote="elfprince13"]
Some variant on a slider constraint? See Page 26 Nah, a slider constraint constrains to an axis, not a path. We're going to need something more complex, like a variation on the Point-to-Point constraint that is a Point-to-Spline constraint, possibly something we'll need to write ourselves. Not to mention intelligently realizing that adjacent linked tracks should continue the Spline.

Nor me, although from a high-level view based on my answer to (5), perhaps something that changes which single Spline is the active path for that track?

I had that thought too, especially for speed, but a more accurate representation would use several hinge constraints on different axises.


My understanding is that user-controlled objects have to be kinematic. I suppose we can apply forces externally to it though.


My guess is we'll need a dedicated track-building mode to build a doubly-linked list of track-splines in a connected rail system.


Ooh, I like that.

*topic split*

[quote="elfprince13"]
I had that thought too, especially for speed, but a more accurate representation would use several hinge constraints on different axises. I suppose, but it seems to me for the sake of avoiding unfortunate problems with conflicting physics systems, there's no hinge that would allow car to car anti-rotation where one car is rotating on its front-to-back axis and the other is rotating in the opposite direction along its front-to-back axis.

Aight, we'll have to read up on that more.

How do you propose creating that and storing it in the map? Perhaps have it be dynamically generated whenever you switch out of editor mode and exported to the other clients? It seems to me that it wouldn't be too computationally-expensive to find all the track-type bricks that are built and figure out which of them are adjacent and connected. Also, what about spawning trains onto tracks? Snap to the nearest track or something?

Of course, the main difficulty would be propagating that change and then updating the lists of connected-track splines.

There have countless train simulators, including one in Torque, Bridge Construction Set. Perhaps you should look up and contact one of their dev teams and ask them for help.

Not a bad idea at all, to be sure! I don't think any of them were really sandbox games though. Sid Meier's Railroads! would be the game that I know of that closest to what we're discussing, and I'm sure their track storage mechanism is very complex.

Maybe you could look at how OpenTTD does it and see if it applies or can be applied to Torque.

Whoa, very impressive; their routing algorithm for trains must be completely insane. The main different between that and Torque imho is that that requires tracks on tiles in one of four orientations, whereas tracks in Torque can be placed arbitrarily in the coordinate system and at arbitrary rotations 🙂

Point-point it is.


We can make wrapper models for the straight LDraw track models. The wrappers can have LDraw meta-data defining track endpoints and pairs of splines (or for mono-rail, single splines) that represent valid routes across the track. Model instances can have a variable representing the active route. Tracks are linked at endpoints, so the question is what format we want for the meta-data encoding the links between tracks. In-game is easy. Spawning makes sense to do by way of snap-to-track. As far as building goes, construction should never ever be propagated between clients. Clients send build commands to the server and the server propagates updates to all clients.


We should maintain the entire data structure all the time, so I guess a graph is a more accurate description than a list, and propagating active edge information can be handled by way of Torque's normal net events or ghosting system.

[edit]
Both OpenTTD and the Bridge Construction program look very cool, but I'm not sure we need the structural elements of Bridge Construction.

Excellent.

Sorry, that is indeed what I meant. I propose that each of the wheels tries to follow the track splines to a certain degree of tolerance. Snap-to-track sounds awesome, but what about the first track? 🙂 I suppose snap-to-track doesn't necessarily preclude arbitrary placement.

Definitely agreed. A graph would most certainly be the most accurate method; shall we maintain a per-wheel pointer into the graph as to what piece of track that wheel is on? (and of course break the link if that piece of track is moved or deleted)

Will the track be "magnetic" eg. Will the trains be able to drive up the walls and on the roof? (If the tracks can be placed there?)

If we're using the vehicle controller, we don't necessarily want per-wheel tracking. To save processing power, we could run our path to follow between the two rails and have 2 point-spline constraints (however we end up implementing those). Then we just need to track the front and back of the car.


Lucas: I'd like to see support for non-conventional track orientations, but I'm not sure how the details would play out. It would make the old lego monorails look really cool though.

That sounds fair, I can't think of any flaws yet.

The monorails would work even without that, they couldn't turn upside down either (at least the LEGO monorail set that I had).