Industry consumption query

[jamespetts]

Probably a silly question, but it is not immediately obvious from reading the code: where can one find a variable/getter in the fabrik_t class representing the monthly maximum consumption of one particular type of input goods in any given industry?

Edit: My investigations into this have dug up some very weird behaviour, and I am not sure whether this is confined to Experimental or not: a market consumes fruit, vegetables, meat and fish in proportions 100%, 100%, 33%, 200%. It is connected to a single arable farm in a test game, which produces vegetables far faster than the market can consume them (I set up the test game to test the max_intransit_percentage adjustment feature that I am writing).

Production is nominally 16 units per month. The industry is not connected to electricity. When I run the game fast forwarded and it is connected to the arable farm, consumption of vegetables is 41/month (as shown on the "goods needed" graph). When run for a month without fast forwarding, consumption is only 20/month. A diary, meanwhile, with a nominal consumption of 800/month consumed exactly that in a very similar test when connected to two cattle farms with sufficient transport to meet its need more than sufficiently.

Also, I examined the code and deduced that this was the relevant code determining industry consumption rates:

Code Select Expand


if(  ausgang.empty()  ) {
            // consumer only ...
            if(  besch->is_electricity_producer()  ) {
                // power station => start with no production
                power = 0;
            }

            // finally consume stock
            for(  uint32 index = 0;  index < eingang.get_count();  index++  ) {
                if(!besch->get_lieferant(index))
                {
                    continue;
                }
                const uint32 vb = besch->get_lieferant(index)->get_verbrauch();
                const uint32 v = max(1,(menge*vb) >>;

                if(  (uint32)eingang[index].menge > v + 1  ) {
                    eingang[index].menge -= v;
                    eingang[index].book_stat(v, FAB_GOODS_CONSUMED);
                    currently_producing = true;
                    if(  besch->is_electricity_producer()  ) {
                        // power station => produce power
                        power += (uint32)( ((sint64)scaled_electric_amount * (sint64)(DEFAULT_PRODUCTION_FACTOR + prodfactor_pax + prodfactor_mail)) >> DEFAULT_PRODUCTION_FACTOR_BITS );
                    }
                    // to find out, if storage changed
                    delta_menge += v;
                }


In theory, therefore, the following code should produce the correct number:

Code Select Expand


const uint64 max_prod = (uint64)prodbase * (uint64)(get_prodfactor());
    const uint64 menge_prod = (max_prod >> (18-10+DEFAULT_PRODUCTION_FACTOR_BITS-fabrik_t::precision_bits)) * welt->ticks_per_world_month + (uint64)menge_remainder;
    const uint32 menge = (uint32)(menge_prod / (uint64)PRODUCTION_DELTA_T);
    const uint32 vb = besch->get_lieferant(index)->get_verbrauch();
    const uint32 v = max(1,(menge*vb) >>;
    const uint32 TEST = convert_goods(v);


("TEST" should be the same as shown in the "goods needed" graph). However, this produces the figure of 16, which is the same as would be produced by the much simpler:

Code Select Expand


(get_current_production() * besch->get_lieferant(index)->get_verbrauch()) >> 8;


This looks to me like a rounding error somewhere. Would changing "fabrik_t::precision_bits" to a higher number assist, or would doing so cause overflows somewhere?

[prissi]

Part of the problem is how often step() is called. When bits per month were introduced, I set this so the pa128 open pit mine did not overflow until setting of 23 (if memory serves me right, that was a little ago already).

[jamespetts]

Interesting - thank you. Does that mean that industries whose monthly production is less than 23 are likely to see this problem?

[prissi]

No, this would be an underflow. For this I tested until bit per month 16. But I only tested the standard paks, so a risk of underflow might still exist. Best to add some debug logging and see for yourself.

Although with bits per month = 20, you should only get productions which are divideable by four.