AtomicStryker's Infernal Mobs

AtomicStryker's Infernal Mobs

34M Downloads

[Ruins] PreserveBlocks/Prefixes (!?) in 1.14.*

Tiscan76 opened this issue ยท 12 comments

commented

I'm kinda new to template-making and I'm currently trying to create some templates for a 1.14.4 modpack.

While I figured out how to use Loottables and how to create Spawners, there doesn't seems to be a way to preserve exsisting blocks?

From what I understand, there were 3 ways to force the mod to preserve/replace blocks in the 1.12 and prior.

By using "preserveBlock" in a rule, or by making blocks foreground/background blocks using the question-/exclamation mark as a prefix in the block-name.

I tried a few things but can't get this to work. I even decided to take a look at the Java-file but as I don't know much Java i'm not sure if what i found is correct. As far as I can tell, 1.12 setup an array called "preservePolicy" in RuinTemplateRule.java which handled what blocks should be preserved. And this seems to be gone completely.

Sorry if i'm just missing something obvious.

commented

To QuarterAnimal:

I have tested the "!rule" "foreground block" notation which according to your docs:

"A "!" prefix does the opposite, creating a foreground

block which ONLY replaces air and preserved blocks."

It does not appear to work as intended in 1.14 (maybe i broke it?). A block with ! prefix overwrites everything in the world, both preserved blocks and those than aren't.

commented

Sorry...I'm just seeing this now. I'll get on it tonight.

commented

You can check RuleStringNbtHelper#StringFromBlockState - doing everything in a NBT compound is actually fully vanilla, and i intend to stick to it for compatibility reasons if nothing else.

As you can also see i've embedded the tile entity nbt as a tag inside the block nbt - so by all means feel free to embed your implementation metadata too.

commented

To AtomicStryker:
Yes, support for foreground/background blocks was, among other things (such as block weighting), removed as part of the 1.14 migration. I can add it back in, but I'm not sure implementing it as a !/? prefix is appropriate now--it seems you went the way of specifying everything within an NBT compound. Maybe you'd rather see a Ruins-specific tag within the block NBT for such stuff? That'd be more consistent with what you've already got and (arguably) more extensible. Let me know.

commented

Foreground air almost gets you where you want to go, but probably not quite. In addition to air, a foreground block clobbers leaves and snow, and--depending on other parameter settings--water, ice, and lava. (In the 1.12 version, wood blocks and most plants were also on the hit list, but it seems that's no longer the case.)

Anyway, I think what you really want here is the old preserveBlock directive, a special pseudo-block used in rules to mean "don't change whatever's already there." Usually a good choice for the outside space surrounding a Ruins structure, but looks like it's been removed.

commented

Thanks for the work you put into it.

Here is a little screenshot that shows why it is important to be able to keep blocks intact:

preserve

If I understand the foregorund/background correctly all I would have to do is fill the area around the house with "minecraft:air" that is set to be a foreground block. It would replace air with air and keep existing blocks.

commented

Yeah, I noticed that it's gone and you only mentioned fore-/background. That's why I said I would use the foreground-rule.

I somewhere read that the rules-parser basically ignores the number and only the order of the rules matters. So if the first line of your rule-definition says "rule123=...." it would use this as rule 1 and ignore the 123.

Probably it would be a good idea to change this and make it so that the number is actually parsed and used and you could nicely re-define rule-0 that way.

Then add foreground/background/preserve as attributes for blocks.

That way you could re-define rule0 as "minecraft:air" with "preserve:1" and it would act as in 1.12

commented

If i may offer a suggestion: I don't know how much the foreground/background system was used, if ever. Uhm ... keep it simplistic? And maybe consider a way to add it to the ingame parser (World2Template...).

Currently, you have to hit one of the "baseplate" blocks for a template to be parsed. You could define that the block directly on top of the initial block is the "preserveBlock" type or whatever you want to call it. Any matching block inthe template area is immediatly translated as a preserving rule.

Or do whatever you want. I won't stop you :)

commented

I'm putting both preserveBlock and foreground/background support--or equivalents thereof--back in. The preserveBlock directive isn't an attribute, though; it's a do-nothing pseudo-block. You'll see.

It doesn't have anything to do with this issue, but the idea of using the specified rule ID rather than basing it on the order in which rules are listed was proposed before. There was the risk of possibly breaking existing templates. Now that they've all been broken anyway, however, this might be the right time to reconsider. I'll submit something along those lines next week.

Incidentally, you can redefine rule0. At least you could in 1.12...I think it still works. The trick is to make the first rule in your template nameless--that will be rule0. For example:

=0,100,{Name:"air"}
rule1= ... etc.

It must precede all other rules, and it must be missing both the 'rule' keyword and an ID. Otherwise, it's the same as any other rule specification (e.g., it can have variants, though I'd be hard pressed to think of a situation where that'd be useful).

commented

To AtomicStryker:
I don't disagree--I think background blocks in particular are of dubious utility, especially since the blocks they preserve are hardcoded and rather arbitrary. Unless I'm missing something, I suspect preserveBlock is almost always an adequate--if not superior--choice. Foreground blocks can be useful for blending things into the terrain, but have some annoying limitations. Maybe that's a question to throw to the Forum. In any event, though, I do believe preserveBlock is indispensable, so I'll implement that first and hold off on foreground/background for now.

As for the ingame parser...as someone who never uses it, I can't say anything with authority. Listening to template authors in the Forum, however, I expect the simplest and most intuitive thing to do is just map air into preserveBlock. I think that's what they typically do--use a nonsense block to fill the interior space if necessary and edit the resulting template file to replace that block with air.

To Tiscan76:
Ruins and Recurrent Complex have very different fundamental design principles; I don't see the two mods converging any time soon. Each has its strengths and weaknesses. Still, that doesn't mean one can't be mined for interesting features to add to the other. I kind of like the "natural floor" idea, for example, and that'd pretty much obviate the need for foreground blocks.

I haven't really followed Ruins's post-1.12 migration until very recently, but I'm pretty sure you can already specify that a rule should use a particular loot table to fill a container. Ruins is, by design, a server-only mod, so you can't do it RC-style via a client GUI, but you can edit a template file to do it.

commented

I kinda like the system Recurrent Complex uses (at least as far as i can tell from the Wiki and 5 minutes of messing with it :-))

They add two new tabs to the game. One has a bunch of blocks in it that render as little colored cubes without a hitbox. They are used to define where "Natural Air" (inside of buildings/caves) is and stuff like this. So you would basically build your structure and then fill its inside with the "Natural Air" blocks. And I guess the area that should be preserved with "Natural Floor" blocks.

And they also add "proxy-items" for all loottables the mod can find to the second tab. You can then place these items inside of chests and that way the mod knows what loottable to use for that particular chest.

But that is basically "Ruins 2" material and not just a bugfix.

commented

In the next release, the ruins:null pseudoblock will be available as a do-nothing directive, leaving the existing block at that location unscathed. It can be used in rules just as any other block; for example...
rule7={Name:"cobblestone"}{Name:"ruins:null"}
...places a cobblestone block 50% of the time, and doesn't touch whatever's already there the other 50%. This is exactly the same as the old preserveBlock directive, just updated to current naming conventions. Note it's not a real block--you can't give yourself a ruins:null block in-game, for instance (why would you want to?)--it's actually an instruction to the Ruins mod to skip that block position.

I also changed the default rule0 to be ruins:null instead of minecraft:air, so you may get the benefits of block preservation without having to modify your templates at all just by using the latest release of the mod. I'm holding off on reinstating the foreground/background business for now, at least until there's interest expressed in it.