New map features

[romazoon]

effectively sounds like a major bug.

is it not possible to demolish the bridge entirely in those case instead of letting it be a bridgehead ?? I actually would expect my bridgehead go back to normal bridgehead when i demolish the custombridgehead. here it seems to stay as a "customized"bridgehead, and there is no use for that i can think of. (i know that might sound simplish...but i can t help more.)

I wish you luck finding the solution

edit : and you say try not to leave a single tile bridgehead...the crash actually happenned right from the moment i created that "hacky" bridgehead with half a road tile (and you know allready, i was more expecting the bridge to go back to normal)

[wallyweb]

... single-piece custom road bridgeheads...

Interesting. In all the years that I have played ttdpatch (which supports custom bridgeheads), I have never thought to try to build a dead end (cul-de-sac), the thought being that the road would continue well beyond the bridgehead, in any one or combination of directions. Later this evening I will crank up TTDP and see what is possible. I'll try to get some screenshots as well.

[cirdan]

effectively sounds like a major bug.

It is—a crash of any sort is a major bug.

is it not possible to demolish the bridge entirely in those case instead of letting it be a bridgehead ?? I actually would expect my bridgehead go back to normal bridgehead when i demolish the custombridgehead. here it seems to stay as a "customized"bridgehead, and there is no use for that i can think of. (i know that might sound simplish...but i can t help more.)

The idea behind allowing single-piece bridgeheads is to give the player more flexibility: they can first remove the piece out of the bridge and then build another one to the side. Otherwise, they would be forced to do it the other way around.

I wish you luck finding the solution

Thanks. The real problem here is that the code can only make road vehicles turn around on real tiles, not on a bridge (or in a tunnel, for that matter). Thus, if a road vehicle reaches a bridgehead that only has the piece heading back into the bridge, it cannot go on, but it cannot turn around either, and havoc ensues.

edit : and you say try not to leave a single tile bridgehead...the crash actually happenned right from the moment i created that "hacky" bridgehead with half a road tile (and you know allready, i was more expecting the bridge to go back to normal)

Yes, because the pathfinder will explore that tile as soon as it exists and there is a vehicle nearby, even if said vehicle would never go into that bridge.

Interesting. In all the years that I have played ttdpatch (which supports custom bridgeheads), I have never thought to try to build a dead end (cul-de-sac), the thought being that the road would continue well beyond the bridgehead, in any one or combination of directions. Later this evening I will crank up TTDP and see what is possible. I'll try to get some screenshots as well.

Knowing how TTDP handles this would be nice, since it would give us a hint of what the expectations are. There is always the possibility of disallowing single-piece road bridgeheads at all, but I would rather avoid it if possible, and more so if TTDP did allow them.

By the way, while we are dealing with road bridgeheads, do you happen to know, or can test, if TTDP changes the pavement of custom bridgeheads (tree-lined, streetlights, etc.) according to the town area in which the tile lies? I hunted for screenshots showing this months ago, to no avail, and I would really like to know.

[wallyweb]

Interesting. In all the years that I have played ttdpatch (which supports custom bridgeheads), I have never thought to try to build a dead end (cul-de-sac), the thought being that the road would continue well beyond the bridgehead, in any one or combination of directions. Later this evening I will crank up TTDP and see what is possible. I'll try to get some screenshots as well.

Knowing how TTDP handles this would be nice, since it would give us a hint of what the expectations are. There is always the possibility of disallowing single-piece road bridgeheads at all, but I would rather avoid it if possible, and more so if TTDP did allow them.

By the way, while we are dealing with road bridgeheads, do you happen to know, or can test, if TTDP changes the pavement of custom bridgeheads (tree-lined, streetlights, etc.) according to the town area in which the tile lies? I hunted for screenshots showing this months ago, to no avail, and I would really like to know.

Screenshots are not required. The TTDP behaviour is the same as your branch. I am able to have half lengths on a bridgehead. In my test, the RV turned around properly.
Trees, lights and sidewalks are not built on a bridgehead even though the bridge lies within the appropriate town zone.

[Hafting]

The idea behind allowing single-piece bridgeheads is to give the player more flexibility: they can first remove the piece out of the bridge and then build another one to the side. Otherwise, they would be forced to do it the other way around.
The real problem here is that the code can only make road vehicles turn around on real tiles, not on a bridge (or in a tunnel, for that matter). Thus, if a road vehicle reaches a bridgehead that only has the piece heading back into the bridge, it cannot go on, but it cannot turn around either, and havoc ensues.

Some ideas:
1. Don't consider an incomplete bridge "driveable". If cars don't try, they won't get stuck either. As long as it isn't finished, the bridge pieces is just fancy looking terrain.
2. Allow cars to turn around while on a bridge. That would be useful for normal bridges too, when the player needs to turn a car around. Waiting for the car to exit a bridge is a problem in 1.4.4 also.
3. If either of the above is too hard at the moment, make some sort of "ugly turn". Such as turning the car around 'instantly', and 'teleport' it to the other side of the road or even off the troubled bridge. Ugly is better than a crash. :-/

[Hafting]

A crash, and some minor tunnel signal problems

The crash:
The game just crashed for me. I sent a train to depot in order to replace one of the mail wagons with a passenger car. (Fine-tuning my rail line, a mail backlog just cleared but I seem to need more passenger capacity.) I right-clicked one of the mail wagons to see how much mail it had - to maximize profit I replace the wagon with the least mail inside. This action will usually pop up the contents of the wagon, but instead the came crashed. The crash image shows a partial popup window - seems it crashed while painting the window.

crash.png

The game crashed while right-clicking one of the mail wagons. We see the text "ogn" which is part of "Postvogn" (mail wagon in Norwegian)

(859.09 KiB) Downloaded 8 times

The crash seems to be repeatable:
Load the game
Click the depot to view the train inside
Make sure the game is not paused - or it won't crash! It has to be running to crash.
Right-click the mail wagons

I may be able to keep playing this game, by pausing when doing depot work. I usually do that anyway, so the depot work won't upset schedules. But this time, I wanted another train to get a lead, so I did not pause - and the game died processing the right-click.

The minor tunnel signal problem:
Use the same saved game. A few tiles north of station "Svolvær Mølle" is a tunnel with signals. To see the problem, remove the signals from both tunnel ends first. Then, do what I did to add signals to the track: Set signal density to 8. Ctrl-click the path signal just nort of the station, and drag in direction of the tunnel. This is how I normally add signals to long tracks. What normally happens, is that the game create signals 8 tiles apart - and these signals are of the same type and orientation as the signal being clicked. In this case, a oneway path signal allowing traffic into the station but not out.

The rest of the track gets correct signals, but not the tunnel. The northeast end of the tunnel gets a signal that face the wrong way, so trains stops there. A minor problem because I can turn the signal by clicking it. (The normal way of turning a wrong-way signal.) But that could easily get boring in a mountain game with lots of tunnels. When I correct this signal, another signal magically appear at the southwest end of the tunnel. It has correct orientation, but seems to be the wrong type. Again, this is easily corrected using the signal tool.

The game is compiled with the patch that fixes the "settings dialog" crash.

The crash log:

Code: Select all

*** OpenTTD Crash Report ***

Crash at: Wed Nov 19 12:56:28 2014
In game date: 1951-10-10 (73)

Crash reason:
 Signal:  Aborted (6)
 Message: Assertion failed at line 603 of /usr/src/openttd/src/fontcache.cpp: IsPrintable(key)

Binary:
 Version:    gf4a25ce8M (2)
 NewGRF ver: 150064d0
 Build date: Nov 17 2014 12:55:54
 Flags:      64-bit little-endian

Stacktrace:
 [00] /usr/local/games/openttd() [0x5eac08]
 [01] /usr/local/games/openttd() [0x6df06b]
 [02] /usr/local/games/openttd() [0x5eab93]
 [03] /usr/lib/libc.so.6(+0x339f0) [0x7fe125b819f0]
 [04] /usr/lib/libc.so.6(gsignal+0x37) [0x7fe125b81967]
 [05] /usr/lib/libc.so.6(abort+0x16a) [0x7fe125b82d3a]
 [06] /usr/local/games/openttd() [0x5ee6c0]
 [07] /usr/local/games/openttd() [0x538c83]
 [08] /usr/lib/libicule.so.54(_ZNK6icu_5414LEFontInstance16mapCharsToGlyphsEPKtiiaPKNS_12LECharMapperEaRNS_14LEGlyphStorageE+0x129) [0x7fe12641bb59]
 [09] /usr/lib/libicule.so.54(_ZN6icu_5412LayoutEngine16mapCharsToGlyphsEPKtiiaaRNS_14LEGlyphStorageER11LEErrorCode+0xc0) [0x7fe12641ec40]
 [10] /usr/lib/libicule.so.54(_ZN6icu_5420OpenTypeLayoutEngine15glyphProcessingEPKtiiiaRNS_14LEGlyphStorageER11LEErrorCode+0x93) [0x7fe12641c1b3]
 [11] /usr/lib/libicule.so.54(_ZN6icu_5420OpenTypeLayoutEngine13computeGlyphsEPKtiiiaRNS_14LEGlyphStorageER11LEErrorCode+0x1db) [0x7fe12641cc5b]
 [12] /usr/lib/libicule.so.54(_ZN6icu_5412LayoutEngine11layoutCharsEPKtiiiaffR11LEErrorCode+0xe5) [0x7fe12641eed5]
 [13] /usr/lib/libiculx.so.54(_ZN6icu_5415ParagraphLayoutC1EPKtiPKNS_8FontRunsEPKNS_9ValueRunsES8_PKNS_10LocaleRunsEhaR11LEErrorCode+0x436) [0x7fe1261fc796]
 [14] /usr/local/games/openttd() [0x5c03b5]
 [15] /usr/local/games/openttd() [0x5c14ff]
 [16] /usr/local/games/openttd() [0x6f9e35]
 [17] /usr/local/games/openttd() [0x695183]
 [18] /usr/local/games/openttd() [0x7209ee]
 [19] /usr/local/games/openttd() [0x718774]
 [20] /usr/local/games/openttd() [0x72073e]
 [21] /usr/local/games/openttd() [0x5b38cd]
 [22] /usr/local/games/openttd() [0x5b3ac5]
 [23] /usr/local/games/openttd() [0x700779]
 [24] /usr/local/games/openttd() [0x752231]
 [25] /usr/local/games/openttd() [0x6069a3]
 [26] /usr/lib/libc.so.6(__libc_start_main+0xf0) [0x7fe125b6e040]
 [27] /usr/local/games/openttd() [0x4aa08e]

Operating system:
 Name:     Linux
 Release:  3.15.0-rc8-ARCH
 Version:  #1 SMP PREEMPT Thu Aug 14 16:15:10 CEST 2014
 Machine:  x86_64
 Compiler: GCC 4.9.2 "4.9.2"

Configuration:
 Blitter:      32bpp-sse4-anim
 Graphics set: zBase (251)
 Language:     /usr/local/share/games/openttd/lang/norwegian_bokmal.lng
 Music driver: extmidi
 Music set:    NoMusic (0)
 Network:      no
 Sound driver: sdl
 Sound set:    NoSound (2)
 Video driver: sdl

Fonts:
 Small:  DejaVu Sans
 Medium: DejaVu Sans
 Large:  DejaVu Sans
 Mono:   sprite

AI Configuration (local: 0):
  0: Human
  1: RoadRunner (v9)
  2: Chopper (v10)
  3: AdmiralAI (v25)

Libraries:
 FontConfig: 2.11.1
 FreeType:   2.5.3
 ICU:        54.1
 LZMA:       5.0.7
 LZO:        2.08
 PNG:        1.6.13
 SDL:        1.2.15
 Zlib:       1.2.8

---- gamelog start ----
Tick 0: New game
    Revision text changed to gf4a25ce8M, savegame version 22, modified, newgrf version 0x150064d0
    New game mode 1, landscape 0
    Added NewGRF: GRF ID 33325A43, checksum 8767596EEC0C25A41B060D834C356402, filename: 32bpp_ez-0.1.grf (md5sum matches)
    Added NewGRF: GRF ID 44440A01, checksum FCEEC76CF44EC23E7FE9C88048CF11CC, filename: av8_aviators_aircraft_set-2.21/pb_av8w.grf (md5sum matches)
    Added NewGRF: GRF ID F1250005, checksum 6B9F2DD07EFA14B7A5FE5F2150A10F80, filename: firs.grf (md5sum matches)
    Added NewGRF: GRF ID 52571201, checksum 9548AAA21E5B7E8168B3B19EF8290A83, filename: grvts32.grf (md5sum matches)
    Added NewGRF: GRF ID 4A430002, checksum 658BE666D7F1EAA7D23B93BC38890D71, filename: industrial_stations_renewal-1.0.1/indstatr.grf (md5sum matches)
    Added NewGRF: GRF ID 4C4D0103, checksum 96DC4AD076690CD135F91332F2E477A6, filename: roads.grf (md5sum matches)
    Added NewGRF: GRF ID 4F472B31, checksum 21377D78803A5BB9C57DE4C918A534B3, filename: ogfx-trains.grf (md5sum matches)
    Added NewGRF: GRF ID EC0D9110, checksum D1510A1006B03BCDAAFE562D5D05BACF, filename: raise_landscaping_costs.2/raise_landscaping_costs.grf (md5sum matches)
    Added NewGRF: GRF ID 48530101, checksum EC17E22A38C037D156BD22A96F4A8523, filename: reduced_passenger_payment.1.0/reducedpassengerpayment.grf (md5sum matches)
    Added NewGRF: GRF ID 414E0201, checksum 809D7424C8CEFC9DDC8E0AE4F64D79AB, filename: fish_2-squidrc8/fish.grf (md5sum matches)
    Added NewGRF: GRF ID 54670901, checksum F3699B81A7B2BB59EABD49164AE53796, filename: TGrandom.grf (md5sum matches)
    Game started
Tick 37050: Load game
    Game loaded
Tick 54581: Load game
    Game loaded
---- gamelog end ----

*** End of OpenTTD Crash Report ***

[Eddi]

an alternative to the dead-end handling would be to change the movement pattern of the vehicle so it actually first enters the dead end tile and turns around on there, instead of at the end of the previous tile. (for all tiles, not just bridge heads)

[cirdan]

Screenshots are not required. The TTDP behaviour is the same as your branch. I am able to have half lengths on a bridgehead. In my test, the RV turned around properly.

Then this is a strong argument for single-piece bridgeheads.

Some ideas:
1. Don't consider an incomplete bridge "driveable". If cars don't try, they won't get stuck either. As long as it isn't finished, the bridge pieces is just fancy looking terrain.

The thing is that they are already undrivable, and this is precisely what makes vehicles get stuck at them.

The current implementation treats single-piece road tiles as undrivable for normal (non-tram) road vehicles; when a vehicle reaches the tile, it turns around immediately, remaining in the previous tile, as it does at any dead end. This is not possible when a vehicle arrives at such a tile from a bridge: when it gets to the bridge head, it is still on the bridge, not on a tile, so there is no previous tile on which to turn.

On the other hand, trams behave differently: single-piece tram tiles are drivable, and force reversing. (In the road vehicle controller, this is called a long turn, as opposed to the short turn used by non-tram vehicles).

A simple fix would be to make all road vehicles behave like trams do now on single-piece tiles: they all enter the new tile, and turn around there. Non-trams will keep the ability to turn around almost anywhere, but they would do it differently on single-piece tiles.

A more elaborate solution would be to overhaul the road vehicle controller. We all have heard complaints about handling of road vehicles, especially with respect to wormholes (tunnels and bridges) and overtaking. The bug at hand is serious but not urgent (there is an easy workaround), so perhaps we could take this chance to redesign the controller. If we somehow allow vehicles to turn around on a bridge, for instance, the bug will be gone. Then again, while the current controller is far from perfect, we may not come up with a better way of handling, say, overtaking.

2. Allow cars to turn around while on a bridge. That would be useful for normal bridges too, when the player needs to turn a car around. Waiting for the car to exit a bridge is a problem in 1.4.4 also.

This would be one of the solutions above.

[wallyweb]

A more elaborate solution would be to overhaul the road vehicle controller.

Here's an interesting TTDP confguraton parameter:

// `rvovertakeparams' (-ZK) road vehicle overtaking behaviour parameters. Hexadecimal bit field: 0=enable overtaking of non-stationary vehicles with same max speed, 1,2,3=disable overtaking (collision) checks on: current tile, next tile, and tile after next respectively, (tile after next always ignored for stationary overtakees), 4=set maximum overtaking counter value to bits 8-15 (TTD default=0x23), 5=set stationary overtakee overtaking count initial value to bits 16-23 (TTD default=0x11), 6=overtake even if on junction tile if overtakee is stationary. Experimental switch, some values may produce adverse/unusual results.
rvovertakeparams 0

Also,

What about 3-way and 4-way intersection priorities?
Some logic:

Code: Select all

If next tile is an intersection
  then
    if next tile is occupied
      then stop rv/tram
        else proceed
If more than one rv/tram occupy intersecton tlle
  then trigger rv colision disaster

[andythenorth]

Would be more like:

Code: Select all

If next tile is an intersection
  then
    get all vehicles on next tile
       for each vehicle
          is vehicle travelling same direction as this vehicle and is not turning
             stuff to check preceding vehicle length, including articulated trailing parts
             stuff to check preceding vehicle speed
             stuff to check if preceding vehicle is stopping
          if vehicle travelling orthogonal to this vehicle
             stuff to check if orthogonal vehicle is turning 
                if turning
                   is it turning towards this vehicle or away
                       more stuff
               if not turning
                   stuff to check orthogonal vehicle length
                   stuff to check orthogonal vehicle speed
                   stuff to check if orthogonal vehicle is stopping
          then stop rv/tram
            else proceed
If more than one rv/tram occupy intersecton tlle
  then trigger rv colision disaster

etc

Could probably consolidate that. Needs more than a tile check though, or instant gridlock. Would also need gridlock-breaking mechanism for player (no 'ignore signals' for RVs).

[wallyweb]

Could probably consolidate that. Needs more than a tile check though, or instant gridlock.

No Nooo ... You are thinking like a logical citizen when the thoughts of a town engineer who subscribes to the "We'll fix the gridlock when we see it" method are what is called for. Too many disasters or gridlocks and perhaps it is time for the player to consider thoroughly challenging the local authorities by dynamiting roads and houses and cutting down many trees to make way for a proper intersection with complicated over and under passes and exit ramps and lots of undecipherable multilingual inconsistent and conflicting signage. Gridlock must be created to be enjoyed.

Would also need gridlock-breaking mechanism for player (no 'ignore signals' for RVs).

A click on the vehicle's reverse direction icon would send the rv to another location wherein to create gridlock mayhem.

[romazoon]

Hi Cirdan,

seems i found another bug causing a crash, happens when i bulldoze (not dynamite) a piece of road that is located over a rail tunnel.

*** OpenTTD Crash Report ***

Crash at: Sat Nov 29 12:21:56 2014
In game date: 2037-11-11 (10)

Crash reason:
Exception: E1212012
Location: 764AC42D
Message: Assertion failed at line 79 of C:/MinGW/msys/1.0/home/Adminguy/fttd/src/map/../tile/road.h: tile_is_road(t) || tile_is_crossing(t) || tile_is_road_tunnel(t) || tile_is_road_depot(t) || tile_is_station(t)

Binary:
Version: gbec282d1 (0)
NewGRF ver: 150064d0
Build date: Nov 17 2014 17:46:39
Flags: 32-bit little-endian

Registers:
EAX: 0028AD90 EBX: 00000016 ECX: 00000000 EDX: 0008E3C8
ESI: 74ED3180 EDI: 00000000 EBP: 0028ADE0 ESP: 0028AD90
EIP: 764AC42D EFLAGS: 00000246

Bytes at instruction pointer:
C9 C2 10 00 CC CC CC CC CC 8B FF 55 8B EC 56 8B 75 08 83 FE F4 72 18 83

Hopefully this bug will be easier, or let s say just less complex to fix than the last bug i reported

Cheers

[cirdan]

Thanks for the bug report. There is a missing check in the road removal code which causes the crash. I am currently reworking the road vehicle controller to fix the issue with single-piece road bridge heads, plus I am suffering from a severe real-life-induced shortage of development time, but I will try to test and push a fix soon. In the meanwhile, just try not to do that.

[romazoon]

Thanks for the bug report.

you are welcome.

I am currently reworking the.......

oh ! that sounds great

severe real-life-induced shortage of development time

sounds less cool, but "c'est la vie" take your time, it s already great to know you are working on it !

just try not to do that

sure...i m looking for other bugs now anyway!

[te_lanus]

found a "bug(?)", not sure why it happens, doesn't happen in the Vanilla

when I per-accident click on a save from Vanilla OpenTTD the build (gbec282d1) crashes

[TrueSatan]

Hmm if its the Windows version from wally it is maybe a bug in the older gcc.
Cirdan was looking into it (if he has time )
Anyways I provide my compiled version as well to be sure it works with this
one and there is not some bug somewhere else around the get file info
in openttd source of nmf.

@wally have you tried to update your msys and gcc?

Cheers

[te_lanus]

Hmm if its the Windows version from wally it is maybe a bug in the older gcc.
Cirdan was looking into it (if he has time )
Anyways I provide my compiled version as well to be sure it works with this one and there is not some bug somewhere else around the get file info in openttd source of nmf.
Cheers

My "Bug" doesn't happen with your Build.



THanx

[wallyweb]

@wally have you tried to update your msys and gcc?

I've held off doing this. There are no updates to the "Compiling on Windows using MinGW" wiki page so I have to assume that it is up to date. What I might do this weekend is reinstall MinGW.

[TrueSatan]

As long as you stick to the lib versions there, there should be no problem using a newer mingw and gcc.
Maybe its good then to update the wiki page after we can confirm then, that the newer version compiles
without the crash.

Hope the new setup works flawless. And no don't even try to compile icu

Cheers

[wallyweb]

As long as you stick to the lib versions there, there should be no problem using a newer mingw and gcc.
Maybe its good then to update the wiki page after we can confirm then, that the newer version compiles
without the crash.

Hope the new setup works flawless. And no don't even try to compile icu

Cheers

Help!