Post generation doesn't work when the post does not have a top sign

[Spoonerj1]

When the Top Sign is set to be blank in the config options, the plugin cannot identify the region post, and the region post continually gets rebuilt when the area is loaded/rechecked (I'm not sure when exactly the plugin rebuilds them) which creates very large towers.

A desired way to handle this would be to ignore blank signs or toggle them off/on in config. so hat the plugin is not checking for the sign, but the block assigned for posts

[Spoonerj1]

Referencing issue #71 as related

[RoboMWM]

As per title - I'm assuming the desired/expected behavior is that a blank sign should be placed?

[Spoonerj1]

No, desired behavior is that a blank sign is ignored and is not placed.

edited title

[RoboMWM]

I'm assuming that's the title you want - since I'm assuming the desired behavior (regarding sign generation) already occurs, yes? I believe your issue is with the post generation not working when there is no top sign present as part of the post.

[Spoonerj1]

Yeah, the main issue is that when the sign is not there, the post continues to regenerate a "new" post on top of the existing platform, creating giant towers at each location.

[RoboMWM]

Ok. The issue is just worded weirdly - just state the issue despite the fact I didn't know about this "feature" lol.

Actually... I think I know why this feature is here - probably so if you don't want the bottom signs to have anything, then they won't be placed (which is the case in your screenshot).

[Spoonerj1]

That works fine for the bottom signs, but the top sign is the one that causes the problem. I've added a sign back to my region posts in order to stop them from climbing upwards, but it would be better if these signs simply behaved the same way as the lower signs and the plugin didnt look for the sign to determine a post.
Would it be possible to have the plugin look for the top block that is defined in config?

[zedwick]

I think I can see the cause for this issue, which is the same for #71 .

Relevant code:

PopulationDensity/src/me/ryanhamshire/PopulationDensity/DataStore.java

Lines 529 to 540 in c59156a

	if (Tag.SIGNS.isTagged(blockType))
	{
	y -= 4;
	}
	// Changed check because of the refactor to the postdesign.
	else if (blockType == PopulationDensity.instance.postMaterialMidTop)
	{
	y -= 2;
	} else if (blockType == Material.BEDROCK)
	{
	y += 1;
	}

In the example given in this issue all three blocks of the post are all the same material, Where-as in #71 the block at the top of the post is a campfire which is different to the other blocks below it in the post. Neither example has a sign as far as I can see.

PD has rules which dictate the height of the base of the post depending on which material it finds at the highest block. If it's a sign, the base is 4 blocks below. If it's the same material as defined in"PopulationDensity.PostDesign.MidTopBlock" in the config then the base is 2 blocks below, and if it is bedrock then the base is one block above.

So in this case, it finds there is no sign, and then finds the top block matches the material for the mid block so builds the post 2 blocks lower (1 block above where it should be built.

In the case of #71 it finds there is no sign, and the top block does not match the material for the middle block, and it is not bedrock. So it does not change the height of the base block, overwriting the height block (the top of the post) with the new post base.

So the fix is likely going to be to check it matches the material of the top block ("PopulationDensity.PostDesign.TopBlock"/postMaterialTop) and to change the y of the base to y -= 3.

Issue likely introduced here:

128baeb#diff-d50870b19bf70b8d5e94dbaa463cc2ffL489

I'm not currently able to test any of this so am making a note here for I or anyone else who wants to have a go at fixing this.

[Spoonerj1]

bumping in case this could be done with 1.17 versions