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 - sdog

6
Randomness Lounge / rail in north america
i'm moving my off-topic from the pak128.USA thread  here. as i don't want to bloat it too much.

here's my ot posting:
Quote
ot: those engines fascinated me quite a lot since i arrived here. very primitive, but apparently still economically enough. I live 1km away from the tracks in downtown toronto and i can hear the engines, that's the actual motors!

I only had the luck to see one of the trains rolling once so far. in fact 3 trains where running partially parallel. one extremely long, from the second i saw only the end, but the third one -- behind the second -- i saw entirely. I lost count, but the length was between 40 and 50 cars, with double stacked containers. Obviously no tunnels or catenary in eastern canada! The first train could have been even longer, i couldn't see beginning or end.

Quite fascinating was also to watch, and more importantly listen, to it stopping and starting again at a signal. I was surprised how much the space between wagons changes.

[...]

ps.: i went on a trip to montreal, in summer. just 600 km, but definitely too far to use a car. it took me 7h with the bus. a pitty there's no usable p****enger rail network available.

Lmallet's reply:
Quote
I lost count, but the length was between 40 and 50 cars, with double stacked containers. Obviously no tunnels or catenary in eastern canada!
There are a few tunnels in eastern Canada, and I know at least one in northern New Brunswick which was modified 20 years ago to allow for double stacks.  The 2nd St. Clair tunnel between the US and Canada (Sarnia, Ontario) was built with double-stacks in mind.  http://www.tunnels.mottmac.com/projects/?id=3352&mode=type.  There is catenary in Montreal, but no freight trains use that line.

Quote from: sdog on Today at 02:26:00
ps.: i went on a trip to montreal, in summer. just 600 km, but definitely too far to use a car. it took me 7h with the bus. a pitty there's no usable p****enger rail network available.
VIA Rail is actually not that bad on the Quebec-Windsor corridor, Toronto-Montreal is usually a 5h trip, and there are plenty of trains.  I find it more confortable than the bus, and often less of a h****le than flying.  Toronto-Vancouver is another story, I don't think I could stay on a train for 5 days.

my reply
oh, by useable i actually meant the cost, the cheapest VIA return trip did cost more than i paid for the whole week in montreal. Or 9 times the bus fare. 1.5 to 2 times the price would have been acceptable to me for the better comfort and speed.

i think VIA seems to market mostly to seniors who don't care for money but like comfort or nostalgia.

5 h should easily beat flying: check-in, security, boarding, being there really early (and toronto's airport being quite difficult to reach) i wonder why they don't try to appeal to business p****engers. (train has more comfort, more space for working, and you just have to get to the train station a few minutes before departure.

i've just googled images on google with the option to show only images with faces:
Code: [Select]
site:www.bahn.de
and
Code: [Select]
site:www.viarail.ca

roughly half of the bahn faces should show helpfull employes. the rest mostly customers. divided in roughly 1/3 children, 1/3 casual/recreational travelers and about 1/3 with business clothing.

on VIA's site google found only about 20 face pictures, one has a suit, and is VIA's president.
boarding
without the face filter, bahn shows mostly maps,
7
Other paksets / Re: pak128.USA
ot: those engines fascinated me quite a lot since i arrived here. very primitive, but apparently still economically enough. I live 1km away from the tracks in downtown toronto and i can hear the engines, that's the actual motors!

I only had the luck to see one of the trains rolling once so far. in fact 3 trains where running partially parallel. one extremely long, from the second i saw only the end, but the third one -- behind the second -- i saw entirely. I lost count, but the length was between 40 and 50 cars, with double stacked containers. Obviously no tunnels or catenary in eastern canada! The first train could have been even longer, i couldn't see beginning or end.

Quite fascinating was also to watch, and more importantly listen, to it stopping and starting again at a signal. I was surprised how much the space between wagons changes.


back on topic:
those extra long trains are rather unwieldy in simutrans. Platform lenghts of 20 or even 30 would be required.


ps.: i went on a trip to montreal, in summer. just 600 km, but definitely too far to use a car. it took me 7h with the bus. a pitty there's no usable p****enger rail network available.
10
Simutrans-Extended development / Re: [8.2] Going uphill seems a bit unrealistic.
that's a clear disadvantage of the 2d game engine, we only have discrete inclinations.

i think however the system works quite well at the moment. just ad a few signals or bends to your mountainous setup. as soon as a train has to break and move again you really notice the slopes.

if you want you can see the 4 km/h 'playability' speed as a complexity reduction for adding a banking engine and pulling the train over the slope.

is there a reason to keep the total height difference limitation (-9 to 14) with the greatly enlarged maps we use nowadays?

by the way i exploited your physics engine in suburban train setups in the steam age, by building my stations on viaducts. saving the kinetic energy as potential energy to have them start faster.
13
Simutrans-Extended closed bug reports / Re: [crash devel] crash when starting/loading demo.sve
Quote
If, however, you have saved a game then try to re-load it using exactly the same binary and it fails, then there is a problem that needs to be addressed. Could you confirm whether or not that is the case? Thank you for your report.
it worked of course, i would have reported it as a bug if it hadn't.

james, it's not necessary to make yourself the work of always explaining trivial reasons for crashes. just ignore the unimportant part. else i always get the feeling to bother you when i report trivial bugs/crashes. not reporting them however would not a good approach either, since i would else apply judgement.
14
Simutrans-Extended closed bug reports / Re: [crash devel] crash when starting/loading demo.sve
With james latest devel version the crash when creating a new demo map does not occur anymore. I haven't seen that your fix was included already inkelyad, so it must have been something else.


The games still crashes at startup when loading demo.sve
Code: [Select]
Program received signal SIGABRT, Aborted.
0x00007ffff6c1ea75 in raise () from /lib/libc.so.6
(gdb) bt
#0  0x00007ffff6c1ea75 in raise () from /lib/libc.so.6
#1  0x00007ffff6c225c0 in abort () from /lib/libc.so.6
#2  0x000000000063f26e in log_t::fatal (this=0xa7b390, 
    who=0x67807b "loadsave_t::rdwr_str()", 
    format=0x678178 "string longer (%i) than allowed size (%i)")
    at utils/log.cc:242
#3  0x00000000004670f4 in loadsave_t::rdwr_str (this=0x7fffffffbbb0, 
    s=0x7fffffffb1f0 "~", size=2) at dataobj/loadsave.cc:731
#4  0x00000000004869d0 in leitung_t::rdwr (this=0x3f6e3b0, file=0x7fffffffbbb0)
    at dings/leitung2.cc:447
#5  0x0000000000486b8f in pumpe_t (this=0x3f6e3b0, welt=0x11f8830, 
    file=0x7fffffffbbb0) at dings/leitung2.cc:476
#6  0x00000000004567e2 in dingliste_t::rdwr (this=0x4626d90, welt=0x11f8830, 
    file=0x7fffffffbbb0, current_pos=...) at dataobj/dingliste.cc:762
#7  0x00000000004462a6 in grund_t::rdwr (this=0x4626d88, file=0x7fffffffbbb0)
    at boden/grund.cc:367
#8  0x00000000005f665d in boden_t (this=0x4626d88, welt=0x11f8830, 
    file=0x7fffffffbbb0, pos=...) at boden/boden.h:27
#9  0x00000000005f4f4f in planquadrat_t::rdwr (this=0x43a1288, welt=0x11f8830, 
    file=0x7fffffffbbb0, pos=...) at simplan.cc:249
#10 0x000000000062e294 in karte_t::laden (this=0x11f8830, file=0x7fffffffbbb0)
---Type <return> to continue, or q <return> to quit---
    at simworld.cc:4550
#11 0x000000000062d296 in karte_t::laden (this=0x11f8830, 
    filename=0x2524368 "/home/gschenk/simuexp/pak128.britain-ex/demo.sve")
    at simworld.cc:4347
#12 0x00000000005e79e2 in simu_main (argc=1, argv=0x7fffffffe2d8)
    at simmain.cc:867
#13 0x000000000066dbb2 in main (argc=1, argv=0x7fffffffe2d8) at simsys_s.cc:749

when loading my own savegame, saved directly before this latest version i get this crash:
Code: [Select]
FATAL ERROR: planquadrat_t::rdwr()
Error while loading game: Unknown ground type '0'


Program received signal SIGABRT, Aborted.
0x00007ffff6c1ea75 in raise () from /lib/libc.so.6
(gdb) bt
#0  0x00007ffff6c1ea75 in raise () from /lib/libc.so.6
#1  0x00007ffff6c225c0 in abort () from /lib/libc.so.6
#2  0x000000000063f26e in log_t::fatal (this=0xa7b390, 
    who=0x69b2a3 "planquadrat_t::rdwr()", 
    format=0x69b270 "Error while loading game: Unknown ground type '%d'")
    at utils/log.cc:242
#3  0x00000000005f5123 in planquadrat_t::rdwr (this=0x7fffecd70018, 
    welt=0x14f4d50, file=0x7fffffffb1e0, pos=...) at simplan.cc:257
#4  0x000000000062e294 in karte_t::laden (this=0x14f4d50, file=0x7fffffffb1e0)
    at simworld.cc:4550
#5  0x000000000062d296 in karte_t::laden (this=0x14f4d50, 
    filename=0x4b3b6d8 "\221\001\375\001") at simworld.cc:4347
#6  0x000000000051c655 in loadsave_frame_t::action (this=0x4b71ba0, 
    filename=0x4b3b6d8 "\221\001\375\001") at gui/loadsave_frame.cc:51
#7  0x000000000053e480 in savegame_frame_t::action_triggered (this=0x4b71ba0, 
    komp=0x4b721a8, p=...) at gui/savegame_frame.cc:399
#8  0x00000000004ac99b in gui_action_creator_t::call_listeners (
    this=0x4b721a8, v=...) at gui/components/gui_action_creator.h:36
#9  0x00000000004c847e in gui_table_t::infowin_event (this=0x4b72190, 
    ev=0x7fffffffb840) at gui/components/gui_table.cc:146
#10 0x00000000004c4ef0 in gui_scrollpane_t::infowin_event (this=0x4b72390, 
    ev=0x7fffffffb8a0) at gui/components/gui_scrollpane.cc:102
#11 0x0000000000500c73 in gui_container_t::infowin_event (this=0x4b71ba8, 
    ev=0x7fffffffb980) at gui/gui_container.cc:171
#12 0x0000000000502773 in gui_frame_t::infowin_event (this=0x4b71ba0, 
    ev=0x7fffffffba30) at gui/gui_frame.cc:88
#13 0x000000000053f13f in savegame_frame_t::infowin_event (this=0x4b71ba0, 
    ev=0x7fffffffba30) at gui/savegame_frame.cc:545
#14 0x0000000000617fe3 in check_pos_win (ev=0x7fffffffbb60) at simwin.cc:984
#15 0x0000000000632f80 in karte_t::interactive (this=0x14f4d50, 
    quit_month=2147483647) at simworld.cc:5680
#16 0x00000000005e8684 in simu_main (argc=1, argv=0x7fffffffe2d8)
    at simmain.cc:1067
#17 0x000000000066dbb2 in main (argc=1, argv=0x7fffffffe2d8) at simsys_s.cc:749
This error is an old aquaintance. The savegame was saved with experimental version set to 9.0. Loading and saving worked without any apparent flaws before. I tested with the latest master branch of pak128.britain-experimental.
17
Simutrans-Extended closed bug reports / [crash devel] crash when starting/loading demo.sve
the latest devel version 2010-07-24 crashes when loading demo.sve of pak128.britain.

Code: [Select]
FATAL ERROR: loadsave_t::rdwr_str()
string longer (511) than allowed size (2)


Program received signal SIGABRT, Aborted.
0x00007ffff6c1ea75 in raise () from /lib/libc.so.6
(gdb) bt
#0  0x00007ffff6c1ea75 in raise () from /lib/libc.so.6
#1  0x00007ffff6c225c0 in abort () from /lib/libc.so.6
#2  0x000000000063febe in log_t::fatal (this=0xa7d390, 
    who=0x678ddb "loadsave_t::rdwr_str()", 
    format=0x678ed8 "string longer (%i) than allowed size (%i)")
    at utils/log.cc:242
#3  0x0000000000467648 in loadsave_t::rdwr_str (this=0x7fffffffbbb0, 
    s=0x7fffffffb1f0 "~", size=2) at dataobj/loadsave.cc:732
#4  0x000000000048704e in leitung_t::rdwr (this=0x7fffea880730, 
    file=0x7fffffffbbb0) at dings/leitung2.cc:447
#5  0x000000000048720d in pumpe_t (this=0x7fffea880730, welt=0x7fffea58d480, 
    file=0x7fffffffbbb0) at dings/leitung2.cc:476
#6  0x0000000000456893 in dingliste_t::rdwr (this=0x7fffea873490, 
    welt=0x7fffea58d480, file=0x7fffffffbbb0, current_pos=...)
    at dataobj/dingliste.cc:762
#7  0x0000000000446318 in grund_t::rdwr (this=0x7fffea873488, 
    file=0x7fffffffbbb0) at boden/grund.cc:367
#8  0x00000000005f7279 in boden_t (this=0x7fffea873488, welt=0x7fffea58d480, 
    file=0x7fffffffbbb0, pos=...) at boden/boden.h:27
#9  0x00000000005f5b6b in planquadrat_t::rdwr (this=0x7fffea5d9f18, 
    welt=0x7fffea58d480, file=0x7fffffffbbb0, pos=...) at simplan.cc:249
#10 0x000000000062ee0e in karte_t::laden (this=0x7fffea58d480, 
    file=0x7fffffffbbb0) at simworld.cc:4549
#11 0x000000000062de04 in karte_t::laden (this=0x7fffea58d480, 
    filename=0x7fffe8882ad8 "/home/gschenk/simuexp/pak128.britain-ex/demo.sve")
    at simworld.cc:4346
#12 0x00000000005e8592 in simu_main (argc=1, argv=0x7fffffffe2d8)
    at simmain.cc:867
#13 0x000000000066e916 in main (argc=1, argv=0x7fffffffe2d8) at simsys_s.cc:749

without demo.sve it still crashes: <== resolved
Code: [Select]
Program received signal SIGSEGV, Segmentation fault.
0x000000000042d29c in karte_t::ist_in_gittergrenzen (this=0x0, x=1, y=1)
    at bauer/../simworld.h:813
813			return (x|y|(cached_groesse_gitter_x-x)|(cached_groesse_gitter_y-y))>=0;
(gdb) bt
#0  0x000000000042d29c in karte_t::ist_in_gittergrenzen (this=0x0, x=1, y=1)
    at bauer/../simworld.h:813
#1  0x000000000042d374 in karte_t::lookup_hgt (this=0x0, k=...)
    at bauer/../simworld.h:1057
#2  0x000000000059fb76 in stadt_t::random_place (wl=0x42662f0, 
    sizes_list=0x4134ad0, old_x=0, old_y=0) at simcity.cc:4295
#3  0x000000000061d3d9 in karte_t::distribute_groundobjs_cities (
    this=0x42662f0, sets=0x42636b0, old_x=0, old_y=0) at simworld.cc:857
#4  0x0000000000620ee6 in karte_t::enlarge_map (this=0x42662f0, 
    sets=0x42636b0, h_field=0x0) at simworld.cc:1558
#5  0x000000000061f5b9 in karte_t::init (this=0x42662f0, sets=0x7fffffffc730, 
    h_field=0x0) at simworld.cc:1270
#6  0x00000000005e8724 in simu_main (argc=1, argv=0x7fffffffe2d8)
    at simmain.cc:888
#7  0x000000000066e916 in main (argc=1, argv=0x7fffffffe2d8) at simsys_s.cc:749

tested on linux 64 with gcc 4.4.3


there were several changes in loadsave calls in the merge from standard. e.g.:
Code: [Select]
-senke_t::senke_t(karte_t *welt, loadsave_t *file) : leitung_t(welt , file)
 	577	
+senke_t::senke_t(karte_t *welt, loadsave_t *file) : leitung_t( welt, koord3d::invalid, NULL )
maybe they're to blame for the first crash?
20
Pak128.Britain-Ex closed bug reports / Re: Tram track max weight bug.
tram catenary can't be built on rail tracks. In the screenshot i built tram tracks first then tram catenary and replaced it with standard track later.

by the way, did british trams use standard gauge or metre gauge?

i don't know where the photo is from, except devon, just a random google hit to illustrate what i meant. i'm afraid the only i know about devon is the geological age named after it. on a second glance, it's not good for this purpose. it is a grade crossing, there's a sign at the left and it's in a rural area not a city. (theres a grating to prevent animals to get on the tracks)

24
Simutrans-Extended closed bug reports / Re: [crash devel] elevated tracks with stations, crash on weight check
ciao james,

last time i checked the savegame could be loaded without stepping up the number. Some of the new features won't work however, which shouldn't change a lot for the crash. Besides stepping up the version in simversin.h and compiling it takes roughly a minute. let git restore the old version of the file afterwards.

sdog

ps.: just thought about the old version number again: the train causing the crash is reversing on his schedule. perhaps starting without the reverse schedule patches active could mean it doesn't find it's way to the 'crash-site'. (you should perhaps think about stepping up the version numbers in dev versions anyway. else you will always hide possible bugs from testing. only to be found when you step up the number for release.)
25
Simutrans-Extended closed bug reports / Re: [crash devel] elevated tracks with stations, crash on weight check
here's a savegame where the crash is 'primed'.
Train 841 an EMU is stuck before a newly built tunnel, if you delete it (or fix the third rail) a following steam train drives into the tunnel and crashes the game.

http://dl.dropbox.com/u/1876190/71.sve

Code: [Select]
Program received signal SIGSEGV, Segmentation fault.
0x000000000044c008 in weg_t::get_max_weight (this=0x0)
    at boden/../boden/wege/weg.h:193
193		uint32 get_max_weight() const { return max_weight; }
(gdb) bt
#0  0x000000000044c008 in weg_t::get_max_weight (this=0x0)
    at boden/../boden/wege/weg.h:193
#1  0x000000000064e564 in waggon_t::ist_befahrbar (this=0xa034e10, 
    bd=0x69adec8) at vehicle/simvehikel.cc:2933
#2  0x0000000000646a11 in vehikel_t::hop_check (this=0xa034e10)
    at vehicle/simvehikel.cc:1157
#3  0x0000000000643aef in vehikel_basis_t::fahre_basis (this=0xa034e10, 
    distance=128424) at vehicle/simvehikel.cc:303
#4  0x00000000005a83d6 in convoi_t::sync_step (this=0xa033f10, delta_t=100)
    at simconvoi.cc:660
#5  0x0000000000623eff in karte_t::sync_step (this=0x1213320, delta_t=100, 
    sync=true, display=false) at simworld.cc:2765
#6  0x0000000000630c42 in karte_t::interactive (this=0x1213320, 
    quit_month=2147483647) at simworld.cc:5776
#7  0x00000000005e5fd7 in simu_main (argc=1, argv=0x7fffffffe2d8)
    at simmain.cc:1076
#8  0x000000000066ae76 in main (argc=1, argv=0x7fffffffe2d8) at simsys_s.cc:749

the savegame requires latest development version of pak128 britain experimental and devel branch of experimental. simversion.h version numbers were stepped up to 9. But this should probably not interfere with your testing.
27
Simutrans-Extended closed bug reports / Re: [crash devel] elevated tracks with stations, crash on weight check
Quote
FIX: Speculative fix for reported crash that I cannot reproduce.

i'll test it momentarily

crashed, already when running over a normal viaduct
Code: [Select]
Program received signal SIGSEGV, Segmentation fault.
0x000000000044c008 in weg_t::get_max_weight (this=0x0)
    at boden/../boden/wege/weg.h:193
193		uint32 get_max_weight() const { return max_weight; }
(gdb) bt
#0  0x000000000044c008 in weg_t::get_max_weight (this=0x0)
    at boden/../boden/wege/weg.h:193
#1  0x000000000064e564 in waggon_t::ist_befahrbar (this=0x9754a70, 
    bd=0x569a088) at vehicle/simvehikel.cc:2933
#2  0x0000000000646a11 in vehikel_t::hop_check (this=0x9754a70)
    at vehicle/simvehikel.cc:1157
#3  0x0000000000643aef in vehikel_basis_t::fahre_basis (this=0x9754a70, 
    distance=106951) at vehicle/simvehikel.cc:303
#4  0x00000000005a83d6 in convoi_t::sync_step (this=0x9754430, delta_t=100)
    at simconvoi.cc:660
#5  0x0000000000623eff in karte_t::sync_step (this=0x137a060, delta_t=100, 
    sync=true, display=false) at simworld.cc:2765
#6  0x0000000000630c42 in karte_t::interactive (this=0x137a060, 
    quit_month=2147483647) at simworld.cc:5776
#7  0x00000000005e5fd7 in simu_main (argc=1, argv=0x7fffffffe2d8)
    at simmain.cc:1076
#8  0x000000000066ae76 in main (argc=1, argv=0x7fffffffe2d8) at simsys_s.cc:749

I've overlooked something important before, which also explains why the bug does not happen after saving the game.

To cause the crash, the elevated track must be built after the train has calculated it's route already.
Recipe to cause the crash:
- build a lenght of track with two stations,
- let a train run between them.
- while the train leaves one of the stations pause the game
   the timing is critical here, i think the change has to be built during the trains route finding.
   a good time seems to pause is just after the train is reversed.
- remove a few pieces of track
- build the elevated way and connect it with bridge parts
- wait for the train to come.

There are some other conditions i couldn't quite understand, since this recipe does not produce the crash for some cases. It worked for 75 km/h 61 t wooden sleeper track, 3 tiles elevated way of 80t type, and 136 t brick railway viaduct. Runing a M7 steam loc with one carriage. It did never crash when i tested with a 100t diesel engine on heavy weight modern tracks/viaducts. Perhaps certain weight ratios must be given.

Some more trying, i couldn't get it to crash whatever i did, with the above setup. But on other occasions it crashed whener i did something.
It is sometimes visible that the train changes it's position (tank engines get turned around!) when it notices that the track has changed. In that case nothing happens. But sometimes it gets overlooked, the train just goes on the viaduct and the program crashes.

when pausing and changing the track right after the train reversed in a station, causes the crash also with heavy tracks and any engine.
29
Simutrans Help Center / Re: Where'd the trees go?
Quote
... when i expand the map after i start playing ...

The expanded part of the map is just bleak terrain, without trees, rivers or cities. I don't know if there are any plans to add this feature in the future. Right now you can work around it by either starting the game with a much larger map, or by expanding and adding things manually as public player.

Since your initial posting is a bit ambiguous  the question now is: Does expanding the map remove the trees from the whole map, the parts you had already before expanding it?
30
Simutrans-Extended closed bug reports / [crash devel] elevated tracks with stations, crash on weight check
the crash can be reproduced by building elevated rails (pak britain viaducts), putting a station on them, as soon as a train calls to the station the crash happens. Pure elevated rails without stop/station does not cause the crash in several tests. Saving before a train arrives also prevents the crash.


Code: [Select]
Program received signal SIGSEGV, Segmentation fault.
0x000000000044bdc4 in weg_t::get_max_weight (this=0x0)
    at boden/../boden/wege/weg.h:193
193		uint32 get_max_weight() const { return max_weight; }
(gdb) bt
#0  0x000000000044bdc4 in weg_t::get_max_weight (this=0x0)
    at boden/../boden/wege/weg.h:193
#1  0x000000000064cd4f in waggon_t::ist_befahrbar (this=0x9582f30, 
    bd=0x57dd128) at vehicle/simvehikel.cc:2927
#2  0x00000000006452e9 in vehikel_t::hop_check (this=0x9582f30)
    at vehicle/simvehikel.cc:1157
#3  0x00000000006423c7 in vehikel_basis_t::fahre_basis (this=0x9582f30, 
    distance=92082) at vehicle/simvehikel.cc:303
#4  0x00000000005a746e in convoi_t::sync_step (this=0x95828b0, delta_t=100)
    at simconvoi.cc:660
#5  0x0000000000622a69 in karte_t::sync_step (this=0x11fd240, delta_t=100, 
    sync=true, display=false) at simworld.cc:2766
#6  0x000000000062f51c in karte_t::interactive (this=0x11fd240, 
    quit_month=2147483647) at simworld.cc:5764
#7  0x00000000005e509b in simu_main (argc=1, argv=0x7fffffffe2d8)
    at simmain.cc:1076
#8  0x0000000000669392 in main (argc=1, argv=0x7fffffffe2d8) at simsys_s.cc:749

i thought i reported it earlier, but couldn't find the thread anymore.
31
Pak128.Britain-Ex closed bug reports / Re: several minor issues (not really bugs)
My savegames need the version to be set to 9.0 in simversion.h, so i was partially waiting for 9.0 to be released, and partially for cold weather to fix things up and write a summary. I have the whole timeline of savegames, about 60 right now, and will either realease all, or some at milestones.

Before the Bulldogs i've been using LNWR Jumbos with MR 6 wheel carriages. And Jones Goods on some local trains. Before Jumbos, i used LBSCR Gladstones. I extensively used LBSCR Terriers on all local routes, they are dirt cheap. I'm phasing them out in 1900 and replace them with M7s. The main branch is 450 km long.

However i didn't connect it completely until Bulldogs were available. Jumbos caused extreme fluctuation with huge losses due to refunds. So i built the last 150 km only after the new engines arrived.

I know you're planing to re-balance the steam engines, so i want to give you some game economics feedback before. It is rather stable at the moment, i think it needs tweaking only.
32
Pak128.Britain-Ex closed bug reports / Re: several minor issues (not really bugs)
James, sometimes i report issues also relevant or inherited from standard, since i tested it in experimental. I'm also aware that the pak set is work in progress, when i post something. It is just so far advanced that only some details reduce playability, and i want to spell them out.

The difficulty with those mail coaches, which are available, is their loading time, exceeding the p****enger coaches loading time by far. It doesn't matter for long distance, but intra-city i have to use commuter trains without mail coaches. (Metropolitan). They have load times of 3500. The full capacity mail coaches load at 6000+ however. Using those on urban rails causes m****ive bunching of the commuter trains.

At first i could work around this by using 4 MSLR 4 wheel break carriages pulled by a terrier , with a load time of 10. It can load only 4x10 bags however, by far not enough later on. I built third platforms on my bidirectional stations, but this isn't perfect either. Also unnecessarily complicated, in particular with the new reverse route functionality.

My suggestion would be introducing parcel box wagons based on the 8t box wagon first, and 12t box wagons later on. Slow speed, like their freight counterparts, but low load times, equal to the predominant commuter carriages.


In my current test game i can see a bit more about economic balance. I had a hardly profitable company with very strong fluctuations in income due to (suspected) p****anger travel time time-outs. But on the same tracks with introduction of GWR Clerestory sets and GWR Bulldog engines it turned immediately into a cash cow. Before 1905 0 to 400k Operating profit. 1907 2M profit.

I think a slight increase of 1890s carriages comfort should help. (Perhaps additional 1st cl**** carriages?) Perhaps GWR Bulldogs should also become a bit more expensive.

Midland Spinners are too weak to compete with old LBSCR Gladstones in 1896.

LSWR M7 are also too good, to use any other engine of her cl****.

Is the GWR Saint Cl**** supposed to be a step backwards from the GWR Bulldog? Heavier, more expensive, weaker, slower.

LBSCR in 1870 and LSWR Compartments in 1900 don't have fitting mail coaches; intended, todo, historical?
33
Simutrans Gaming Discussion / Re: GUI overhaul
I don't quite understand why 'transient window' is bad? It describes the behaviour very directly, regardless if it is a computer science word or not. It is self explanatory.

Or do you suggest to call it persistent and transient windows, to get rid of the 'non'?
34
Simutrans Gaming Discussion / Re: GUI overhaul
Isaac, look at the picture again, it's turned off, i think.

Quote from: skreyola
But some emacs fan will probably say they [the keyboard shortcuts] need to be different.
screw emacs users! They're just to dogmatic to learn vi, that's the standard anyone should immediately adopt.
35
Pak128 / Re: Metro - as tram or train?
They avoided the naming problem in hannover by calling it Stadtbahn (city rail).

Wien has a very typical Tram system i think, at least those in districts I to XVI. They're colloquially called Bim by the way.

I think it's still sensible to consider also longer sets with their own right of way as tram, this is rather common in europe and comming to north america. Toronto's Transit city plan will (perhaps) replace the american style Streetcars with modern Tram sets.

I'm a bit doubtful if it will actually be done, it seems like the city planers and politicians are very undecided about public transport here.