jeffryfisher

Eclipse's suggestions must always be taken with several grains of salt. They're often like offering to amputate your leg to cure you of athlete's foot. It doesn't seem to have a direct BlockPos field. BlockPos is a class, not a field name. Didn't you even explore the event class to see what's in it? Did you try a text-wise search for "BlockPos"? Please look at the fields and their types and their visibility.

Does the event have a BlockPos field? If so, the pos (position) has x, y and z getter methods.

You may also set "particle" in a defaults segment, and you may set it to one of your faces (e.g. "#up").

I think he wants to let the TE be replaced, but he wants to transfer the data from old to new. It has been a while since I walked the TE replacement code. I recommend using the debugger to do so. Make notes of when and where the switch occurs. There may be some overlap when both TEs exist (like inside the constructor of the replacement, or inside of your block's create TE). At that moment, you may be able to grab the data from the old TE and assign it to the new. If that's not so easy, then you may see how to grab and hold a reference to the old TE and use it if needed. Just make sure to let it go so the TE will be garbage-collected when dead.

MC version 1.10 removed the auto-magic creation of item for block. You must now instantiate and register your own ItemBlock. If your tutorial doesn't warn you of this, then it is obsolete.

Agreed, vanilla walls are too stupid. My custom walls include their own cobble and mossy-cobble variants so vanilla's walls can be completely avoided.

Your custom walls should reach only to the edges of their own cubes. If they're not connecting to vanilla walls, it's because the vanilla walls are too stupid to reach back. My custom walls include their own cobble and mossy-cobble variants so vanilla's walls can be completely avoided.

Matryoshika has reached the point I was aiming at several messages earlier. Create imitation gravel that doesn't fall, but make sure it drops the vanilla gravel item-block when broken. And, if you're going to be as radical as eliminating all netherrack from the nether, then I like the idea of designing your own chunk-provider that never creates netherrack in the first place.

I think Winnetrie has a point. You extended BlockWall, which has a state with a two-value property. I don't see you overriding it, so you could get two versions of your wall. Investigate what your wall's parent class is doing to you.

The solution depends on what you're really trying to do. For instance, you could create an extension of dirt that is textured to look like gravel, and it could even drop vanilla gravel (act like gravel ore, and it could randomly drop flint too). Would that achieve your goals?

Not to mention being stringly typed and immune to refactoring. For a minute I thought you had misspelled "strongly", but I now see the pun. The linked definition sums up my feelings nicely.

Mojang. The Forge team supplied the Forge blockstate system that lets you break up the cardinality map. I still suspect Microsoft I like Forge's format better, but all json formats fail my "let the compiler do as much work as possible" paradigm. Even if models need to be baked during loading, I'd prefer to code one or more methods to translate my properties into model pointers rather than needing to trust my spelling and spacing. Reminds me of Hollerith fields on punch cards back in my early Fortran days.

Wow, white space is significant. That is SO fragile. Who gave us such a paradigm? Anyway, your blockstates json is only defining n, s, e, w. You left out UP and DOWN. I think you should change your BlockChair class to extend class BlockHorizontal (which leaves out the UP and DOWN for you).

Then you should write a plan. First learn structured programming in any language. Then learn object-oriented programming in any language. Then latch onto a good online Java tutorial and follow it until you can rewrite your last O-O exercise in Java. Then go to Forge's "Getting Started" tutorial. Your first mod should be dirt simple. Literally... add a new form of dirt block to the game that is somehow different from podzol, normal or coarse. When you get stuck, try again to get as much info as possible and then ask for help. When asking for help, give as much info as possible. Never use the phrase "doesn't work". Instead, say what you expected and what you saw instead. If your sticking point includes a crash, always post or link to the crash log. If you don't crash, it's usually helpful to include the log file (not console output). Add as much of your code as might be relevant. All large texts (logs and source files) should be encapsulated in code or spoiler tags. In the case of your spawn egg mod, you should give us the complete class (in tags of course) where the recipes are defined.

If you also want to protect against other time skips (commanded in creative mode), then your block will need to remember what day (time/24000) it was last updated so that it can see if it is on a different day and needing to be updated again. With metadata (day % 16), you can do this without a tile entity for up to 15 days before the cycle repeats. However, if your block activity uses up your metadata range, then your cycle of days will be shorter. However, as long as you have one bit to detect a day change, you can handle sleep and short time adds without a TE. Since you're only interested in daily updates, you may wait for your block to be randomly ticked (see crops).

What version of MC and Forge are you developing in? If it's older than mc 1.8, then 07 will lock the thread and tell you to upgrade. You should find where that message is generated, then set a break point and run in the debugger so you can look at the client call stack when it hits. That should give you a clue what you're doing to trigger it. Of course, if you upgrade to the latest Forge, then the problem may vanish on its own (after solving many other problems).

OK... you override getSubItems, but did you set hasSubtypes to true?

Are these models actually different? Did you copy-paste and forget to customize the copies?

Every ItemBlock is now explicit. canConnect method is private. Replace meshing with setCustomResourceLocation (and move it to preInit) set and get RegistryName For items, builtin/generated becomes item/generated Some renderers were rewritten (again). Vertex buffer has a new xface. Vanilla blockstates became more advanced, and some blocks' use of properties became more intelligent (I dropped a *lot* of code from custom walls). Sound effects use a different server-side method. In general, playing sounds is more difficult because server-side impetus and client side rendering are more confusable than ever (the methods all look the same). You may now find yourself calling playEvent with a literal numeric constant (bad design). In general, sounds have evolved from using just ResourceLocation to SoundEvent. BlockDirectional now uses all 3 dimensions, so blocks that rotate on the Y axis need to extendBlockHorizontal. item/generated is now good enough that mods don't need firsthand or thirdhand "display". In blockstates json, resources now default to minecraft domain instead of modid. All custom resources need to be prefixed with "modid:"

If each model has a different "to", then I think you need to stick to separate model files.

The picture you showed was a large number of particles moving in circles, and none of them were circling around any of the others. Instead, each circled about a fixed point, and the apparent wave motion there depends on coordinating the phases of the various particles. To simulate this in detail, you would need a field of tile entities (computationally expensive), with each responding both to its neighbors (propagation) and specific external stimuli (stimulation). What is it that you are ultimately trying to achieve?

That highlights the main reason that I HATE this new-fanged json scheme. Brokenness is not detected or traced by our IDE (Eclipse for most of us). Our most powerful tool knows neither syntax nor semantics of these opaque text files. For us old Fortran coders, it's much like returning to the 1970's. I understand why Mojang wanted to "bake" models, but they could have used a callback method in Block and Item rather than pushing so much fragile code into the purgatory that is JSON. Imagine if each state to be baked could call a function, pass the BS, and get back an object to be baked. Our mods could then use all of Java's power to concatenate, consolidate etc. Cartesian products would never have happened. Errors would all have been in Java. Life would have been so much simpler.

switch(world.provider.getDimension()) What version of Minecraft are you using? If 1.10, then use your IDE to look at getDimension and its return type. Fix your switch statement to ref those enum values.

The initial description sounds more like a sun and planets, but whatever... For one object to orbit another, you need to give the orbiter an initial velocity tangential to the hub, then periodically impart a radial impulse toward the hub. Calculating the vector directions will be easy, but calibrating magnitude will take testing. Your orbiter can tick 20 times per second, and you can initialize radius and tangential speed, which tells you how many ticks you have to complete an orbit. Start doing physics calculations for circular motion. And then decide what should happen if anything gets in the way.

Is there an underlying block that spreads with these locusts? Is the total data usage low enough that you could avoid using tile entities altogether? It could be a weird fluid that spreads only across vegetation, and whose spread can increase in depth depending on what it eats.