Captain_Chaos

Alright, I give up. What a disappointing response. This is the most cliquish, unhelpful, dismissive forum I've encountered in a long time. Not one of you took the time to understand the context, or gave me the benefit of the doubt and answered a simple question about the Forge API. All I got was high and mighty second guessing based on a cursory skim of my question as if I'm some kind of noob writing My First Mod. You'll all be glad to know that in the mean time I figured out an alternate way to achieve my goal and I now have the complete ID to name mapping which according to you would either be impossible to get, or herald the End Times. Thanks for your time.

@diesieben07, unfortunately not, as your advice is based on a lack of understanding of the context. Do you know the answer to my question?

@diesieben07, thanks for the advice. Do you know the answer to my question?

@jabelar, thanks. WorldPainter (which is not a mod) has existed since 2011 and you can still load world files from back then, and it can still export worlds to Minecraft 1.1 (not a typo), so I know a little bit about versioning, converting block IDs, etc. I want to use registry names within a version, but I also want to correlate them to the block IDs and data values of previous versions, for various valid reasons which I've tried to explain, and are of no relevance here anyway. I'm only using Forge temporarily in order to get this information from Minecraft. None of this is relevant to my actual question, which has nothing to do with integers, converters, etc.. I just gave this information for background, which I can now see was a mistake. I'm also not looking for programming advice. Would it be possible for someone to address the question I'm actually asking? Many thanks in advance!

@diesieben07, that implies that WorldPainter would just have to keep creating 1.12.2 maps forever, relying on Minecraft to convert them to 1.13 and later and never supporting any new blocks or other features past version 1.12.2. I hope you can see that that would not be very satisfactory. Perhaps it would clarify things to take a look at WorldPainter (I've linked it in my previous message) to see what it does exactly, and why I might like to map the block IDs and data values currently used on disk by Minecraft to the names and properties it will use from version 1.13, for instance so that it can load existing worlds yet export them to MC 1.13, keep supporting exports to pre-1.13 MC, etc., etc.

@diesieben07, let me explain in more detail what I'm doing. I'm the author of WorldPainter, a map generator for Minecraft. It's a stand-alone program that generates Minecraft chunks directly to create a Minecraft map according to your own design which you can then load in Minecraft to play in. Minecraft (up to now) stores blocks and their states on disk as block IDs and data values. There are no block names or properties (at least not in a vanilla map), so I couldn't use those if I wanted to. I really do need to touch integer IDs. Minecraft 1.13 however will store blocks by their names and properties. I would like WorldPainter to provide continuity between pre- and post 1.13 versions of Minecraft, so I want to correlate the pre-1.13 block ID and data values with their corresponding post-1.13 block names and states. For vanilla blocks only, I'm not trying to support mod blocks. This mod I'm creating isn't intended as an actual mod to be used by anyone, I'm just using it as the quickest and easiest way to invoke the Minecraft API and interrogate its block database to establish this mapping (on the assumption that the names and states already used at runtime by MC 1.12.2 will be how they will be stored on disk by MC 1.13, which seems reasonable). I've already implemented the part everybody keeps telling me won't ever work, which is retrieving all the block names and states for every valid combo of block ID and data value and writing them to a file. This just leaves the actual question I asked, which is if there is a way of determining which of the properties contained in the block states are ephemeral properties that are not stored on disk but calculated at runtime, such as the two examples I gave?

@Draco18s thanks for your reply! I should perhaps clarify what I'm trying to do. For vanilla blocks, the block ID's and data values are guaranteed to be the same from save to save, because that's how Minecraft stores them on disk (for now). The reason I'm getting the blocks and block states this way is because I need a mapping from vanilla block ID and data value to block name and properties. This is not relevant to my actual question however, which is if there is a way to know which properties are runtime or transient properties which are not stored in the chunks. BlockStateContainer.getValidStates() returns all of them, including transient properties.

Hello everyone, I'm writing a mod to dump Minecraft's block database to a file, to get canonical data to use in WorldPainter (a map generator I've created). I'm using Block.getBlockById(int) to get each block, then getStateFromMeta(int) to get all the possible states and then getProperties() to get the properties of each state. I'm most of the way there, but one hiccup I'm encountering is that some of the block state properties are transient/runtime properties which are not saved to disk (if I understand correctly). Examples would be the snowy property of Dirt blocks and the occupied property of Bed blocks. These properties are not of interest to WorldPainter, so I would like to filter them out. Is there a way to tell which properties are transient/runtime and will not be saved to disk, so I can skip those? Many thanks in advance for any assistance! Cheers, Captain_Chaos