![Smile :)](./images/smilies/icon_smile.gif)
Here is the usual Ubuntu 14.04 64bit version of the trace restriction "branch"
![Smile :)](./images/smilies/icon_smile.gif)
No updated version for the original cirdan trunk,
because it was the windows only fix
![Smile :)](./images/smilies/icon_smile.gif)
Cheers
Moderator: OpenTTD Developers
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.TrueSatan wrote:No updated version for the original cirdan trunk, because it was the windows only fix
I have not seen the problem again - thanks!cirdan wrote:I have just pushed an update with (hopefully) a fix for your bug. Thanks for your report!
Nice to know, and thanks for testing.Hafting wrote:I have not seen the problem again - thanks!
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.Hafting wrote:I believe I see some different behaviour, though:
[...]
So, is this how cargodist must work now?
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.KeldorKatarn wrote: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?
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.KeldorKatarn wrote:Also this seems to have grown into a full fork... what are the plans to integrate this into trunk?
oops sorry,seems the forum ate my linkycirdan wrote: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.
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.TrueSatan wrote: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.
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.TrueSatan wrote: Btw. update... I have seen that you updated your patch JGR.
Not sure if those updates to route restriction are needed.
Thanks JGR, Currently compiling in the background, will post the ubuntu executable l8er.JGR wrote: 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.
... and we have the unguaranteed Win32 binary: I had no issues with crashes when scrolling, BUTJGR wrote:I went ahead and updated the branch ...
This should be fixed now, it was a bad merge conflict resolution on my part.TrueSatan wrote: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
... and we have the unguaranteed Win32 binary: Enjoy.JGR wrote:This should be fixed now ...
Users browsing this forum: Bing [Bot] and 0 guests