Chronic Logic

Well, I'd play... I'd most likely loose money, http://www.pontifex2.com/iB_html/non-cgi/emoticons/smile.gif" border="0" valign="absmiddle" alt=':)'> but i'd be a neat environment.  You could go from city to city.  See what had been built.  Kinda like Sim City meets BB.

I think you would have to have a HUGE base of bridge levels before you could do it, and then the hard part would be bidding.  I think that part would be a long process to make sure who wanted to bid was able to get in, and what if you had 10 bidding on a bridge?  That would mean 9 wouldn't get to build anything?  You would almost need 10 levels if 10 were bidding, and then asess who would get to build what bridge at what cost.  That way everyone wins a bridge.  Quickly though you would have cycled through all bridge levels with the current pool.

This is a game idea for a year or so away at least.  We need to amass some levels first.

See CL, this is why we need mods... Someone needs to ban this guy before he hurts someone else, or himself. :biggrin:

I think it's ok, I've posted some things in some threads where it would have been more appropriate in another.

Yeah pj, what were you thinking. :rolleyes:

OK, Yes, on some levels it is tedious to try and mirror the level.  I try to use that to my advantage though, and will often intentionally build two different designs to see what holds up the best.

... Anyway, mendel and I just finished a couple hour long discussion about gravity and I will have to finish this thought later.

While an interesting concept, I think that implementation would be impractical.

Cable stay and suspension bridges are built in completely different ways. Cable stay are built from the towers out, and with suspension bridges, the cables are laid first, then the deck. How would you handle a cable stay design with two towers?

With the current system and .pxb file format, this isn't something that I can see being added.

How about, if a new system kept track of what you were adding, where, and when; and implemented gravity in the edit mode.  Then you could build the bridge in a fashion that requires you to plan about where links are added, and where they are removed. Building the bridge would be half the challenge. Running the train would be the other half. Pretensioned cables would be essential if you wanted to build a proper deck. Maybe a link when placed would show you the level of stress it is receiving when you build it by changing color, and if an added piece were to break, it would change to a new color like yellow. Before you could build on, you would have to eliminate yellow links.

This would add a different element of challenge. Perhaps you would be able to add different types of anchor points now, but I think that floating anchors should be abolished. Pilons would cost a different amount than anchor points on the shore. Perhaps that amount would be dependent on the water depth, and/or how deep the pilons are set to add stability.

Easing into gravity would not be needed or even desired in this game design. Bridges could be given a rating based on how much load they can support by the cost of materials to build it. The load is a value that could be adjusted by a slider perhaps, and selecting the highest possible load could be done before the level is tested. Part of the challenge would then not be design a cheap bridge, but it would be to design the most efficient bridge. That would be a much more appropriate measure of who are truly the Pontifex Maximi.

Funding wouldn't have to be capped anymore, but you would require a certain efficiency to pass the level.

Real quick note before I have to sign off.. I didn't see any horrible errors with that log... I'm not even sure what has been edited, but that was the jist of our conversation.

I approve. http://www.pontifex2.com/iB_html/non-cgi/emoticons/smile.gif" border="0" valign="absmiddle" alt=':)'>

I'll try to address more at a later date and time.

Instead of a thread discussing if this thread is being discussed or not, I've posted a message in the http://www.chroniclogic.com/cgi-bin/ikonboard/topic.cgi?forum=6&topic=18" target="_blank">Pre-tensioning Cables thread to direct them here. Now on with the countdown.

In case you are just joining us ;), I'll post a condensed version of my last message before the split:

Quote: from mendel on 5:08 am on Oct. 31, 2001
Lowering gravity will not eliminate "overshoot" or bouncing, because if damping was to eat all potential energy, the bridge would be "stuck" by friction and suddenly give when the train passed.Damping doesn't work to eliminate potential energy, it works to eliminate kinetic energy. Damping, in a mechanical sense, is a function of velocity. It will not change the final position of the system, only how long it takes to get there.

P* is an underdamped system because the bridge will bounce, and it will reach ss at sometime.

You are correct that as an underdamped system, slowly introducing gravity will not elliminate a problem with bounce. However, if the bridge is allowed to reach ss before gravity is increased additionally, then the impact of that bounce on the overall design will be minimal.

Of course, a poorly designed bridge is still going to collapse.

Quote: from Chillum on 2:10 pm on Nov. 7, 2001
An alternative idea: Make all links *unbreakable* until the bridge has settled.Or just unbreakable until you click "run train or HAV." That seems like a good solution because then you won't have to make the program guess as to when the bridge has "settled".

The only problem I see is this becomes a Train Timed bridge so to speak. It's not quite the same thing, but perhaps too close.

I've had "http://www.vectorlounge.com/04_amsterdam/jam/flamjam.html" target="_blank">Spank the Monkey" playing in the background for a while now. Addictive little game. It's a pretty simple loop, drums, a violin, and something I can only disscribe as bubbles.

I'm just not sure I see the need to ADD music to P*. I like the ability to load up my favorite mp3's or CD's. Sometimes I like to build bridges to the NiN soundtrack on Quake, other times it will be the Brady Bunch Theme song. It isn't as if the music will alter the mood of a level.

Quote: from mendel on 5:08 am on Oct. 31, 2001
Lowering gravity will not eliminate "overshoot" or bouncing, because if damping was to eat all potential energy, the bridge would be "stuck" by friction and suddenly give when the train passed.Damping doesn't work to eliminate potential energy, it works to eliminate kinetic energy. Damping, in a mechanical sense, is a function of velocity. It will not change the final position of the system, only how long it takes to get there.

There are only four possible states for a mechanical system. It can be overdamped, underdamped, undamped and critically damped. The bridges in P* are an underdamped system. If the bridges were critically damped, they would not have any overshoot, and they would reach steady state in a minimal amount of time. If they were overdamped, they wouldn't overshoot (and bounce) either, but the time to reach ss would be longer. If the coefficients of damping were too great, it may take hours to reach ss. The opposite of course would be an undamped system. In this system, the bridge would continue to bounce forever.

P* is an underdamped system because the bridge will bounce, and it will reach ss at sometime.

You are correct that as an underdamped system, slowly introducing gravity will not elliminate a problem with bounce. However, if the bridge is allowed to reach ss before gravity is increased additionally, then the impact of that bounce on the overall design will be minimal.

If the current system causes the bridge to overshoot its ss position by 1m when the level is first tested, then by easing into gravity, it may only overshoot by .01m. This makes a tremendous difference when waiting for the bridge to settle, and an even greater difference when you start adding mass (in the form of a train).

Of course, a poorly designed bridge is still going to collapse, but perhaps the deflection in the bridge will be less from the train than by the start of the simulation. A level that only requires 2 cars or so would gain from such a change.

Quote: from beaujob on 10:10 pm on Oct. 31, 2001
My vote is for having a settle button in the editorI think this is a tremendous idea. It is certainly needed if there is going to be a way to tense the cables. In such a mode, I think CL needs to change the damping coefficient to be critical.  This way, you won't need to wait for a settle period before you tense the cables.  An underdamped system is still reasonable for the actual simulation.

Quote: from Calastigro on 9:10 pm on Oct. 25, 2001
i like the idea to ease into gravity.

Please impliment it, CL!Has my vote... even so I think the pre-tensioned cables would be needed for some structures.  I can't think of any easy way to implement it though.

I'm on vacation... http://www.pontifex2.com/iB_html/non-cgi/emoticons/smile.gif" border="0" valign="absmiddle" alt=':)'> well, visiting the folks out of town anyway, so I son't be able to put a lot into this discussion, but I would like to mention, that I too have solved problems with the deck breaking by suspending it completely, and not using anchor points in the water to physically attach to the deck.

Until this post, I never gave much thought as to why it works. I also find myself using that technique subconsiously now. I've been intentionally building in a way so as not to physically support the deck. In order to create stronger support towers, I've been sagging the deck by 10m to allow me to build taller towers. (See the short links bug)

Anyway, just wanted to give mendel some feedaback on his post, and I'll try to make more of an appearence when I get back in town.

The PM has spoken. Take note CL ;). I will however disagree slightly. Yes, some nodes might still break, but not all the ones that currently break. This is because the dampining of the structure does not currently prevent overshoot. That is why current bridge designs must "settle". If gravity were eased into the simultation, then there wouldn't be an overshoot, and some joints that had previously failed would not experience as great a load.

Pretensioned cables, while a great idea, and something I want to see implemented, are not the end all. I think that the ease into gravity is more improtant to more than just cables, and should be implemented first.

Andy 24 has started a new thread so that this one can continue with pretensioned cables. Visit the new thread, http://www.chroniclogic.com/cgi-bin/ikonboard/topic.cgi?forum=6&topic=63" target="_blank">Easing into Gravity to continue gravity related discussions.

I agree with kvinge that easing into gravity is not a solution to making suspension bridges work, pretensing the cables is needed, and I hope to see this thread address some of the ways this can be implemented.

Based on the limited knowledge I have, this is not something that can be implemented with the current bridge format.  I think this is something that can be added, but will require a change in the way the cables are stored, and will result in a new version of the pxb file.

It should also be possible to convert version 1 pxb file to version 2, without causing some radical change in the P* engine. After reading the header, P* can determine if it is dealing with the newer file format, or the old format, and add a pretension of 0 to all the old bridges.

Quote: from mat-c on 11:26 am on Oct. 26, 2001
Also, a "pause on first break" option would be nice... the bridge would pause, with the broken link highlighted.I think the pause would work, but I want my broken links flying around the screen.  If they just turned yellow, I'm not sure I'd like that.  Half to fun is watch a poor bridge design collapse.

Better yet, what if the thumbnail were kept in the screens directory. Bridges that have a corresponding .thm could display that, otherwise, it could, otherwise, just generate one after the bridge is loaded for the first time. That would keep the .pxb format the same, and only make a change to the way p* handles things.