Understanding factory goods consumption/production

[R1dO]

I'm a bit puzzled here.

As far as i understand factory production works like:
Given that a factory that has:
* A base_production of 100 units/month
* Consumption is 300% for an input (oil)
* Production is 60% for an output (chemicals)
I'd expect it to use 300 oil and produce 60 chemicals

However in my current game (Chemical-Plant.png) it is more like:
* Consuming: 400% (100 + 300)
* Producing:   160% (100 + 60)

To make matter worse another factory (that has 100% for production), Sawyers Workshop.png), the original understanding holds up.

What am i missing here?

P.s. The attached .ods file holds the numbers as displayed in the graphs (remove the .txt extention, needed to bypass forum restrictions)

[An_dz]

The thunder sign at the top right corner shows you're giving electrical energy to the first factory and electricity boosts the factory production.

[R1dO]

Are you saying that if electricity is provided more is created for the same input?
E.g. in chemical screenshot:
* chemical 60% ->acts as: chemicals 120%
* inkt 30% ->acts as: inkt 60%
* oil 300% -> still acts as: oil 300%

Because i was in the understanding that boosts are related to base_production (e.g. amount of oil consumed as well as chems produced) goes up.
E.g. in chemical screenshot:  "Max, 2040 units/moth" instead of the initial "Max, 1972 units/month"

On a side-note:
Electricity should not be active on this factory. No electricity provider is available on the map (and the year is 1891).
Double checked it in the graph window for "Power (Mw) [Usage/Output]" , and this shows 0 for each month (as expected)

[Matthew]

The electricity icon looks greyed-out to me.

[ceeac]

Is the Chemical Plant connected to your passenger/mail network? Passengers or mail also boost production if I understand this correctly.

[R1dO]

It is connected to both passengers and mail yes.
The productivity graph ([Production:] under the tab Production/Boost) also show it is boosted. So far so good.

What i fail to understand is how it would impact the production modifiers on the consumed/produced goods, they are no longer in line with the percentages shown directly after the good names on the images.
In this case Chemicals is off by 2, e.g. if the graphs are true (which seem to be the case when looking at consumption rate of connected pharmacies) i'd expected the image to say:

Code Select Expand


Production:
- Chemicals 120% : ...


Thank you all for your input though .. i appreciate trying to help here.

[makie]

A base_production of 100 units/month

all boosts increase the production per month
production = base +  boosts electricity + boosts passenger + boosts mail

[R1dO]

Thank you for confirming my understanding of a factory's production rate (e.g. units per month).

The thing what is left is how this "production" (using the terminology from your post) relates to "goods produced" and "goods consumed".

In my understanding:

Code Select Expand


goods consumed = production * input_factor
goods produced = production * output_factor


e.g for this factory:

Code Select Expand


oil consumed = production * 300% = production * 3
Printer ink produced = production * 30% = production * 0.3  # None produced in this case, since it is not connected to a supplier.
Chemicals produced = production * 60% = production * 0.6  # According to info display, when looking at graphs it is: production * 120 %


[makie]

In my understanding:

Code Select Expand


goods consumed = production * input_factor
goods produced = production * output_factor


this is my understanding too

e.g for this factory:

Code Select Expand


oil consumed = production * 300% = production * 3
Printer ink produced = production * 30% = production * 0.3  # None produced in this case, since it is not connected to a supplier.
Chemicals produced = production * 60% = production * 0.6  # According to info display, when looking at graphs it is: production * 120 %


I understand, the oil consume looks like 400%
can you show the production at the "production / boost tab"?

[R1dO]

Added 2 images (due to high production rate the boosts wouldn't be visible otherwise)

Regarding the 400% oil usage, that is also possible. If you look at the attached .ods file from the initial post i identified 2 possible scenarios for this factory:

1) Oil consumption is 300% but chemicals production is 120%
2) Oil consumption is 400% and chemical production is 160%

[makie]

OK
I'm just a bit confused at the production in the chart about 2200
this is the maximum production and not as i think the real production

may be there works something different with just_in_time=2, as i am used to

the boosts are not so high to change the result significant

in wiki they say: do not use imputfactor and outputfactor together
https://simutrans-germany.com/wiki/wiki/tiki-index.php?page=de_FactoryDef#zus_tzliche_Parameter_f_r_factory

i understand the problem
i looking for the real production, as a base for the calculation
maybe this is a error in the programm

[Leartin]

in wiki they say: do not use imputfactor and outputfactor together

Not quite, it says "if you use them together, they might counteract each other". Thats because if both are above or below 100%, they partly cancel each other and might as well be changed to use 100% on either. Eg. if you have a base productivity of 100 units, input 200%, output 150%, you might as well change it to a base productivity of 200 units, input 100%, output 75% OR base productivity 150 units, input 133%, output 100%. That way, the player has one step less to calculate.

[makie]

ok test pak64 with 120.4.1 Nightly
just_in_time=1 behaves as expected
production = oil / 3 (oil = production * 300 / 100 (100%))
chemical = oil / 3 * 0.6 ; (or chemical = production * 60 / 100 (60%))

just_in_time=2  behaves differently



that should perhaps be viewed by DrSuperGood

from my point of view it is a program error

[R1dO]

Thank you for looking into this and confirming that my observation (and assumptions) seem correct.

Now i'm curious if this is intended behavior for jit2 or indeed a program error

[DrSuperGood]

from my point of view it is a program error

What do you think is a programming error? JIT2 is not as tested as it should be due to low general adoption hence I cannot rule out there being bugs in it.

The topic creator is using JIT2 mode. This means the following is happening...

• Output and Input rate are limited by the demand and supply attached to them. The factory will bottleneck on one of these concepts. The Bottleneck can be identified by the "@ X%" in the UI since it will be limited to the input with the lowest percentage or the average of percentage of all outputs.
• Factories with multiple outputs treat each output separately with regard to production with each output using an equal share of inputs. The numbers listed for inputs in the UI are for the maximum possible factory usage, which will only happen when all outputs are operating @ 100% and there is no other bottleneck.

To explain topic creator's Chemical Plant image...
Factory produces 2,040 units per month. Inputs are not bottlenecked but outputs are. The product ware "Chemicals" are produced at ~60% of that and are bottlenecked @ ~70% due to limited demand and hence the factory will produce ~ 2040 * 0.6 * 0.7 or ~856 Chemicals per month . The Graph kind of reflects this estimate. No "Printers Ink" wares are being produced, there must be no attached demand for them. The input ware "Oil" is consumed at ~300% of the production amount and are bottlenecked @ 50% of ~70% and 50% of 0% so will consume ~2040 * 3 * (0.7 + 0) / 2 or ~2,142 Oil per month. This is close to the actual amount as shown in the graph.

To explain topic creator's Sawyer's Workshop image...
Factory produces 980 units per month. There is no bottleneck at all allowing for full production to be obtained. The product ware "Planks" are produced at 100% with no bottleneck so will produce 980 * 1 * 1 or 980 Planks per month. The input ware "Wood" is consumed at ~120% with no bottleneck so will use 980 * 1.2 * (1) / 1 or ~1,176 Wood per month. Differences with the graph are likely due to a bottleneck occurring briefly during the month, since the consumed amount graph shows some variance with months.

To explain makie's chemical plant image without repeating the above...
The chemical plant has 2 products and as such its input is shared equally between them. As such each output uses 150% Oil to make. The Oil consumed to make 124 Chemicals can be worked out as 124 / 0.6 * 3 / 2 or 310 Oil per month. The difference with the number shown by the graph is likely due to fixed point rounding error during calculation.

At the time JIT2 was implemented there was much discussion if factories with multiple products should work this way. Some wanted the factory to consume the UI stated amount per product. This would result in existing balanced factories such as Pak64 oil refineries and chemical plants consuming an absolutely silly amount of wares per month if fully utilized (potentially 600%) and would likely still confuse the player as to why so much is being used. Others wanted to retain the JIT0/1 concept of locked production which would mean the least bottlenecked product would dictate the consumption rate with bottlenecked product having to be discarded. This makes no sense for some types of industries and was non-trivial to implement at the time as the concept of output demand bottlenecking was only implemented a few years later by which time the existing mechanic was in use.

At some stage it was intended that the ratio which input maps to output could be configured, or that alternative operating modes such as those originally suggested could be selected by pakset authors. However due to low JIT2 adoption no one coded support for this as it was not particularly a requested feature and even if implemented it would not likely see use.

I was planning to completely overhaul how factories work. Specifically in an attempt to lay ground work for better economic simulation of factories, which is a much requested feature. Under such changes production would be moved to "batches" which take some amount of time to produce. The advantage of this approach is it greatly simplifies the production logic (once per batch, otherwise just the overhead of decrementing a counter or searching a data structure) and completely eliminates production logic rounding error (batches have fixed sizes). Batches could be used to emulate existing factory production behaviour by making the batch frequency sufficiently high. Production rate could be controlled by changing the frequency that batches are produced at. UI wise such factories would then become more clear since either the productions would be displayed as separate batches the factory can produce, or as a single batch type with excess being discarded.

[makie]

Thank you for the quick and extensive response.
My English is not so good and I do not have that much time right now. That's why I'll need some more time to work through the answer.

But before a quick answer.
in JIT=1 the Factory use 5 Oil for producing 1 Chemicals (or 3 for 0.6 )
in JIT=2 the Factory use 2,5 Oil for producing 1 Chemicals (or 3 for 1.2 )
i think changing JIT form 1 to 2 should not change the design of the pak 

[makie]

ok DrSuperGood i think i understand your point of view

consuming 3 Oil is enough for 0.6 Chemicals and 0,3 ink
so if the ink is not thown way, it is possible to produce more  Chemicals

JIT=1 use the Oil for the ink and throw away the ink

in reality, there are probably both cases
1. the partner product must be thrown away
2.  it can be decided what will be produced, either, or, or both

[DrSuperGood]

in reality, there are probably both cases1. the partner product must be thrown away2.  it can be decided what will be produced, either, or, or both

Yes however one cannot just guess which is correct. Such operating mode would need to be specified by pakset authors. This would need functionality added to support multiple modes of operation. The behaviour I choose is a good enough default in that it keeps the potential amount of wares used the same while making sense for some types of multi product factory.

It has a gameplay advantage as well since it rewards players for using multiple products from a factory with more input demand. In JIT1 one obtains maximum input demand by using just 1 product fully.

so if the ink is not thown way, it is possible to produce more  Chemicals

No it will not be able to produce any more Chemicals. If no ink is being produced the factory uses a lot less Oil. If one wants the factory to use more oil, and hence make more money moving Oil, one would need to use the printer ink.

[makie]

However due to low JIT2 adoption ......

You complain about the low use of JIT = 2
I would like to share my experiences with it. Maybe it helps.

As a player on a big map with pak128.german I had big problems with goods transportation. It runs like big waves. It was like ebb and flow. Pak128.german has default JIT=1. But i like the game and so i searched for a solution. I found JIT=2 and i found the documentation. https://forum.simutrans.com/index.php?topic=13789.0 I have a bookmark on it, but this big text is is beyond my English abilities. I does not understand how it works exactly but i give it a try. In theory it should be the solution to my problems and in detail it looked good. But I had problems that I did not understand and therefore could not solve. Sometimes the transportation and production break down nearly completely and i don't know why.  With all the advantages of JIT=2 I did not get the problems in the handle, and so I switched back to the smaller evil to JIT=1.
One Bug i could reproduce and it is fixed now. https://forum.simutrans.com/index.php/topic,17394.0.html
Another problem: JIT=2 is allergic to too small incoming storage. It then comes to production blockades until over several years.
In the meantime i joined to the maintainer of the pak128.german and after some fight, I could increase the entrance storage, so that they are now generous. I'm planning new tests with JIT=2 and if these are successful, I will suggest the team JIT=2 as default for the new planned version 1.2. Version 1.1 is ready for release, there we make no more change on it.

But back to this thread. The starter of this thread does not understand the behavior of JIT=2. He ask and he try to help Simutrans. It seems, it was not clear what had happened.

For me: I found again a property of JIT=2, which I did not expect.

[R1dO]

@DrSuperGood
Thank you for the detailed explanation. That was exactly the kind of information i was missing.
Definitely not something i would have derived myself using the information on the first screen.

For what it's worth, if you are open to it (and if technically possible).
The information on that screen might better reflect JIT2 behavior (and understanding by the player) with the following alteration:
Currently

Code Select Expand


Consumption:
- Oil 300% : ....


To (or something akin)

Code Select Expand


Consumption;
- Oil 150% (xN) : ...


E.g. Divide the consumption factor by the number of output good types, and N based on the number of currently active output production types (1 or 2 for this example).

[makie]

maybe like this

[R1dO]

That is i concept i toyed with mentally as well but i feel it has 2 pitfalls:
* For factories with a large list of outputs (and/or inputs) the list grows pretty fast, making it unwieldy.
* There is a duplication on the extra consumption lines that can cause confusion. For instance does this factory store 2 times 1315 oil or just 1 time.

That being said, I do like your effort for trying to improve this aspect. Thank you for that.

[makie]

yes,
maybe the Input store and the consumption should not be in the same line 
the stored, ordered and on transportation are equal for all output products
the  consumption is individual for one product

my problem is:
there are a lot of numbers and it really cryptic labeled
I would rather like a long list and more clarity at meaning of the numbers / information

[R1dO]

If i understand you correctly you are looking for something more along the line of:

Code Select Expand


Production:
- Chemicals ...  # As it currently is
- Printers Ink ... # As it currently is

Consumption:
- Oil 300% ...  # As it currently is
   - 150% for Chemicals
   - 150% for Printers Ink
- SomeOtherInput 450% ... # As it currently is
   - 225% for Chemicals
   - 225% for Printers Ink


In that case it won't deviate too much from the information in the windows for other factories.

[Leartin]

I think the best approach would be not to change how anything is depicted, but instead change how JIT2 works - because it's inconsistent and has no reason to work like that.

In a vacuum, both approaches can work sometimes, or they are silly. However, as a pak-designer I would like to know which approach it is. If I were to plan for my chemical plant to consume 10 units of oil to produce both one unit of ink and two units of chemicals, then it should not change to require 10 units of oil for two units of chemical and 10 units of oil for one unit of ink. Neither should it require 5 units of oil for two units of chemical and 5 units of oil for one unit of ink. Obviously neither are the same, there is a functional difference. And if you could set it up for this approach, a pak-designer would probably want to be able to divide input differently than just splitting it half-half, eg. in this case require 200% oil for chemicals and 100% oil for ink.

That's not to say that it couldn't be in the game at all. It just shouldn't depend on the choice of JIT-setting.


The suggested display would be kind of sad to me. That's because it would be capable to convey several different recipes in the same factory to the player.
In this case, it would only be like Recipe1: 150%oil->60%chemicals; Recipe2: 150%oil->30%ink.
That could be more complex though. Just as an example, say you need natural gas for chemicals, but not for ink. Recipe1: 150%oil+100%gas->60%chemicals; Recipe2: 150%oil->30%ink.
It could be displayed with that system:

Code Select Expand


Production:
- Chemicals ...  # As it currently is
- Printers Ink ... # As it currently is

Consumption:
- Oil 300% ...  # As it currently is
   - 150% for Chemicals
   - 150% for Printers Ink
- Gas 100% ... # As it currently is
   - 100% for Chemicals

I know just displaying it is not enough, and you'd still be far off from getting something like that functional. But I wonder if it's a good idea doing that kind of display that hints at such possibilities, only to let users down with it being always an even split.

[makie]

i think changing JIT form 1 to 2 should not change the design of the pak

I agree Leartin

[Matthew]

my problem is:
there are a lot of numbers and it really cryptic labeled
I would rather like a long list and more clarity at meaning of the numbers / information

This is my problem too. Even playing with JIT=1, I have to use a printed sheet explaining what the numbers in the Industry Info window mean. I find them the most confusing part of the game. More labelling of numbers would be very welcome.

[DrSuperGood]

The reason it works as it does is so that the total production of a factory did not increase under ideal conditions (everything used).

The issue with adding JIT2 only mechanics for pakset authors is that people who demand to play JIT1 need to also use the same factories. How are they meant to work in these conditions? Supporting both old operating modes and new operating modes has always been a problem and complicates the code.

[Leartin]

The reason it works as it does is so that the total production of a factory did not increase under ideal conditions (everything used).

You did not need to change anything compared to JIT1. In JIT1, if either output is produced at full rate, the input is consumed at full rate. So do the same in JIT2. Check for each of the outputs at which rate they are ordered. The one that's required more is used to set the consumption rate of the input, all others are created alongside. Now you still achieve the goal of JIT2, limiting the resources a factory supplies to how much is needed, without changing the pakset balance.

Let me put it differently: JIT1 and JIT2 should only differ in how the downtime of routes with too many vehicles are spread out. In JIT1, they all run for a while, and then they all stop. In JIT2, some are waiting at all times. If you had the perfect amount of vehicles on every route, they should behave exactly the same. Your changes to how several inputs work, as well as the consumer problem in the other thread, messes this up. It just makes JIT2 worse.

The issue with adding JIT2 only mechanics for pakset authors is that people who demand to play JIT1 need to also use the same factories. How are they meant to work in these conditions? Supporting both old operating modes and new operating modes has always been a problem and complicates the code.

There should not be any JIT2-only-mechanics at all. This is exactly where you went wrong. If you want factories to require more input if several outputs are produced, you can add that to the game, but you can't attach it to JIT2, it has to be seperate.
As a seperate game mechanic the pakset author could decide which factories have parallel production (meaning both outputs come from the same input) and which have serial production (meaning the different products are made one after another from similar input), parallel production being the default due to history. This way, the pak author can give extra settings for serial production.
The player may also have a setting for the production type, to make them all parallel or seriel in their game, with the default to let the pakset decide.

Is it worth it? I don't actually think so, it's just a minor thing that doesn't even come up that often, and even if the code was easy to write, displaying it meaningfully would be an issue. I'd rather scrap it for now and wait until someone is about to make more useful changes in the same area (eg. adding optional inputs,...)

[Ters]

More labelling of numbers would be very welcome.

And where would those labels go? This is one of the biggest windows in the game, and it is pretty full already.

I don't think simple labels would help either. There is more to these numbers than can be explained with a word or two.

[Leartin]

And where would those labels go? This is one of the biggest windows in the game, and it is pretty full already.

Icons with mouseover? That would be something.
Forum does not allow me to post emojis, so...



Not sure if horizontal or vertical space is more limited, with p192c and normal font the image dictates the size of the dialog.

[DrSuperGood]

You did not need to change anything compared to JIT1. In JIT1, if either output is produced at full rate, the input is consumed at full rate. So do the same in JIT2. Check for each of the outputs at which rate they are ordered. The one that's required more is used to set the consumption rate of the input, all others are created alongside. Now you still achieve the goal of JIT2, limiting the resources a factory supplies to how much is needed, without changing the pakset balance.Let me put it differently: JIT1 and JIT2 should only differ in how the downtime of routes with too many vehicles are spread out. In JIT1, they all run for a while, and then they all stop. In JIT2, some are waiting at all times. If you had the perfect amount of vehicles on every route, they should behave exactly the same. Your changes to how several inputs work, as well as the consumer problem in the other thread, messes this up. It just makes JIT2 worse.

The change was made to prevent exploits where by one could double the amount of input used (shipped) by shipping to separate factories. For example in pak64 one can source chemicals from one refinery and printer ink from another and each would need absolutely stupid amounts of oil. This also results in double the power used and hence double the power sold.

Under JIT2 this exploit was removed since that configuration would use similar amounts of oil and electricity to sending them to a single factory.

There should not be any JIT2-only-mechanics at all. This is exactly where you went wrong.

Except I did not add any JIT2 only mechanics. Hence how can I have gone wrong?

Icons with mouseover? That would be something.

Inline icons with mouse over do not really exist currently and certainly is a non trivial change. Currently the entire output is composed as a piece of printed text. With the proposed change one would need some sort of layout table with multiple pieces of printed text and some icons. Pakset authors would also need to add icons, or at least someone would need to make default ones. Emoji's cannot be used in Simutrans text as the text composer only works for Unicode plane 0. It should still correctly parse, import and export Unicode from other planes thanks to conformance improvements which were made but it can only display glyphs for plane 0. The default English plane 0 font is missing most glyphs as well.

Only 1 sort of units per time should be used. There should be an option to change this in settings which should effect most units except for financial maintenance (which works in months for gameplay reasons). I only added units per minute because it is month length invariant and gives the player some idea of how fast the factory will produce (a train every minute? hour? many hours?).

Since players may want to alter production rate or build new factories, the ratios are still required to be displayed otherwise they will have no idea where the production numbers are coming from and how they relate to the numbers shown to them in the factory creator tool. Pakset authors give the factory production number different meanings, such as being the total sum of all outputs, or total sum of all inputs, or even a multiple of a normalized production amount.

[Leartin]

The change was made to prevent exploits where by one could double the amount of input used (shipped) by shipping to separate factories. For example in pak64 one can source chemicals from one refinery and printer ink from another and each would need absolutely stupid amounts of oil. This also results in double the power used and hence double the power sold.

You keep answering to the question "Why do you feel that's how it should work?". That's not what's asked. The question is "Why should it be part of JIT2?" As in "Why should 'fixing that exploit' be a JIT2-only-mechanic?".
Clearly, if it was unanimously accepted that it's an exploit that requires fixing, everyone would be happy if it was fixed in JIT1 as well.

Just imagine when drive_on_left was implemented, whoever did it decided that they would also like for busses and trains to not stop for each other at a crossing and instead just clip through, because otherwise you can exploit it by blocking other players roads by parking your trains across them.
It does not even matter if that's an exploit worth fixing, whether it makes the game better or worse: It just should not depend on a completely different mechanic/setting.

Since players may want to alter production rate or build new factories, the ratios are still required to be displayed otherwise they will have no idea where the production numbers are coming from and how they relate to the numbers shown to them in the factory creator tool. Pakset authors give the factory production number different meanings, such as being the total sum of all outputs, or total sum of all inputs, or even a multiple of a normalized production amount.

The simple solution is the show the relation to the "base productivity" in the build-factory-dialog (which would be a good idea anyway) such that the player can calculate the goods-production when they place new factories. Other than that, the player does not need to know such a thing as base productivity even exists, on it's own it's just an arbitrary value.

Inline icons with mouse over do not really exist currently and certainly is a non trivial change.

Not completely serious: Place each Icon in a button. Buttons can be in line with text (eg. in a station dialog, the button to toggle display of waiting goods) and can have mouseover information. Clicking the button could open a seperate dialog with a legend for all the icons, such that touch-screen-users can see them, too. It's stupid, but the technology is there.

[DrSuperGood]

"Why should 'fixing that exploit' be a JIT2-only-mechanic?".

Clearly, if it was unanimously accepted that it's an exploit that requires fixing, everyone would be happy if it was fixed in JIT1 as well.

Because I was explicitly told not to alter the way JIT0 and JIT1 worked. Hence I cannot fix any exploits with them.

Part of the motivation behind JIT2 was to help with exploits and nonsense like this.

Just imagine when drive_on_left was implemented, whoever did it decided that they would also like for busses and trains to not stop for each other at a crossing and instead just clip through, because otherwise you can exploit it by blocking other players roads by parking your trains across them.

This is not a valid comparison. Drive on left is largely a visual thing and was added to not change how anything worked but to make cars look like they are driving on the correct side of the road for some locale themed paksets.

A valid comparison would be a setting for Russian driving regulations or EU driving regulations. This might alter how cars work and act at intersections and crossing and if an unintended exploit existed in one of the modes it might be fixed in the other during implementation.

The simple solution is the show the relation to the "base productivity" in the build-factory-dialog (which would be a good idea anyway) such that the player can calculate the goods-production when they place new factories. Other than that, the player does not need to know such a thing as base productivity even exists, on it's own it's just an arbitrary value.

I agree and have already considered that after some of the recent posts. But it might cause confusion similar to how hiding the demand counters has as to why things work the way they do.

Not completely serious: Place each Icon in a button. Buttons can be in line with text (eg. in a station dialog, the button to toggle display of waiting goods) and can have mouseover information. Clicking the button could open a seperate dialog with a legend for all the icons, such that touch-screen-users can see them, too. It's stupid, but the technology is there.

Buttons cannot be inline with text. That is not how the text flow or UI composer works.

Only in the last year have dynamically composing UI elements been added to Simutrans. Before then all kind of dynamic composition was implemented at a low level for each window, hence why most windows lacked support for it and why dynamic themes were not supported. Even still a lot of dialogs still use the old approach.

With dynamic composition one achieves the desired effect using tables. The tables are a single row and use columns which alternate icon and then text elements, each being unique. Updates are no longer a simple function call asking for a block of text but rather a sequence of queries by the UI. Certainly possible but not trivial to make, not the sort of thing one does in a few lines of code.

[Leartin]

Because I was explicitly told not to alter the way JIT0 and JIT1 worked. Hence I cannot fix any exploits with them.

Implementing JIT2 should not change how JIT0 and JIT1 work. If you proposed a patch to include JIT2 that altered the other JITs, it would be bad.

Proposing a seperate patch which 'fixes that exploit' is a completely different story with two possible outcomes:
A) It's accepted, because everyone feels the same way as you about that exploit and agrees that it's a good idea.
B) It's rejected for some reason or another.

If the result was A, you got what you wanted, and different JIT-settings would still be consistent. Pak-devs probably raise the required input manually.
If the result was B, then it's rejected. It would be very bad practice to sneak it in regardless, concealed in a larger patch, no?

Part of the motivation behind JIT2 was to help with exploits and nonsense like this.

Maybe, but it's "JIT2", not "Play the game as DrSuperGood deems best".
As a JIT-setting, it should only deal with how many goods are sent on their way, not how they are consumed.

This is not a valid comparison. Drive on left is largely a visual thing and was added to not change how anything worked [...]
A valid comparison would be a setting for Russian driving regulations or EU driving regulations. This might alter how cars work and act at intersections and crossing and if an unintended exploit existed in one of the modes it might be fixed in the other during implementation.

My example was too random, but you fixed it for me with hypothetical driving regulations. It was "added to not change how anything worked", as far as we understand it now. Though I never used it, so for all I know, it could include British driving regulations and behaviour. If you had asked me, or I guess most people, JIT2 was implemented to deal with stop-and-go behaviour, and that's it. I would not have guessed what else it does.
Sure, British driving regulations in drive_on_left would make sense in a way - but only if drive_on_right already had some. If drive_on_left was the only thing that included driving regulations, it would be just as wrong and shouldn't do that. Either drive_on_right got driving regulations as well, or driving regulations would have to be a seperate option, that can be turned on or off and then change depending on which side you drive on.

This is because one of two things is true:
EITHER everyone wants driving regulations - than it's wrong that those who use drive_on_right can't access them
OR not everybode wants driving regulations - then it's wrong to force them on british players

And it works exactly the same with your reasoning for splitting inputs. If everybody wants it, great, implement it for everyone as standard. If not everybody wants it, don't force it on people who just want to remove stop-and-go-order-behaviour. It does not matter whether it's a good change or not, if there is no technical reason to constrain it to another setting, just don't.


Now a sidenote about whether or not your exploit-explaination actually makes sense:
For best play experience, you can't fix everything with the base game functionality, you also have to consider the pakset. 300% to 60% is significant, but if the pakset author was smart, he could have balanced it in a way where you have to deliver that 300% amount of oil to make the same or less profit as if you would delivering the 60% chemicals. You would need to invest much more to get the oil flowing (even more so from an oil platform, operating a harbour), and would rather build routes for the more profitable chemicals and ink instead of investing as much again. Would not be exploitable if done right, in fact, if the pakset was balanced like that, your "removing the exploit" just destroys a wonderful balance, and players just get cheaty cheap chemicals that were supposed to cost them much more in oil delivery.
On the other hand, say there are more consumers for chemicals than for ink. In order to deliver to all of them (which you want to do to maximize profit), you would have to connect every single refinery. At least, that's what's supposed to happen with the current factory generation. Therefore, you have to use them all just for chemicals, and any ink that is also used is just a bonus.
I don't think it's a matter of exploits, it's a matter of pak balance. The way I plan the p192c factory overhaul, my refinery will produce Naphtha, Fuel and Heavy Oil, because Crude Oil is split into those parts with different heats, it produces parallel. I intend to make it that generally two of the goods need to be used to make a profit, because it can't be profitable to throw 2/3 away. This, to me, would make nice gameplay. JIT2 does not help, it just messes up the balance.