Houses - substitute, override and other properties

[TadeuszD]

I need some explanation for this properties.
The 'substitute' property for me is clear: this is ID of the original home which will be displayed when the current house is not available. One original ID can be used in many houses. Am I right?
But I have a few question about 'override' property. Documentation says that this property is used for replacing original house. It is ignored, if the original house has already been overridden. What happens if two houses in my set overrides the one original house? The second house should never appear in the game? What should happen if the 'override' property is not set at all?
And the last question - can I safely override the original house defined for temperate climate with my house dedicated for another climate?

[PikkaBird]

What happens if two houses in my set overrides the one original house?

It is ignored, if the original house has already been overridden.

For the rest, may I suggest trying it and seeing what happens? The property seems fairly self-explanatory to me - come back to us if something does something unexpected.

[TadeuszD]

...come back to us if something does something unexpected.

Yes, I tried before... I overrode one original house by two my houses using 'override' property with the same value, and... both houses are visible in the game. I don't understand why?

[planetmaker]

...come back to us if something does something unexpected.

Yes... I override one original house by two my houses using 'override' property with the same value, and... both houses are visible in the game. I don't understand why?

The "substitute" property is defining a fallback houseID should your NewGRF for some reason not be available upon map load. The "override" property disables the default house with that ID and your house is used instead with the properties as you define it. If you use the "override" property in another house, there is no default house anymore to disable, thus you'll simply define a new house instead.

[TadeuszD]

If you use the "override" property in another house, there is no default house anymore to disable, thus you'll simply define a new house instead.

Thanks! If I good understand, 'override' property is not necessary? If I omit this property, both types of houses (original and delivered by my set) will be used by the game?

[planetmaker]

If you use the "override" property in another house, there is no default house anymore to disable, thus you'll simply define a new house instead.

Thanks! If I good understand, 'override' property is not necessary? If I omit this property, both types of houses (original and delivered by my set) will be used by the game?

That's my understanding. yes.

[TadeuszD]

Thanks!

[frosch]

There is a difference between "disabling" a house, and "overriding" one.

A) Disabling:
This is done by setting property 08 to FF for the id of the original house. The "id of the original house" is in this case defined by the id in the action 0. Usually this is a GRF local id for your own houses, but in the very special case of setting property 08 to FF it is something entirely different. [1] (Setting property 08 to FF for id 01 disables the original house 01, setting property 08 to something else for id 01 defines a new house.)

B) Overriding:
This replaces the original house with the id specified in the property with your new house. That is, you do not add a new house, but you replace the original one. (If it was already replaced, you define a new house).


The difference between (A) disabling an original house and adding a new one, and (B) replacing an original house, matters in the theoretical case that you change NewGRF in a game. Disabling a house will stop it from being spawned, but existing houses still remain. Replacing a house will make your new graphics appear in place of the old ones.

[1] If you think that it is stupid and confusing to use something for completely different purposes, welcome to assembler programming. Do not do this at home.

[TadeuszD]

Thanks for all explanations.
I have another question about houses - what means the negative value for goods/food acceptance (http://newgrf-specs.tt-wiki.net/wiki/DefaultHouseProps)?

[Eddi]

positive: accept goods
negative: accept food

[TadeuszD]

I have question about 'cargo_type_accept' callback. This callback requires return value calculated as type1 + (type2 << 5) + (type3 << 10). What is a type1..3? Can I use labels from my cargotable for calculating this value?

Code: Select all

cargotable {  PASS, MAIL, GOOD, FOOD  }

item(FEAT_HOUSES, ...) {
    graphics {
        cargo_type_accept:  return PASS + (MAIL << 5) + (FOOD << 10);
    }
}

[frosch]

Yes, you can. It will only work for the first 32 items in the table though.

[TadeuszD]

...only work for the first 32 items in the table though.

Of course. Only 5 bits are available for cargo type.

[TadeuszD]

Next question...
I want to create the building compatible with Snowline Mod NewGRF. It means that the building must have at least two graphics (normal and snowy) and the correct graphics must be choosen according to current snowline high or ground tile type.

The simplest method is using graphics callback and switch:

Code: Select all

switch (FEAT_HOUSES, SELF, switch_house_graphics, terrain_type) {
    TILETYPE_SNOW: return spritelayout_house_snow;
    return spritelayout_house_normal;
}

But using this method I found some glitches. For example, only half of the building was repainted at the moment when snowline was changed.
How can I erase these glitches? Is it possible? I'm thinking about using animation frames, but I'm afraid about the resultant performance...

[planetmaker]

Next question...
I want to create the building compatible with Snowline Mod NewGRF. It means that the building must have at least two graphics (normal and snowy) and the correct graphics must be choosen according to current snowline high or ground tile type.

The simplest method is using graphics callback and switch:

Code: Select all

switch (FEAT_HOUSES, SELF, switch_house_graphics, terrain_type) {
    TILETYPE_SNOW: return spritelayout_house_snow;
    return spritelayout_house_normal;
}

But using this method I found some glitches. For example, only half of the building was repainted at the moment when snowline was changed.
How can I erase these glitches? Is it possible? I'm thinking about using animation frames, but I'm afraid about the resultant performance...

Hm, it should not glitch. But maybe it's better to check for the snowline height:
https://rhodecode.openttdcoop.org/ogfx- ... .pnml#L418

Are we talking a multi-tile house? Then you might want to check consistently this property for the Northern most tile.

[TadeuszD]

Are we talking a multi-tile house?

No, I'm talking about single-tile house. These glitches appears very rarely. But I'm lucky man - and I catched a few glitches in one screenshot!
Glitches are arranged in regular patterns. I think their appearance is associated with "dirty blocks" and viewport repainting process.

[Eddi]

that might be because your bounding box is set incorrectly

[TadeuszD]

that might be because your bounding box is set incorrectly

All bounding boxes in spritelayouts are set correctly. The zextent property is set to the high of the building (not sprite) in pixels.

[frosch]

This happens for all houses, industries, objects and stuff.

Tiles are drawn only when OTTD decides that they need redrawing. For ground tiles the tile loop detects that the snow density changes (which happens after the snowline changed), and triggers redrawing.

For NewGRF stuff there is no trigger for redrawing, since noone knows when a NewGRF changes graphics.

(Btw. the bounding box has nothing to do with this at all. Bounding boxes are only used to sort sprites, not to decide drawing.)

[Eddi]

maybe this helps then: http://newgrf-specs.tt-wiki.net/wiki/Gl ... 95.2C96.29