JGR's Patch Pack

[Nathkel]

A couple more Feature Requests for the patchpack:

Colored Load-by-type and Unload-by-type entries: In the Load/Unload-by-type windows, the list can be hard to read esp. if the list of cargo types is long. It would be great if the cargo and action text were colored so that its easier to peruse the list of our load modifications.

For example, "No loading" or "No unloading" would be in red, "Transfer" could be in yellow, "if accepted [available]" would be in green, and "Load [unload] all" could be in white.

Default Load/Unload by type actions: i would love to be able to choose a default action for loading and loading by cargo type. For example, if we, say, Ctrl-clicked "Full load" in the Load-by Cargo-Type window, "Full Load" would automatically fill the list whenever we opened this window.

[Nathkel]

[sorry for double-posting, but my previous post was about Feature Requests with this patch pack, while this post is about a bug I found using JGRPP.]

Got pretty far into a game, and found out about the wonders of Load-by-type orders. But a situation popped up that frustrated my use of this feature.

An industry was generated on the map by OTTD, so i went to make use of the production. The mine was superfluous and far away from the industries that could use its respurces, and would require a series of transfers between existing rail lines. I went backwards and adjusted the orders of all the trains that would pick up the cargo (by simply adding a "load if available order" at the pickup point and a "transfer" at the drop off of the next leg), then finally created a new train and station at the mine to begin the process of transporting.
Since I found load-by-type works wonders, I initially set up the new train with a load-by-type order for that particular cargo, as well as a "refit to available cargo" order. I let each train run their leg to establish the route that the cargo would take, but after a few months of checking each transport segment to make sure the orders were right, the cargo was still not being produced. The only thing that was new that I hadn't done before was using load-by-type on a brand new station with a brand new train. So I had a hunch that was the problem...
So I changed the refit order to a fixed cargo (the one that should be produced), let it run, and apparently that was the problem.

So in my opinion, this is a bug in which the load-by-type order cannot be used to start production at an industry.

[PikkaBird]

So in my opinion, this is a bug in which the load-by-type order cannot be used to start production at an industry.

Yes, you'll need to explicitly refit a vehicle to initialise a service, as you describe. But it's not a bug - if available refit could start production, you'd far more often find your trains running around full of the wrong cargo. Imagine, for example, what would happen if the game spawned a new industry, that produced a different cargo that your wagons can refit to, in the catchment of an existing station?

[Nathkel]

Ok good.. so its not a bug, just not a setting.

It's rather unlikely that production at a "surprise" industry would start on a load-by-type train unless there was a complete line from primary industry to receiving industry, which would not be a bad thing — the transport would "auto-generate!"

I think it would be far more useful as a setting, since the odds of accidentally creating a transport line is far less important than allowing load-by-type orders to initiate production.

[Walter Novotny]

I have a question:
Is there a calculator or formulas for calculating in Excel, which I can use to calculate the speed of the train on the route without running the test train every time?

For example, a train with 2719 horsepower, a maximum tractive force of 276 kN, a mass of 696 tons and a maximum speed of 125 km/h.

In the game settings, we will turn on all physics options to realistic and the acceleration scaling to 30% and the slope gradient to 4%.
Driving on a slope with a steepness of 1 up to 3 forward, it will maintain a speed of 67 km/h.

This train needs to travel 65 fields on flat terrain to reach a speed of 120 km/h.

[ino]

I have a question:
Is there a calculator or formulas for calculating in Excel, which I can use to calculate the speed of the train on the route without running the test train every time?

For example, a train with 2719 horsepower, a maximum tractive force of 276 kN, a mass of 696 tons and a maximum speed of 125 km/h.

In the game settings, we will turn on all physics options to realistic and the acceleration scaling to 30% and the slope gradient to 4%.
Driving on a slope with a steepness of 1 up to 3 forward, it will maintain a speed of 67 km/h.

This train needs to travel 65 fields on flat terrain to reach a speed of 120 km/h.

There is an explanation on the Wiki: https://wiki.openttd.org/en/Manual/Game ... cle-speeds

In addition to those, you also need to know the weight of each train wagon, the gradient profile of the route, and the air drag value of the engine (which isn't shown in the UI).

Which is extremely complicated calculation.

If you can assume constant speed the formula is (d*16*256)/(2v) where d is distance in tile and v is velocity in km-ish/s. I normally assume constant top speed s and acceleration distance a, which result in a formula of ((d-a)*16*256)/(2v) + a*16*256/v.

[peter1138]

Ok good.. so its not a bug, just not a setting.

Well there is a setting. `set order.selectgoods false` will cause output from industries to go to stations without requiring collection of that type first.

[xxxvinniexxx]

I now always use the conditional load order of 50% before my trains can go further with the route. Is there a wat to automate this? Maybe a setting to make full load 50% in stead of 100%?

[MagicBuzz]

Hello,

Using 0.60.2 JGRPP, I have a strange behaviour with acceleration model or something like that.
Don't know really what happen.

My regular trains look like to run at full speed without any problem.

But my TGV aren't.
I rebuilt the speed railway with unlimited speed tracks.
The trains should be powerful enough to run at full speed.

But as soon as they reach 200 kmph they slow down around 190, then accelerate again to 200 and so on.
They should run at 270 kmph.


You'll find attached a copy of my save game.

-- Edit : I removed all signals from the track the TGV use. It was very strange because CTRL + drag & drop wasn't able to remove all the signals, and the behaviour when placing new signals : ctrl + drag wasn't "planting" signal all the way. Now the TGV can run at 270 kmph. It looks like something is messing around with signals and train speed adaptation.

[ino]

Hello,

Using 0.60.2 JGRPP, I have a strange behaviour with acceleration model or something like that.
Don't know really what happen.

My regular trains look like to run at full speed without any problem.

But my TGV aren't.
I rebuilt the speed railway with unlimited speed tracks.
The trains should be powerful enough to run at full speed.

But as soon as they reach 200 kmph they slow down around 190, then accelerate again to 200 and so on.
They should run at 270 kmph.
[youtube=https://youtu.be/RGbKitToWMM[/youtube]

You'll find attached a copy of my save game.

There is a reason "Realistic braking is aspect limited" setting is marked with "Expert, Difficult". Your signal on the line has 3 aspects, which mean the train can only reserve path up to 3 sections ahead (hence "aspect limited"). Which mean your top speed is limited by the train braking capacity -- as the train need to be able to come to a stop within the distance of reserved section.

If you disable this setting, then the train will reserve enough sections ahead so that it can reach its top speed.

[Walter Novotny]

Would it be possible to increase the distance limit between automatically deployed semaphores to a minimum of 40-50 fields? Such distances will allow traffic to be conducted on high-speed lines.

[JGR]

Hello,

Using 0.60.2 JGRPP, I have a strange behaviour with acceleration model or something like that.
Don't know really what happen.

My regular trains look like to run at full speed without any problem.

But my TGV aren't.
I rebuilt the speed railway with unlimited speed tracks.
The trains should be powerful enough to run at full speed.

But as soon as they reach 200 kmph they slow down around 190, then accelerate again to 200 and so on.
They should run at 270 kmph.
...

You'll find attached a copy of my save game.

-- Edit : I removed all signals from the track the TGV use. It was very strange because CTRL + drag & drop wasn't able to remove all the signals, and the behaviour when placing new signals : ctrl + drag wasn't "planting" signal all the way. Now the TGV can run at 270 kmph. It looks like something is messing around with signals and train speed adaptation.

Using mechanical sempahores for TGVs seems a bit odd in general...

If you want to continue with these settings, you should use a more reasonable signal spacing.
Alternatively you can use a signal GRF which provides extra signal types with different aspect limits/propagation behaviour.
JP+ Signal Extensions has a Shinkansen marker type which is intended for this sort of use case (pretending to use ETCS-type signalling).

Would it be possible to increase the distance limit between automatically deployed semaphores to a minimum of 40-50 fields? Such distances will allow traffic to be conducted on high-speed lines.

I think if 20 tiles is too small a gap between signals, you're probably better off picking and choosing where you want your signals to go anyway,

[OzTrans]

Quite a few issues ...

a) Callback 0x13 for Roadstops and Waypoints no longer works. All fine in v0.60.0, but no longer in v0.61.0. All stops and waypoints are enabled when CB 13 returns 0x00. The exceptions are items that have the flag 'Only show in road build menu' or 'Only show in tram build menu' set [compare images below].

b] Roadstop Draw Mode, bit 2 does not work; groundsprite is never shown, if bit enabled.

c) Roadstop General Flags, bit 8 : 'Read the road stop draw mode from variable 0x100' does not work for waypoints [see below, circled waypoints].

Road Waypoints v0.60.0.png (28.63 KiB) Viewed 518 times

Road Waypoints v0.61.0.png (27.38 KiB) Viewed 518 times

We would have far less cluttered construction menus, if disabled items were NOT SHOWN AT ALL.

Many more issues to come ...

[JGR]

Quite a few issues ...

a) Callback 0x13 for Roadstops and Waypoints no longer works. All fine in v0.60.0, but no longer in v0.61.0. All stops and waypoints are enabled when CB 13 returns 0x00. The exceptions are items that have the flag 'Only show in road build menu' or 'Only show in tram build menu' set [compare images below].

b] Roadstop Draw Mode, bit 2 does not work; groundsprite is never shown, if bit enabled.

c) Roadstop General Flags, bit 8 : 'Read the road stop draw mode from variable 0x100' does not work for waypoints [see below, circled waypoints].

We would have far less cluttered construction menus, if disabled items were NOT SHOWN AT ALL.

Many more issues to come ...

I have sent a PR upstream for the availability callback.

I tried bit 2 of the road stop draw mode and bit 8 of the general flags, and they appeared to work as expected.

[Quast65]

We would have far less cluttered construction menus, if disabled items were NOT SHOWN AT ALL.

As an Eyecandy player, I disagree.
I like to be able (via the date-cheat) to still place "historical" stuff and see in advance what is available.
I do say yes though to an option in the settings to en-/disable the availability of disabled items, as I can see that for non-eyecandy players it can be annoying.

[OzTrans]

I tried bit 2 of the road stop draw mode and bit 8 of the general flags, and they appeared to work as expected.

Well, they don't ...

I am talking about Road Waypoints and NOT Road Stations. Below, a sample, the Container Terminal is a STATION and the other a WAYPOINT. Bit 8 of general flags set and 0x00 in register 0x100 works for the station but not for the waypoint; i.e. the road tile still shows below the custom menu sprite ...

Road Station vs Waypoint.png (53.88 KiB) Viewed 383 times

If bit 2 of road draw mode is set, it does NOT display the given ground sprite for the waypoint. Initially I defined the ground sprite as building sprite, but doing that makes RVs going under the ground sprite, even when set as 16 x 16 x 0. This is the very first time I used this approach.

As an Eyecandy player, I disagree.
I like to be able (via the date-cheat) to still place "historical" stuff and see in advance what is available.
I do say yes though to an option in the settings to en-/disable the availability of disabled items, as I can see that for non-eyecandy players it can be annoying.

Yes, a setting to disable showing of unavailable waypoints/stations would be the way to go. See well above, the only two waypoints available are for the '6-lane express way' and none of the others are suitable for this road type, all marked with a red cross to make it clear.

The 'ALL' button could be used to show all waypoints/stations (including the disabled ones). I do show additional info for those who want that, like year available from (if the arrow is on the left, it means station was available until).

Road Station Menu.png (23.16 KiB) Viewed 383 times

[JGR]

I tried bit 2 of the road stop draw mode and bit 8 of the general flags, and they appeared to work as expected.

Well, they don't ...

I am talking about Road Waypoints and NOT Road Stations. Below, a sample, the Container Terminal is a STATION and the other a WAYPOINT. Bit 8 of general flags set and 0x00 in register 0x100 works for the station but not for the waypoint; i.e. the road tile still shows below the custom menu sprite ...

The road sprite is supposed to be drawn, it is a road waypoint, and can only be built on a road tile, and other than routing is functionally equivalent to a road segment.
See here for the documentation: https://newgrf-specs.tt-wiki.net/wiki/A ... e_.280C.29
At no point has it been advertised that changing the draw mode will turn the road off.

[Redirect Left]

So big oof!

I accidentally opened a scenario in JGR patchpack and slightly edited it and resaved it. So vanilla OTTD now is like "newer version, can't open so sorry not sorry not even going to try". To my knowledge i didn't use anything exclusive to the JGR pack. Is this a salvageable situation to remove the JGRPP attribution, or has it now actually added data to the scenario file that isn't removable back to vanilla?

[JGR]

So big oof!

I accidentally opened a scenario in JGR patchpack and slightly edited it and resaved it. So vanilla OTTD now is like "newer version, can't open so sorry not sorry not even going to try". To my knowledge i didn't use anything exclusive to the JGR pack. Is this a salvageable situation to remove the JGRPP attribution, or has it now actually added data to the scenario file that isn't removable back to vanilla?

The savegame formats are sufficiently different that it would be impractical to modify it or vanilla to be able to read it.
By default, there's a warning dialog which specifically mentions this when you try to overwrite a vanilla savegame.

[Redirect Left]

By default, there's a warning dialog which specifically mentions this when you try to overwrite a vanilla savegame.

Well, I guess that is what I get for blindly accepting any messages produced, I blame constantly clicking on cookie permissions on websites, its desensitized me and I just don't read any of them things.
Thankfully it wasn't near completion anyway, nor was i that committed to finishing it, so not big loss. Thanks for replying anyway.