Transport Tycoon Forums

Ship sailing sideways , firts turn in right direction few seconds before dock

Good idea with improved station ratings - albeit it is possible to do via newgrf, it is not trivial to make such newgrf addon for existing industries (for example, FIXES have some glitches: fruit are called food), thus such hardcoded feature is much more convenient.
However relying on cargo classes is not precise, for example WOOD deserve to be treated like any other primary cargo,
but it is piece_goods, not bulk, in contrary to WDPR in FIRS, which is also bulk - you would get better rating for secondary than for primary.
I suggest to add WOOD as an exception to those with reduced effect of cargo waiting.

skummel wrote:Ship sailing sideways , firts turn in right direction few seconds before dock

Gordon & Co., 31-01-1925.png

Thanks for reporting this, this issue has been fixed already though, it'll be in the next release.

McZapkie wrote:Good idea with improved station ratings - albeit it is possible to do via newgrf, it is not trivial to make such newgrf addon for existing industries (for example, FIXES have some glitches: fruit are called food), thus such hardcoded feature is much more convenient.
However relying on cargo classes is not precise, for example WOOD deserve to be treated like any other primary cargo,
but it is piece_goods, not bulk, in contrary to WDPR in FIRS, which is also bulk - you would get better rating for secondary than for primary.
I suggest to add WOOD as an exception to those with reduced effect of cargo waiting.

I don't believe that this is possible via NewGRFs, or at least it doesn't appear to apply to this particular path.
Cargo classes are not precise, but they are better than nothing. I don't really want to be in the business of whitelisting arbitrary cargo labels or maintaining my own cargo classes.
My primary motivation for this was for station ratings to more realistically reflect the differing service interval requirements between passengers and freight.

Not sure if someone else has mentioned this but I've run into an issue on the most recent version of JGR pp. When I set the day length factor to 40 and try to use scheduled dispatch, my vehicles arrive at the first stop and are declared to be apx 900000000 minutes early. I haven't tested this with other day length factors.
The period of the timetable is 60 minutes. If you need any other info on this possible issue, I can find a save.

Gwyd wrote:Not sure if someone else has mentioned this but I've run into an issue on the most recent version of JGR pp. When I set the day length factor to 40 and try to use scheduled dispatch, my vehicles arrive at the first stop and are declared to be apx 900000000 minutes early. I haven't tested this with other day length factors.
The period of the timetable is 60 minutes. If you need any other info on this possible issue, I can find a save.

Thanks for reporting this issue, it looks like one which has been fixed already though.
It will be in the next release,

JGR wrote:

Gwyd wrote:Not sure if someone else has mentioned this but I've run into an issue on the most recent version of JGR pp. When I set the day length factor to 40 and try to use scheduled dispatch, my vehicles arrive at the first stop and are declared to be apx 900000000 minutes early. I haven't tested this with other day length factors.
The period of the timetable is 60 minutes. If you need any other info on this possible issue, I can find a save.

Thanks for reporting this issue, it looks like one which has been fixed already though.
It will be in the next release,

I thought it was fixed in 0.29.1? (Unless it was a different issue) But the symptom does sound like the same integer overflow bug.

I would like to report a bug
Steps to reproduce - Programmable signals are constantly red. If I do not delete the signal, but only change the normal combined signal, it then works as programmable. Everything is OK and the signal works
Version of OpenTTD - JGR 0.29.2
Platform - Windows 7 64b, LinuxMint 18.3; download version JGR 21.february 2019; on Linux own compilation, on Windows download from web
Game file: programmable-signals-bug

ino wrote:

JGR wrote:

Gwyd wrote:Not sure if someone else has mentioned this but I've run into an issue on the most recent version of JGR pp. When I set the day length factor to 40 and try to use scheduled dispatch, my vehicles arrive at the first stop and are declared to be apx 900000000 minutes early. I haven't tested this with other day length factors.
The period of the timetable is 60 minutes. If you need any other info on this possible issue, I can find a save.

Thanks for reporting this issue, it looks like one which has been fixed already though.
It will be in the next release,

I thought it was fixed in 0.29.1? (Unless it was a different issue) But the symptom does sound like the same integer overflow bug.

Perhaps a savegame would be a good idea so that I can take a closer look.

nirasa wrote:I would like to report a bug
Steps to reproduce - Programmable signals are constantly red. If I do not delete the signal, but only change the normal combined signal, it then works as programmable. Everything is OK and the signal works
Version of OpenTTD - JGR 0.29.2
Platform - Windows 7 64b, LinuxMint 18.3; download version JGR 21.february 2019; on Linux own compilation, on Windows download from web
Game file: programmable-signals-bug

Can you clarify what the problem is?
There are no programmable signals in the savegame.
What are you trying to achieve with programmable signals?

nirasa wrote:I would like to report a bug
Steps to reproduce - Programmable signals are constantly red. If I do not delete the signal, but only change the normal combined signal, it then works as programmable. Everything is OK and the signal works
Version of OpenTTD - JGR 0.29.2
Platform - Windows 7 64b, LinuxMint 18.3; download version JGR 21.february 2019; on Linux own compilation, on Windows download from web
Game file: programmable-signals-bug

JGR wrote:Can you clarify what the problem is?
There are no programmable signals in the savegame.
What are you trying to achieve with programmable signals?

I have a station, but I just want passengers to follow the first track. The second track is for cargo only.
Sorry for my english.

JGR wrote:There are no programmable signals in the savegame.

Programmable signals on the my map exist, but they look like combined. In the Signal panel, set Routefinding restrictions, then click one of the combined signals. Please.

nirasa wrote:Programmable signals on the my map exist, but they look like combined

why is that? there are 2 unused signal sprites in every base set that could be used here.

nirasa wrote:Programmable signals on the my map exist, but they look like combined

Eddi wrote:why is that? there are 2 unused signal sprites in every base set that could be used here.

That's the mistake. If I use original programmable signals, they do not work. They are permanently red. If I don't delete them, but only change from the signal panel to normal combined signals, they work! I click on the normal combination signal with Sprocket (Routefinding restrictions), I can change the commands.

nirasa wrote:

nirasa wrote:Programmable signals on the my map exist, but they look like combined

Eddi wrote:why is that? there are 2 unused signal sprites in every base set that could be used here.

That's the mistake. If I use original programmable signals, they do not work. They are permanently red. If I don't delete them, but only change from the signal panel to normal combined signals, they work! I click on the normal combination signal with Sprocket (Routefinding restrictions), I can change the commands.

nirasa wrote: I have a station, but I just want passengers to follow the first track. The second track is for cargo only.
Sorry for my english.

Programmable signals and routing restrictions are completely orthogonal features.
Of these, routing restrictions are what you would use for controlling access depending on the properties of trains.

JGR wrote:Programmable signals and routing restrictions are completely orthogonal features.
Of these, routing restrictions are what you would use for controlling access depending on the properties of trains.

Ok, thank's.

Hello

once again a have a wish.

isit possible to have a second Starttime or a Returntime?
for example:
A train go from A to Z and back from Z to A
At Station A i can say Start at time xx
At Station Z i only can say wait min xx but not go back at time xx

and

a split to changing Staytime at Stations and Waypoints
so that you can change the Staytime at all Stations at once but not on the Waypoints or change all Waypoints but not the Staions

Thanks
Vanderbildt

Question - zoning patch doesn't seem to work in scenario editor, and the house placement patch only works in scenario editor.

Any chance of getting zoning patch to work in scenario editor so we can figure out what houses to place where?

kamnet wrote:Question - zoning patch doesn't seem to work in scenario editor, and the house placement patch only works in scenario editor.

Any chance of getting zoning patch to work in scenario editor so we can figure out what houses to place where?

Also note that in the house placement tool gui, the zone numbers are the reverse of what is described in the NewGRF Specs.
EDIT: Also, the correct range is 0 to 4, not 1 to 5.

I have a feature request. Is it possible to add a "remove train from slot" in the slot management GUI? It would make fixing a mess with slot way, way easier. Thank you in advance.

ino wrote:I have a feature request. Is it possible to add a "remove train from slot" in the slot management GUI? It would make fixing a mess with slot way, way easier. Thank you in advance.

You can do this by drag and dropping the train out of the slot, into all trains.

JGR wrote:

ino wrote:I have a feature request. Is it possible to add a "remove train from slot" in the slot management GUI? It would make fixing a mess with slot way, way easier. Thank you in advance.

You can do this by drag and dropping the train out of the slot, into all trains.

Didn't know that. Thank you!