JGR's Patch Pack
Moderator: OpenTTD Developers
Re: JGR's Patch Pack
I understand that, and I have consider using that before. But that methods get really cumbersome when the number of groups running through a line get higher (>10) This also required all of the split to be re-programmed if new groups are added (which can be very frequent imo)
Re: JGR's Patch Pack
Hello,
Is there any chance to see "Grass on rails" patch in future?
Thanks.
Is there any chance to see "Grass on rails" patch in future?
Thanks.
Ask, and it shall be given you.
Seek, and ye shall find.
Knock, and it shall open unto you.
Seek, and ye shall find.
Knock, and it shall open unto you.
Re: JGR's Patch Pack
The train never leaves the platforumino wrote:You mean to canceled a previously reserve path? I do not think that can be done. However, if you describe how you want your train to behave (preferably without wall of text) people might be able to help signal it.
Code: Select all
Go non-stop to Station A (No loading) [near end] and wait for 30 minutes.
Travel for 4 minutes. <----- RESERVE PATH NOW
Go non-stop to Station A [far end] and wait for 4 minutes.
I can solve the possibility of deadlocks but i've never had once since i set up my timetables correctly so i wouldn't bother.
----------------
Great explanation of the features of Scheduled dispatch btw!
Re: JGR's Patch Pack
JGR previously stated he wasn't going to add this patch due to technical reasons. See: viewtopic.php?p=1171307#p1171307eshield wrote:Is there any chance to see "Grass on rails" patch in future?
Also, from the first post in the topic, that patch is actually stripped out when importing games created with Spring Patch Pack (which does include that patch). So I don't think it's going to get reconsidered.
Do you like drones, quadcopters & flying toys? Check out Drone Strike Force!
Base Music Sets: OpenMSX | Scott Joplin Anthology | Traditional Winter Holiday Music | Modern Motion Music
Other Projects: 2CC Trams | Modern Waypoints | Sprite Sandbox & NewGRF Releases | Ideabox | Town Names | Isle of Sodor Scenario | Random Sprite Repository
Misc Topics: My Screenshots | Forgotten NewGRFs | Unfinished Graphics Sets | Stats Shack | GarryG's Auz Sets
Base Music Sets: OpenMSX | Scott Joplin Anthology | Traditional Winter Holiday Music | Modern Motion Music
Other Projects: 2CC Trams | Modern Waypoints | Sprite Sandbox & NewGRF Releases | Ideabox | Town Names | Isle of Sodor Scenario | Random Sprite Repository
Misc Topics: My Screenshots | Forgotten NewGRFs | Unfinished Graphics Sets | Stats Shack | GarryG's Auz Sets
Re: JGR's Patch Pack
Not sure if this is a bug report or a feature request, so here goes.
The dispatch scheduler is a little dodgy when the first order is to go to a depot. The only way to get trains to stay in the depot until their scheduled departure time is to manually enter a length of time to stay in the depot (which must be greater than 0). If no time is entered, the trains go in the depot, get maintenance, and leave no matter how far they are away from scheduled departure. Also, when the modifier Go To Depot (Stop) is selected, the trains will not ever leave unless prompted.
The dispatch scheduler is a little dodgy when the first order is to go to a depot. The only way to get trains to stay in the depot until their scheduled departure time is to manually enter a length of time to stay in the depot (which must be greater than 0). If no time is entered, the trains go in the depot, get maintenance, and leave no matter how far they are away from scheduled departure. Also, when the modifier Go To Depot (Stop) is selected, the trains will not ever leave unless prompted.
Perhaps a dropdown menu with a list of station stops leading to the grid UI for scheduled departures? Not sure how difficult that would be.You currently cannot set the scheduled time for anything other than the first waiting order. This is not implementation limitation, but rather I cannot think of a UI to do that without being confusing and fragile. It is also a feature I want (being able to release train on schedule on both end of the terminus etc.), so if you have any idea regarding UI feel free to post.
Re: JGR's Patch Pack
The OTTD vehicle code does not allow trains to wait at any points that do not have wait time explicitly defined (including waiting when it arrive early). It only allow waiting at orders that has wait time explicitly timetabled, which, IIRC, in vanilla OTTD, stations are the only order that can have wait time timetabled. This patch pack (JGR patch pack) add an ability to time the waiting time in depot, but by default it is not timetabled at all, thus unless I muck around with the core vehicle code, it is not easily solvable.p4nzer wrote:The dispatch scheduler is a little dodgy when the first order is to go to a depot. The only way to get trains to stay in the depot until their scheduled departure time is to manually enter a length of time to stay in the depot (which must be greater than 0). If no time is entered, the trains go in the depot, get maintenance, and leave no matter how far they are away from scheduled departure.
However, you can actually enter "0" waiting time at the depot, and while the timetable windows displays same thing, the waiting time is now explicitly timetabled and the train would wait there as you expected.
In case that the first depot order is not explicitly timetabled, the schedule dispatch would dispatch from the first station instead. (Technically, it would dispatch from the first order that has waiting time explicitly timetabled)
Hope this clears up confusion.
I believe that is the desired behaviour? If the train is stopped, you wouldn't want it to leave on schedule?p4nzer wrote:Also, when the modifier Go To Depot (Stop) is selected, the trains will not ever leave unless prompted.
Thank for the idea. Though I think the next release of the scheduled dispatch patch will allow scheduling at any stations, including multiple stations. Already have something in mind.p4nzer wrote:Perhaps a dropdown menu with a list of station stops leading to the grid UI for scheduled departures? Not sure how difficult that would be.
Re: JGR's Patch Pack
Is it possible for NotRoadTypes to be included at some point? As far as I am aware, NotRoadTypes is kept up-to-date with Trunk anyway, and I don't think there are any real differences aside from being able to use roadtypes. Theoretically, all it'd require is using NotRoadTypees as the base of the Patch Pack instead of Trunk. (I would compile it myself, but I've never been able to get OpenTTD to compile even without patching it.
Re: JGR's Patch Pack
Ino, I must compliment you on your amazing patch. OpenTTD is practically a whole different game with it enabled. I can't wait to see where it goes in the future!
Re: JGR's Patch Pack
Ino, i am pretty sure this is related to scheduled dispatches.
The train in question was cloned from another train with an already established scheduled dispatch. To where i then changed the clone's orders to a completely different route.
I was about to enable scheduled dispatches for the clone but as i opened that i already saw it was enabled (obviously, since it's a clone) but before i had a chance to change anything the game hung in an endless loop.
One of my cores is constantly working hard while the game remains unresponsive.
There's no related crash dumps or logs for this occurrence because the game hung, it did not crash.
EDIT: And i would love to give you a savegame but again, because of many custom GRF's, it's going to be difficult at best without breaking a license along the way. Besides, the last savegame i have was prior to the issue even being possible. Running the game at daylength factor 16 and the issue cropping up in June with autosave every 12 months. The game hasn't hung or crashed for me since 2015.
The train in question was cloned from another train with an already established scheduled dispatch. To where i then changed the clone's orders to a completely different route.
I was about to enable scheduled dispatches for the clone but as i opened that i already saw it was enabled (obviously, since it's a clone) but before i had a chance to change anything the game hung in an endless loop.
One of my cores is constantly working hard while the game remains unresponsive.
There's no related crash dumps or logs for this occurrence because the game hung, it did not crash.
EDIT: And i would love to give you a savegame but again, because of many custom GRF's, it's going to be difficult at best without breaking a license along the way. Besides, the last savegame i have was prior to the issue even being possible. Running the game at daylength factor 16 and the issue cropping up in June with autosave every 12 months. The game hasn't hung or crashed for me since 2015.
Re: JGR's Patch Pack
Thank you for the report. That is very weird. Yes it is definitely schedule dispatched related. Duration time of "zero" definitely freezes the game (because when it try to calculate the schedule in the current time, duration time of "0" will not get it anywhere at all). Maybe I should safeguard that loop, but I thought I protected all possible circumstance of having zero duration (You cannot set it via the UI, for instance.)Cadde wrote:Ino, i am pretty sure this is related to scheduled dispatches.
Would you mind explaining the exact step you did since cloning this vehicle? I have my hunch on where it could happen, but exact steps would help. Did, after cloning a train, clone an order from another vehicle?
Re: JGR's Patch Pack
The original train had a bunch of orders, auto timetabling on and scheduled dispatch with a duration of 720 minutes.
I cloned the original train, removed the orders (i only wanted the train setup with locos and wagons) and set new orders elsewhere with auto timetabling on and scheduled dispatch untouched, A.K.A still on as they were set on the clone. I believe the fact that removing all orders on a vehicle will nullify the duration.
As soon as i felt i had a good timetable autofilled i went to check the dispatches and wham, forever loop.
Also, when i code i generally check inputs where they are going to be used. But if there's any form of UI involved i also check them at the source, not because of code safety but because of user information.
And if i am really picky about it, i sanity check at every entry and exit point of a variable. I.E, where it can change and where it's being used. But only if i am making a production worthy piece of code. Which i never (or rarely) waste my time with on public releases.
I cloned the original train, removed the orders (i only wanted the train setup with locos and wagons) and set new orders elsewhere with auto timetabling on and scheduled dispatch untouched, A.K.A still on as they were set on the clone. I believe the fact that removing all orders on a vehicle will nullify the duration.
As soon as i felt i had a good timetable autofilled i went to check the dispatches and wham, forever loop.
Also, when i code i generally check inputs where they are going to be used. But if there's any form of UI involved i also check them at the source, not because of code safety but because of user information.
And if i am really picky about it, i sanity check at every entry and exit point of a variable. I.E, where it can change and where it's being used. But only if i am making a production worthy piece of code. Which i never (or rarely) waste my time with on public releases.
Re: JGR's Patch Pack
That is even more weird. Deleting all order and re-creating should not make that happen. I have test that scenario a few time already. Can you be more specific about what you do?
Specifically, I have not test it, but I am very sure now that cloning an order (NOT train) from another vehicle, when cloning vehicle has scheduled dispatch on, and it does not matter if the cloned vehicle has it on or not, would result in the same result you have got.
For now, as an immediate fix, please disable schedule dispatch before performing such action.
Also, the reason validation is not performed is because a duration of 0 is an UNDEFINED state for schedule dispatch. It should never happen, ever. What I mean by putting safeguard is to properly crash if it happen anyway.
Specifically, I have not test it, but I am very sure now that cloning an order (NOT train) from another vehicle, when cloning vehicle has scheduled dispatch on, and it does not matter if the cloned vehicle has it on or not, would result in the same result you have got.
For now, as an immediate fix, please disable schedule dispatch before performing such action.
Also, the reason validation is not performed is because a duration of 0 is an UNDEFINED state for schedule dispatch. It should never happen, ever. What I mean by putting safeguard is to properly crash if it happen anyway.
Re: JGR's Patch Pack
I reproduced it. I had to add a departure slot on the cloned train as well.
Re: JGR's Patch Pack
And that is why I ask you to say exactly step-by-step, because I cannot reproduce it with your instruction at all. Beginning when you clone the train, please?
Re: JGR's Patch Pack
Fine, do this:
It hangs when the cloned train arrives at the first station in it's orders, after it's made a round trip.
Or this:
It hangs when i press enter after inputting 0 while adding a departure slot on the cloned train.
I've attached the last video's savegame. No GRF's loaded.
It hangs when the cloned train arrives at the first station in it's orders, after it's made a round trip.
Or this:
It hangs when i press enter after inputting 0 while adding a departure slot on the cloned train.
I've attached the last video's savegame. No GRF's loaded.
- Attachments
-
- Reedfield Transport, 2010-01-07.sav
- Should hang when you add a departure slot to train 2.
- (78.77 KiB) Downloaded 48 times
Re: JGR's Patch Pack
Thank you for a detailed reproduction. Identified and fixed in my branch.
I never knew that you can delete all orders that way. I have always been deleting each item separately. That is why I cannot reproduce (yes, in case you wonder, two different ways result in a very different internal game state) because it works fine if it is done the way I do it.
Unfortunately, in this case, the scheduled dispatch config will be cleared (because the structure holding this information is cleared). Will see what can I do.
I am sorry I cannot provide a build for you because I cannot cross-compile to Windows from Linux right now.
I never knew that you can delete all orders that way. I have always been deleting each item separately. That is why I cannot reproduce (yes, in case you wonder, two different ways result in a very different internal game state) because it works fine if it is done the way I do it.
Unfortunately, in this case, the scheduled dispatch config will be cleared (because the structure holding this information is cleared). Will see what can I do.
I am sorry I cannot provide a build for you because I cannot cross-compile to Windows from Linux right now.
Re: JGR's Patch Pack
At some point I may look into this. It would probably require some non-trivial effort to merge it in.sstabeler wrote:Is it possible for NotRoadTypes to be included at some point? As far as I am aware, NotRoadTypes is kept up-to-date with Trunk anyway, and I don't think there are any real differences aside from being able to use roadtypes. Theoretically, all it'd require is using NotRoadTypees as the base of the Patch Pack instead of Trunk. (I would compile it myself, but I've never been able to get OpenTTD to compile even without patching it.
I would not rebase on top of NotRoadTypes, I don't see that that would be beneficial. If it were to be included I'd do an ordinary 3-way merge in the same way that most other external branches have been merged.
Thanks, this is also updated and merged in my repo now, it'll be in the next release.ino wrote:Thank you for a detailed reproduction. Identified and fixed in my branch.
I tend to use exit destinations and/or waypoints for this sort of thing, by using the "next order" conditional.ino wrote:I understand that, and I have consider using that before. But that methods get really cumbersome when the number of groups running through a line get higher (>10) This also required all of the split to be re-programmed if new groups are added (which can be very frequent imo)
Ex TTDPatch Coder
Patch Pack, Github
Patch Pack, Github
Re: JGR's Patch Pack
The Send Money feature appears to not be working for me. If I try to type in any number, it returns this error message:
This despite the fact that I have no loans and clearly enough money to spare.
This despite the fact that I have no loans and clearly enough money to spare.
Re: JGR's Patch Pack
Are you running in single-player or multi-player?p4nzer wrote:The Send Money feature appears to not be working for me. If I try to type in any number, it returns this error message:
This despite the fact that I have no loans and clearly enough money to spare.
It looks like money transfers are rejected in single-player mode.
Edit:
This is fixed and will be in the next release.
Ex TTDPatch Coder
Patch Pack, Github
Patch Pack, Github
Re: JGR's Patch Pack
This looks quite suspiciously like a typo: https://github.com/JGRennison/OpenTTD-p ... e.cpp#L182
Shouldn't it be:
power_temp should be multiplied by 746 for HP to Watts, not 74,611. The end of the corrected line has double L's for "long long int" as used further up in the function. Right?
Code: Select all
power = power_temp * 74611;
Code: Select all
power = power_temp * 746ll;
Who is online
Users browsing this forum: No registered users and 20 guests