HalestormXV

thank you for that link. it will be most helpful. and yes i want the structures to spawn in all biomes which i’ve already achieved by simply adding a .isEmpty() check the the code segment where it checks for valid biomes. The not spawning in the ocean is handled by the last getTopBlock function so it will assure that only designated blocks will allow structure spawns. Also nether and end biomes are automatically checked by the switch statement that these are nested in. This is mainly for knowledge sake and alternative options so i can work better with biomes and fetching them in and of themselves.

Wow, that makes perfect sense actually. An excellent piece of code. So once I call ModBiomes.registry.getValues() from my https://pastebin.com/SS42VEK4 on line 45 the Vaarg will be populated with all the registered singleton classes of biomes right?

Alright, so I probably used it wrong. So what would have to be done is this would have to be called and then all results stored into an array correct? And then in the code on line 45 you'd put in your array? Like I said, the .isEmpty() works fine and has the same effect, I am asking for my own knowledge sake.

Perfect, thank you very much. No idea how I missed that lol. I've only been here for about 3+ years now?

Does not work it seesm. Here is the way I've worked around it: https://pastebin.com/SS42VEK4 To basically accomplish the same thing as you can see on line 73 I've added a simple or classesList.isEmpty() This will basically as you can see just check if the array is empty which and if it is spawn it in all biomes even those added by mods. I don't think this is too problematic. Although I am curious, what would be the best way to do this without the .isEmpty() check? Just for knowledge sake? UTilize the ForgeRegistries.BIOMES.getValues() to fetch all of them and store them into an array and call that? Example of pseudo code maybe if anyone cares to share? Also, no i have no idea where the format eraser is to stop the formatting problems on the text of my post after copy and pasting some code.

I'll have to give that a shot. It should return the classes? (I'm only asking because I'm at work and not able to test it at this moment)

https://wiki.mcjty.eu/modding/index.php?title=Dimensions-1.12

So I have a generator that spawn structures in the world. It will only spawn structures in the designated Biomes. So for example, certain trees will only spawn in my BiomeMysticLands.class. I created another structure that I want to have spawn everywhere, in all Biomes. Storing them in an array is what I'm guessing is the best course of action, but the problem is fetching them all to put in the array. I mean sure I can manually create an array and do Biome.BEACH.getClass(), Biome.FOREST.getClass, etc. etc. But there has to be a more efficeint way right? Here is the Code: https://pastebin.com/4H5QYEic This is a tutorial that I happend to find heavily modified for some nice structure generation. Now if it is not feasable or efficient to fetch the Biome classes then technically, i could do/add an or classesList.isEmpty() check when the code reachs the classesList.contains(biome) right? Which would mean since you didn't put anything in the Vararg segment it would pass the check?

Found it. I forgot to add my: @Override public String getUnlocalizedName(ItemStack stack) { return super.getUnlocalizedName()+ "_" + this.getSpecialName(stack); } into the class. That was an oversight on my part. But for anyone who is interested on how I did it. (Not sure if it is the "conventional" way for whatever new standards are set for 1.12.2) Here it is: ItemRunes: https://pastebin.com/rnddRz7c RunesHandler: https://pastebin.com/sB0x4exm All items and blocks are registered in a separate class but that doesn't show any functionality on how the actual runes are handled and registered so I just left them out.

So I decided to bump my modding into 1.12.2 to try and stay with the times. Wasn't too hard to migrate from 1.11.2 but I started fresh to and see a huge reliance now on JSON, which is fine. I understand it well enough. However I have run into a slight issue. I am sure I have to change something in my JSON to get this working but Im not sure what. I have an item, it has subtypes. The item registers just fine, gets added to the game just fine and has the correct name. The variatns register the different textures. No issues. Only problem I seem to have is that the name for the item (And its variants/subtypes) is all item.item_runestone.name. It has the correct meta data values assigned to it from 0 - 5. So I am guessing perhaps I have to indicate in my .JSON how it should be names? Here is the JSON: https://pastebin.com/5jS9ECNd Each Respective Runestone JSON: https://pastebin.com/mchBZipj (there are 5 more of these each named properly. The only thing that changes in each is the "layer0": "hsrs:items/runestones/rune_air" To the proper runestone. If you need anything else please let me know, but I'm imagining since nothing is erroring it isn't anything code related and purely the way i constructed the .json But then again I could be wrong.\ Is it supposed to be something like: "variant=rune_basic": { "model": "hsrs:runestones/rune_basic", "displayName": "Basic Runestone" }, Maybe?

This is a really clean and nice way to do registereing. I may switch to it myself. But would you need to add a new method for Items with Metadata? At least model/texture wise? Or edit those regiser models to cycle through meta data as well?

That is a perfect explanation. Thank you. The forge docs wiki should have an example like that lol.

I am aware of the wikipedia link and how the operators function. Thats why I used them in the code. What I am asking is how it works in his code in a simplified explanation for people like myself and others who may view this post and seek a more defining answer specifically to what is going on in this code. Different explanations or explaining something different ways help me learn as I am sure it helps others learn. This isn't about just getting answers and asking for stuff. It is about learning the code and how it functions in game without simply looking up definitions. People explain stuff in different ways. A wikipedia link gives you the definition sure, but it doesn't tell you how it is actually functioning in the above code. I am asking so that can see how @gummby8 explains it. The wiki link doesnt explain why he is using i += 4; or if (facing >= 4) { facing -= 4; etc. and then using return this.getDefaultState().withProperty(FACING, EnumFacing.getHorizontal(meta & 3)

This is an excellent reference point. Can you explain exactly how the meta & 3 works? Is it similar to my post above?

Thanks. I think I got it. I shifted it one more spot over: @Override public int getMetaFromState(IBlockState state) { int blockIsActive = (state.getValue(BURNING) ? 1 : 0) << 3; int facingDirection = ((EnumFacing)state.getValue(FACING)).getIndex(); return facingDirection | blockIsActive; } And switched up the facing (to use horizontal) along with the ordering: @Override public IBlockState getStateFromMeta(int meta) { EnumFacing facing = EnumFacing.getHorizontal(meta); if(facing.getAxis() == EnumFacing.Axis.Y) facing = EnumFacing.NORTH; boolean blockIsActive = (meta & 8) > 2; return this.getDefaultState().withProperty(FACING, facing).withProperty(BURNING, blockIsActive); } I imagine all of this is correct? Since it seems to be replicating properly in game. And that ( meta & 8 ) > 2 effectively takes whatever the 8th value of the meta is compares if it is greater than 2 and destroys the rest? I do apprecaite all the help you gave me through all of this. Now my last request. And this has nothing to do with the code. This purely has to do with me wanting to learn so I know how to manipulate the metadata/bits in the future. I started off with the original example shifting the bits over with this ? 1 : 0 << 2 which basically added 2 zeros to the 1 or the 0 right? Effectively multiplying the number by 2. So either 2 * 1 or 2* 0. Which shifted the bits over 2 places. But that wasn't good enough because I was using the Enum Facing which takes 6 spots. So when I was trying to pull the data out it was screwing crap up. So by changing the EnumFacing facing = EnumFacing.getFront(meta); to EnumFacing facing = EnumFacing.getHorizontal(meta) it freed up two extra spots or 1 Extra Spot? in the bit data. So once I changed that and then changed the shift over to a 3 with << 3 it moved the boolean value (1 or 2) over 6 bytes (3*2) or did it just add 3 zeros to the value? Regardless of what it did, the actual code effectively moved the boolean value (1 or 2) over enough spaces so that there was no conflict with the facing data and was able to extract the new reduced facing data (4 values instead of 6) and the boolean value (0 or 1). Does that sound right or is it somewhat right. Like I said, I don't just want answers I legeitametly want to learn by code what is going on. And tutorials, classes, etc. can only do so much (for me at least). For me i learn best by seeing an example and trying/doing a replication of it and then I can see its functionality. Everyone is different but that is just how I learn. And if at all possible in your explanation can you not use bx0111 etc. that quite literally confused the crap out of me. (I think it means decimal value of a number?)

Similar to what you did here: but wouldn't that mean I'd have to change all the code around for the block along with the JSON properties for it? Or are you saying I have to do that anyway, because I cannot get the data for blockIsActive effectively because it is only going to be a 0 or a 1 and it won't be able to be stored correctly to begin with? I mean if EnumFacing is 6-value and this boolean is 1 Value (true or false) that is a total of 7. Can't the block store 16 bits? So why would have to change it, unless the boolean isn't able to be stored corretly.

Just giving this a BUMP as it is quite literally the last part that is preventing me from releasing the update of my Mod. I am parsing through and I have tried a variety of combinations but cant seem to get anything working. The issue doesn't have to do with the blockIsActive only being either a 1 or 0 does it? Becasue the positions are sticking properly. I'm imagining I am just "unpacking" the data incorrectly? I really am not trying to be annoying lol, I am just trying to figure this out and then learn from it so I can replicate it in the future on my own should I decide to make other blocks in which I may need to manipulate the Meta Data.

Okay thank you, now I tried that and now blocks facing east, south, and west show the active texture when they are not active and if you look at them with F3 screen opened it says they are "burning" and the block facing north is the only one that is not showing its "burning" texture. The F3 screen shown as burning false, So does this mean that the getStateFromMeta now needs to be fixed? And if so, I am imagining @Override public IBlockState getStateFromMeta(int meta) { boolean blockIsActive = (meta & 7) > 2; EnumFacing facing = EnumFacing.getFront(meta); if(facing.getAxis() == EnumFacing.Axis.Y) facing = EnumFacing.NORTH; return this.getDefaultState().withProperty(FACING, facing).withProperty(BURNING, blockIsActive); } https://pastebin.com/YSEDaJAM (if the colors are messed up above) Is not the correct way to do it. Or at least does not have the correct value to get the boolean blockIsActive.

Okay, so I shifted wrong it would seem. Can you please show me in my code how I should shift it correctly so that it displays properly? I understand if you don't want to and that is fine, you have helped me tremendously and I made it this far with the assistance. Maybe as a reward for the good student lol. Also not shifting the facing values shouldn't be a problem right, and just letting them stay as their defaults. The only issue really is the burning or "blockIsActive" value.

Alright, Im pretty sure i shifted them correctly becasue now if they are active their face changes to the active face and if you log out and log back in the face still stays as the active one and the direction stays the same, so I am not overwriting any data. New issue creeped up though which I dont THINK has to do with the way I shifted/offset the data and extracted it. But I haven't done this in ages so I could be wrong. Now once they stopped cooking the items the face doesn't change back to the non-burning face. It just stay as active, even if you log in and out. In other words once the block stops "burning" like a furance its graphic changes. This doesn't happen here. Here is how i offset the data and extracted it. https://pastebin.com/pQe7XN5H Here is the full block class now: https://pastebin.com/XWTxfMgA Here is the TileEntityClass: https://pastebin.com/MXCbPdzd Perhaps it is in my TileEntity class now? I wil admit I haven't touched it since I started editing the blockClass around. So perhaps i am missing something in there. DIAMOND_ORE

So I am running a 1.11.2 server and yes I know its an older version of forge and I am actually going to be updating it today. But I am at a loss. I have been in the forge world since 1.6 versions of minecraft when ModLoader was a thing and stuff and I have never once come across this error with ANY servers I have ever run. I can't make sense out of the error log so maybe someone with a better understanding of Java errors can help me out. The error is a "Watching Server" error and I don't know what causes it, I don't know where it originates from, and I can't even figure out which mod is causing it because the error log is never really the same. Here is the most recent "watching server crash" https://pastebin.com/6cxtBUeD Is it cause by a memory issue? Perhaps there isn't enough RAM on the server. It is currently a 6GB server. Or is a Core mod causing it? Which is why I can't make sense of the error log. This error log references animania, yesterday's error log referecned ReccurentComplex with the same Watching Server description. This is why I can't make sense of it, I don't know what is actually causing it. Or is it purely that 6G just isn't enough memory for all the stuff happening when players are exploring and stuff and it is causing such a backlog that threads are freezing?

Alright so how can I bitWise these values? @Override public int getMetaFromState(IBlockState state) { int facingDirection = ((EnumFacing)state.getValue(FACING)).getIndex(); int blockIsActive = state.getValue(BURNING) ? 1 : 0; } I know it can't be as simple as return blockIsActive & facingDirection. I haven't bitWised anything since 1.7.10 and coolAlias basically taught me it in the thread lol. So directions have 6 values right that go from D-U-N-S-W-E meta data can be stored in bits of up to 16 right? So 0-5 are taken by the direction, that leave 6 --> 15. So the boolean for BURNING would have to be stored in value 6 ---> 15 somewhere right? So if I want to store it in 8, which is binary 1000 right? How would I combine the values of 0--->5 with 8? Would I have to shift? For this i really may need an example if at all possible. The last time I attempted to bitWise was in 1.7.10 and it sucked then also (even though it is very important to manipulate metadata) I know bitwising hasn't changed but I am sure a number of other things how to fetch data has so maybe an example of some code so I can actually see it in front of me?

Actually the way you explained it @Choonster makes perfect sense now and I thank you for that. And yes @Draco18s I understood what you were saying as well but I couldn't get it into code terms. So now my only remaining question is since the BURNING is a boolean value, how would I store that as meta data? could I simply create a custom method that if BURNING is true set the int to 1 or if it is false set the into to 2. Or does the true/false default to 0 and 1 respectively on its own as with pretty much any coding? Because I can't use state.getValue(BURNING) as it is in the #getMetaFromState Or in the alternative should i change burning from a PropertyBool to a PropertyInteger

I'm at a loss. The methods are there the block stores data and saves the inventory but the graphic gets lost on a restart. I pretty much get what you are saying, I think. As the block is ticking away we have to see if it is actually "active." Once the game shuts down that "active" state gets discarded and when you restart it, even though everything is still functional the game doesn't know that the state should be set back to active which is why you have to tell it to re-set it to active. So in other words for the furnace entity I created, if the furance "isBurning" still when you log back into the game you need to tell the game that it "isBurning" so set the state correctly to update the graphic of the block or in this case since I am using varients in my .json select the correct .json. I know it is probably stupid simple to do since I am able to explain it just about right in plain english but I can't figure out where to place it in the code. I appologize. TileEntity: https://pastebin.com/Wpp4EKHq Block: https://pastebin.com/BXdDCJCx

Yes and I know it returns a boolean so if we get a true, in other words the oldState of the block does not equal the new/current state of the block we return true. If we return true then we must sendUpdates correct? I've tried to do that and it doesn't work. Is it possible there is an error in the block class where the setState is actually found?