Have a look in the graphics development forum - "Station Ratings". I'm having a go at providing a newgrf that does the job.Mizari wrote:It's removed in the latest FIRS. The default ratings is terrible.Pyoro wrote:Isn't it also a parameter in FIRS? Maybe make a little GRF with that feature. Shouldn't be too difficult to c&p the code.
JGR's Patch Pack
Moderator: OpenTTD Developers
Re: JGR's Patch Pack
Re: JGR's Patch Pack
Hello, I found an annoying problem with planes :
With improved breakdowns patch enabled, planes break down to 0 km/h mid-air. It seems to happen only with WAS planes.
If you want, here is a savegame :
With improved breakdowns patch enabled, planes break down to 0 km/h mid-air. It seems to happen only with WAS planes.
If you want, here is a savegame :
- Attachments
-
- BUG.sav
- (31.7 KiB) Downloaded 56 times
Re: JGR's Patch Pack
Thanks for reporting this, I'll look into it.Jyratos wrote:Hello, I found an annoying problem with planes :
With improved breakdowns patch enabled, planes break down to 0 km/h mid-air. It seems to happen only with WAS planes.
If you want, here is a savegame :
Edit: This is now fixed and will be in the next release.
Ex TTDPatch Coder
Patch Pack, Github
Patch Pack, Github
Re: JGR's Patch Pack
JGR, can you please look this?
viewtopic.php?f=26&t=30188&p=1170135#p1170129
I"m having the same problem, maybe it's a Patch bug? (ECS no Tourist appearing)
viewtopic.php?f=26&t=30188&p=1170135#p1170129
I"m having the same problem, maybe it's a Patch bug? (ECS no Tourist appearing)
Re: JGR's Patch Pack
This is due to the town cargo generation factor patch, and so has been present in every jgrpp release to date.nihues wrote:JGR, can you please look this?
viewtopic.php?f=26&t=30188&p=1170135#p1170129
I"m having the same problem, maybe it's a Patch bug? (ECS no Tourist appearing)
I'm slightly surprised that no-one has noticed it until now, then again I suppose most players don't use ECS.
This is fixed now and will be in the next release.
Ex TTDPatch Coder
Patch Pack, Github
Patch Pack, Github
Re: JGR's Patch Pack
Great package! I know this is probably a long shot and probably a little bit niche but have you ever considered this patch?
viewtopic.php?f=33&t=63721
As I said, a bit niche, but I like it because it allows for timetable creation with arrival and departure 'dates'as opposed to time elapsed at a stop. It currently uses days and I don't know if it can be adapted to ticks or the clock face. Also since the 'wait in depot' got added it's done something weird to road vehicles and depots. I've tried poking around but I got lost pretty easily.
viewtopic.php?f=33&t=63721
As I said, a bit niche, but I like it because it allows for timetable creation with arrival and departure 'dates'as opposed to time elapsed at a stop. It currently uses days and I don't know if it can be adapted to ticks or the clock face. Also since the 'wait in depot' got added it's done something weird to road vehicles and depots. I've tried poking around but I got lost pretty easily.
Re: JGR's Patch Pack
Without looking at the code yet, it sounds like there is a lot of overlap with timetable patches already included in the patchpack.le_harv wrote:Great package! I know this is probably a long shot and probably a little bit niche but have you ever considered this patch?
viewtopic.php?f=33&t=63721
As I said, a bit niche, but I like it because it allows for timetable creation with arrival and departure 'dates'as opposed to time elapsed at a stop. It currently uses days and I don't know if it can be adapted to ticks or the clock face. Also since the 'wait in depot' got added it's done something weird to road vehicles and depots. I've tried poking around but I got lost pretty easily.
I don't think it would be practical to merge that on top of the existing patches.
Is some kind of timetable padding mechanism what you'd be looking for?
Ex TTDPatch Coder
Patch Pack, Github
Patch Pack, Github
Re: JGR's Patch Pack
Really the core mechanism that I am looking for is to do with how you create a schedule. So OpenTTD in it's current format does time tables like this:JGR wrote: Without looking at the code yet, it sounds like there is a lot of overlap with timetable patches already included in the patchpack.
I don't think it would be practical to merge that on top of the existing patches.
Is some kind of timetable padding mechanism what you'd be looking for?
- Stay at station for 15 days
- Travel for 10 days
- Stay at station for 5 days
What the aforementioned patch does in it's current state is operate more like an actual schedule. You select 'dates' for the vehicle to arrive so lets say you timetable starts on 01/01/00 your would set a departure time for 15/01/00. Then because it should take ten days to travel you can set expected arrival at the next station as 25/01/00 with a departure of 30/01/00. Now in this example. If the train took 12 days to travel instead of 10 it will arrive 27/01/00 but still leave 30/01/00.
I hope that makes sense.
Re: JGR's Patch Pack
The behaviour in trunk is already that if a vehicle arrives late or early, it will make up time or wait to meet the timetable.le_harv wrote: Really the core mechanism that I am looking for is to do with how you create a schedule. So OpenTTD in it's current format does time tables like this:
Now if the train takes 12 days to travel it's still going to wait for 5 days at the station when it gets there.
- Stay at station for 15 days
- Travel for 10 days
- Stay at station for 5 days
What the aforementioned patch does in it's current state is operate more like an actual schedule. You select 'dates' for the vehicle to arrive so lets say you timetable starts on 01/01/00 your would set a departure time for 15/01/00. Then because it should take ten days to travel you can set expected arrival at the next station as 25/01/00 with a departure of 30/01/00. Now in this example. If the train took 12 days to travel instead of 10 it will arrive 27/01/00 but still leave 30/01/00.
I hope that makes sense.
In your example, the train would wait for 3 days at the station, if it arrived 2 days late.
If you set the start date for the timetable, and then the arrival time for say the last entry, how does that work for intermediary entries?
Are your set times relative to the previous entry or is something more clever going on? If it's the former it boils down to a different UI to set timetable entries. If you adjust an arrival date, are subsequent entries bumped?
Ex TTDPatch Coder
Patch Pack, Github
Patch Pack, Github
Re: JGR's Patch Pack
This is slightly awkward. You're absolutely right. My apologies for not noticing that.JGR wrote: The behaviour in trunk is already that if a vehicle arrives late or early, it will make up time or wait to meet the timetable.
In your example, the train would wait for 3 days at the station, if it arrived 2 days late.
If you set the start date for the timetable, and then the arrival time for say the last entry, how does that work for intermediary entries?
Are your set times relative to the previous entry or is something more clever going on? If it's the former it boils down to a different UI to set timetable entries. If you adjust an arrival date, are subsequent entries bumped?
As to the second part, there is a autofill function that sets the other stops relative to the start date however there is the added dimension of actually picking the date for departure. You can choose the exact date for departure as opposed to setting length of stay to manipulate that departure date, for example. If you change a date the others aren't affected as you have to set a total timetable length at the beginning.
Your system is quite intuitive. I will play around some more, thanks for pointing it out to me.
Re: JGR's Patch Pack
JGR, how much would i have to bribe you/twist your arm to include the Yellow Path Signals patch, (its an optional parameter in advanced settings that modifies standard PBS signals).
viewtopic.php?f=33&t=74451
I believe its just an extension of the long reserve patch you have already included
viewtopic.php?f=33&t=74451
I believe its just an extension of the long reserve patch you have already included
Re: JGR's Patch Pack
Integrating this brings up a lot of questions about behaviour and edge cases which haven't really been addressed IMO.Leanden wrote:JGR, how much would i have to bribe you/twist your arm to include the Yellow Path Signals patch, (its an optional parameter in advanced settings that modifies standard PBS signals).
viewtopic.php?f=33&t=74451
I believe its just an extension of the long reserve patch you have already included
I don't think it really makes sense to include this without also including something like YAAM, which also raises again the question of what to do with block signals, as the current behaviour does not make sense.
As the various block/pre signals are fairly useless in a yellow PBS/YAAM environment, I'd be inclined to think more radically about signal types.
As for integration with the long reserve feature, as the yellow signals patch effectively turns it on by default, there needs to be some non-tedious way to turn it off on a per-signal basis.
If I did merge it, it would have to be off by default as it would cause havoc if unexpectedly enabled on an existing game.
Either way, a significant amount of thought/more development needs to occur before it would be sensible to merge this sort of behaviour.
Ex TTDPatch Coder
Patch Pack, Github
Patch Pack, Github
Re: JGR's Patch Pack
Oh absolutely i would have it off by default. I wasnt aware of YAAM, what is that?
Re: JGR's Patch Pack
Leanden wrote:Oh absolutely i would have it off by default. I wasnt aware of YAAM, what is that?
Fun with SPADs!
Re: JGR's Patch Pack
This: viewtopic.php?f=33&t=74482Leanden wrote:Oh absolutely i would have it off by default. I wasnt aware of YAAM, what is that?
Ex TTDPatch Coder
Patch Pack, Github
Patch Pack, Github
Re: JGR's Patch Pack
Ooo ill have to look into that.
Looking at the other patches in your pack i cant see anything that would conflict with yellow PBS, even programmable signals sits on its own signal ID, and the leftover id could be used to input the MAS signals and still keep the standard path signals in game?
Looking at the other patches in your pack i cant see anything that would conflict with yellow PBS, even programmable signals sits on its own signal ID, and the leftover id could be used to input the MAS signals and still keep the standard path signals in game?
Re: JGR's Patch Pack
Having read over YAAM i would personally leave it out if i was including yellow pbs, as that is severely changing a core aspect of the game, A LOT more than reserving 3 signals instead of 1
Re: JGR's Patch Pack
Hello JGR, I'm having a crash. It started in 1977 and almost 20 years later with no crashes, got again, and now got an autosave days earlier of the crash. All attached.. Dunno if i'ts related to your patchpack. Using lastest 0.13.3.
Here is the code crash.log
Here is the code crash.log
- Attachments
-
- Openttd JGR crash dump.zip
- first crash, recovered, no crash after sav.
- (648.36 KiB) Downloaded 55 times
-
- autosave-3-crash.sav
- second crash, always crash days later, same error as first crash....
- (188.25 KiB) Downloaded 53 times
Last edited by nihues on 17 Jun 2016 22:38, edited 1 time in total.
Re: JGR's Patch Pack
started a save 1 year before the 2nd crash and it crashed on 1st Jan 1994. Same error.
EDIT: probably could be a NewGRF error. But what NewGRF?
https://bugs.openttd.org/task/3683
EDIT: probably could be a NewGRF error. But what NewGRF?
https://bugs.openttd.org/task/3683
Who is online
Users browsing this forum: No registered users and 15 guests