Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

16 cargo types in and out for industries #6867

Merged
merged 3 commits into from Nov 3, 2018

Conversation

Projects
None yet
6 participants
@nielsmh
Copy link
Contributor

commented Jul 25, 2018

Since the number of cargo types was increased to 64, allowing industries to have more input and output types is natural so fewer industry types can service more cargo types.

The internal macros to set accepts/produces remain unchanged only supporting 3 in/2 out, but the generated structures do have full 16 slots, the remaining filled with "invalid". The new features require NewGRFs to be exploited.

Summary of current NewGRF spec changes:

Action0 Industry properties:

  • Prop 1A, adds flag 18 (4000): Indicates that callbacks 14B and 14C use a new parameter and return format to support "unlimited" number of input/output cargo types. Also changes the meaning of the parameter passed to callback 37.
  • Prop 25, new: Format B n*B, first byte is a count of how many cargo ids follow. Set cargoes produced by industry. If fewer cargoes are supplied than max, all remaining are set to "invalid". Deprecates property 10.
  • Prop 26, new: Format B n*B, first byte is a count of how many cargo ids follow. Set cargoes accepted by industry. If fewer cargoes are supplied than max, all remaining are set to "invalid". Deprecates property 11.
  • Prop 27, new: Format B n*B, first byte is a count of how many production rate values follow. Set production rates of cargoes produced by industry. If fewer cargoes are supplied than max (or set in prop 25), all remaining are set to zero. Deprecates properties 12 and 13.
  • Prop 28, new: Format B<n> B<m> n*m*W, first byte is number of input cargo rows, second byte is number of output cargo columns, the cargo multiplier words are arranged in row-major order. Total property length is 2+2nm bytes. Multipliers are specified in 256ths of a cargo unit, so a value of 0100h produces 1 unit of output for each unit of input. Input and output cargoes are ordered as in properties 25 and 26. Multiplier values outside the provided matrix are zeroed. Deprecates properties 1C, 1D, 1E.

Action0 Industry tile properties:

  • Prop 12, adds flag 1 (02): Tile accepts all cargoes the industry it belongs to accepts. The tile acceptance properties (0A, 0B, 0C, 12) are used, the sum of tile base acceptance and industry acceptance is used.
  • Prop 13, new: Format B n*(B B), first byte is a count of how many accepted cargo structures follow. Total property length is 1+2n bytes. In each structure, first byte is a cargo id the tile accepts, the second byte is acceptance rate in 1/8 units. If fewer cargoes are supplies than max, all remaining are set to "invalid"/zero. Acceptance rate is a signed int8, it can be negative to counteract the "accepts all" flag in prop 12. Deprecates properties 0A, 0B, 0C.

Industry callbacks 14B and 14C:

  • When industry prop 1A has flag 18 (4000) set, these may be called more than 3 respectively 2 times each.

Industry callback 37:

  • When industry prop 1A has flag 18 (4000) set, the follow changes apply.
  • The lowest byte of var 18 is 00 if querying an input cargo, 01 if querying an output cargo.
  • The second byte of var 18 keeps the old meaning.
  • The third byte of var 18 (bits 16..23) contain the cargo id being queried. Note that this is the cargo id and not the "slot" of the cargo.

Industry tile callbacks 2B and 2C:

  • If these are used, all accepted cargoes are cleared and only the three cargoes returned by the callbacks are used. In other words, they are incompatible with both the "accepts all" flag and prop 13.

Industry production callback:

  • A new callback format, version 02, is defined. Remaining applies to format version 02.
  • Version 02 format: <Sprite-number> * <Length> 02 0A <set-id> <version> <num-inputs> [<input-cargo-1> <subtract-in-1> ...] <num-outputs> [<output-cargo-1> <add-out-1> ...] <again>
  • The num-inputs and num-outputs values specify how many cargo/units pairs follow. (Number of pairs, not number of bytes.)
  • input-cargo-n and output-cargo-n are byte values specifying valid cargo ids that participate in the production callback.
  • subtract-in-n and add-out-n are byte values with same meaning as in production callback version 01, except they apply to the immediately preceding cargo id.
  • Don't try to specify the same cargo multiple times.
  • If a cargo does not participate in a production rule, don't include it in the parameters.

New VA2 variables for industries:

  • All of these variables require a parameter indicating the cargo id being queried.
  • 69[cargo]: Amount of produced cargo waiting to be transported.
  • 6A[cargo]: Amount of cargo produced this month.
  • 6B[cargo]: Amount of cargo transported this month.
  • 6C[cargo]: Amount of cargo produced last month.
  • 6D[cargo]: Amount of cargo transported last month.
  • 6E[cargo]: Date cargo was last delivered to the industry.
  • 6F[cargo]: Amount of delivered cargo waiting to be processed.
@nielsmh
Copy link
Contributor Author

left a comment

I think I covered all locations referencing to specific indices of the production/acceptance arrays, but my only testing so far is "compiles" and "does not crash loading an old save".

cargo_type == ind->accepts_cargo[4] || cargo_type == ind->accepts_cargo[5] || cargo_type == ind->accepts_cargo[6] || cargo_type == ind->accepts_cargo[7] ||
cargo_type == ind->accepts_cargo[8] || cargo_type == ind->accepts_cargo[9] || cargo_type == ind->accepts_cargo[10] || cargo_type == ind->accepts_cargo[11] ||
cargo_type == ind->accepts_cargo[12] || cargo_type == ind->accepts_cargo[13] || cargo_type == ind->accepts_cargo[14] || cargo_type == ind->accepts_cargo[15]
);

This comment has been minimized.

Copy link
@nielsmh

nielsmh Jul 25, 2018

Author Contributor

This is really ugly, but it also feels wrong to have a for loop nothing but an assert.

This comment has been minimized.

Copy link
@frosch123

frosch123 Jul 25, 2018

Member

It is possible to put the loop inside the assert:
assert(std::find(ind->accepts_cargo, endof(ind->accepts_cargo), cargo_type) != endof(ind->accepts_cargo));

SLE_CONDARR(Industry, produced_cargo, SLE_UINT8, 16, 200, SL_MAX_VERSION),
SLE_CONDARR(Industry, incoming_cargo_waiting, SLE_UINT16, 3, 70, 199),
SLE_CONDARR(Industry, incoming_cargo_waiting, SLE_UINT16, 16, 200, SL_MAX_VERSION),
SLE_CONDARR(Industry, produced_cargo_waiting, SLE_UINT16, 2, 0, 199),

This comment has been minimized.

Copy link
@nielsmh

nielsmh Jul 25, 2018

Author Contributor

I think this is correct, but not entirely sure, converting SLE_ARR to SLE_CONDARR starting at version 0.

This comment has been minimized.

Copy link
@frosch123

frosch123 Jul 25, 2018

Member

I think the savegames stores the size of the array.
So it may not even need the condition. Just changing 2 to 16 may be enough.
But needs trying and possibly proper initialisation of the array with CT_INVALID.

if (num_cargos == 0) return false; // industry produces nothing
int cargo_num = RandomRange(num_cargos) + 1;
int cargo_index;
for (cargo_index = 0; cargo_index < lengthof(src_ind->produced_cargo); cargo_index++) {

This comment has been minimized.

Copy link
@nielsmh

nielsmh Jul 25, 2018

Author Contributor

This algorithm feels overly complicated. Does it seem right?

This comment has been minimized.

Copy link
@frosch123

frosch123 Jul 25, 2018

Member

"ci" and "cargo_index" for the same thing is a bit weird.
But otherwise I see nothing wrong.

This comment has been minimized.

Copy link
@frosch123

frosch123 Jul 27, 2018

Member

warning: comparison between signed and unsigned integer expressions [-Wsign-compare]

Show resolved Hide resolved src/table/newgrf_debug_data.h Outdated
@frosch123

This comment has been minimized.

Copy link
Member

commented Jul 25, 2018

This PR does not seem to extend the NewGRF stuff, so no NewGRF can make use of this.
Suggestion/draft of a spec:
https://paste.openttdcoop.org/pwwcxs3a7

@andythenorth

This comment has been minimized.

Copy link
Contributor

commented Jul 26, 2018

Needs nml patched too. I can probs do that.

@nielsmh

This comment has been minimized.

Copy link
Contributor Author

commented Jul 26, 2018

Okay here's an attempt at implementing the NewGRF spec changes @frosch123 suggests. I skipped var 6E for now since that requires additional logic to record the data, currently there is only an "any cargo last accepted" date for each industry.

@nielsmh nielsmh force-pushed the nielsmh:indcargonum branch from 66abd5c to fdd4338 Jul 26, 2018

@nielsmh

This comment has been minimized.

Copy link
Contributor Author

commented Jul 26, 2018

An open question about GUI: The Industry chain window sizes itself after the max number of cargo types in/out possible, and with 16 types this results in some ridiculously large windows. It can't fit with standard font and 1x GUI on 1024x768 resolution.
Which is better then, keep it as-is? Count the actual max number of inputs or outputs any industry has in the current configuration? Dynamically change sizing based on number of ins/outs of currently selected chain? Just make the graphics smaller, maybe dynamically?

image

@andythenorth

This comment has been minimized.

Copy link
Contributor

commented Jul 27, 2018

I think it would be worth looking at extending tile callbacks 2B and 2C, to allow more accepted cargos per tile.

https://newgrf-specs.tt-wiki.net/wiki/Callbacks#Get_accepted_cargo_types_.282A.2F2C.29

I suggest allowing return value to be either

  • all 16 cargos
  • or if that's not viable, 4 cargos (on the basis that 4 x 4 makes 16 neatly, whereas the current limit of 3 requires 6 tiles)

I've played grfs with the 'multiple tiles are required for acceptance' and it's not as fun as it might sound imho.

Also, putting gameplay aside, FIRS tends to split tile IDs for different animation cycles, or for building on different land shapes (water, slope, flat etc). It could be quite faffy to combine that with splitting IDs for tile acceptance and then also giving a visual cue to the player. :)

As far as I can see in docs, cargo acceptance for the tile is not stored in the map, so I am hoping it would be relatively simple to extend :)

This would probably make more sense as a separate PR.

@nielsmh

This comment has been minimized.

Copy link
Contributor Author

commented Jul 27, 2018

I wonder if it would really be so bad to introduce a couple new Action0 properties to set acceptance. If you're developing a NewIndustries set that depends on 64 cargo type and 16-in-16-out, chance is you won't be compatible with OpenTTD 1.8 and earlier anyway, so shouldn't the NewGRF failing to load on older versions be a non-problem?

@andythenorth

This comment has been minimized.

Copy link
Contributor

commented Jul 27, 2018

I agree. The failing-to-load seems to be a non-problem.

With or without new action 0 props, the CBs would need extended for the 'stop accepting cargo according to conditions' case for industries, which tiles also need to handle :)

@nielsmh

This comment has been minimized.

Copy link
Contributor Author

commented Jul 27, 2018

Suggestion for new Action0 properties:

  • Industry Action0 property 25: Type V (variable length byte sequence), production cargo ids (local ids), deprecates property 10. If the number of cargoes is larger than number supported by game, error.
  • Industry Action0 property 26: Type V (variable length byte sequence), acceptance cargo ids (local ids), deprecates property 11. If the number of cargoes is larger than number supported by game, error.
  • Industry Action0 property 27: Type V (variable length byte sequence), production multipliers for output cargos, in same order as specified in property 25. Deprecates property 12. If length is shorter than number of cargoes, any missing are assumed to be zero. If length is larger than number of cargoes out supported by game, error.
  • Industry Action0 property 28: Type V (variable length byte sequence, length must be a multiple of 4), input cargo multipliers as a sequence of B B W structures. First byte is input cargo slot, second byte is output cargo slot, word is input cargo multiplier. Any in-out cargo combinations not specified are implicit zero. Note this uses cargo slots (cargo orders specified by properties 25 and 26) rather than cargo ids. Deprecates properties 1C, 1D, 1E.
  • IndustryTile Action0 property 13: Type V (variable length byte sequence, length must be a multiple of 2), tile cargo acceptance as a sequence of B B structures. First byte is cargo id (local id), second byte is acceptance level 1 to 8.
  • House Action0 property 21: Type V (variable length byte sequence, length must be a multiple of 2), house cargo acceptance in same format as IndustryTile property 13. Deprecates properties 1E, 0D, 0E, 0F.
/* Query actual types */
uint maxcargoes = 3;
if (indspec->behaviour & INDUSTRYBEH_CARGOTYPES_UNLIMITED) maxcargoes = lengthof(i->accepts_cargo);
for (uint j = 0; j < maxcargoes; j++) {
uint16 res = GetIndustryCallback(CBID_INDUSTRY_INPUT_CARGO_TYPES, j, 0, i, type, INVALID_TILE);
if (res == CALLBACK_FAILED || GB(res, 0, 8) == CT_INVALID) break;
if (indspec->grf_prop.grffile->grf_version >= 8 && res >= 0x100) {
ErrorUnknownCallbackResult(indspec->grf_prop.grffile->grfid, CBID_INDUSTRY_INPUT_CARGO_TYPES, res);
break;
}
i->accepts_cargo[j] = GetCargoTranslation(GB(res, 0, 8), indspec->grf_prop.grffile);

This comment has been minimized.

Copy link
@frosch123

frosch123 Jul 27, 2018

Member

Possibly also check for duplicate results.

/* Query actual types */
uint maxcargoes = 2;
if (indspec->behaviour & INDUSTRYBEH_CARGOTYPES_UNLIMITED) maxcargoes = lengthof(i->produced_cargo);
for (uint j = 0; j < maxcargoes; j++) {
uint16 res = GetIndustryCallback(CBID_INDUSTRY_OUTPUT_CARGO_TYPES, j, 0, i, type, INVALID_TILE);
if (res == CALLBACK_FAILED || GB(res, 0, 8) == CT_INVALID) break;
if (indspec->grf_prop.grffile->grf_version >= 8 && res >= 0x100) {
ErrorUnknownCallbackResult(indspec->grf_prop.grffile->grfid, CBID_INDUSTRY_OUTPUT_CARGO_TYPES, res);
break;
}
i->produced_cargo[j] = GetCargoTranslation(GB(res, 0, 8), indspec->grf_prop.grffile);

This comment has been minimized.

Copy link
@frosch123

frosch123 Jul 27, 2018

Member

Possibly also check for duplicate results.

break;
}
for (uint i = 0; i < group->num_input; i++) {
/* XXX: maybe check for same cargo id used multiple times and warn/error? */

This comment has been minimized.

Copy link
@frosch123

frosch123 Jul 27, 2018

Member

I think it is useful to allow passing 255 here, to skip cargotypes.

This comment has been minimized.

Copy link
@nielsmh

nielsmh Jul 28, 2018

Author Contributor

If you don't want a cargo type to participate in a production callback, don't include it in the parameters to the callback, I don't see what a "skip" value would do.

break;
}
for (uint i = 0; i < group->num_output; i++) {
group->cargo_output[i] = buf->ReadByte();

This comment has been minimized.

Copy link
@frosch123

frosch123 Jul 27, 2018

Member

I think it is useful to allow passing 255 here, to skip cargotypes.

ErrorUnknownCallbackResult(indsp->grf_prop.grffile->grfid, CBID_INDUSTRY_INPUT_CARGO_TYPES, res);
break;
}
indsp->accepts_cargo[j] = GetCargoTranslation(GB(res, 0, 8), indsp->grf_prop.grffile);

This comment has been minimized.

Copy link
@frosch123

frosch123 Jul 27, 2018

Member

Check for duplicates?

uint8 again;

// version 2 extensions

This comment has been minimized.

Copy link
@frosch123

frosch123 Jul 27, 2018

Member

this comment is not useful in the future

// version 2 extensions
uint8 num_input;
uint8 num_output;
uint8 cargo_input[INDUSTRY_NUM_INPUTS];

This comment has been minimized.

Copy link
@frosch123

frosch123 Jul 27, 2018

Member

cargo_input/output are CargoID, not uint8?

if (num_cargos == 0) return false; // industry produces nothing
int cargo_num = RandomRange(num_cargos) + 1;
int cargo_index;
for (cargo_index = 0; cargo_index < lengthof(src_ind->produced_cargo); cargo_index++) {

This comment has been minimized.

Copy link
@frosch123

frosch123 Jul 27, 2018

Member

warning: comparison between signed and unsigned integer expressions [-Wsign-compare]

} else if (type == 2) {
group->num_input = buf->ReadByte();
if (group->num_input > lengthof(group->subtract_input)) {
grfmsg(1, "NewSpriteGroup: Industry production wants more inputs than possible, given=%d, max=%d, skipping", group->num_input, lengthof(group->subtract_input));

This comment has been minimized.

Copy link
@frosch123

frosch123 Jul 27, 2018

Member

warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘long unsigned int’ [-Wformat=]

}
group->num_output = buf->ReadByte();
if (group->num_output > lengthof(group->add_output)) {
grfmsg(1, "NewSpriteGroup: Industry production wants more outputs than possible, given=%d, max=%d, skipping", group->num_output, lengthof(group->add_output));

This comment has been minimized.

Copy link
@frosch123

frosch123 Jul 27, 2018

Member

warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘long unsigned int’ [-Wformat=]

@frosch123

This comment has been minimized.

Copy link
Member

commented Jul 27, 2018

The industry directory also needs some love.
The current layout may be unsuitable when extending to more cargos.

@nielsmh

This comment has been minimized.

Copy link
Contributor Author

commented Jul 28, 2018

I think industry directory might be best for a separate PR.
Here's a mockup of possible improvement:
image
Adding a filter (grouping) column to view only industries of specific types, belonging to a specific city, producing a specific cargo, or accepting a specific cargo. E.g. selecting "Produces" for filter type and then selecting "Goods" for cargo in the left-hand list, would show all Factory, Sawmill, Oil Refinery industries in the right-hand list.
As a special case, if the left-hand list is filtered by Produces and you choose to sort the right-hand list by cargo produced amount, it sorts by the filter selection cargo instead of production sum.

@nielsmh

This comment has been minimized.

Copy link
Contributor Author

commented Jul 28, 2018

Summary of NewGRF spec changes was moved to first post.

@michicc

This comment has been minimized.

Copy link
Member

commented Jul 28, 2018

Small side note: Our commit message style allows "Add:" and discourages "Change:". Maybe change some of your "Change: Add ..." messages?

@nielsmh

This comment has been minimized.

Copy link
Contributor Author

commented Jul 28, 2018

@michicc Good point. I'll have to squash some of these commit eventually regardless.

More on topic, I made a little test NewGRF that lets the power station burn several more things.
image
superpowerstation.zip

@nielsmh

This comment has been minimized.

Copy link
Contributor Author

commented Jul 29, 2018

I managed to make a slightly more complex NewGRF exercising some of the new properties: oilstuff.zip (It introduces new cargo types so you'll want a vehicle set/extension that supports more than the standard ones.)

It highlighted another issue with the industry chain window, which is now fixed, at least partially.
image
There are some strange little squares at the bottom, which I haven't figure out the source of yet.

It also appears that something prevents town houses from accepting more than 3 cargoes despite them being supposed to. The above NewGRF should make three house types accept a new "diesel oil" cargo, but they don't. I haven't debugged that yet.

@nielsmh

This comment has been minimized.

Copy link
Contributor Author

commented Jul 29, 2018

Looks like the stray squares are from the "Draw the other_produced/other_accepted cargoes." loop in CargoesField::Draw(), but right now I can't understand the code well enough to realize a fix.

@frosch123

This comment has been minimized.

Copy link
Member

commented Jul 29, 2018

About the spec:

  • When adding industry properties 25/26, there is little point in calling callback 14B/14C at GRF load. So if you add the properties, then remove the call of the callback again.
  • I am not a big fan of the tile acceptance mechanics. All the tile callbacks which are called periodically are kind of CPU expensive, complicated to use, and achieve very little.
    I think we should focus on actual use cases instead of replicating the behaviour of the old callbacks.
    When considering the interaction between industry and tile acceptance, I see these uses:
    • A tile accepts all cargos that the industry accept.
    • Different tilse accept different subsets of the cargos, which the industry accepts.
    • A tile accepts town-like cargos like passengers, which are not processed by the industries, but compensate for the industry occupying space that would be used by houses otherwise.
    • When acceptance changes throughout the game, this behaviour always matches callback 3D.
  • Overall I would prefer a spec where tiles do not specify acceptance independently from the industry, but where they rather specify differences if any.
    • By default tiles accept all cargos, which the industry accepts.
    • Tiles accepting more cargos is an exception. Tiles accepting fewer cargos is an exception.
    • In all cases, callback 3D should also affect tiles. There should be no alternative way to change tile acceptance independent of industry acceptance.

Anyway, now that house stuff got added I think this PR has kind of derailed. There are tons of new stuff, but with no use case on the horizon.
In existing GRFs callbacks 1F/2A/2B/2C/148 are hardly used. And in the few cases when they are used, they are rather cumbersome to use.

For now I suggest:

  • Not touching tile acceptance, especially not adding more expensive and cumbersome tile callbacks.
  • If really needed, a new flag for tile property 12 "accept all cargos, which the industry accepts, in addition to those in properties 0A, 0B, 0C". I think that would not affect other options in the future.
  • Not touching houses.

@nielsmh nielsmh force-pushed the nielsmh:indcargonum branch from 6b8fd48 to 141c9ba Jul 30, 2018

@nielsmh

This comment has been minimized.

Copy link
Contributor Author

commented Jul 30, 2018

Whelp here's a large squashing into much fewer commits. The house accepts is removed and moved to PR #6872 instead. I'll remove some of the callback nonsense later too.

All issues of the Industry chain window should be fixed too now.

@nielsmh

This comment has been minimized.

Copy link
Contributor Author

commented Aug 13, 2018

Changing industry property 28 to use a direct matrix form instead of a list for a sparse matrix. Here's an updated test GRF using the new property format: oilstuff.zip

@andythenorth

This comment has been minimized.

Copy link
Contributor

commented Sep 10, 2018

There are nml patches here https://github.com/nielsmh/nml/commits/indcargonum

There's no clean reference nml file, but I have a patched FIRS that builds ok and appears to do the right thing (GPL 2).

firs-indcargonum.zip

I am unclear whether prop 28 in the nml patch is correct, it dates from August 5th, but the comment about changing from list to direct matrix is 13th August. I don't understand enough to judge that.

@nielsmh nielsmh force-pushed the nielsmh:indcargonum branch from c2515fe to 1b0f879 Sep 18, 2018

@nielsmh

This comment has been minimized.

Copy link
Contributor Author

commented Sep 18, 2018

Bumped savegame version again and squashed the various changes since last squashing. Since @andythenorth claims to have tested the callback functionality and found it working, I think this should be ready for a final review. @frosch123 ?

@LordAro LordAro requested a review from frosch123 Sep 19, 2018

@nielsmh
Copy link
Contributor Author

left a comment

Looking over the code again there's definitely things to improve.

Show resolved Hide resolved src/industry_cmd.cpp Outdated
Show resolved Hide resolved src/industry_cmd.cpp Outdated
Show resolved Hide resolved src/industry_cmd.cpp Outdated
CargoID cargo = GetCargoTranslation(GB(res, 0, 8), indspec->grf_prop.grffile);
if (std::find(indspec->accepts_cargo, endof(indspec->accepts_cargo), cargo) == endof(indspec->accepts_cargo)) {
/* Cargo not in spec, error in NewGRF */
ErrorUnknownCallbackResult(indspec->grf_prop.grffile->grfid, CBID_INDUSTRY_INPUT_CARGO_TYPES, res);

This comment has been minimized.

Copy link
@nielsmh

nielsmh Oct 7, 2018

Author Contributor

I don't think I've actually tested that these error conditions trigger correctly.

}
if (std::find(i->accepts_cargo, i->accepts_cargo + j, cargo) == i->accepts_cargo + j) {
/* Duplicate cargo */
ErrorUnknownCallbackResult(indspec->grf_prop.grffile->grfid, CBID_INDUSTRY_INPUT_CARGO_TYPES, res);

This comment has been minimized.

Copy link
@nielsmh

nielsmh Oct 7, 2018

Author Contributor

Haven't tested this error conditions triggers correctly.

Show resolved Hide resolved src/newgrf_industries.cpp
Show resolved Hide resolved src/subsidy.cpp Outdated
Show resolved Hide resolved src/table/build_industry.h
int num_cargos = 0;
uint cargo_index;
for (cargo_index = 0; cargo_index < lengthof(src_ind->produced_cargo); cargo_index++) {
if (src_ind->produced_cargo[cargo_index] != CT_INVALID) num_cargos++;

This comment has been minimized.

Copy link
@nielsmh

nielsmh Oct 7, 2018

Author Contributor

Why such a weird algorithm to select a random cargo type. Could as well add valid types to a std::vector and select an element from that.

Show resolved Hide resolved src/table/newgrf_debug_data.h Outdated
Show resolved Hide resolved src/industry_cmd.cpp Outdated
Show resolved Hide resolved src/industry_cmd.cpp Outdated
Show resolved Hide resolved src/industry_cmd.cpp Outdated
Show resolved Hide resolved src/industry_cmd.cpp Outdated
Show resolved Hide resolved src/industry_gui.cpp
Show resolved Hide resolved src/newgrf.cpp Outdated
Show resolved Hide resolved src/newgrf_industries.cpp Outdated
Show resolved Hide resolved src/newgrf_industries.cpp Outdated
Show resolved Hide resolved src/newgrf_industries.cpp Outdated
Show resolved Hide resolved src/table/newgrf_debug_data.h Outdated
Show resolved Hide resolved src/newgrf.cpp Outdated
Show resolved Hide resolved src/newgrf.cpp Outdated

@nielsmh nielsmh force-pushed the nielsmh:indcargonum branch from 7f57cf5 to 2284aa7 Nov 3, 2018

All points should be addressed now

@nielsmh nielsmh merged commit 9b560ea into OpenTTD:master Nov 3, 2018

6 checks passed

continuous-integration/jenkins/pr-head This commit looks good
Details
openttd/commit-checker The commit looks good
Details
openttd/linux-amd64-clang-3.8 The commit looks good
Details
openttd/linux-amd64-gcc-6 The commit looks good
Details
openttd/linux-i386-gcc-6 The commit looks good
Details
openttd/osx-10.9 The commit looks good
Details

@nielsmh nielsmh deleted the nielsmh:indcargonum branch Jan 5, 2019

@Eddi-z

This comment has been minimized.

Copy link
Contributor

commented Mar 24, 2019

New VA2 variables for industries:

* All of these variables require a parameter indicating the cargo id being queried.

there seem to be a few vars missing here.

New Var Old Var Description
88, 89
69 8A, 8C Amount of produced cargo waiting to be transported.
8E, 8F
90, 91, 92
6A 94, 96 Amount of cargo produced this month.
6B 98, 9A Amount of cargo transported this month.
9C, 9D
6C 9E, A0 Amount of cargo produced last month.
6D A2, A4 Amount of cargo transported last month.
6E (B4) Date cargo was last delivered to the industry.
6F 40, 41, 42 Amount of delivered cargo waiting to be processed.

Eddi-z added a commit to Eddi-z/OpenTTD that referenced this pull request Mar 24, 2019

Eddi-z added a commit to Eddi-z/OpenTTD that referenced this pull request Mar 24, 2019

PeterN added a commit that referenced this pull request Mar 27, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.