GRF Tools » NewGRF Meta Language

1. Menu graphics are a problem (you already notice that, it needs special syntax or manual cb handling by the user)
2. I've thought about this before, but it takes the freedom away from the user to have different callback implementations per cargo type. Or a different callback implementation depending on the date. With this syntax the only way to do that is:
switch (cb_x, cur_date) {
0..1990: cb_x_1;
cb_x_2;
}
switch (cb_y, cur_date) {
0..1990: cb_y_1;
cb_y_2;
}
switch (callbacks, cb_num) { // This one is implied by nml, not manually written)
1: cb_x;
2: cb_y;
}

While if you leave it to the user he could do:
switch (callbacks_1, cb_num) {
1: cb_x_1;
2: cb_y_1;
}
switch (callbacks_2, cb_num) {
1: cb_x_2;
2: cb_y_2;
}
switch (callbacks, cur_date) {
0..1990: callbacks_1;
callbacks_2;
}

The difference is not so obvious with only 2 callbacks, but with 5 callbacks the need to not duplicate the 0..1990 check becomes more obvious.

In principle the user doesn't have to use this new scheme, if the current system fits better he is free to keep using it.

w.r.t. 1, they are already a problem. Exposing it is better than hiding it and confusing users later on, IMO.

To avoid point 2, I'd like to propose that 'return <expr>' also allows variables inside <expr>. I think this reduces the number of switch blocks needed for trivial callbacks. We could even allow this in the graphics block, just like it is possible to refer to sprite groups without an intermediary switch. This way, simple callbacks don't need any (explicit) switch block at all.

OK, agreed. We'll just need to make it very clear in the documentation that the menu graphics are a special case. I'm still not sure about automatically writing the callback flags. While that does make it easy it can also cause confusion if the user wrote the callback flags manually and they're overwritten by the compiler.

Allowing "return <expr>" including variables seems like a good idea, we could silently rewrite it in a switch-block. Basically it'd just be:
switch (..., <expr>) {
return; // Return computed value.
}

Before I make too many steps in this direction, I'd like to get a few issues ironed out. Please tell if you agree with my proposals:

- Callbacks with an equivalent property get the same name as the property
- If there is a separate callback for in the purchase list, it gets prefixed with "purchase_"
- 'default' and 'purchase' define the default and buy menu graphics. 'default_na' is additionally defined as type 0xFE for stations
- If there is a default defined in the graphics block, it is used for all unhandled callbacks. This to keep backward compatibility and allow manual callback handling. Else all unhandled callbacks chain to CB_FAILED.
- Cargo choice is handled via action3, i.e. one varaction2 per cargo. This, because there is no way (yet) to determine the cargo for stations.
- The existing railtype and purchase list pseudo-cargos will also need conversion to the new system. 'PURCHASE_LIST' will become 'purchase' and I suggest to make all railtype stuff lowercase. A (temporary) old->new conversion table with warnings should do in this case, IMO.

• basic implementation
• vehicles
• railtypes

• documentation
• regression testing
• stations
• houses
• industry tiles / industries
• airport tiles / airports
• cargos
• removing the old constants, when grfs are updated