OpenTTD

Tasklist

FS#6367 - Industries with randomised cargos don't display correctly on minimap

Attached to Project: OpenTTD
Opened by 3iff (3iff) - Tuesday, 25 August 2015, 08:40 GMT
Type Bug
Category NewGRF → NewIndustries
Status New
Assigned To No-one
Operating System All
Severity Low
Priority Normal
Reported Version trunk
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

Problem when an industry has randomised output products (Firs 143 for example)

A recycling plant can produce varied products (decided when the industry is built). Manufacturing supplies are the default while the secondary product can be building materials, scrap metal, farm supplies or chemicals.

The minimap will always show that industry type as providing scrap metal regardless of what the second product actually is.


Savegame with firs143 as the only grf, created with nightly 27325. Screenshot also supplied.
Discussed in "FIRS Industry Replacement Set - Development & Translations" page 190+


NML code as used in Firs143 (omitting irrelevent code)

/* Decide randomly on cargo output:
* First cargo is always MNSP, 2nd is randomly a choice of 4,
* 3rd cargo is not allowed nor defined */
random_switch (FEAT_INDUSTRIES, SELF, recycling_plant_random_output_cargo) {
1: return SCMT; // scrap metal
1: return RFPR; // chemicals
1: return BDMT; // building materials
1: return FMSP; // farm supplies
}

// industry code that specifies the 'default' products

item(FEAT_INDUSTRIES, recycling_plant, 23) {
property {
accept_cargo_types: [RCYC];
prod_cargo_types: [SCMT,MNSP];
}
}
This task depends upon

Comment by Alberth (Alberth) - Wednesday, 26 August 2015, 05:58 GMT
Somewhere around http://www.tt-forums.net/viewtopic.php?p=1154727#p1154727 starts the discussion.
Comment by andythenorth (andythenorth) - Wednesday, 16 September 2015, 18:51 GMT
It's a bug in how newgrf authors are using the newgrf spec. There is no good gameplay reason to returning random results to the cb for setting accept/produce cargos.

Arguably the whole cb is redundant, there should be no need to change cargos when industry is constructed, even without randomisation.
Comment by 3iff (3iff) - Thursday, 17 September 2015, 07:35 GMT
I've removed the randomising code from the SPI industry set so it will no longer be a problem for me.
Comment by adf88 (adf88) - Sunday, 20 September 2015, 09:51 GMT
"The minimap will always show that industry type as providing scrap metal" WHAT?! I don't understand. Since when minimap is related to any of cargoes?
Comment by frosch (frosch) - Sunday, 20 September 2015, 10:43 GMT
The cargochain view can be linked to the minimap. That way selecting a cargo in the cargochain view, will highlight industries producing/accepting that cargo. Just that this based on the static industry definition, instead of instance variables.
Comment by adf88 (adf88) - Tuesday, 29 September 2015, 06:47 GMT
So... the industry chain is buggy.

For whatsoever reason the cb was added, it's meant to allow different cargoes then specified in prop 10. But the industry chain doesn't bother about the callback and rely on prop 10 only.

Second issue is that industry chain suggests that it is capable of displaying cargo-related minimap while there is no such feature*, "link to smallmap" shows something different.

* The minimap would be capable of displaying cargo-related view if industry cargoes would not be allowed to vary during a running game. It's not clearly forbidden by the NewGRF spec. It's neither forced e.g. CB could be called once per game per industry type, not once per industry.
Comment by frosch (frosch) - Tuesday, 29 September 2015, 17:04 GMT
Yes the cargochain view is only an approximation for what is going on:
* Industries may have random cargos (this issue).
* There is no criterion whatsoever what houses/towns can accept or produce. The displays are only guesses.

The industry issue in the cargochain view can be solved by extending NewGRF specs to return all possible cargos, see for example https://wiki.openttd.org/Frosch/GRF_version_9#Callback_14B.2C_14C:_Input.2Foutput_cargos

Potentially conceptually easier (but still hard GUI-design-wise) may be to add a new legend to the industry smallmap, which allows selecting cargo types instead of industries, and then changing the cargochain<->smallmap link to pass cargos instead of industries in some cases. But well, the industry legend is usually already pretty huge.

The house issue is likely unsolveable, but likely also hardly used.

Loading...