News:

Zatikon is back and free to play! https://www.chroniclogic.com/zatikon.htm

Main Menu
Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Topics - Calis

#1
BCS General / Pneumatic mechanism starts too fast
September 30, 2002, 04:36:02 PM
I managed to build a bridge that folds nice, but when it starts unfolding, the pneumatic mechanism pushes back too fast, instead of gently releasing the tension...

I think, the mechanism should not work with a linear compression/expansion speed, it should have a gentle acceleration/deceleration phase (maybe including some damping effect)

#2
BCS General / How to specify a joint?
September 30, 2002, 05:05:36 PM
I tried to raise 2 decks vertically (they are hanging down on 3 pneum elements for examlpe), but I couldnt figure out how to create appropriate joints.

The problem is, I have to support the non moving decks on the sides but my joints (I know how to do basic joints) usually release the wrong connections at least on one side. Copy + mirror + paste the working side doesnt solve this problem  (I fear, the information which part of a joint will get released is not part of the construction process at all :(

I'd like to tell the program for every component that is part of a joint whether it belongs to the left or to the right part. (maybe it is useful to split a joint into more parts, imagine one part moving away to the left, one to the right and a third one is just pulled up)

Well, maybe it is just a quirk of the pre release version ;)

#3
Next Version Ideas / Batch testing
October 21, 2001, 12:39:49 PM
... would come in handy when you start to evaluate the contest, too :)

What I'm thinking of:
Point the program to a directory, set preferences
(like number of cars, difficulty setting, number of runs,
number of tests - to make multiple tests for the same bridge, and MOST important: delay between start of sim and start of train - that way you dont have to have such unpredictable things in the rules like:'We will run the train a few seconds after..' - you could state exactly: 'We will test it with delays 3 and 5'),

and then the program will take every bridge found in that folder and test it with these settings, gathering infos into a text file (file name, bridge name, architect, cost, broken links, time for each of the train passes (for some benchmark guys  or  hehe... let the fastest train win :), total test time).

No graphics needed (maybe a progress report or whatever), should be able to be run in background..

I would like to see multiple tests per brigde, too:
test it with increasing load until it breaks on successive runs.. (maybe optional configuration via script file) so you can easy specify such runs:
easy 7 cars 2 runs
easy 9 cars 4 runs
medium 5 cars 2 runs
...

of course, here is another contest idea:
make a bridge that withstands the heaviest load
with a given budget :)  (on a tie, the cheaper bridge wins)

#4
Next Version Ideas / How close to the limit?
October 20, 2001, 06:54:33 PM
I would like to see how close the weakest link is to break.

A numerical readout somewhere on the screen should do the job..  something like 95.73% (of maximum load).

And an easy way to find this link would be nice, too :)
(blinking, special color during testing or a key in editing mode to highlight it)

#5
General Discussion / I just would like to know..
October 23, 2001, 08:38:38 AM
.. why the simple links from Bridge Builder have been replaced with these structured links and complicated nodes in Pontifex. (I do *not* want to criticise this decision, I just want to understand it http://www.pontifex2.com/iB_html/non-cgi/emoticons/smile.gif" border="0" valign="absmiddle" alt=':)'>

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)