jeffryfisher

I thought the server sent NBT data to the client, so at some level wouldn't the client load from NBT in response to a packet from the server? My TE's haven't needed those (yet), but I haven't ported beyond MC 1.10.2. Are they something new? I seem to be getting away with just reading and writing to and from NBT (and marking dirty / for update). The packet mechanism seems to work invisibly in the background (so far). If that stops working in 1.11 or later, then I'm not looking forward to needing explicit packet handling in mods that haven't needed it before. I'll confess that I still have difficulty wrapping my mind around tile-entities. That's why I follow threads like this.

Sounds like an X-ray cheat in the making. I'm surprised this thread hasn't been locked already.

You might try making two block instances (basic, advanced) from one block class, registering each under a slightly different name. Then the basic/advanced value can be an instance field rather than a property, and then I think you could create a separate blockstates file for each registered name.

That should work, keeping your ores away from the North and West edges of the given chunk (unless you start generating really huge or sprawling ore bodies). If you know enough about the size and shape of your ore bodies, you could use different numbers. Just avoid stepping on or over the NW edges with any of your blockstate changes.

In Eclipse, select onBlockActivated in your code, right click on it, and then pick show references. Put @Override on absolutely every method override in every class in every mod, no exceptions or excuses. If Eclipse suggests that you remove the annotation, it means you did something else wrong (mismatched signature, or attempted to override a private or static method). If proper to override, then hammer at the method signature until Eclipse stops complaining.

The error has a SRG name, and you asked about a deobfuscated method name. Is there some deobfuscation/reobfuscation mismatching going on? How and where are you running your mod? Did you compile your mod by running gradlew build, or did you export your mod using Eclipse?

WorldGenMinable uses +8x and +8z. What you want to accomplish is moving far enough away from north and west that even the largest ore body never changes a block on or beyond the north or west edge of the given chunk (even staying in the chunk, tickling the edge causes neighbor change in the next chunk). Why can't you use WorldGenMinable itself?

I nest my common proxy class inside my abstract main mod class. Not only can my abstract mod declare a proxy for every mod, but the proxy class has visibility to fields and methods in the abstract mod (and client proxies can call inherited methods that exploit that visibility). Since a proxy acts on behalf of a mod, it seemed to make sense to me to grant that visibility. Similarly, when I define a tile entity class, I usually nest it inside the block class that it supports. In vanilla Minecraft, I see loads of enum classes defined within other classes that use them to define variants. However, don't take Minecraft and modder's hacks as a guide to good programming discipline. If you're curious about learning general Java and programming, then look to a more general Java forum. Hackers like me might show you bad habits that you'll need to unlearn someday.

"Bugs out" doesn't mean anything. Step through in the debugger. Tell us what really happens.

Read about worldGenMinable

1) Just for grins, could you add a "this." in front of each call to each instance method and then recompile? 2) Did you compile your server jar using gradlew build? i ask because your build.gradle file looks like the default with group = "com.yourname.modid" still in it.

Does the printing run on both client and server? If so, then one may be counting down while the other is stuck at zero. If you want to see what is really going on, then step through your code in the debugger, examining variables as you go.

Explore this call in Witch's code:

When you create the ItemBlock for the variable block, you need to use (or imitate) the ItemMultiTexture class that sets hasSubtypes to true. It'll need a method to generate a name suffix for each "damage" (metadata) value so your client proxy can create a resource location for each item subtype: if (i.getHasSubtypes ()) { ResourceLocation[] variant = new ResourceLocation[varSuffixes.length]; // Not to be confused with *model* locations for (int meta = 0; meta < varSuffixes.length; meta++ ) { variant[meta] = new ResourceLocation (i.getRegistryName ().toString () + '_' + varSuffixes[meta]); ModelResourceLocation m = new ModelResourceLocation (variant[meta], "inventory"); ModelLoader.setCustomModelResourceLocation (i, meta, m); } ModelBakery.registerItemVariants (i, variant); } In this code snippet, 'i' is my item, and varSuffixes is an array of strings that I passed into this client proxy method.

Learn properties and blockstates for things like variable textures/colors of of functionally identical blocks. Do not burn up block IDs simply because a basic Forge or Minecraft programming feature needs to be learned.

Where do you use facing? I see it calculated but not used.

I apologize that I can't give a full answer. What I do know is that much of chunk "decoration" is delayed until a chunk's SOUTH and EAST (+, +) neighbors have been created. That's when ores can be created -- and the vanilla ores are all offset +8, +8. Because large constructs like strongholds and villages will span many chunks, they need to defer decoration even further (and it appears that you've analyzed part of that deferral). Look at how each large-scale construct (Stronghold, mine, fortress) is implemented. Imitate what you find.

Sounds like substitution, which is buggy and probably only for blocks (not items). Ideas: 1) Accept that you will need to extend the shield class. 2) Maybe you can trap events to inject your shield in place of vanilla shields (i.e. when crafted, when picked up). 3) You could replace the enchanting table and/or anvil (or trap events entering each) so you can add your exception for shields.

If you need help with a crash, then post the crash!

That question would be worth a new thread with a matching subject line

What did you see happening when you set breakpoints and used the debugger to step through the code that's trying to generate your structure?

For one unique entity, 1 or 9 chunks is trivial. The difference is how you store the entity's location. If you know you want to store that in some static world data, then you don't need the chunks. If you might prefer to avoid creating static world data, then keeping chunks loaded would mean that this mob would always be found in a search of loaded entities, so some previously mentioned standard utils would succeed. Yet another option is to never allow this entity to stay in a chunk that is being unloaded (unless the server itself is going down). Since every world has a spawning area that is always loaded while the world is running, you could park this special entity there until needed elsewhere. Perhaps you could fashion a subterranean vault beneath your world's spawn point. Alternatively, you could let this entity prowl the spawning area but remain passive while in those chunks.

Do you think you could do something to your entity so it could keep its chunk (and maybe the chunks right around it) loaded?

1) I don't like the redundancy between lit and unlit redstone. Can't one boolean expression test for both? 2) If removing from a list is problematic, then maybe you could build a replacement list that skips the elements you would delete and then swaps lists at the end.

That's not quite true. If your mob doesn't burn, then its AI does not need to seek shade / water. Dump that task from the inherited AI. Idea: Always put the equivalent of a magic helmet on your "skeleton" to trigger the get-out-of-jail-free exception to burning