The International Simutrans Forum


Recent Posts

Pages: [1] 2 3 4 ... 10
Simutrans Extended Paksets / Re: Pak256-Ex Release
« Last post by Phystam on Today at 03:00:38 AM »
In our schedule, the next update including aircraft feature would be released in March. ><
Simutrans Extended Paksets / Re: Pak256-Ex Release
« Last post by Bassem_90 on Today at 02:39:52 AM »
Hi airport still not available right ?
Looking now at when the trains first attempt to reserve the wayward semaphore signal, my first result shows a route_index of 74, next_signal of 162, tiles_to_check of 7 and last_index of 176. The train had reserved up to this signal already, however, so I will need to check again with some other trains before being sure of the significance of these figures.

Edit: As is usual with the signalling system, it checks the route a number of times as it progresses. The next check seems to be at route_index 86. The next_signal is at 145 before the block reserver has finished running and 162 afterwards. modified_sighting_distance_tiles and tiles_to_check remain at 7.

Edit 2: The next check is at route_index 100 with the same figures otherwise save that now next_signal is 65530 (i.e., the semaphore has cleared).

Edit 3: The next check is at route_index 140 with tiles_to_check being 5, last_index 176 and the next_signal being still at 145 before running the block reserver and 162 afterwards. At this point, the route is shown reserved into the station.

Edit 4: It then continues to re-check every tile up to and including 144 and then again at 155, with variation only in modified_sighting_distance_tiles. At route_index 155 it is called again, this time with the next_signal having not been reset to 145 before it is called, but being at 65535 (meaning that the train is clear to run to the end of its calculated route without stopping first).

Edit 5: It then repeats this up to and including route_index 161 (one tile before the semaphore signal) with variations in the modified_sighting_distance_tiles.

Edit 6: I should note that this is running locally in server mode.

Edit 7: Re-loading an slightly older saved game where the trains had yet to approach this signal, the first hit appears now to be at route_index 19, with next_signal at 145 before and 162 after running the block_reserver, modified_sighting_distance_tiles at 7, last_index at 176 and tiles_to_check at 6. This is when the reservation up to (but not beyond) the semaphore signal is first made.

Edit 8: The next check seems to be at route_index 74 with the usual 145/162 pattern.

Edit 9: The next check is now at 86.

Edit 10: The next are at 100, 140, 141, 142, 143, 144, 155, 156, 157, 158, 159, 160 and 161: all the same as previously.

Edit 11: For the next train, the checks are at 19, 74, 86, 100, 140, 141, 142, 143, 144, 155, 156, 157, 158, 159, 160 and 161: in other words, the same check points as the previous train.
The next step is to attempt the same exercise with a debug client connected to a local server on the loopback interface, but that will have to await another evening.
Patches & Projects / Re: Use of player/player_/p in class arguments
« Last post by Ters on Yesterday at 07:24:46 PM »
When a member function takes a parameter that has the same name as a member variable, there are some possible cases I know of:
  • The function assigns the parameter to the member variable: Call the parameter new_player, or p, or similar.
  • The member variable and the parameter serve different roles: Rename them to represent the roles, such as owner, buyer, seller, user or similar.
  • Someone forgot about the member variable when adding the parameter, or the member variable was added after the parameter: Remove superfluous parameter.
Patches & Projects / Use of player/player_/p in class arguments
« Last post by ACarlotti on Yesterday at 05:31:33 PM »
I've been going through the changes made in r7453 (translating spieler->player) to fix any mistakes or inconsistencies in how this was merged into Extended. I've discovered that there is a lot of inconsistency over whether a method argument is named "player" or "player_". It might be relevant that sometimes "player" is also a member of the class (often by inheritance); however, there is no clear link between this and the choice of "player" or "player_" for an argument name. Even within a single class both "player" and "player_" are sometimes used as argument names. In one case this issue is averted by using "player_builder" as the class member name.

I mention this because in addition to the inconsistency within Standard, there is also a great deal of inconsistency between Extended and Standard (including one place where Extended has used "p" which is more in keeping with the other parameters of that method). So, are there any thoughts on what would be better? I would like to make Standard an Extended use consistent naming, and I think it would be better to choose a sensible consistent naming scheme and adapt both Standard and Extended to this scheme, rather than changing Extended from one inconsistent scheme to another.
Simutrans Extended Development / Re: No route counts mail's no route
« Last post by Ranran on Yesterday at 04:50:20 PM »
One of my ideas is like this design. (The mail data is still dummy :P)
Simutrans Extended Development / Re: Class reassignemet - line/convoy override
« Last post by Ves on Yesterday at 12:51:54 AM »
I think this would require writing to actual game mechanic parts, and that is something I have never done. The class manager(s) work as a tool to change here and now and doesn't remember anything significant when not in use.

For this to work, I believe there would need to be a place in eg simline that the gui_convoy_creater can look up upon when buying new vehicles.
It could be useful also later on when recombinating convoys is a thing, so the vehicles can change classes on the fly...

I could look and see, for instance how the name of a line is stored, and work my way out from there.

Skickat från min ONEPLUS A6003 via Tapatalk

Simutrans Extended Development / Re: Class reassignment - by comfort
« Last post by Ves on Yesterday at 12:41:34 AM »
No worries! I read in the forum frequently and pray to the train gods that the cause of the desync soon will reveal it self for you who are working so hard to narrow it down! I'm sorry I can't be of much help with that since it is way above my skill level.

Regarding this subject, I do indeed find it best to have one entry for every class existing for pax with a text field for comfort entry. It could even be expanded on to include more parameters, but there might be not really any other parameters which would affect class selections (loading time, etc...)? I think it should have its own tab, so you select reassigning method by changing the tabs.

I also thought of prefilling the ranges, but that might be difficult as you mention, so best I think would be to leave them blank until specified. One could make it attempt to do it, and display "overlapping ranges" if necessary. The entries would need to be remembered though when the window is closed, and blanked out when the "other" method is used.

I will upload the vehicle manager in its current status to GitHub tomorrow, and then you can have a look and try out at the text field input that I am talking about.

Skickat från min ONEPLUS A6003 via Tapatalk

Simutrans Extended Development / Re: Instability on the Bridgewater-Brunel server
« Last post by jamespetts on January 15, 2019, 09:26:39 PM »
Looking at the signalling at this location, I immediately notice two linked anomalies. First of all, the area is generally signalled by track circuit block signals, but the last signals before the station approaching from the Bealden Rye end are older absolute block mechanical signals. One of these, at 6331,1260 would presumably be the signal that is the issue in your testing.

Secondly, these signals purport to be connected to a mechanical signalbox at 6345,1259. However, there is no such signalbox: instead, part of Bickstable Fields railway station stands on that tile. One can imagine that a mechanical signalbox once stood there before the station was widened to four platforms and resignalled.

It should not be possible for signals to exist where their signalbox has been destroyed, as the destruction of the signalbox should automatically delete all connected signals. I notice that these signals are on an elevated way, so it is possible that this in some way caused the failure to delete these signals properly.

I have set a breakpoint for the point in the code when the block reserver first engages with the signal at 6331,1260, and I will see if I can work out how these anomalies affect the code.

Edit: Note for internal reference that, in a save running in single player mode, the signal first clears when the train is at 6273,1255.

Edit 2: The signalbox had not been deleted after all: it is still present, underneath the bridge.

Edit 3: The check at 6273,1255 is with route_index at 100 and next_block at 162.

Edit 4: This seems to be consistent in position over a round of trains passing Brickstable Fields.

Edit 5: When running as a server in debug mode, the signal first clears  6273,1255 is with route_index at 100 and next_block at 162 just as in single player mode.

Edit 6: The above is repeatable with multiple passes of trains.

I think that that is as far as I can go to-night before going to bed. I have yet to find any actual anomalies in the running code, but it is noteworthy that the problem occurs with (1) signals placed in a very odd way (it appears as though whoever was playing Bay Transport forgot to delete the old signals when resignalling the station); and (2) a signalbox placed under a single height elevated rail line, which should not be possible.

The signalling system has not been tested for the case of an absolute block combined signal sandwiched between two track circuit block signals each controlled by the same signalbox as each other. However, the signal appears to be working as intended (i.e., as a stand-alone stop signal, the distant aspect not working as the next signal is not of the absolute block type and in any event showing danger as the train is stopping at the station), so there is no immediate clue as to what the issue could be here.
Simutrans Extended Development / Re: No route counts mail's no route
« Last post by Ranran on January 15, 2019, 04:53:00 PM »
Yes, I think that information is useful if it is alone (and the successful count is enable). The point is that it gets confused when it comes together.
Pages: [1] 2 3 4 ... 10