Increase maximum monthly production (ex: coal mine)

[Digitalfox]

Ok what I'm about to ask may seem crazy, but bear with me

I've been looking to the source code for where to change the max production for raw industries like mines, forests, plantations etc...


Currently I have set my industries grf to: prod_multiplier : [255];

As such the maximum production say for a coal mine is 2.040t month.


I'm trying to double or quadruple that value!

I've been looking at industry.h and seems this is not a limitation but rather a choice since most of the variables related to production are uint16 (max 65,535).

But industry_cmd.cpp is huge and way overwhelming for someone not familiar with the code as me (I've been looking at this for the last hours and still am stuck on 2.040 :\).

So I'm asking if you (anyone) could please point me to where I should look or change to achieve my goal!

Thank you!

Maybe I should have created this topic in problems or general

[PikkaBird]

Maybe I should have created this topic in problems or general

Or newgrf development.

If you want higher production, the trick would be to use the industry production callback (produce_256_ticks) to code your own production system rather than relying on the default "primary industry" behaviour.

[Alberth]

industry.h says production level of an industry is a byte.

If you want more, you need a bigger value there. That in its own is not that complicated. The real puzzle is then that in every expression where this value is used, you need to accommodate for bigger values too. That will probably result in changing other variables too. Those also have to be enlarged, and so on.

The area where you're going to have most fun is in the NewGRF code, which implements the NewGRF specs. There you have the choice between staying compatible with the specs (ie somehow you have to handle bigger values while the NewGRF industries still expect smaller values, or you have to change the NewGRF specs to handle bigger values. The latter of course without breaking every NewGRF industry set that exists.


I would think building two or four mines is a much simpler solution

[Digitalfox]

industry.h says production level of an industry is a byte.

If you want more, you need a bigger value there. That in its own is not that complicated. The real puzzle is then that in every expression where this value is used, you need to accommodate for bigger values too. That will probably result in changing other variables too. Those also have to be enlarged, and so on.

The area where you're going to have most fun is in the NewGRF code, which implements the NewGRF specs. There you have the choice between staying compatible with the specs (ie somehow you have to handle bigger values while the NewGRF industries still expect smaller values, or you have to change the NewGRF specs to handle bigger values. The latter of course without breaking every NewGRF industry set that exists.


I would think building two or four mines is a much simpler solution

Yeah, I've changed it before, but came across all sorts of assertions like in saveload.cpp (IsVariableSizeRight)...

Can industry production callback (produce_256_ticks) really increase the max? I mean was it thought for this?

[Alberth]

Yeah, I've changed it before, but came across all sorts of assertions like in saveload.cpp (IsVariableSizeRight)...

That still counts as "not so complicated" with me
ie update savegame version, adjuct old and add new entry for the new size with the right min/max save game version numbers, handle bigger size in afterload.

Can industry production callback (produce_256_ticks) really increase the max? I mean was it thought for this?

I have no idea, sorry, but it sounds like you should look what the NewGRF specs say about it.

[Digitalfox]

I'm trying Pikka tip and found this piece of code http://dev.openttdcoop.org/projects/yeti/wiki/Code

Been trying the simple part: produce(produce_date, 0, 0, 0, current_year /100, 0);

After a small modification I already have 30.000 output

Just need to to some testing to make sure there are no side effects

[Eddi]

you need to especially check whether this output actually arrives at the station.

the limit here is that for every 256 ticks callback, and for every tile of your industry, 255 pieces of cargo can be moved to a station.

[Sylf]

If you set your own production levels with produce_256_ticks callback, then you'll also want to set monthly_prod_change and random_prod_change manually as well, and don't let the game try to increase/decrease the production levels. If you don't, those default behaviors will trigger the news message about production change even when your produce_256_ticks production level hasn't changed.

I hope that made some sense to someone...

[Digitalfox]

you need to especially check whether this output actually arrives at the station.

the limit here is that for every 256 ticks callback, and for every tile of your industry, 255 pieces of cargo can be moved to a station.

Ok so I tried for example:

Code: Select all

produce(production_modifier, 0, 0, 0, 1700, 0);

item(FEAT_INDUSTRIES, industry_coal_mine, 0x00) { 
	property { 
		substitute			: 0x00; 
		override			: 0x00;
		layouts				: [coal_mine_layout];
		accept_cargo_types	: [];
		life_type			: IND_LIFE_TYPE_BLACK_HOLE; //Disable production changes/closure of industries
		prod_cargo_types	: [cargotype("COAL")];
		prob_random			: 8; //When generating the Map
		prob_in_game		: 0; //Game generates while playing new Industries, disable it
		prod_multiplier		: [255]; //Produces 2.040 tonnes/litters by default
		map_colour 			: 0x34;
		fund_cost_multiplier: 40;
	}
	graphics {
        produce_256_ticks	: production_modifier;
    }
}

I'm getting around 17,000t for month on industry window, on station it's does get a lot more coal.

Is there a better way than just having a bunch of trains loading at the station, and properly have statistics over what real cargo is being monthly produced?

[Sylf]

With that code, you're getting either 13,600 tons (1700*8) or 15,300 tons (1700*9) per month. That *8 or *9 modifier comes from the fact that this callback is called every 256 ticks. There are 76 ticks per day, so... you can do the math.

If you want absolutely flat production per month (and not per 256 ticks), you can probably do the math from the current date and number of days in the given month. But is that really what you want?

P.S. This thread really should be moved to NewGRF Technical Discussions.

[Eddi]

the value is 74 ticks per day, not 76.

i don't know of any method to record the monthly throughput of stations.

anyway, to get remotely useful values, you have to modify the station rating calculation to always be 100% (like the parameter for FIRS)

[Digitalfox]

With that code, you're getting either 13,600 tons (1700*8) or 15,300 tons (1700*9) per month. That *8 or *9 modifier comes from the fact that this callback is called every 256 ticks. There are 76 ticks per day, so... you can do the math.

If you want absolutely flat production per month (and not per 256 ticks), you can probably do the math from the current date and number of days in the given month. But is that really what you want?

P.S. This thread really should be moved to NewGRF Technical Discussions.

Ok, thanks for the explanation

Yeah I guess at this point this topic should be merged with my own Digitalfox NML questions, I wasn't sure this could be done with a GRF but now it's for sure the road I'm taking!

the value is 74 ticks per day, not 76.

i don't know of any method to record the monthly throughput of stations.

anyway, to get remotely useful values, you have to modify the station rating calculation to always be 100% (like the parameter for FIRS)

Thanks Eddi I'm going to take a look at that parameter

[PikkaBird]

If you don't, those default behaviors will trigger the news message about production change even when your produce_256_ticks production level hasn't changed.

OTOH, if he wants random production changes still, the production_level variable can be read and fed back into the callback result.