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

1
Extension Requests / Re: Landing plane behaviour
Quote from: Leartin – on
How about implementing an auto-choose-signal at every airport

There is one. But choose signals select a gate, not the path to get there. It might be that this "choose signal" is on the runway, which is too late for this.

Quote from: Leartin – on
There still is some unpredictability, but the player would at least have the tools to eradicat it completely

I think this is backwards with regards to the existing philosophy. It should be predictable by default, with unpredictability something you opt in to. (Not that that will keep players from shooting themselves in the leg.)

Not that I'm happy with how airports work. I hardly use them, in part because of chaotic landing patterns (I don't think planes are first-come first-serve), but also because I like trains and planes look silly flying so low (and planes are very speed bonus sensitive in pak64).
2
Technical Documentation / Re: Maximum of build_time parameter
The change didn't affect the file format. My self-compiled makeobj reports that it's version 55 for 112.1.1 and a population trigger of 150000 was written correctly into the pak file for a city attraction. If something still truncates this value, it's the game itself, but I can't see anything wrong with the loading code either.
 
EDIT:
Just loaded this modified pak into the game. The correct number is shown in the curiosity builder window.
4
Incorporated Patches and Solved Bug Reports / Re: Game crash and sheep causing giant jam
I have had troubles with urban sheep as well. I wish there was some AI game warden that automatically killed sheep when they enter a town. When my vehicles end up trapped behind a flock on a road outside a town, I would like some notification so I can go take them out myself. The latter will not help much for sheeps in towns, because they are a pain to bulldoze in there. I usually have to bulldoze a bunch of pedestrians and city cars before I get to the sheep, sometimes also taking out stops in the process.

Another problem with sheep is that they often spawn inside a forrest (not the industry type) and can't get out. They just walk back and forth on a single tile (or maybe two). A tree or two should not prevent a flock of sheep from entering a tile. Either change that, or prevent sheep from spawning on tiles they can't get out of.
5
Incorporated Patches and Solved Bug Reports / Re: r3802 - Farm overgrowing station
That particular track has been there for gameyears. The track to the lower left is recent, probably built during my last play session prior to this problem appearing. I don't remember seeing any fields when I built that third track/platform. In fact, I was wondering why the farm had no fields. It is as if the fields just popped into place when either saving or loading the game, but they might also have appeared before that when I was not watching. It is not a station I visit often. I am not sure what triggers field growth.
8
Incorporated Patches and Solved Bug Reports / r3802 - Farm overgrowing station
After upgrading simutrans through several weeks of revisions to revision 3802, and pak64 from r300 or something to r321, I have started getting crashes shortly after loading one of my savegames. I have since managed to track the problem down to a train trying to enter a station where one of the tracks have been overgrown by a crop-tile belonging to the old farm served by the station (and the train). Last time I checked, that farm had no crop tiles.

The crash itself is at vehicle/../boden/wege/weg.h:283, but I suspect the real bug is crops overgrowing stations. I have tried building older revisions of simutrans, and the problem is still there, but I have not been able to figure out which revision I was using before. I have not tried downgrading pak64, but nothing in the changelog looks like it could cause this. Any ideas?

I am using a self-compiled simutrans (using mingw), SDL, Windows 32-bit.
9
Extension Requests / Re: Names for Depots
I would also like named depots, and labels won't work for me.

Usually when replacing vehicles, especially buses and locomotives, I keep the old vehicles around in case I find use for them somewhere else later. (Seems more realistic that way.) I then use the vehicle list with "in a depot" filter to look for suitable vehicles. When I click on one of them, the depot window pops up, but I can not tell whether the depot is nearby or on the other side of the map. Clicking the next and then the previous button moves the view to the depot, but it's cumbersome.
10
Pak64 Bug Reports / Re: Can't build pak64
That took care of the warnings.

I have also found out what made my build failed. It's svn info | grep "Revision: ". The word "Revision" does not exist in the output of svn info, since it is localized.

A quick-fix for me was to localize the Makefile. Not sure what this text is used for, or whether localizing it will have any bad effects, but everything seems to be working.
12
Pak64 Bug Reports / Can't build pak64
When I upgraded my pak64 source files to r310, pak64 would no longer build. I get the following warnings:

Makefile:83: warning: overriding commands for target `ground'
Makefile:73: warning: ignoring old commands for target `ground'

Then it errors following:

OUTSIDE with REVISION and grounds

The trouble seems to have crept in at r301. r300 builds fine.
16
Incorporated Patches and Solved Bug Reports / Re: r3146: Error in routing
Strange. I haven't done any changes in Malliville lately. I did however do some minor adjustments in two far away town not too long ago. It consisted of extending a train line underground to an often overcrowded bus stop in Appingham, and a subsequent rearrangement of the lines in that town. Shortly after, I added some bus stops in Renden.

Other than that, I have only been freshening up some tunnels, upgrading some track and replacing some vehicles. If something at Malliville has moved recently, it moved by itself. Or is that what you were trying to say?
17
Incorporated Patches and Solved Bug Reports / Re: ****ertion failure when world is destroyed
I generally use whatever is the newest revision on trunk is SVN. Currently that is revision 3146. The problem goes back a few revision (a week), but before that I had a longer break from playing Simutrans so I can't say how far. I do not think the problem was there four months ago.

The ****ertion also fails if I try to load a new game when I already have a game opened.
18
Incorporated Patches and Solved Bug Reports / ****ertion failure on exit
I have started getting this ****ertion failure in the normal Simutrans. Not really a problem for me, as it only comes when I quit, but it might
indicate that something is wrong deep down in the code.

I use a self-compiled 64-bit Linux build.
19
Incorporated Patches and Solved Bug Reports / r3146: Error in routing
When I loaded one of my games, I noticed that one of my stations was crowded with p****engers going to Error in Routing via Error in Routing. Furthermore, the number was gradually increasing, apparently when some buses were arriving with p****engers, but I could find nothing wrong with the buses' p****engers. The problem might have been there for some time, but not too long. I generally compile a fresh executable and pakset before I play, if there have been changes.

I have put the savegame at http://simutrans-germany.com/files/upload/Ters%203.sve in case it needs to be studied. The station with the problem is called Malliville station and is located almost straight north-east (right) of the savegame's starting location.

Simutrans r3146
pak64 r269 (with food and waste enabled)
20
Incorporated Patches and Solved Bug Reports / Glowing tunnels
I have noticed that the roof of the new high speed tunnels (which otherwise looks great by the way) glows in the dark. Looks like the colour used is one of those that do not change as day turns into night. I believe this is not how it's supposed to be.
22
Incorporated Patches and Solved Bug Reports / Re: [r2972] Crash when building tunnel entrance
So it's one of those bugs...

I cranked up the debug level for tunnelbauer.cc from 1 to 2, so that it would be easier to debug. That drastically reduced my ability to reproduce the crash, but I am still able to trigger it by trying again and again until I succeed. According to gdb, the immediate cause of the crash is wrong data in zv. In the debugging session I have open now, it contains x = 3176 and y = 348, which obviously is bad for a 1024x1024 map. These values were fetched, already corrupted, from koord::from_hang[12]. They differ from crash to crash. Something seems to be writing where it should not, but what and why only to koord::from_hang[12]? I'll try to dig deeper.


According to gdb, freelist_t::putback_node is the culprit. For some reason list ends up pointing to koord::from_hang[12]. Comparing putback_node with gimme_node, I noticed the following difference that I think is to blame:

gimme_node:
Code: [Select]
size = max( min_size, size );
size = (size+3)>>2;
size <<= 2;

// hold return value
nodelist_node_t *tmp;
if(size>MAX_LIST_INDEX) {
	switch(size) {

putback_node:
Code: [Select]
size = max( min_size, size );
size = ((size+3)>>2);

if(size>MAX_LIST_INDEX) {
	switch(size) {

In gimme_node, size is shifted right then left, while in putback_node, it is just shifted right. But both compare it against the same constants afterwards. As far as I can tell, gimme_node does it right, while putback_node ends up going beyond the end of the all_lists array.
23
Incorporated Patches and Solved Bug Reports / Re: [r2972] Crash when building tunnel entrance
Have you tried it on a hill with exactly the same form as the one in the image I posted? It is very sensitive to terrain. It does not crash if I leave out the extra raised land on the northern side.

As for the second bug, I did not mean a vertical wall, but a slope. I have attached screenshots showing how to reproduce that one.
24
Incorporated Patches and Solved Bug Reports / [r2972] Crash when building tunnel entrance
When attempting to build an entrance for a tunnel with ctrl+click, I get the following crash:

Program received signal SIGSEGV, Segmentation fault.
tunnelbauer_t::baue (welt=0xaad6e0, sp=0xaae4f0, pos=<value optimized out>,
    besch=0x1040e90) at bauer/tunnelbauer.cc:269
269         if(welt->lookup(end)  ||  welt->lookup_kartenboden(pos+zv)->get_hoehe()<=end.z) {

The triggering factor seems to be the road I had already prepared where I later was going to build the tunnel exit one level lower. See attached screenshot for how to reproduce.

64-bit Linux, SDL, pak64 r244. Using modified simgraph16.cc, but I do not think that should affect this.


Since posting this, I have noticed other possibly related problems with tunnels. I tried to build a straight tunnel by just using the tunnel tool normally (without holding down ctrl), but it failed when I tried building it from south to north. It did not crash, but told me that no tunnel could be built there. When I clicked on the northern end, the tunnel was built as it should. The southern end did have an artificial slope.

Futhermore, when trying to reproduce this bug, the game crashed when I tried to remove the second tunnel built in the same place. I could reproduce this by building a tunnel, removing it, rebuilding it and then attempting to remove it again. bauer/tunnelbauer.cc line 541.
26
Pak64 / Re: Some balancing comments on pak64
The buses of the late 20th century is something that has bothered me too. They have much poorer acceleration, which makes them unsuited for use in cities, where they have to stop at halts and intersections every other tile. In addition, the BuessingLinie (untranslated name), the last "normal" bus, disappears in 1995. The jointed bus works reasonably well, but it does not feel right to use jointed buses in rural services.
27
Simutrans Gaming Discussion / Re: General Inquiry: Your Fun Element in ST
Building a complex network and watching the (hopefully) smooth flow of trains through the landscape to their correct platforms. And I like it when the maps are so big that the trains have to travel some distance through the countyside, although this causes latency in the network that is less fun to deal with.
29
Incorporated Patches and Solved Bug Reports / Re: [r2826] Tiny bug and other potential problems
Are all objects allocated using new routed through this memory management system? I don't see anything indicating that they are. This seems to be done on a cl**** by cl**** basis. Since most of the leaks are objects belonging to a cl**** without an overridden new operator, I do not think the leak reports are caused by the self made memory management system.

Even if many of the reported leaks are not that problematic, it is harder to spot the real problems when they are hidden among lesser issues. I have attached a patch that silences many leak reports. Hopefully they have no negative side effects.

I might use the remaining leak reports as a learning exercise in both Valgrind and the simutrans source code. Apart from the SDL related leak reports, Valgrind lists many leaks related to karte_t's plan array.
30
Incorporated Patches and Solved Bug Reports / [r2826] Tiny bug and other potential problems
Just out of curiosity I ran simutrans through Valgrind and discovered a tiny bug. The patch speaks for itself. It's not a very serious bug, but it's better to be safe than sorry. Hopefully the patch is correct.

I also got a lot of messages from Valgrind about invalid reads that made no sense to me. Some in factory_reader_t::register_obj, some related to calls to haltestelle_t::get_halt and the rest scattered about. Have anyone else encountered these?

Valgrind also reported a lot of memory leaks. Some indicate that SDL was not properly shut down or bugs in SDL, while others may indicate that an instance of karte_t is not properly disposed of. A search on this forum show that reported memory leaks apparently are a well known "problem", though.

I can post the full log if someone is interested.
31
Incorporated Patches and Solved Bug Reports / Filename case confusion
Not really a graphic error, but I post this here anyway.

When activating the factory_food and/or factory_waste directories in pak64, I get errors about missing files when I try to compile the pakset. The files are there, but their names are in lower case, while the .dat files use mixed case when referencing them. That won't work on many platforms.

I am not sure if these directories are even supposed to work, since they are not activated by default, but I have attached a patch which changes the names to lower case in the .dat files so that it compiles without errors. An alternative is to rename the files to mixed case, but I think lower case filenames are safest. I don't think I can make a patch for that anyway. Asdonkshof.png is in mixed caps in both the file system and the .dat file. Since it works as it is, I have let it be.
33
Incorporated Patches and Solved Bug Reports / [r2818] Changing schedule takes a long time
Recently, changing the schedule of some vehicle that is driving about or waiting at a stop has started taking a long time, probably close to half a minute. Even just telling the vehicle to skip a stop or turn back. It does not seem that the task of calculating a new route should be so time consuming, because vehicles have no problem re-routing to a depot in almost no time. And changing the schedule of a vehicle in a depot is as fast as ever. I have not done any changes in the network that should cause this on a global scale.

Linux, sdl, pak64 r225
34
Incorporated Patches and Solved Bug Reports / [r2818] Traffic prevents me from setting waypoints
When I try to place I waypoint on a tile containing citycars or pedestrians, I get a message telling my the tile is not owned by player. If I wait until the traffic has cleared, it is okay to put a waypoint there. Surely the presence of traffic should not affect the possibility of setting wayspoints. At least it did not until recently.

Linux, sdl, pak64 r225
35
Bug Reports / Re: [r2785] Crash with GCC 4.3
I don't remember any names, but I rembember learning that some architectures require that memory addresses are aligned to the size of the data type being used. That means that int16 pointers must be even, int32 pointers divisible by four, and so on. I have even read that non-aligned memory access is bad even on x86, because the processor will use two bus cycles to fetch the non-aligned data. Modern processors have however become so complex that I will not even try to predict if this will have a speed impact in this case. If your profiling indicates that the current code is the fastest for the targetted architecture(s), then it is.