Recent Posts

1

Game Servers / Re: The Simutrans-Extended server listing seems to be down

« Last post by jamespetts on Today at 09:57:59 AM »

Excellent - thank you!

2

Incorporated Patches and Solved Bug Reports / Re: Priority signals

« Last post by Leartin on Today at 07:47:49 AM »

The choose signal cannot combined with any other signal, since it would reserve anyway until the destination or the next choose signal.

I suppose thats in regard to creating a signal that is both. But what actually happens if the next signal after this 'prioritysignal' is a choose signal? Would the prioritysignal trigger the platform-search of the choose signal (given the scheduled platform is occupied), and if so, in case that's not done in an instant - would the train wait for the platform search to finish? Would the choose signal trigger again when the train reaches it, and if so, just to check the scheduled platform or would it start the whole platform search again?

3

Game Servers / Re: The Simutrans-Extended server listing seems to be down

« Last post by Vladki on Today at 06:33:03 AM »

Sooooo, I learned more about nameserver setup today at work! lol.

And http://list.extended.simutrans.org/ should be working again.

Should I start moving it to new server?

4

Incorporated Patches and Solved Bug Reports / Re: Priority signals

« Last post by prissi on Today at 04:19:34 AM »

Corected in r8597. That is hopefully all the cosmetics to have working three aspect greedy block signals ...

5

Bug Reports / Re: [120.4] Can not start with addons

« Last post by prissi on Today at 02:58:08 AM »

The sorting feature added vehicles more than once to the hashtable fixed in next nightly

6

Game Servers / Re: The Simutrans-Extended server listing seems to be down

« Last post by Isaac.Eiland-Hall on Today at 02:25:27 AM »

Sooooo, I learned more about nameserver setup today at work! lol.

And http://list.extended.simutrans.org/ should be working again.

7

Game Servers / Re: Bridgewater-Brunel no. 1 - Great Britain sized map (no. 2) - FATAL ERROR

« Last post by DrSuperGood on Today at 02:23:31 AM »

I do not think the save is corrupt, rather there is a fatal bug that manifests itself almost immediately after load. Someone will have to debug it...

Edit:
Stack trace below...

Code: [Select]

Exception thrown: read access violation.
this was nullptr.
> Simutrans-Extended Normal x64 Debug (SDL 2).exe!strasse_t::get_overtaking_mode() Line 57 C++
  Simutrans-Extended Normal x64 Debug (SDL 2).exe!road_vehicle_t::can_enter_tile(const grund_t * gr, int & restart_speed, unsigned char second_check_count) Line 3655 C++
  Simutrans-Extended Normal x64 Debug (SDL 2).exe!vehicle_t::hop_check() Line 1640 C++
  Simutrans-Extended Normal x64 Debug (SDL 2).exe!vehicle_base_t::do_drive(unsigned int distance) Line 372 C++
  Simutrans-Extended Normal x64 Debug (SDL 2).exe!convoi_t::sync_step(unsigned int delta_t) Line 1312 C++
  Simutrans-Extended Normal x64 Debug (SDL 2).exe!karte_t::sync_list_t::sync_step(unsigned int delta_t) Line 4661 C++
  Simutrans-Extended Normal x64 Debug (SDL 2).exe!karte_t::sync_step(unsigned int delta_t, bool do_sync_step, bool display) Line 4724 C++
  Simutrans-Extended Normal x64 Debug (SDL 2).exe!interrupt_check(const char * caller_info) Line 112 C++
  Simutrans-Extended Normal x64 Debug (SDL 2).exe!karte_t::step() Line 5488 C++
  Simutrans-Extended Normal x64 Debug (SDL 2).exe!karte_t::interactive(unsigned int quit_month) Line 10570 C++
  Simutrans-Extended Normal x64 Debug (SDL 2).exe!simu_main(int argc, char * * argv) Line 1384 C++
  Simutrans-Extended Normal x64 Debug (SDL 2).exe!sysmain(int argc, char * * argv) Line 826 C++
  Simutrans-Extended Normal x64 Debug (SDL 2).exe!WinMain(HINSTANCE__ * __formal, HINSTANCE__ * __formal, char * __formal, int __formal) Line 793 C++
  [External Code]

In road_vehicle_t::can_enter_tile the local variable current_str is null.

I am guessing this is a bug with the overtaking patch. It probably only manifested itself now because someone actually bothered to use one of the many overtaking or direction limited road mechanics other than the default.

Code: [Select]

// When overtaking_mode changes from inverted_mode to others, no cars blocking must work as the convoi is on traffic lane. Otherwise, no_cars_blocking cannot recognize vehicles on the traffic lane of the next tile.
//next_lane = -1 does NOT mean that the vehicle must go traffic lane on the next tile.
const strasse_t* current_str = (strasse_t*)(welt->lookup(get_pos())->get_weg(road_wt)); // THIS IS NULL
if(  current_str  &&  current_str->get_overtaking_mode()==inverted_mode  ) {
if(  str->get_overtaking_mode()<inverted_mode  ) {
next_lane = -1;
}
}

if(  current_str->get_overtaking_mode()<=oneway_mode  &&  str->get_overtaking_mode()>oneway_mode  ) {
next_lane = -1;
}
The error appears to be that the second conditional test is not testing that current_str is non null like the first conditional test is. It can pass the first conditional test if NULL but will crash with a null pointer dereference with the second test.

In case someone wants to blame a person for it (joking, this would be more for interest) the details of which vehicle is causing the crash are below.

Code: [Select]

x = 6102
y = 3237
owner_n = 3
name_and_id = "(5015) Clydesdale horse (single)"
Apparently this was one of my horses! I have not touched that area of the map for decades...

Also the tile it was on was not a road? Very strange.

I tested the following fix and it appears to prevent the crash. If this does not cause other bugs I do not know.

Code: [Select]

// When overtaking_mode changes from inverted_mode to others, no cars blocking must work as the convoi is on traffic lane. Otherwise, no_cars_blocking cannot recognize vehicles on the traffic lane of the next tile.
//next_lane = -1 does NOT mean that the vehicle must go traffic lane on the next tile.
const strasse_t* current_str = (strasse_t*)(welt->lookup(get_pos())->get_weg(road_wt));
if(  current_str  ) {
const overtaking_mode_t current_overtake_mode = current_str->get_overtaking_mode();
if(  current_overtake_mode==inverted_mode  ) {
if(  str->get_overtaking_mode()<inverted_mode  ) {
next_lane = -1;
}
}

if(  current_overtake_mode<=oneway_mode  &&  str->get_overtaking_mode()>oneway_mode  ) {
next_lane = -1;
}
}

8

Game Servers / Re: Bridgewater-Brunel no. 1 - Great Britain sized map (no. 2)

« Last post by SuperTimo on Yesterday at 11:51:49 PM »

I think I should be alright, I am almost back in credit, although I have an extra 30,000 in interest to pay each month now. I think the server save is corrupted again. I have tried loading it offline and it causes Simutrans to crash after loading finishes. I have a save from around 22:00 that works.

9

Simutrans Extended Development / Re: Schedule features: technical discussion

« Last post by Ves on Yesterday at 11:40:36 PM »

The end goal is that good should never have to rearrange.

Let me try to do an example:

Lines:
"Branch line X - B"
"Main line A - B - C - D"
"Branch line C - Y"

Consist orders:

"Branch line X - B"
X -> B - [Power unit] - [piece good] - [piece good]
Target at B:  "Main line A - B - C - D"

"Main line A - B - C - D"
A -> B - [Power unit] - [piece good, fastest possible] - [piece good, fastest possible]
Target at B:  none
B -> C - [Power unit] - [piece good, fastest possible] - [piece good, fastest possible] - [piece good, fastest possible] - [piece good, fastest possible]
Target at C:  "Branch line C - Y"
C -> D - [Power unit] - [piece good, fastest possible] - [piece good, fastest possible]

"Branch line C - Y"
C -> Y - [Power unit] - [piece good] - [piece good]

Vehicles:
Beside the power units, which we dont bother with in this example, we own:
[Piece good car, 40km/h]
[Piece good car, 40km/h]
[Piece good car, 80km/h]
[Piece good car, 80km/h]


So, the scenario:

The power unit on line "Branch line X - B" is at station "X", and according to its consist order, it is supposed to fit two piece good cars, with no further constraints or priorities. At station "X", these two cars are located: [Piece good car, 80km/h] and [Piece good car, 80km/h], which are the two fastest cars that we own.
The power unit departs from "X" with those two cars, which is full of piece good to "Y".

At station "A", the convoy is assembled for line "Main line A - B - C - D". It will consist of the power unit and [Piece good car, 40km/h] and [Piece good car, 40km/h], since there are no faster vehicles available at "A". Those two cars are running empty.
When the convoy arrives at station "B", it fullfills its consist order by fetching the missing vehicles from the branch line convoy, and it is now ready to travel to station "C" with all four cars.

At station "C", is where it gets difficult:
The consist order for line "Main line A - B - C - D" departure from "C" tells it to have only two cars attached, for which its priorities is to have the fastest cars possible.
However, the two fastest cars available are currently loaded with good to "Y", so they are disquallified, and hence given the lowest priority in any of the slots for the departure from "C" to "D".
That would result in the two slow cars becoming the "fastest" cars available, and therefore they are choosen to be kept in the convoy for the departure from "C" to "D".

Does this makes sense?


What would happen if the consist order from "C" to "D" looked like this (added one more car):
C -> D - [Power unit] - [piece good, fastest possible] - [piece good, fastest possible] - [piece good, fastest possible]
Answer: Since the cars loaded with good to "Y" only was given the lowest priority, one of those cars would get detached, and the other would remain in the convoy. That would be a player mistake.

10

Français (French) / Re: Stratégie Urbaine

« Last post by Lieven on Yesterday at 10:51:19 PM »

Peut être un bonus écologique pour les véhicules non vapeur/pétrole à partir d'une certaine année et qui augmenterai avec le temps...