elfprince13 wrote:
Lucas W wrote:
Quote:
So as long as Freebuild is being developed
Is it? I haven't heard any development news lately.
I just shot my finger with a nailgun. 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.
KermMartian wrote:
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.
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.
elfprince13 wrote:
KermMartian wrote:
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.
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.
KermMartian wrote:
1) How to connect cars
2) How to disconnect cars
Initializing/deinitializing point to point or hinge constraints. See Page 26
KermMartian wrote:
3) How to differentiate powered and unpowered (but spinnable-wheeled) cars
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
KermMartian wrote:
4) How to resolve inconsistencies, like two powered engines pulling in opposite directions (coupling disconnect threshold?)
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.
KermMartian wrote:
5) How to follow tracks
Some variant on a slider constraint? See Page 26
KermMartian wrote:
6) How to implement things like switching tracks or X's where one or more tracks becomes more than one track.
For this, I'm actually not entirely sure.
elfprince13 wrote:
KermMartian wrote:
1) How to connect cars
2) How to disconnect cars
Initializing/deinitializing point to point or hinge constraints. See Page 26 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.
elfprince13 wrote:
KermMartian wrote:
3) How to differentiate powered and unpowered (but spinnable-wheeled) cars
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 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).
elfprince13 wrote:
KermMartian wrote:
4) How to resolve inconsistencies, like two powered engines pulling in opposite directions (coupling disconnect threshold?)
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. Sounds good to me.
[quote="elfprince13"] KermMartian wrote:
5) How to follow tracks
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.
elfprince13 wrote:
KermMartian wrote:
6) How to implement things like switching tracks or X's where one or more tracks becomes more than one track.
For this, I'm actually not entirely sure. 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?
KermMartian wrote:
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.
I had that thought too, especially for speed, but a more accurate representation would use several hinge constraints on different axises.
KermMartian wrote:
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).
My understanding is that user-controlled objects have to be kinematic. I suppose we can apply forces externally to it though.
KermMartian wrote:
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.
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.
KermMartian wrote:
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?
Ooh, I like that.
[quote="elfprince13"]
KermMartian wrote:
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.
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.
elfprince13 wrote:
KermMartian wrote:
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).
My understanding is that user-controlled objects have to be kinematic. I suppose we can apply forces externally to it though. Aight, we'll have to read up on that more.
elfprince13 wrote:
KermMartian wrote:
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.
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. 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?
elfprince13 wrote:
KermMartian wrote:
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?
Ooh, I like that. 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.
DShiznit wrote:
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.
TheStorm wrote:
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
KermMartian wrote:
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.
Point-point it is.
KermMartian wrote:
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?
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.
KermMartian wrote:
Of course, the main difficulty would be propagating that change and then updating the lists of connected-track splines.
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.
elfprince13 wrote:
KermMartian wrote:
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.
Point-point it is. Excellent.
elfprince13 wrote:
KermMartian wrote:
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?
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. 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.
elfprince13 wrote:
KermMartian wrote:
Of course, the main difficulty would be propagating that change and then updating the lists of connected-track splines.
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. 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.
elfprince13 wrote:
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.
That sounds fair, I can't think of any flaws yet.
elfprince13 wrote:
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.
The monorails would work even without that, they couldn't turn upside down either (at least the LEGO monorail set that I had).
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.
»
Go to Registration page
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum