Trying to genereate some ores from Immersive Engineering, they all use the block immersiveengineering;ore with the meta-tag of 0 - 5. However, trying to specify a decoration like this:

dec = newOreDecoration()
dec.set("mainBlock", "immersiveengineering:ore:1")
dec.set("size", 8)
dec.set("count", 4)
dec.set("minY", 44)
dec.set("maxY", 72)
dry_hills.addDecoration(dec)

Fails with the error -- No block found for resource location immersiveengineering:ore:1

Is there another way to specify meta data with decorations?

https://github.com/superckl/BiomeTweaker/wiki/Using-BlockStates

Please thoroughly research the topic before you open an issue about it. If you have questions like this (rather than an actual bug or issue), please join the discord channel. You can find the link on the wiki.

Sorry, badly phrased issue... What I was meaning to say here was an improvement to support that syntax without having to create a block object and set the property only to use it once.

This request has been raised many times, but I will not implement it. Metadata is meant as an internal-only value that should not be exposed to the user. It is the fault of the authors of the mod if they expose them to identify their blocks to users. This has been the standard for several versions now, and I will not add a special exception to break it. I use default Minecraft/Forge methods for parsing block resource locations.

If you are having trouble finding property information, ask the mod author, or ask in the discord channel and we can help you find it. You can also view it in the debug info screen in-game.

Reading that response was painful. I'm so sorry you had to receive that Clubpetey. Also thanks for making sure I know the lay of the land.

It certainly isn't conforming to minecraft/Forge standards to do things this way. I do a lot of custom stuff with various mods and nobody else does things like this.

That is why Superckl is getting the request raised MANY times. It is jarring to come to this mod after scripting things to the same standard in every other mod you use. This is an awesome mod, and I'll do things however Superckl wants but . . . I certainly am not going to complain to anyone else.

If I hadn't seen this I would be bothering Superckl. Most likely I would have called it a bug. . . I wouldn't even have looked for some alternative method that requires me to essentially code a compound object and insert it using a variable.

Forge is an intermediary between Minecraft and mod makers that makes things easier on you. It doesn't set community standards for the modding community, and certainly not for pack makers, many of whom aren't even programmers.

You have to deal with Forge's standards as a mod maker in the same way I have to code a compound object and insert it into my code using a variable if I want to use BiomeTweaker . . . it may suck but the person making an application sets the standard for those directly using it. If you want to use forge you conform to their standard. Otherwise, maybe you write a spigot plugin or whatever.

But I don't work with forge. I mostly work with Json files, Config files, and Zenscript. That's the life of a modpack maker rather than a mod maker.

If I want to use Zenscript the standard changes . . . and that is a community standard with commands like "MT hand" and tools like the Creative Probe making accessing the data simple and easy. Most Json files and configuration files conform to this format as well.

To be fair it's easy enough to find the data you want using the F3 debugging screen in Minecraft, or by looking inside the code of a mod . . . but I'm autistic and wrote my first line of code at five. For most people, the method you are using is MORE abstract. Spaghetti naming is just as bad as spaghetti coding. lol

But the real problem here isn't the data used, it is the fact that it is inserted in such a clumsy way. Using modID:ObjectName:meta is a very quick thing for me to write out in between doing other things. It also keeps all the relevant data right in my face if I have a problem pop up or just want to change things six months later.

Contrast that to me having to define a variable on one line, and comment it so it is readable later . . . then write two lines of code that create a compound object . . . and finally, I have to insert my variable into the code wherever I'd normally place an item ID. It takes up ten times as much space and that makes my code longer and less readable . . . and if I put the variable in the wrong spot it's harder to spot a mistake . . . and there are more places I could have screwed up.

People might be jarred but I doubt they would complain as much if you simply used modID:ItemName:VariantName as the standard way of instantly defining an object. The compounding method is more powerful . . . but it only makes sense for complex objects like the "set" command used for defining Biomes and Decorations.

Even then it would be nice if there were a simple command such as "/BT Debug " which would print out the entire listing for our object so we could read it . . . especially if it highlighted errors, and pointed out where standard info had been inserted versus what we had put in ourselves.

I was using /JED Debug for a custom dimension the other day and it was a lifesaver when it came to tracking down a variable I had assigned to the wrong place. lol

I'm fortunate in that my autistic brain works well with a lot of this, and I'm retired so my schedule has a lot of time for fiddling with things and getting them to work . . . but I'm also a husband and father and my time isn't infinite. Most people, most of the time, want to be able to keep their code short, easy to read, and as simple to write and debug as possible. K.I.S.S: Keep it simple for stupid. lol

My current project has 180 mods. All of them have a config, some have a JSON, a Zenscript or 10, maybe a structure file. You wouldn't beleive the amount of organization I use to make sure everything is on track and backed up. Jarring, different, and longer are never my favorite words. lol

I hope that makes some sense. :)

There are several rebuttals I could make to your argument here, but I'm not going to go into a length discussion in a Github issue. We can talk more about this through Discord if you like.

There are many things I would like to do to make BiomeTweaker more accessible, but my time is also finite. Perhaps my most desired feature is a scripting GUI that will assist with precisely these issues so users don't have to learn many different standards. But again, limited time and no collaborators makes that pretty much a pipe dream.

If you would like to raise a question about standards, I can refer you to the official mcforge guide:

https://mcforge.readthedocs.io/en/latest/blocks/states/

To quote, "In Minecraft 1.8 and above, direct manipulation of blocks and metadata values have been abstracted away into what is known as blockstates. The premise of the system is to remove the usage and manipulation of raw metadata numbers, which are nondescript and carry no meaning."

I'm sorry if you are finding my responses jarring. I am being terse here because of the exact points you have made being made many times over. It is the standard defined by forge. Metadata values should not be exposed.