New map features

[TrueSatan]

Thanks jgr
Here is the usual Ubuntu 14.04 64bit version of the trace restriction "branch"
No updated version for the original cirdan trunk,
because it was the windows only fix

Cheers

[cirdan]

No updated version for the original cirdan trunk, because it was the windows only fix

Not quite... it was a fix for compiling the code without SSE support. But it is true that, if you compiled the code fine without last commit, then it will not make a difference for you.

[Hafting]

I have just pushed an update with (hopefully) a fix for your bug. Thanks for your report!

I have not seen the problem again - thanks!
I believe I see some different behaviour, though:

Consider a train picking up a natural resource at A. Then it goes to B, C and D before returning to A to pick up more.
B and C do both want to process the A-cargo, and turn it into more valuable cargo. D is a city that will take everything produced.

If I don't use refits, then the A-cargo will be brought to both B and C. Initially, everything will be consumed at B, (as long as A produce cargo for "any station") but as soon as cargodist provides destinations, there will be a near-50% split between stuff to B and stuff to C.

But I use re-fits, the train that brings in sand/stone can also take building material out in the empty cars. Similar for trains bringing timber, they can also bring goods/building material out.

So my trains have these orders:
Go to A, full load with refit to A-stuff
Go to B, re-fit to B-products (accepts A-stuff)
Go to C, re-fit to C-products (accepts A-stuff)
Go to D (where they accept B-products and C-products)

Usually, A.-stuff is never brought to C when I start the first train with orders like that. I can wait, but apparently, the re-fit at B means that cargodist never plans to bring A-stuff through station B.

I can get around this by cancelling the re-fit at B for a little while. Then, A-stuff destined for C is produced and loaded onto trains. After that, I can re-enable the re-fit at B - and A-stuff for destination C will be produced. Everything will work as intended - with one train (or set of trains) bringing A-stuff to both B and C, and take their cargoes to D.

Bringing cargo from B to D is never a problem, even with the re-fit at C. I believe this is so because C does not accept B-products, so the initial B-products "for any station" are not unloaded at C. But cargo from A to C never happens (unless I allow this to start by temporarily cancelling a re-fit) because B is capable of processing all the A-stuff and then the entire train is re-fit to B-products.

But I don't want this - B is closer to the source and pay less for cargo than C - and the C-products are needed in my world too. Having to do temporary order changes in order to "start" some route is extra trouble - especially if the chain of stations are much longer than this simple example. Also, there is the risk that the ability to transport stuff A-C is "forgotten" if the trains suffer a long-lasting gridlock. (Bad management, sure. But then I'll have to cancel re-fits again - in addition to fix whatever caused the lockup.)

Another fix I can do, is to explicitly re-fit to "B-products and A-suff" at station B. It is an acceptable solution in this case, but could lead to some long re-fit lists for trains that service lots of stations. Re-fits just to make sure cargo is brought past some point, even though that station doesn't make such cargo.


So, is this how cargodist must work now? Or is it possible for cargodist to consider "what if not all cargo is unloaded at B - are there further accepting stations down the line"? That already seems to work for stuff brought from B to D (past the re-fit at C, with the one difference being that C doesn't eat B-products.) It would make things easier, I believe.

[cirdan]

I have not seen the problem again - thanks!

Nice to know, and thanks for testing.

I believe I see some different behaviour, though:

[...]

So, is this how cargodist must work now?

Yes, this is an indirect consequence of the fix for the other issue. You should treat the refit set as the set of cargo types that the vehicle is allowed to leave the station with, rather than just those that the vehicle is allowed to refit to if it does refit at all. It is a subtle difference, but it means that, if you really want to allow a vehicle to keep whatever cargo type it was carrying when it arrived at the station, you should explicitly add it to the refit set. Otherwise, the cargodist code will not notice that cargo can be carried forward from a previous station and will not create a demand for it.

[KeldorKatarn]

I scanned the thread for a bit but didn't find this question answered. Sorry if I missed it, but 48 pages is a bit much and the front post doesn't mention it.

Is it planned to also add signals on bridges? So far they seem to only allow signals on the bridge heads while tunnels have full signal simulation going on it seems. Any reason for this and is is planned for later? Also this seems to have grown into a full fork... what are the plans to integrate this into trunk?

[cirdan]

Is it planned to also add signals on bridges? So far they seem to only allow signals on the bridge heads while tunnels have full signal simulation going on it seems. Any reason for this and is is planned for later?

Yes, as long as you only want plans. The reason why we have signals in tunnels but not on bridges is that they were easier to add. Signals in tunnels did not require much storage in the map array: just a signal on the exit side and possibly another one on the entry side. There are no real signals inside the tunnel—trains just slow down if they come too close to the train ahead—but this is not a problem as they would not be visible anyway. Bridges are different in that the bridge head can already be a full-blown rail tile, so any additional signals would have to be placed in the middle section (the "wormhole"), not on the head. And, since bridges are out in the open, I really think that there should be some visual feedback as trains traverse them (signals turning red and green), instead of the magical behaviour that we get in tunnels.

Also this seems to have grown into a full fork... what are the plans to integrate this into trunk?

That is a question for the openttd developers to answer. But, seeing the interest that they show in fixes for openttd bugs that I develop along the way [1] [2], I would say that there are no plans at all.

[Gremnon]

Perhaps have a look at how it's handled in JGR's patchpack? It has signals on bridges as well. Granted it doesn't have the problem here where the bridgehead can be a full rail tile, but might it at least offer some insights?

[te_lanus]

how difficultwould it be to add this patch to this branch?

[cirdan]

You mean signals on bridges? I have not looked into the patch in detail, but I am afraid that it would be quite a bit of work. For a start, bridges are stored in a different way in my fork, so you no longer have as many free bits in the map array to store extra data. In fact, bridge heads can already be full rail tiles, so any additional signalling on the bridge must be done in the middle part, and this has a serious impact on signal updates and the pathfinder. It can be done, but it is far from straightforward.

[te_lanus]

You mean signals on bridges? I have not looked into the patch in detail, but I am afraid that it would be quite a bit of work. For a start, bridges are stored in a different way in my fork, so you no longer have as many free bits in the map array to store extra data. In fact, bridge heads can already be full rail tiles, so any additional signalling on the bridge must be done in the middle part, and this has a serious impact on signal updates and the pathfinder. It can be done, but it is far from straightforward.

oops sorry,seems the forum ate my linky
[patch] Terminus Airports v1.44 (r27460)

[TrueSatan]

Yeah the Airport stuff looks nice. But I fear it will be some major work as well, because of
the modifications Cirdan did.

But if then I would vote for that patch as well, even if I lose JGR's signal patch then.
I guess JGR won't update his patch for Cirdan's branch anymore.

Cheers and nice to see you back Cirdan

[JGR]

But if then I would vote for that patch as well, even if I lose JGR's signal patch then.
I guess JGR won't update his patch for Cirdan's branch anymore.

If people want me to do an update I can do so, and otherwise there's nothing stopping anyone else from doing it. Some minor features are unlikely to be supported due to architectural differences however.
I may choose to integrate that airport patch in my own branch when it is finished.

[TrueSatan]

Yeah I seen that you wrote it looks unfinished to you.
Btw. update... I have seen that you updated your patch JGR.
Not sure if those updates to route restriction are needed.

Anyway I am happily running my cirdan/jgr patched game
nearly every evening and had no issues so far

Thanks you two for your big efforts on the game.

Cheers

[JGR]

Btw. update... I have seen that you updated your patch JGR.
Not sure if those updates to route restriction are needed.

I went ahead and updated the branch anyway. The only new features are related to the recolouring of signal posts, the rest is some minor bug fixes.
The long/through reserve features aren't included as they have an excessive number of merge conflicts.

[TrueSatan]

I went ahead and updated the branch anyway. The only new features are related to the recolouring of signal posts, the rest is some minor bug fixes.
The long/through reserve features aren't included as they have an excessive number of merge conflicts.

Thanks JGR, Currently compiling in the background, will post the ubuntu executable l8er.

The reverse feature was nice (tried it with my windows machine once) but it was hard to
set it up the right way. So I wouldn't use it anyway.


Cheers

[TrueSatan]

Here is my Ubuntu 14.04 64bit version
from the cirdan-jgr patch.

Cheers

edit: removed because it carshed

[TrueSatan]

Hmm got a crash yesterday, so this is a placeholder for the crashlog coming this evening.
Not sure what happened, but i can't scroll to a certain region anymore.

Okay i checked the version before g869c939f-tracerestrict
and even the save made with the new version works fine there.
So something has changed with the newest patches from JGR.

Here is the crashlog, with the savegame that crashes.
If you need anything just let me know JGR

Thanks

Edit: Found it. It signals on bridgeheads that’s crashing the game. Start any new game, build a bridge and place a signal on the bridgehead.
It crashes then

[wallyweb]

I went ahead and updated the branch ...

... and we have the unguaranteed Win32 binary:

OpenTTD-g2e32d381-tracerestrict-cirdan-Win32.7z

(5.47 MiB) Downloaded 65 times

I had no issues with crashes when scrolling, BUT
Use with caution pending the outcome of TrueSatan's crash report.

[JGR]

Edit: Found it. It signals on bridgeheads that’s crashing the game. Start any new game, build a bridge and place a signal on the bridgehead.
It crashes then

This should be fixed now, it was a bad merge conflict resolution on my part.

[wallyweb]

This should be fixed now ...

... and we have the unguaranteed Win32 binary:

OpenTTD-ge6310d07-tracerestrict-cirdan-Win32.7z

(5.47 MiB) Downloaded 69 times

Enjoy.