marioxcc wrote:When I hold CTRL and use the mouse wheel, the viewport does not change. I expected that it would switch to the enhanced viewport mode as described in viewtopic.php?f=33&t=53394.
It works for me. Are you sure you are in extended zoom where it looks like a minimap? It only works in that mode, not at the normal zoom level.
marioxcc wrote:The “Day length factor” setting is limited to odd numbers. I can not set it to 2 for example.
You can. Just click on the number, and it would allow you to enter any number (From 1 to 125)
marioxcc wrote:Apparently cargo production per month is scaled by the day length factor, but maintenance costs are not. How can I make maintenance costs scale too?
You can't. Not sure if this is intended or not.
marioxcc wrote:I do not understand the “Wall clock” settings. Is it documented anywhere? How does it interact with “Day length factor”?
I don't think it was documented anywhere, as it is just what it is called. It just convert your display to 24-hour clock format, which looks nice in departure board. That's it. It does not change anything else at all. Everything still works under the original day-month-year system, just that the display changed. The setting isn't even store in save, so it is global for your game.
It works for me. Are you sure you are in extended zoom where it looks like a minimap?
Ok. I had to increase the max zoom level to 128 to enable this. I did not know that it was only supposed to work when zoomed out a lot and I had max. zoom out set to 8.
I don't think it was documented anywhere, as it is just what it is called. It just convert your display to 24-hour clock format,
Oh, so are the “wall time” settings entirely cosmetic?
ok, now i tried for 2 days to add the clipboard to this patchpack for win64, gained more knowhow about compilers and stuff but i am still unable to play with clipboard (copy and paste for tracks) enabled. Is there a friendly player with knowledge in here who can add the clipboardpatch and compile this pack for me?
Is it me or are "Scheduled Departures" and "Conditional Stops" incompatible with one another? I'm trying to have my trams and buses depart in regular intervals but as soon as a vehicle skips an empty bus/tram stop it is massively delayed the moment it stops at the stop after. This completely clogs up my cities and there is nothing I can do about it it seems. I don't care about their arrival times at the first/final stop, as long as they depart according to my time table... but alas, it doesn't work. Attached is one of the many examples in my current game I'm struggling with.
Am I doing something wrong here or am I doing things that were never intended?
Xaxa wrote:Is it me or are "Scheduled Departures" and "Conditional Stops" incompatible with one another? I'm trying to have my trams and buses depart in regular intervals but as soon as a vehicle skips an empty bus/tram stop it is massively delayed the moment it stops at the stop after. This completely clogs up my cities and there is nothing I can do about it it seems. I don't care about their arrival times at the first/final stop, as long as they depart according to my time table... but alas, it doesn't work. Attached is one of the many examples in my current game I'm struggling with.
Am I doing something wrong here or am I doing things that were never intended?
I imagine you would run into a lot of problems trying to do conditional orders of those types.
If scheduled dispatch didn't require a timetable otherwise (so dispatch every 5 days, run flat out until you get back to the first order, even if other orders are untimetabled) this kind of conditional setup would probably work better, but it doesn't seem to be the case presently (scheduled dispatch doesn't work unless the timetable is complete).
Xaxa wrote:Is it me or are "Scheduled Departures" and "Conditional Stops" incompatible with one another? I'm trying to have my trams and buses depart in regular intervals but as soon as a vehicle skips an empty bus/tram stop it is massively delayed the moment it stops at the stop after. This completely clogs up my cities and there is nothing I can do about it it seems. I don't care about their arrival times at the first/final stop, as long as they depart according to my time table... but alas, it doesn't work. Attached is one of the many examples in my current game I'm struggling with.
Am I doing something wrong here or am I doing things that were never intended?
I imagine you would run into a lot of problems trying to do conditional orders of those types.
If scheduled dispatch didn't require a timetable otherwise (so dispatch every 5 days, run flat out until you get back to the first order, even if other orders are untimetabled) this kind of conditional setup would probably work better, but it doesn't seem to be the case presently (scheduled dispatch doesn't work unless the timetable is complete).
I run into problems using any conditional orders, really. Indeed because it gets rid of the complete timetable, which is quite frustrating as all the info for a complete timetable is there.
Normally I would simply expect the trams to be running ahead of schedule when they enter the stop after the conditional one, and that they just wait longer to run on schedule again. Ideally you could let them run ahead of schedule and only have them wait extra long at specific stops. Neither of these situations are the case and they run into major delays skipping a stop when they only have a scheduled departure time at their first stop. So I guess I can currently only do conditional stops /or/ scheduled dispatches, which is a bit sad. I'll live though, but I wonder if they'll ever be able to work together.
eisenbahner wrote:ok, now i tried for 2 days to add the clipboard to this patchpack for win64, gained more knowhow about compilers and stuff but i am still unable to play with clipboard (copy and paste for tracks) enabled. Is there a friendly player with knowledge in here who can add the clipboardpatch and compile this pack for me?
The clipboard patch is not compatible. You would need to expend significant effort to make it work correctly with other features in this patchpack.
marioxcc wrote:Oh, so are the “wall time” settings entirely cosmetic?.
Yes, they just change the way that times/dates are displayed locally, and what units are used to display/edit timetables and so on.
The underlying time units are the same.
Xaxa wrote:I run into problems using any conditional orders, really. Indeed because it gets rid of the complete timetable, which is quite frustrating as all the info for a complete timetable is there.
Normally I would simply expect the trams to be running ahead of schedule when they enter the stop after the conditional one, and that they just wait longer to run on schedule again. Ideally you could let them run ahead of schedule and only have them wait extra long at specific stops. Neither of these situations are the case and they run into major delays skipping a stop when they only have a scheduled departure time at their first stop. So I guess I can currently only do conditional stops /or/ scheduled dispatches, which is a bit sad. I'll live though, but I wonder if they'll ever be able to work together.
Conditional orders definitely don't work with timetable auto-separation as the timetable length is not fixed.
Other timetable features seem like they could plausibly work with conditional orders, though I have not done any testing.
Only timetabling the first station wait (which you do the schedule dispatch on), might work?
Could you upload a savegame with your setup that you used for the screenshot, and I'll take a look?
JGR wrote:Conditional orders definitely don't work with timetable auto-separation as the timetable length is not fixed.
Other timetable features seem like they could plausibly work with conditional orders, though I have not done any testing.
Only timetabling the first station wait (which you do the schedule dispatch on), might work?
Could you upload a savegame with your setup that you used for the screenshot, and I'll take a look?
Yeah sure, I hope you have a way to deactivate newgrfs though for testing because I've scavenged all of the internet for some of the ones I play with (and there's quite a few ones). That's the reason why I initially didn't post the save file. If I can do that somehow to make life easier for you, you can let me know too and I'll get rid of the newgrfs for you.
Just fyi, these are the vehicle groups that have conditional stops /and/ scheduled departures (all belong to company #2: Connexxion):
- RB 1
- RB 2 (this one has quite a few)
- SVz 1
- SVz 2
- SVz 3 (only one each way)
- SVz 4
I got rid of the conditional stops with the other trams as it was bothering me.
Scautura wrote:I've been getting really frustrated with not being able to play OpenTTD because of the Fall update and the right click/mouse drag issues it brings. I normally play this patch pack, so I've tried compiling my own, and even without making the required code changes, I get errors while trying to compile (specifically in btree.h, due to a COMPILE_ASSERT, after I've fixed all the other errors by using the openttd-useful file containing Windows includes/libraries) JGRPP, that I don't get when compiling vanilla (which gives me linker errors, but that's an entirely different kettle of fish).
What am I missing/doing wrong? I've tried with MSVC 2017 (14.1) and MSVC 2015 (14.0), and while I installed versions of MingW (Cygwin64 and MingW-w64), my Posix style compilation abilities verge on the non-existent.
Edit: More detail on the errors; 190 errors, 95 copies of variations of this pair (the only difference being the "compiling source file"):
Error C2672 'btree::btree<Params>::key_compare_checker': no matching overloaded function found (compiling source file ..\src\cargomonitor.cpp)
openttd c:\users\me\documents\github\openttd-patches\src\3rdparty\cpp-btree\btree.h 1396
Error C2118 negative subscript (compiling source file ..\src\cargomonitor.cpp)
openttd c:\users\me\documents\github\openttd-patches\src\3rdparty\cpp-btree\btree.h 1396
Edit2: I've fixed my issues with linking Vanilla OTTD, so I can build Vanilla without issues. I'd prefer a "fixed" version of JGRPP (so used to many of the extras that I can't even think of them compared to Vanilla, routing restrictions and signals on bridges and tunnels being the only ones that come to mind)
Edit3: Commenting out that assert allows it to compile (I don't believe it's causing problems, but my C++ is rusty enough to not know enough to say with absolute 100% certainty), but now getting linker errors (similar to the ones I got when building Vanilla, but my same solution didn't fix linking JGRPP) as attached.
Edit4: Nope, way over my head!
Edit5: Tried again with Cygwin/MingW-w64, which tells me that it can't find "src/endian_check.cpp" - which is a load of poppycock. I'm really not destined to get this working!
Edit6: Last one I swear! I actually got it compiled and working using Linux and MXE to cross compile. Yay!
Note that this is the very quick'n'dirty fix from the post in "Problems". It works, but there may be issues (I haven't come across any in the time I've been playing). It's also 64bit (I didn't compile a 32 bit version, but I'll double check)
Duct tape is like the Force - it has a Dark side, a Light side, and it holds the universe together.
JGR wrote:Conditional orders definitely don't work with timetable auto-separation as the timetable length is not fixed.
Other timetable features seem like they could plausibly work with conditional orders, though I have not done any testing.
Only timetabling the first station wait (which you do the schedule dispatch on), might work?
Could you upload a savegame with your setup that you used for the screenshot, and I'll take a look?
Yeah sure, I hope you have a way to deactivate newgrfs though for testing because I've scavenged all of the internet for some of the ones I play with (and there's quite a few ones). That's the reason why I initially didn't post the save file. If I can do that somehow to make life easier for you, you can let me know too and I'll get rid of the newgrfs for you.
Just fyi, these are the vehicle groups that have conditional stops /and/ scheduled departures (all belong to company #2: Connexxion):
- RB 1
- RB 2 (this one has quite a few)
- SVz 1
- SVz 2
- SVz 3 (only one each way)
- SVz 4
I got rid of the conditional stops with the other trams as it was bothering me.
I've done some initial testing and the effect where vehicles become unexpectedly late does not require the use of scheduled dispatch, only conditional orders.
It seems that after the conditional order jump the scheduled arrival time at the station which has been jumped to is the same as the scheduled departure time of the station before the jump (i.e. the timetabled travel time for conditional order jumps is 0).
Of course the real travel time is not 0 and so the vehicle becomes behind schedule.
In the case where conditional order jumps are not taken, timetabling seems to work fine.
I will look into a solution/workaround, but this may take some time.
Scautura wrote:I've been getting really frustrated with not being able to play OpenTTD because of the Fall update and the right click/mouse drag issues it brings...
cmhbob wrote:Here's some research I did WRT the panning issue and Windows FCU.
Trunk committed a fix for this yesterday. I've published a new release (v0.22.1) which includes this commit.
I don't have a Windows 10 system available, but I presume the trunk commit addresses the issue.
Scautura wrote:I've been getting really frustrated with not being able to play OpenTTD because of the Fall update and the right click/mouse drag issues it brings...
cmhbob wrote:Here's some research I did WRT the panning issue and Windows FCU.
Trunk committed a fix for this yesterday. I've published a new release (v0.22.1) which includes this commit.
I don't have a Windows 10 system available, but I presume the trunk commit addresses the issue.
In the "more conditional orders" patch there is the "percent of times' option. According to the original thread linked to on that, this is deterministic, so if you set it to 50 percent it will take the conditional every second time.
From playing around with this, this is the case, however there seems to be a counter for each individual train, rather than the shared order group. As such the obvious uses of this conditional in splitting routes into branches, are not fully realised.
What I'm wanting to do with this conditional is not actually branching, but just using it to maintain spacing without timetables. So I take a station near the middle of my route, and use the 50% conditional order so that trains coming into the station are alternately directed to go one direction, then the other. Hence if two trains get too close to each other due to natural bunching, it's likely they will get split up into opposite directions when they hit this central station. This could easily be extended to a central hub with multiple branching routes all under a single shared order list, indeed you could have your entire passenger network under a single shared order list though that might be a bit much. You could also vary from the 50% to give higher frequencies on certain sections of your lines.
(Alternatively, what other mechanisms are there for getting a system that does this sort of thing? A randomised "percent of times" setting would crudely achieve the same goal, not quite as efficiently. If conditional orders interacted with slots I imagine you could set something up which has this sort of effect, not as easily though. It's probably possible to use logic trains (a flip-flop?) to interact with the "waiting platforms" conditional order but it would be complex and clumsy.)
JGR wrote:Conditional orders definitely don't work with timetable auto-separation as the timetable length is not fixed.
Other timetable features seem like they could plausibly work with conditional orders, though I have not done any testing.
Only timetabling the first station wait (which you do the schedule dispatch on), might work?
Could you upload a savegame with your setup that you used for the screenshot, and I'll take a look?
Yeah sure, I hope you have a way to deactivate newgrfs though for testing because I've scavenged all of the internet for some of the ones I play with (and there's quite a few ones). That's the reason why I initially didn't post the save file. If I can do that somehow to make life easier for you, you can let me know too and I'll get rid of the newgrfs for you.
Just fyi, these are the vehicle groups that have conditional stops /and/ scheduled departures (all belong to company #2: Connexxion):
- RB 1
- RB 2 (this one has quite a few)
- SVz 1
- SVz 2
- SVz 3 (only one each way)
- SVz 4
I got rid of the conditional stops with the other trams as it was bothering me.
I've done some initial testing and the effect where vehicles become unexpectedly late does not require the use of scheduled dispatch, only conditional orders.
It seems that after the conditional order jump the scheduled arrival time at the station which has been jumped to is the same as the scheduled departure time of the station before the jump (i.e. the timetabled travel time for conditional order jumps is 0).
Of course the real travel time is not 0 and so the vehicle becomes behind schedule.
In the case where conditional order jumps are not taken, timetabling seems to work fine.
I will look into a solution/workaround, but this may take some time.
Thanks for looking into it! I have an error log now as well for you in case you're interested. The error pop-up I got playing specifically mentioned the JGR pack, so yeah.
Attached is the game that crashes as well. Crash at 11.54 (at least when game is sped up.) In the screenshot the game crashed at 10.54, so I think the bug may be activated by the departure of one of my vehicles at xx.54.