squirrel script - building_desc_x.get_available_stations waytype filter

[Andarix]

Simutrans r11871

Despite specifying Waytype 0, objects with other waytypes are also returned.

Code Select Expand

list = building_desc_x.get_available_stations(building_desc_x.station_extension, 0, good_desc_x(good))
good is "Post"

pak64


pak64.german

[victor_18993]

I had a look at this. The behaviour is actually by design: waytype 0 means "all
waytypes" here, so getting entries of other waytypes back is expected.

In the script API, `wt_all` is defined as `ignore_wt`, which is 0 (api_const.cc:
`enum_slot(vm, "wt_all", ignore_wt);`). And get_available_stations treats 0 as the
catch-all:

    // ...
    bool accept_all_wt = wt == invalid_wt || wt == ignore_wt;  // ignore_wt == 0
    // ...
    && (accept_all_wt || desc->get_extra() == (uint32)wt)

So `get_available_stations(station_extension, 0, good)` deliberately returns every
matching building regardless of waytype (the API changelog even lists "Changed
get_available_stations to accept wt_all"). To filter, pass a concrete waytype, e.g.
`wt_road`, `wt_water`, etc., instead of 0.

The reason this is confusing is a wrong comment in the function itself, which says
wt_all "is equal to invalid_wt". It is not — api_const.cc maps wt_all to ignore_wt
(0); invalid_wt is -1 (both are accepted, but the equality claim is wrong). I've
attached a one-line, behaviour-neutral comment fix that states this correctly.

One caveat for station extensions specifically: extensions are normally
waytype-agnostic (their stored waytype is ignore_wt / 0), so filtering by a concrete
waytype tends to return nothing for them, and 0 (wt_all) is really the only way to
list them. Because wt_all and ignore_wt are the same value (0), there is no way to
ask for "only the waytype-agnostic ones" — that is the known overlap flagged by the
FIXME on `ignore_wt` in simtypes.h. Changing that would be an API change (moving
wt_all off 0), which is a maintainer decision; the comment fix alone does not touch
behaviour.

[Yona-TYT]

I'm not very familiar with pak parameters, but shouldn't extension buildings have a waytype value = 0?.

[victor_18993]

Yona is right, and I think this explains the other half of the problem.
Looking at

Code Select Expand

building_writer.cc, an extension keeps waytype 0 when its

Code Select Expand

.dat file does not include a

Code Select Expand

waytype line:

Code Select Expand

else if (!STRICMP(type_name, "extension")) {
type = building_desc_t::generic_extension;
const char *wt = obj.get("waytype");
if(wt && *wt>' ') {
// no waytype => just a generic extension that fits all
extra_data = get_waytype(wt);
}
}
The important part is the comment: for extensions, 0 means that the building is generic and "fits all". It is not just an empty or invalid value.
The problem appears when this is compared with the filter in

Code Select Expand

api_obj_desc.cc:

Code Select Expand

bool accept_all_wt = wt == invalid_wt || wt == ignore_wt;
...
&& (accept_all_wt || desc->get_extra()==(uint32)wt)
When 0 is passed as the query, the filter accepts everything, which is what Andarix encountered.
But when a specific waytype is passed, such as road, the generic extensions are rejected because their stored value is still 0. So the writer says that 0 means "fits every waytype", while the filter effectively treats it as "does not match this waytype".
I checked pak128 and pak64 to see whether this has any real effect.
In pak128 there are 53 station extensions:

Code Select Expand

no waytype line (extra = 0, "fits all") 27
waytype=air 25
waytype=monorail_track 1
In pak64 there are 25:

Code Select Expand

extra = 0 ("fits all") 7
extra = 2 track 9
extra = 16 air 8
extra = 5 monorail 1
Neither pakset has an extension explicitly marked as road.
That means a road query returns no station extensions at all, even though the generic ones should probably be valid results. In pak128, the same issue also affects rail, water and tram.
So there seem to be two opposite behaviours:

• Passing 0 returns too many results.
• Passing a concrete waytype can return too few results, or none at all.

A possible fix would be to also accept descriptors whose stored waytype is 0:

Code Select Expand

&& (accept_all_wt || desc->get_extra()==(uint32)wt || desc->get_extra()==0)
I have not turned this into a patch yet because I am not sure how broad the exception should be. It could apply to all building descriptors, or only to

Code Select Expand

generic_extension, where 0 is explicitly documented as "fits all".
I also have not tested the query directly in-game yet. The result above comes from following the writer and filter logic and checking the pakset data. The pak64 values were read from the compiled pak files because I could not find its sources on GitHub, but all 291 building nodes were parsed successfully without any being skipped.

[Yona-TYT]

After doing some research, it seems the menus for building stations/extension buildings are organized according to waytype, so perhaps that's why it's not 0, since in some cases it needs to appear in a specific menu; for example, airport terminals only appear in the Aircraft menu.

We'd have to find a solution that takes this into account.

Edit.
Previously, in Simutrans it didn't matter if it was a building extension for an airport or trains; both worked without any restrictions for any waytype. I suppose this is still the case today? Would it be a good idea to put restrictions on waytypes? We should discuss this.

[victor_18993]

Yes, exactly — and that is why I would not remove or ignore the specific waytype stored by an extension.
An airport terminal with

Code Select Expand

waytype=air should still only appear for air. The issue is only with extensions that have no waytype line at all, because the writer explicitly treats those as generic extensions that "fit all".
So the intended behaviour would be:

• an extension with
  
  Code Select Expand
  waytype=air matches air only;
• an extension with
  
  Code Select Expand
  waytype=track matches track only;
• an extension with no waytype line, and therefore
  
  Code Select Expand
  extra = 0, matches any concrete waytype.

That would preserve the airport terminal case you mention, while also allowing genuinely generic extensions to appear in road, rail or other relevant queries.
I think the safest change would therefore be to handle

Code Select Expand

extra = 0 as "fits all" only for

Code Select Expand

generic_extension, rather than applying that meaning to every building type.
Your example is useful because it shows why the fix needs to be narrow, not a general relaxation of the filter.

[Yona-TYT]

Previously, in Simutrans it didn't matter if it was a building extension for an airport or trains; both worked without any restrictions for any waytype. I suppose this is still the case today? Would it be a good idea to put restrictions on waytypes? We should discuss this.

For example, a control tower looks very out of place without a jetway for airplanes (no air connection).

[Andarix]

The "waytype" attribute for extensions is essentially responsible only for their placement within the menus.

If no waytype is specified, the extension is placed in the special menu.

Wiki - Buildings def - waytype

The expectation was simply that if `waytype 0` is explicitly specified, only those buildings would be returned just as `wt_rail` yields only buildings from the railway menu.

The post office building is also just a fallback for cases where there is no extension featuring a field for the waytype; as far as I know, post office buildings are included in every pakset.

So the question arises as to how `wt_all` should be viewed:

- Should `wt_all` return only what was explicitly defined without a `waytype`?
- Should `wt_all` return everything that is permitted, even if it is intended for a different `waytype`?

In the case of extensions, the `waytype` does not actually restrict construction but merely serves as a visual classification.

[Andarix]

....
 The pak64 values were read from the compiled pak files because I could not find its sources on GitHub, but all 291 building nodes were parsed successfully without any being skipped.

https://sourceforge.net/p/simutrans/code/HEAD/tree/