New map features

Forum for technical discussions regarding development. If you have a general suggestion, problem or comment, please use one of the other forums.

Moderator: OpenTTD Developers

Eddy Arfik
Transport Coordinator
Transport Coordinator
Posts: 260
Joined: 09 Apr 2014 11:10

Re: New map features

Post by Eddy Arfik »

Hafting wrote:If depot-only refits are bad, how about fixing that in the game? Either allow all re-fits in stations - or drop the depot-only refits completely. In one case, an oil tank can be converted to milk at a station. In the other case, you decide what kind of tank it is when you first buy it, you can never change from clean cargo to dirty. (Other than by selling the wagon and then buy a new one - which costs.)

I guess obsoleting newgrf's won't be popular? So an old newgrf may still specify a depot-only refit, but the game won't have to honor that spec.
It seems to be the most sensible option is to remove the depot-only refits and allow all refits to be done in station, maybe this patch deserves another look

viewtopic.php?f=33&t=71253
Hafting
Engineer
Engineer
Posts: 106
Joined: 13 Feb 2014 11:22

Re: New map features

Post by Hafting »

Eddy Arfik wrote: It seems to be the most sensible option is to remove the depot-only refits and allow all refits to be done in station, maybe this patch deserves another look

viewtopic.php?f=33&t=71253
Something needs to be done. Currently, we have depot-only refits, and cargodist fails to understand that. The situation is clearly a bug the way I see it. It does not matter so much to me how it gets solved, but I hope there will be a solution. Currently, my games break up as the complexity increases. I always play with cargodist, I use trains with many kinds of wagons, and find "re-fit to available" very useful.

The solutions I see:
  • All refits allowed in stations, no change to cargodist needed, any cargo scheduled will be moved too. Some refits might seem unrealistic, but games are about fun and not too much realism?
  • Keep depot-only refits, have cargodist understand that. No weird cargo will be routed. Would work, but if depot-only refits is considered wrong... I admit that I have never used a depot-refit order in a game, so it is not something I need. If this holds for other players, then depot refit is indeed unnecessary.
  • Obsolete the depot refits, cargodist will no longer see a re-fit option, no weird cargo will be routed. And no depot-refit orders for the player. Perhaps allow manual re-fits, so players can build the trains they need.
  • Fix all the newgrfs instead, to only have station refits. Not a good solution, as the game will still be able to break with old newgrfs. And anyone making a newgrf will have an obscure trap set for them, if they decide to play with depot refits.
User avatar
wallyweb
Tycoon
Tycoon
Posts: 6102
Joined: 27 Nov 2004 15:05
Location: Canada

Re: New map features

Post by wallyweb »

Eddy Arfik wrote:It seems to be the most sensible option is to remove the depot-only refits and allow all refits to be done in station, maybe this patch deserves another look viewtopic.php?f=33&t=71253
see my comment below.
Hafting wrote:Something needs to be done. Currently, we have depot-only refits, and cargodist fails to understand that.
How is this a problem? Why must cargodist know about the availability of depot-only refits?
The situation is clearly a bug the way I see it.
Where exactly is the bug? Is it in a feature (Depot, Station, etc.) or is it in an implementation (cargodist) or is it in something else?
All refits allowed in stations, no change to cargodist needed, any cargo scheduled will be moved too. Some refits might seem unrealistic, but games are about fun and not too much realism?
This goes to player preference. Many players consider realism to be an essential part of the challenge. At the other end of the "realism" spectrum some players simply want to make lots of money as fast as possible. Which group of players must suffer in order for another group to be satisfied?

Manual Depot Refits is an original part of the game. Depots are where we buy wagons and build our trains. Manual Depot Refit is an essential part of this process.

Station Refit is an attractive and realistic addition to the game.

Station Refit-If-Available is an attractive and realistic addition to the game. The question here is how to schedule the delivery of the new cargo.
Should cargodist be able to automatically alter a train's schedule?
Upon successful delivery, will the wagons be refitted back to their original refit and the train returned to its original schedule?

If I read the discussion properly, the problem seems to be inappopriate cargo being available at a station.
How can this be if cargo acceptance is determined by an industry located within a station's coverage area?
Is the cargo left over from an industry that expired due to poor service?
Is the cargo an oversupply to an industry with an acceptance quota?

The solution is really quite simple.
If a player is unable to provide adequate service to one of his/her stations, the player should dynamite that station.
This is not a Depot/Station/Refit/Cargodist issue. It is a company management issue.
Eddy Arfik
Transport Coordinator
Transport Coordinator
Posts: 260
Joined: 09 Apr 2014 11:10

Re: New map features

Post by Eddy Arfik »

wallyweb wrote: How is this a problem? Why must cargodist know about the availability of depot-only refits?
The problem is when a "refit to available cargo" order is given, Cargodist assumes that all refits can be done at a station, and will send cargo to the station under that assumption, even when the trains serving that station are not capable of performing that refit outside of a depot.
wallyweb wrote:This goes to player preference. Many players consider realism to be an essential part of the challenge. At the other end of the "realism" spectrum some players simply want to make lots of money as fast as possible. Which group of players must suffer in order for another group to be satisfied?
In other words what you are saying is that we should leave the situation as is, and if a player wishes to use "refit to available cargo" orders with Cargodist they should choose a vehicle set without restrictions on where refits can be performed?
User avatar
andythenorth
Tycoon
Tycoon
Posts: 5656
Joined: 31 Mar 2007 14:23
Location: Lost in Music

Re: New map features

Post by andythenorth »

The newgrf spec for refit callback, is at best, unfortunate, at worst broken.

That's way off-topic for this thread, nothing to do with the map; but it has been discussed before elsewhere, including this dedicated thread http://www.tt-forums.net/viewtopic.php?f=68&t=57264
User avatar
wallyweb
Tycoon
Tycoon
Posts: 6102
Joined: 27 Nov 2004 15:05
Location: Canada

Re: New map features

Post by wallyweb »

Eddy Arfik wrote: ...
How does this sound? ...

Three refit types:
1. Manual Refit - Depot only - For configuring new wagon purchases or for mandating a specific refit.
2. Automated - Scheduled Refit - Stations only - For where the player needs the train to pick up a specific cargo from a scheduled stop on a return trip
- Cannot be combined with "Refit If Available"
- Non-Stop scheduling only
- Only refits to and collects cargodist cargoes consigned to a scheduled stop
3. Automated - Refit If Available - Stations only - For where the player's train is available for random pick-ups and deliveries along the return trip route.
- Cannot be combined with "Scheduled Refit"
- Stops at all stations along return trip route
- Wagon type permitting, can refit to and collect and drop cargodist cargoes at any station along the return trip route.
- If the player notes that a cargo is accumulating at a station, this is not a bug. It is a management issue and the player needs to assign a train to service that cargo at that station.

All depots and all stations are permanently able to offer refits as described above.
A train set should have no restrictions on where a refit can be performed as described above.

Have I missed anything?
andythenorth wrote:The newgrf spec for refit callback, is at best, unfortunate, at worst broken.

That's way off-topic for this thread, nothing to do with the map; but it has been discussed before elsewhere, including this dedicated thread http://www.tt-forums.net/viewtopic.php?f=68&t=57264
... The "New map features" title has become a tad misleading, especially since cirdan has moved his project from a patch to a branch.
User avatar
cirdan
Director
Director
Posts: 539
Joined: 07 Apr 2007 18:08

Re: New map features

Post by cirdan »

HackaLittleBit wrote:I am not familiar with road vehicle behavior.
I think that path finding for them is somewhere done while they are on the middle of the tile.
Still, the moment they choose to go in the direction of the bridge (wormhole part), their destination will
not be changed anymore and they could start slowing down if necessary.
A road vehicle calls the pathfinder when it enters a tile, so the situation is the same as for trains.
Hafting wrote:But of course.
Here is a game with FIRS and a nice profitable steel business.
Thank you again for your savegame and your detailed explanation of the problem; please see my analysis below.
wallyweb wrote:Manual Depot Refits is an original part of the game. Depots are where we buy wagons and build our trains. Manual Depot Refit is an essential part of this process.
Nobody is going to remove the ability to refit in depots, at least not in my branch. But it may make sense to remove the distinction between refitting in stations and refitting in depots. This will give the user (player) greater flexibility: they can decide whether to send a train to a depot for refitting or to do it at a station, at their discretion. Those striving for realism can have it their way, and so can those striving for efficiency, and everybody is happy.
andythenorth wrote:The newgrf spec for refit callback, is at best, unfortunate, at worst broken.

That's way off-topic for this thread, nothing to do with the map; but it has been discussed before elsewhere, including this dedicated thread http://www.tt-forums.net/viewtopic.php?f=68&t=57264
Thanks for the pointer, and for this enlightening post. So, if I understand correctly, the only way to know if a refit can be done at a station is via a newgrf callback which can return a different answer every other second? That is... unfortunate indeed, as you put it.

(By the way, this thread is no longer about the map. Many things have gone into my branch and, while everybody still calls it "new map features", it is really a fork of openttd with several new features, such as dock buoys.)


So, this is the current situation, as I see it. Vehicles can be refitted in depots and at stations, but whether a particular refit is allowed at a station is governed by an (unpredictable) newgrf callback. This is the spec, and there are newgrfs in the wild using it. The cargo distribution subsystem, unable to know in advance which refitting options will actually be available at a station, assumes that all of them are, and routes cargo accordingly; when a vehicle cannot perform the expected refit at a station, havoc ensues. Is this correct?

Following wallyweb's ideas, I see a couple of (non-exclusive) possibilities to improve things:
  • Give the player more flexibility in automatic refits, by making it possible to establish the exact set of allowed cargoes. (Currently you can only set a fixed cargo or "any available".) This may be interesting in its own right and helps work around the problem by hinting the cargo distribution system of impossible refits.
  • Ignore the newgrf spec and allow any refit at a station as if it were in a depot. This will remove the problem altogether, and people wishing to do some refits in a depot can still do it the same as before (the game will just not force them to).
User avatar
andythenorth
Tycoon
Tycoon
Posts: 5656
Joined: 31 Mar 2007 14:23
Location: Lost in Music

Re: New map features

Post by andythenorth »

cirdan wrote:Give the player more flexibility in automatic refits, by making it possible to establish the exact set of allowed cargoes.
"Any available from {list}" would be a useful gameplay feature.
Ignore the newgrf spec and allow any refit at a station as if it were in a depot.
I would like to see this done because I think the spec has some issues, not least of which is broken orders. There is always (rightly) caution around removing anything from newgrf spec, so dunno if that would make it to trunk openttd. :)
User avatar
HackaLittleBit
Director
Director
Posts: 550
Joined: 10 Dec 2008 16:08
Location: tile 0x0000

Re: New map features

Post by HackaLittleBit »

Ok, I had a review and here is a slightly more complete patch.
Speed behavior was altered for road-vehicles also.
For me these changes will do.
Trains will slow down on the bridge head as soon as they enter, and have the intention to cross into the wormhole.(bridge middle part).
Speed will not be affected if they just cross the bridge head.
Road vehicles will slow down on the last 5 ticks before entering the worm hole.
The speed differences between bridge and road vehicle is much less than for trains!
If road vehicles don't pass into that zone they will not slow down.
A document (svg) is included to explain the "5 ticks".(You need a modern browser to view it!)
With this document you can investigate more easily and in detail, the various positions that vehicles have on the tile.
Or see photo to make my intentions clear.
I can't find a reason to mess around in the path finder.(am I missing something? newgrf?)
The way I wrote the patch is simple and effective.

Have funn!
Attachments
23580 modify bridge speed.patch_V2.patch
(3.14 KiB) Downloaded 68 times
wormhole.png
wormhole.png (56.73 KiB) Viewed 2878 times
tileMovement.zip
This is svg animated image.
svg extention was changed into html
Use modern browser to view.
Firefox works the best.
(25.27 KiB) Downloaded 67 times
Hafting
Engineer
Engineer
Posts: 106
Joined: 13 Feb 2014 11:22

Re: New map features

Post by Hafting »

wallyweb wrote:
Hafting wrote:Something needs to be done. Currently, we have depot-only refits, and cargodist fails to understand that.
How is this a problem? Why must cargodist know about the availability of depot-only refits?
When playing with cargodist on, the game will try to send cargo to any reachable destination, even if the cargo has to be transferred between various trains at various stations. Cargodist knows where it is possible to send cargo, by looking at what cargo the trains are capable of transporting - and where they go. When using cargodist, the player decides what cargo to pick up, but not so much where to bring it. There is much realism in this: Real railroads pick up stuff at stations too, but don't decide where it should go. Passengers buy tickets for any available destination they want to see, the railroad company cannot just bring them all to the same city and hope they're satisfied with that. Similar for cargo. In a game without cargodist, the player decides where to bring everything. Not so with cargodist. You get coal, but coal destined for a specific coal-consuming station. You cannot decide to deliver it at some other coal consuming station instead.

Now, if a train has orders to "re-fit to available cargo" at some station, then cargodist will try to schedule any cargo that train is capable of bringing, considering every re-fit the train might do. Sounds nice, but this is where the bug is. When cargodist creates cargo for some faraway destination, it considers the re-fit options. And it wrongly assumes that all re-fits are possible to do at the station the re-fit order is for. But not all re-fits are possible to do at a station, so a cargodist game sometimes creates cargo that cannot reach the final destination. The cargo may remain where it was produced, or it may be brought somewhere, and transferred to a station where another train is supposed to pick it up. But that other train cannot pick up, because it would need an illegal re-fit to do so. For example, it might need to change an oil tank wagon into a milk tank - which cannot be done at a station.
wallyweb wrote:
The situation is clearly a bug the way I see it.
Where exactly is the bug? Is it in a feature (Depot, Station, etc.) or is it in an implementation (cargodist) or is it in something else?
The bug is in cargodist. An order to "re-fit to available" will allow an oil train to re-fit its oil tank wagons to chemicals, if chemicals are available at the station. (Common case when bringing oil to a refinery, the refinery then create chemicals from oil.) This works because the train set newgrf specifies that one can re-fit from oil to chemicals at a station.

But if oil is dropped off and milk is available for the return trip, then a re-fit cannot be done. The train newgrf specifies that we can only re-fit from oil to milk in a depot (realistically, you need an incredible cleaning job for such a re-fit.) But cargodist will think it is possible - milk might then pile up at that station because the available trains cannot re-fit to bring it.

This bug is relatively new. Before, cargodist did not consider re-fit orders. That created some other irritating problems. Having cargodist understand re-fit orders generally helps. The only problem is that cargodist should only consider the possible re-fits, not also the impossible ones. Then we won't get cargo produced that no train can bring. Piles of cargo should only happen when the player is transporting something, but with too low capacity.
wallyweb wrote: Manual Depot Refits is an original part of the game. Depots are where we buy wagons and build our trains. Manual Depot Refit is an essential part of this process.
Yes. I do not propose removal of manual re-fitting.
wallyweb wrote: Station Refit-If-Available is an attractive and realistic addition to the game. The question here is how to schedule the delivery of the new cargo.
Should cargodist be able to automatically alter a train's schedule?
Upon successful delivery, will the wagons be refitted back to their original refit and the train returned to its original schedule?
Cargodist creates cargo for specific destinations, and loads it onto trains that can get the cargo closer to the destination. Cargodist do not route the trains, the player still do that. Also, cargodist does not re-fit wagons. The player can set a "re-fit to available" order, (for a specific train, at a specific station) and then the train will pick up anything it can bring. A coal train will only pick up coal. A ore train will only pick up ore. But an station may be connected to several different mines, or other trains might transfer cargo there. So, a station may have ore and coal in amounts that vary greatly over time. It is then useful to use a "re-fit to available order". A train with bulk wagons can then load coal in some wagons and ore in others, depending on how much there is of each kind. So the player can use fewer trains and fill them optimally, instead of having a half-empty coal train pass by a station full of ore.
wallyweb wrote: If I read the discussion properly, the problem seems to be inappopriate cargo being available at a station.
How can this be if cargo acceptance is determined by an industry located within a station's coverage area?
Is the cargo left over from an industry that expired due to poor service?
Is the cargo an oversupply to an industry with an acceptance quota?
It is correct that the problem is inappropriate cargo being available at a station. (Or at many stations, making a huge mess.)
How can this be? It happens because some industry withing the stations coverage area produce cargo, in the mistaken belief that the trains going by can bring the stuff. But the trains cannot, because they would need an illegal re-fit to do so. It also happens because some other train transfers cargo at the station, cargo it is hoped that other trains will pick up and pass on. But again, the other trains cannot, because they would need an impossible re-fit.

This is not a problem with cargo left over from expired industry. And it is not an oversupply issue either - I play with an industry set that doesn't have acceptance quotas.

I think the best solution would be to have cargodist know the difference between station re-fits and depot re-fits, and only consider the former. That would solve the problem for players that use cargodist and orders of the type "re-fit to available cargo". Players that either don't use cargodist or don't use re-fit orders won't see this bug - and they will not see any side effects of this particular way of fixing it either.

But when I proposed this solution, there was a suggestion that depot-only refits was somehow a bad thing that should go away. Changing the game so there are no depot-only re-fits available either means that all re-fits can be done at stations - or that some re-fit options disappear. Either way, the bug I see disappears. But these solutions are more intrusive. They will change the game for everyone - including people who don't use cargodist. Fine with me - but maybe not with everybody else. I just hope the bug will be fixed, as it sometimes ruins the game.
User avatar
andythenorth
Tycoon
Tycoon
Posts: 5656
Joined: 31 Mar 2007 14:23
Location: Lost in Music

Re: New map features

Post by andythenorth »

Hafting wrote:Having cargodist understand re-fit orders generally helps. The only problem is that cargodist should only consider the possible re-fits, not also the impossible ones.
It can't. The station refits are non-deterministic. Cargodist has no way to know the result until the refit runs.

The bug is in the newgrf spec, not cargodist.
Hafting
Engineer
Engineer
Posts: 106
Joined: 13 Feb 2014 11:22

Re: New map features

Post by Hafting »

Game crash bug, savegame cannot load.

I got a strange problem where trains sometimes stop for no reason. This creates long queues of trains, and losses. If I force the stuck train to move by double-clicking the "ignore signals" buttong, then everything is fine. The train moves, there nothing crashes. The game is fine for a while, until the same train get stuck again in the same place. Waiting is not a solution, I usually discover this because 10 trains has queued up and cannot move. But if I force the first one, it all resolves.

It seems to be one train stuck in a depot, another train waiting at a path signal in front of the depot. The railroad from the depot to the next station is clear, so one of the trains should be able to move. But both just sits there forever.

So I tried saving such a game, in order to report a bug, possibly in signalling or pathfinding. But when I tried to reload the savefile, I got a crash. I have several such savefiles that I cannot load.

Here is the log:

Code: Select all

dbg: [grf] Palette sprites are missing
Error: Assertion failed at line 235 of /usr/src/openttd/src/roadstop.cpp: v->direction == dir_east || v->direction == ReverseDir (dir_east)
Loading your savegame caused OpenTTD to crash.
This is probably caused by a corruption in the savegame.
Please file a bug report and attach this savegame.

Crash encountered, generating crash log...
*** OpenTTD Crash Report ***

Crash at: Thu Mar 19 18:39:28 2015
In game date: 1970-06-22 (46)

Crash reason:
 Signal:  Aborted (6)
 Message: Assertion failed at line 235 of /usr/src/openttd/src/roadstop.cpp: v->direction == dir_east || v->direction == ReverseDir (dir_east)

Binary:
 Version:    g93693d36 (0)
 NewGRF ver: 150064d0
 Build date: Mar  5 2015 15:24:43
 Flags:      64-bit little-endian

Stacktrace:
 [00] /usr/local/games/openttd() [0x600178]
 [01] /usr/local/games/openttd() [0x6e2028]
 [02] /usr/local/games/openttd() [0x600103]
 [03] /usr/local/games/openttd() [0x7739d0]
 [04] /usr/lib/libc.so.6(+0x33540) [0x7fb74ce98540]
 [05] /usr/lib/libc.so.6(gsignal+0x37) [0x7fb74ce984b7]
 [06] /usr/lib/libc.so.6(abort+0x16a) [0x7fb74ce9988a]
 [07] /usr/local/games/openttd() [0x6039a0]
 [08] /usr/local/games/openttd() [0x6a5ded]
 [09] /usr/local/games/openttd() [0x77b0e4]
 [10] /usr/local/games/openttd() [0x647abe]
 [11] /usr/local/games/openttd() [0x783312]
 [12] /usr/local/games/openttd() [0x78372b]
 [13] /usr/local/games/openttd() [0x604c7f]
 [14] /usr/local/games/openttd() [0x60519c]
 [15] /usr/local/games/openttd() [0x606a98]
 [16] /usr/local/games/openttd() [0x74b72c]
 [17] /usr/local/games/openttd() [0x61bd5b]
 [18] /usr/lib/libc.so.6(__libc_start_main+0xf0) [0x7fb74ce85800]
 [19] /usr/local/games/openttd(_start+0x29) [0x4a9ab9]

Operating system:
 Name:     Linux
 Release:  3.18.6-1-ARCH
 Version:  #1 SMP PREEMPT Sat Feb 7 08:44:05 CET 2015
 Machine:  x86_64
 Compiler: GCC 4.9.2 "4.9.2 20150204 (prerelease)"

Configuration:
 Blitter:      32bpp-sse4-anim
 Graphics set: zBase (251)
 Language:     /usr/local/share/games/openttd/lang/english.lng
 Music driver: extmidi
 Music set:    NoMusic (0)
 Network:      no
 Sound driver: null
 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: Chopper (v10)
  2: RoadRunner (v9)
  3: CluelessPlus (v37)
  4: OtviAI (v418)
  5: RoadRunner (v9)
 GS: Renewed City Growth (v5)

Libraries:
 FontConfig: 2.11.1
 FreeType:   2.5.5
 ICU:        54.1
 LZMA:       5.2.1
 LZO:        2.09
 PNG:        1.6.16
 SDL:        1.2.15
 Zlib:       1.2.8

---- gamelog start ----
Tick 0: New game
    Revision text changed to g93693d36, savegame version 22, not modified, newgrf version 0x150064d0
    New game mode 1, landscape 1
    Added NewGRF: GRF ID F1250005, checksum EF9CA5244B98B86C62BAC5B39D6F351B, filename: firs_industry_replacement_set-1.4.3/firs.grf (md5sum matches)
    Added NewGRF: GRF ID 52571201, checksum 9548AAA21E5B7E8168B3B19EF8290A83, filename: grvts32.grf (md5sum matches)
    Added NewGRF: GRF ID 4F472B31, checksum 21377D78803A5BB9C57DE4C918A534B3, filename: ogfx-trains.grf (md5sum matches)
    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 4A430002, checksum 332F5EE83BB1A8F7C1766E610B48A222, filename: indstatr_32.grf (md5sum matches)
    Added NewGRF: GRF ID 43415000, checksum 4DA9FE9A87DD330EBAD43916771BAF21, filename: opengfx_airports-0.4.2/ogfx-airports.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 54670901, checksum F3699B81A7B2BB59EABD49164AE53796, filename: TGrandom.grf (md5sum matches)
    Added NewGRF: GRF ID 414E0201, checksum 0551E1BD6EB3100574B0474EAF3DE462, filename: fish_2-2.0.0/fish.grf (md5sum matches)
    Added NewGRF: GRF ID 48530101, checksum EC17E22A38C037D156BD22A96F4A8523, filename: reduced_passenger_payment.1.0/reducedpassengerpayment.grf (md5sum matches)
    Game started
Tick 43858: Load game
    Game loaded
Tick 7378: Load game
---- gamelog end ----

*** End of OpenTTD Crash Report ***

Attachments
wongstop, 22. Jun 1970.sav
Savegame that openttd (with new map features) refuses to load. The game crashes with an assert.
(194.43 KiB) Downloaded 63 times
Hafting
Engineer
Engineer
Posts: 106
Joined: 13 Feb 2014 11:22

Re: New map features

Post by Hafting »

andythenorth wrote:
Hafting wrote:Having cargodist understand re-fit orders generally helps. The only problem is that cargodist should only consider the possible re-fits, not also the impossible ones.
It can't. The station refits are non-deterministic. Cargodist has no way to know the result until the refit runs.

The bug is in the newgrf spec, not cargodist.
When is cargodist considering re-fits then? If it perform the tests while the train is at the station in question, then it is possible to check how the wagon is set up at the moment and what re-fits are possible.

I understand that this is not possible to test if cargodist tries to plan cargo movements when the train is somewhere else. But the only way it can go wrong, is if the train actually has depot re-fit orders. Because then, wagons may be changed to another group (i.e. from "dirty" cargo to "clean" cargo") I understand that predicting such changes is impossible, as conditional orders can create a change regime of arbitrary complexity.

If you fix the newgrf spec - fine with me. If that won't happen quickly for some good reason, please consider changing cagodist so it only consider re-fits that can be done in a station, from whatever state the wagons has at the time of checking. (And ignore re-fit options that won't be possible in a station, if we assume that the wagons don't change until they arrive at the station cargodist is currently planning for.).

I believe this will fix my problem, for all cases where the trains do not have orders to re-fit in depots. (An option I don't use anyway.) If a wagon isn't changed in some depot, then it will stay within the same re-fit group. I.e. a tank wagon will remain either a "clean tank" or a "dirty tank". A flatbed wagon will either be a flatbed with stakes, or a flatbed without stakes. I believe that these cases without depot re-fit orders, are very common. And it seems that cargodist can be made to plan correctly for such cases. The simple assumtion that a wagon will not change until it arrives at the station where cargodist is considering re-fits, and so the re-fit will be from whatever state the wagon has at the moment.

This assumtion can still fail - but it will be a rare mode of failure. It will only happen if the train has a depot re-fit order somewhere in its order list.
Eddi
Tycoon
Tycoon
Posts: 8257
Joined: 17 Jan 2007 00:14

Re: New map features

Post by Eddi »

Hafting wrote:If that won't happen quickly for some good reason
... you stomp your foot on the ground and hold your breath?

what you suggest is not possible. that has been discussed already.

you have exactly three options:
  1. play without cargodist
  2. play without refit orders
  3. change the newgrf so it allows all refits at station without restrictions
there is no bug. there are just two features with colliding philosophies.
Eddy Arfik
Transport Coordinator
Transport Coordinator
Posts: 260
Joined: 09 Apr 2014 11:10

Re: New map features

Post by Eddy Arfik »

andythenorth wrote:
Eddi wrote:you have exactly three options:
(four)

4. choose a newgrf that isn't defective.
Indeed, my original suggestion was to ignore the grf spec with regard to broken refit callback, allowing all refits possible in depot to be also done at a station, giving the player the choice of where they carry out the refit as suits their playing style, the patch I linked to seems to do that, nothing about removing manual refits from depot. Not sure how long it would take to get a proper fix to the spec into trunk, however since the OpenGFX+ Trains seems to be the most popular grf that makes use of the broken spec, I might upload my personal patched copy with the restrictions removed as a temporary workaround when I get back to my computer (it's savegame compatible with a version bump so should be able to upgrade existing games without problems)
User avatar
cirdan
Director
Director
Posts: 539
Joined: 07 Apr 2007 18:08

Re: New map features

Post by cirdan »

andythenorth wrote:
cirdan wrote:Give the player more flexibility in automatic refits, by making it possible to establish the exact set of allowed cargoes.
"Any available from {list}" would be a useful gameplay feature.
How does it look?
Image
There are problems with shared orders though. When you edit an order refit, you are offered all cargoes that the current vehicle can be refitted to, ignoring the rest of the shared group, but it would make sense to offer any cargo that any vehicle in the group can carry. This needs more thought, and likely more coding.

HackaLittleBit wrote:Ok, I had a review and here is a slightly more complete patch.
We still have to decide if we want this, because it will be a change in behaviour from traditional TTD, since now bridgeheads will not be fully affected by bridge speed limits. And your patch still misses the required changes to the pathfinder.
Hafting wrote:Game crash bug, savegame cannot load.
Thanks for your bug report. However, I lack one of your newgrf files, namely TGrandom.grf, and I cannot seem to find it anywhere. Can you tell me where I can get it?
Hafting wrote:When is cargodist considering re-fits then? If it perform the tests while the train is at the station in question, then it is possible to check how the wagon is set up at the moment and what re-fits are possible.
Refits are considered when routing cargo, and the problem is that cargodist cannot possibly know in advance if a refit is allowed at a station or not: the newgrf that provides the vehicle is queried at the precise moment that the refit is attempted, and is free to reply whatever it wants, such as to allow it only when the day of the month is a prime number. Insane, but that is how it works.
Attachments
refit.png
refit.png (6.06 KiB) Viewed 2703 times
Eddi
Tycoon
Tycoon
Posts: 8257
Joined: 17 Jan 2007 00:14

Re: New map features

Post by Eddi »

is there really any harm to apply the speed limit only while in the wormhole, not on the bridge head at all?

to me this seems cleaner than some wizardry with whch path is taken through the tile.
User avatar
HackaLittleBit
Director
Director
Posts: 550
Joined: 10 Dec 2008 16:08
Location: tile 0x0000

Re: New map features

Post by HackaLittleBit »

Ok I saw it. (GetSpeedLimit())
svn 4987
\yapf\follow_track.hpp
line 196 ... 222
KUDr = author

As far as I can understand, you don't do the same cost calculation for road vehicles on bridge head as in trunk.(if (IsRoadTT()) spd *= 2;)
true?
Makes me wonder what a track finder has to do with speed limits?
I need time to investigate better.
Gosh they manage to complicate things! ?(
User avatar
cirdan
Director
Director
Posts: 539
Joined: 07 Apr 2007 18:08

Re: New map features

Post by cirdan »

HackaLittleBit wrote:As far as I can understand, you don't do the same cost calculation for road vehicles on bridge head as in trunk.(if (IsRoadTT()) spd *= 2;)
true?
The pathfinder code in openttd is crippled with bugs, particularly with respect to bridges. Trains will happily choose a longer route over a sequence of short slow bridges rather than a direct route over a single faster bridge. Road vehicles will only get a penalty for using a bridge if doing so forces them to less than half of their maximum speed. And NPF is even worse. You will see large discrepancies between openttd code an mine in this area.
HackaLittleBit wrote:Makes me wonder what a track finder has to do with speed limits?
The pathfinder applies a penaly for using slow bridges, so that vehicles will try to avoid them.
Post Reply

Return to “OpenTTD Development”

Who is online

Users browsing this forum: Amazon [Bot] and 10 guests