Problems with NML Houses

[YSH]

I've been trying to code a house using NML, but instead of the house it just glitches. I've looked trough the code a few times, but can't see any obvious mistakes. I'm assuming it has something to do with the bounding box, since it doesn't have one in the developer mode. The sprite however is loaded in the game, as visible in the alignment tool. So I would like to ask if someone can point me to the error in the code:

Code: Select all

grf {
	grfid: "NLHS";
	name: string(STR_GRF_NAME);
	desc: string(STR_GRF_DESC);
	version: 0;
	min_compatible_version: 0;
}

spriteset (spriteset_townhouse, "gfx/townhouse2.png") {
	[0,0]
	}
	
spritelayout spritelayout_townhouse {
	ground { 
		sprite: GROUNDSPRITE_NORMAL; 
	}
	building {
		sprite: spriteset_townhouse;
		xextent: 8;
		yextent: 16;
		zextent: 27;
		xoffset: 0;
		yoffset: 0;
		zoffset: 0;
	}
}
item (FEAT_HOUSES, item_townhouse, HOUSE_SIZE_1X1) {
	property {
		substitute: 06;
		override: 06;
		probability: 4;
		name: string(STR_TWN30);
	}

	graphics {
		default: spritelayout_townhouse;
	}
}

Update: I've added the grf, in case that helps.

[Eddi]

your spriteset doesn't seem to contain any sprites... you can't just pass a .png filename, you also have to give position and size of each sprite contained in the image.

[YSH]

The image contains just the one sprite, so I left the position out. According to the wiki, the whole image will then be used.

[Eddi]

ok, then at least your offsets are totally wrong.

for houses, the anchor point is the back corner of the tile, so you should pick this pixel in the image editor, and put the negative value of that into the offsets. (or use the ingame sprite aligner to find out the correct offsets, which you find in the ?-menu if you turn on newgrf developer tools)

[YSH]

I tried that, but it just glitches. Also, if it had to do with the offset, shouldn't it just show GROUNDSPRITE_NORMAL?

Geen naam, 30 Jan 1940.png (45.87 KiB) Viewed 890 times

[Eddi]

i'm sorry, that exceeds my knowledge then.

what i can assure you is that it has nothing to do with the bounding box, as that only defines in which order the sprites are drawn, but your issues are because the sprite is not drawn at all (or in the completely wrong place)

[PikkaBird]

On decoding the GRF, it appears NML thinks that it can write house action 0s using extended IDs (it has "FF 00 00" as the ID instead of "00"). It is wrong to think this. Only sound effects and vehicles may use extended IDs.
(Also I really enjoyed the var2 it sticks in there. NML is brilliant. )

[Eddi]

Only sound effects and vehicles may use extended IDs.

i'm not seeing this bit of information in the specs: http://newgrf-specs.tt-wiki.net/wiki/Action0

[planetmaker]

On decoding the GRF, it appears NML thinks that it can write house action 0s using extended IDs (it has "FF 00 00" as the ID instead of "00"). It is wrong to think this. Only sound effects and vehicles may use extended IDs.

(Also I really enjoyed the var2 it sticks in there. NML is brilliant. )

That seems not quite accurate.

OpenTTD allows by specs definition and in the code itself (newgrf.cpp:47236) Action0 IDs as extended byte for every feature. But it limits the permissible IDs to a different maximum depending on the actual feature (for houses in newgrf.cpp:2186).
NML makes use of this and fails correctly when the feature-specific maximum ID is surpassed.

[PikkaBird]

Alright then. I don't know why it doesn't work, unless ID 00 and FF 00 00 are different. The problem seems to be that it's not even drawing the ground tile.

[YSH]

I see, it's most likely a problem with NML itself. I'll try grfmaker then.

[PikkaBird]

I see, it's most likely a problem with NML itself. I'll try grfmaker then.

Don't do that...

[kamnet]

I see, it's most likely a problem with NML itself. I'll try grfmaker then.

Don't do that...

Some people, when confronted with a problem, think “I know, I'll use GRFMaker!” Now they have two problems.

[planetmaker]

I played around a bit with your code and in comparison with the test house from NML's regression test.

Something definitely is fishy in NML and your code looks ok. Your code works, if you add a line to your graphics block:

Code: Select all

   graphics {
      default: spritelayout_townhouse;
      anim_next_frame: 0;
   }

Of course that should not be needed, but for now it might solve your problem.

[YSH]

Don't do that...

Well, it sort of works.

But luckily, setting the animation frame, while not elegant, does indeed solve the problems.

[YSH]

I've encountered some more problems, that I assume are NML's fault. When making a grf with multiple houses in it, only the last one in the code shows up in the game. The code of the houses is completely identical save the id's and some minor details, nothing that could/should cause this. The code is a bit long to paste here, so both nml file and grf are attached.

[planetmaker]

It would be helpful if you also provide the lang and graphics files so that one actually can compile the nml into a NewGRF oneself as well.

What NML version do you use?

[YSH]

Version 0.3.0.r2071 (the latest nightly).

[YSH]

I've been working with this again, and using the latest nightly of NML (r2093) I'm still encountering some issues.

Firstly, the same issue with only one house showing up in the game, even though more than one is in the grf. I've decoded the grf and so far as I can tell, the nfo shows that it does indeed contain more than one house. Could someone tell me what's going wrong here?

Code: Select all

   56 * 43	 00 07 0E 01 FF 00 00 08 06 0A 0A 1E 21 8A 07 22 9E 07 1F 32 0B 1E 13 0F F0 0D 04 0E 01 0F 00 1E
	 00 01 FF 00 18 A0 12 00 DC 1C 0A
   57 * 11	 00 07 02 01 FF 00 00 14 01 1D 00
   58 * 37	 02 07 FC 89 1A 20 00 00 00 00 \2sto 1A 20 FF 00 00 00 \2rst 0C 00 FF FF 00 00 01 F8 00 17 00 00 00 17
	 00 00 00 FC 00
   59 * 7	 03 07 01 00 00 FC 00
   60 * 43	 00 07 0E 01 FF 00 00 08 05 0A 00 00 21 58 07 22 6C 07 1F 32 0B 28 13 0F F0 0D 04 0E 01 0F 00 1E
	 00 01 FF 00 18 A0 12 01 DC 1C 0B
   61 * 11	 00 07 02 01 FF 00 00 14 01 1D 00
   62 * 37	 02 07 FB 89 1A 20 00 00 00 00 \2sto 1A 20 FF 00 00 00 \2rst 0C 00 FF FF 00 00 01 F8 00 17 00 00 00 17
	 00 00 00 FB 00
   63 * 7	 03 07 01 00 00 FB 00
   64 * 43	 00 07 0E 01 FF 00 00 08 04 0A 00 00 21 58 07 22 6C 07 1F 32 0B 28 13 0F F0 0D 04 0E 01 0F 00 1E
	 00 01 FF 00 18 A0 12 01 DC 1C 0B
   65 * 11	 00 07 02 01 FF 00 00 14 01 1D 00
   66 * 37	 02 07 FA 89 1A 20 00 00 00 00 \2sto 1A 20 FF 00 00 00 \2rst 0C 00 FF FF 00 00 01 F7 00 17 00 00 00 17
	 00 00 00 FA 00
   67 * 7	 03 07 01 00 00 FA 00
   68 * 43	 00 07 0E 01 FF 00 00 08 04 0A "(<!¿" 07 22 BC 07 1F 32 0B 96 13 0F F0 0D 08 0E 03 0F 00 1E
	 00 01 FF 00 18 A0 12 02 DC 1C 0D
   69 * 11	 00 07 02 01 FF 00 00 14 01 1D 00
   70 * 37	 02 07 F9 89 1A 20 00 00 00 00 \2sto 1A 20 FF 00 00 00 \2rst 0C 00 FF FF 00 00 01 F6 00 17 00 00 00 17
	 00 00 00 F9 00
   71 * 7	 03 07 01 00 00 F9 00

The second issue has to do with multi-tile houses. This code:

Code: Select all

item (FEAT_HOUSES, item_revolutie1S, HOUSE_SIZE_1X2)
{
	property 
	{
      substitute: 07;

gives me this warning, even though house 07 is 1x2 according to the wiki.

Code: Select all

nmlc ERROR: "nlhsrev.nml", line 55: Substitute / override house type must have the same size as the newly defined house.

[Andrew350]

The problem of all the houses not showing up seems to be because you aren't setting a house id in the item definitions. Adding one just before HOUSE_SIZE_1x1 seems to work:

item (FEAT_HOUSES, item_rij50, 01, HOUSE_SIZE_1X1) {
...
}

I'm not sure if that's working as intended or not, I just know it works

By the way, it looks to me like you really don't need the HOUSE_SIZE_XxX part, as long as the id you replace is the same size house (please correct me if I'm wrong). At least, defining a one-tile house without that parameter doesn't seem to cause any problems (as long as a matching substitute id is defined, anyway).