The structured links/nodes seem to have mostly disadvantages:
1. Shorter links are weaker now than longer ones due to compressed diagonal sublinks
2. The nodes are stiff and seem to break easily (in some situations they behave like ultra short (=ultra weak) links)
3. There are strange lateral forces induced to adjacent links when a node gets compressed (easy to see on top of cable carriers when you dont remove the lateral link between left and right carriers
4. the orthogonal arranged nodes look awkward in arches, and makes the arch really fragile now
5. I guess, it takes *much* more CPU time to calculate
Seeing all this (and I´m sure CL has been aware of this when changing the design), I wonder why it was changed.
2 guesses: CL wanted to have stiff nodes (better matches reality, but taking the first point into account I´d say it is worse now)
CL wanted to make better looking (not so simple) bridges (but taking the 4th point into account I´d say it is worse now)
Doh.. a 3rd guess: Did CL want to free us from the need to have supports going into the 3rd dimension to avoid the bridge falling to the side? But a simple X between symmetric links would have done the job, too (maybe generated automagically like the lateral link now)..
What do I miss here? What was the real ´design decision advantage´ of the structured approach?
(Edited by Calis at 1:47 am on Oct. 23, 2001)
Thats just me though... Many people I talk to like the old style more. Might have something to do with processor power being choked by all those bars.
Torsion is the twisting force, which can be more devastating than any other if you happen to get it wrong.
Torsion is also quite difficult to calculate and would probably add heavily to CPU usage during the game, so I'm guessing that this is a simplified version. Either way, I like the system.....it's enough of a challenge without being tedious IMHO.
(Edited by panther at 9:31 am on Oct. 25, 2001)
Torsion doesn't really seem much more difficult to calculate than tension and compression; you just multiply force by distance from a point to get the torque about that point. It's more expensive to calculate torque than not to calculate it, but it's less expensive to calculate tension, compression, and torque for one beam than to calculate only tension and compression for a dozen beams.
I know I'm playing Devil's Advocate here, but I do enjoy the game a lot. I just think that the new multibeam design adds a lot of frustration by making your bridges weaker and making train runs take longer.
I think that a future consideration would be if there are two beams that are connected at their endpoints, the joining box should be normal to the perpendicular bisector of the angle between them. meaning if two light steel beams were to join at a 90 degree angle, the joint would be orientated at 45 degrees. If a heavy steel or cable were attached to that joint as well, the joint would be orientated to the two beams that are of similar material.
This would solve problems with building the arch and making it look pretty. It would also add strength to the design. Where this would be a problem is when creating a joint made of three or more same material beams. Perhaps it sould be vertical in that case, or perhaps have a "handle" that extends from the joint allowing you to rotate the orientation. That would be really cool.
b) Rotating joint boxes runs the danger of twisting the adjoining bars. If you have three bars that are not coplanar (= in the same plane), you will get twist.
c) If it is worth the effort of checking for condition b) - need only be done in the editor - my suggestion would be to set orientientation when the second bar is connected to the joint and not change it afterwards unless a non-coplanar beam is attached (it reverts to regular orientation then).
Orientation is also changed when after deletion, only two beams remain.
That way, you don't need extra interface stuff, yet have the orientation under your control.