Skip to main content

Show Posts

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

Messages - Bernd Gabriel

2
Simutrans Gaming Discussion / Re: Poll: multiplayer or single player?
Welcome to the forum, Xelofino!

Don't worry about your English, this is an international forum ;)

If I'm already here : Wouldn't it be nice to have environmental disasters like earthquakes and floods which are for example destroying your tracks? ( just a thought)

Simutrans is a construction and economy simulation, but not a destruction game. Therefore it is no place for disasters. Never ever.
4
Simutrans-Extended development / Re: [8.2 bug?] fast forward and speed / acceleration
I'm sorry, but I cannot reproduce this behaviour. In both cases the 3806 kW prairie tank double tractions win the race before the 2nd winners, the 1600 kW churchward stars single tractions.
But some prairie tank trains are named "star" (e.g. number (5)).

As "fast forward" speed depends on processor speed and screen refresh timing, please post some figures.
Mine are:
Processor clock: 1,8 GHz
Frame rate: 10 fps in "fast forward" mode.
5
Simutrans-Extended development / Re: [8.2] Going uphill seems a bit unrealistic.
I'm not entirely sure why the results are inconsistent, but, generally, the trains with faster speed entering the slopes will make it to the top quicker than the trains with a slower entry speed.
That is intended and physically correct. With some inrun you run up the hill faster than from standing still. That's a feature of the new physics model: There are no (regular) abrupt speed changes any more.

I'll have a look into your save game... (pure Britain 128 EX pak?)



Impressive test track!
Fantastic idea with the Cl**** 66 stopper!

You don't see much impact of the effective slope inclination as the slope is too short. The trains have so much energy, that it pushes them uphill. You can see in the convoy windows, that no train would reach the top of the hill without inrun (max. speed is 0..120km/h, 0 with current load, 120, if empty).

If you start the trains at the bottom of the slope, you can see different behaviours until too many hoppers reach the slopes and the trains creep with the playability owed 4 km/h.

{ I have merged your double post. As a reminder, when you are the last one to post in a thread, and you want to add more, and it has been less than 24 hours since you posted: Please modify your existing post instead of making a new post. Thanks! -Isaac }
6
Simutrans-Extended development / Re: [8.2] Going uphill seems a bit unrealistic.
Why are locos too strong going uphill?

In simutrans there is only 1 slope inclination. This inclination is 2.8% (calculated from the standard simutrans slope "friction" penalty of 50). Usually the inclination should not exceed 2.0%.

Being realistic, early steamer loco driven trains could not climb up that 2.8% hills without ****istance by a second or third engine.
Thus for playability the friction impact has been reduced.

- If it is intended, that early locos don't use slopes, then we could increase the friction impact again.
- If there is a way to introduce a mix of half height and full height slopes, I'll support that.
8
Simutrans-Extended development / Re: Infinite loop
@neroden
Thanks Nathanael!
I changed strsim() to return an sint32 to eliminate the risky float comparison.
Could you please test once more before I reduce the extensive debug output.

@prissi
list_tpl.get() and list_tpl.operator [] check boundaries too, but I didn't use them in qsort().
And I didn't use vector_tpl, because I needed more feastures than it provided and i didn't want to modify it for safety/stability reasons.
Actually I started with it before I decided to write another template. List_tpl is built for pointers to (polymorphic) objects.
9
Simutrans-Extended development / Re: Infinite loop
Unfortunatelly I still cannot reproduce the bug. I added some debug output, which should help to find the error.
Would you please merge from my master and execute SE with -log -debug 4 and post the qsort relevant lines of the resulting log?
Thank you.
10
Simutrans-Extended development / Re: Infinite loop
Do you have saved games from all of them?  [...] EDIT: It could also relate to having saved games for a deleted pak?
I took these names from the Load dialog. Not all names refer to an installed package.

In the call stack there is an invalid reference to item1 (0x69) at level #2. Thus the seg fault is not originated in gui_file_table_pak_column_t::get_text(), but in or prior to list_tpl<gui_table_row_t>::qsort(). I guess it is in list_tpl<gui_table_row_t>::qsort(), which would fit best to the infinite loop as well.

I wish I had your savegames...

You've got 17 savegames. How many "Mental" and how many "Mental-3" savegames?

For a reproduction, it would be helpful to now the order in which they are loaded. Could you please compile a Simutrans Experimental without sorting (remove the call to sort_rows() at gui/savegame_frame.cc:191). If it still crashes, qsort() is absolved, otherwise please post the resulting dialog. Thank you.
11
Simutrans-Extended development / Re: Infinite loop
Very strange. If've got paks "pak", "pak128", "pak.german", "Pak128.Britain-Ex", "Pak128-Britain-Ex0_4", "pak128-nightly", and some more, but no problems.

I'll check with less than 3 paks...

But it works. Both Visual C++ and gcc version...

Could you please post a backtrace.
12
Simutrans-Extended development / Re: Refining obsolescence - feedback requested
In real life vehicles are used about 30 to 50 years. This time starts with actually using them. Thus I'd recommend starting a period of increasing maintenance costs after a time since built/bought or amount of kilometers (whatever ends first) of constant maintenance.

These thresholds should be vehicle dependent with a default value in simuconf.tab of 30 years and a kilometrage of say 10,000 hours * max speed (Horse: 25 km/h * 10,000 h -> 250.000 km* :o, Concorde: 2,100 * 10,000 -> 21,000,000 km).

The raise of maintenance should be nonlinear, say 1% per year, which results in 33% after 29 years, 50% after 41 years, 100% after 70 years, and 170% after 100 years (2% p.a.: 32% after 14 years, 51% after 21 years, 100% after 35 years, and 625% after 100 years or 3% p.a.: 34% after 10 years, 51% after 14 years, 100% after 24 years, and 1800% after 100 years).

*) within 30 years this means 23 kilometers per day (with free Sunday 27 km/d ;)). About 1 hour running max speed per day only. ... and with a lot of care a horse can grow very old (evidence: see attached "Very old horse").
15
Simutrans-Extended development / Re: Build-on-Linux patches.
Oops. Sorry. I solved conflicts with James' devel branch by using my local gui_table.h...
Meanwhile I extracted list_tpl to tpl/list_tpl.h and I was wondering why James brought it back in gui_table.h.
I'll incorporate your changes manually again ...
16
Simutrans-Extended development / Re: Reliable crash due to simutrans-experimental.xml
The crash with simutrans-experimental.xml in Version 7.2 is caused by the last but one umgebung_t setting. It remembers the "hilly" setting.
Creating the demo map fails, if it is "true". Set it to false and program starts again.
This does no harm in my master branch although I didn't fix anything, so it should be fixed in next Simutrans-Experimental Version.
17
Simutrans-Extended closed bug reports / Re: ...and a segfault.
This is not fixed.
I only changed copy_convoi() to remove the Trouble in the convoy copy code
You will fix it along with the reworked copy_convoi(), which then will buy the whole convoy or nothing.

BTW: a challenging task, as you must keep track of the already planned to use vehicles in depot. Current code does not ease this task.
You probably will add a method for getting the number of available suitable vehicles before actually getting them. Or the depot offers an "order sheet" (a list of all available vehicle types and quantity), on which you can remember, how many vehicles of which kind you reserved while checking affordability.
20
Simutrans-Extended closed bug reports / Re: And another crash bug....
Yes. is_replacing was only checked in the exp version >= 8 section :(
The exp version < 8 section could not work at all: writing was excluded completely, while reading was completely active.
Thus the codes were incompatible. At least replacing_vehicles_count = 0 had to be written to keep it compatible.
22
Simutrans-Extended closed bug reports / Re: ...and a segfault.
Reviewing the code I found that this error might happen, if the convoy exceeds you credit limit.
Then the new convoy has no vehicle, but needs at least one to create the new schedule.
Without a schedule get_aktuell() will produce the SegFault.

Did you get the "poor man's dialog" about the exceeded credit limit?
27
Simutrans-Extended closed bug reports / Re: And another crash bug....
The new Simutrans Experimental 7.2 should read all savegames save with the official Experimental 7.1 and older versions.
Unfortunatelly it is not compatible with nightly 7.2 builds dated before 15th of March due to a version clash with standard simutrans.

If your savegames are Exp 7.1 or earlier, please upload/post one or two.
28
Simutrans-Extended development / Re: Weight/Road Capacity Issues
@Bersken

Now that we can load your savegame at last, it shows, that Thorncroft Wagons for piece goods are too weak for their load.
That's why they creep at 4 km/h. 11.5 tons is too heavy to start. It can move at most 10.623 tons.
The constructors should enhance them with a gear of about 1.2.


(Zoom image)
31
Simutrans-Extended development / Re: Weight/Road Capacity Issues
I'd suggest to enhance the message "can't find a route." in cases there actually *is* a route, but constraints avoid using it.
The message then could be:
"can't find a route for vehicles above 8 tons total weight." or
"can't find a route for vehicles requiring overhead power." ...
32
Simutrans-Extended development / Re: Development update [7.2]
The convoy ****embler could show the weight per tile. All needed infos are already in there.

BTW: I was following the axle weight discussion superficially. I think axle weight is a too fine specification for simutrans, and will required a new parameter for *all* vehicles and: how many axles has a horse ;) ?

Weight per tile might be a good compromise and does not need new a vehicle parameter.
33
Simutrans-Extended development / Re: Development update [7.2]
The issue with boats moving at minimum speed when loaded and so on? This was an issue that appeared with the new physics.

Yes, ships and other convoys (e.g. some busses in pak128) will be back to normal movement.
Additionally the "maximum speed at given weight" preview in depot frame becomes more precise.
It warns you, if your ****embled convoy might become unable to move and shows the maximum weight, which can be moved and at which speed.
34
Simutrans-Extended closed bug reports / Re: Large map with 193 convoys "freezes" at month start
Where can I get this error?

I've downloaded the savegame again and Simutrans Experimental 7.1 (19.DEC.2009) and my current 7.2 branch still start without errors with pak128.Britain (29.JUL.2009) and pak128.Britain.Exp (08.Nov.2009).

James,
did you try to download the savegam again? It might got broken during download.
did you use the "official" Release 7.1 and an "official" pak128.Britain or pak128.Britain.Exp?
35
Simutrans-Extended closed bug reports / Re: Large map with 193 convoys "freezes" at month start
While freezed simutrans spends a lot of time calculating new season and snow line dependend images.
15,416,848 tile images have to be re-calculated!

Some questions:

Which kind of processor works in your computer and at which speed?

Which executable do you use? Self-compiled or official one?
A debug version is extremly slower compared to an optimized release version.

At which window size do you play?
A smaller window or less frames per second reduce the redraw effort.