jeffryfisher

[*] You can tell MC to ignore whole properties. [*] You can program a new property to exactly match your rendering variants. [*] You can use other variables when converting to or from metadata. I'm not sure exactly what you're trying to do, so I can't say exactly how to combine these degrees of freedom to suit your purpose.

What version are you upgrading from? MC 1.6.2? Why to 1.8.9? If upgrading, you should if possible aim for the latest MC version supported by Forge. And what are the problems? Do you have a crash report or Forge log to post?

If "normal" is the only variant, then try moving everything down from the defaults into that variant.

getMinecraft() will return null if you call it too early (like in preInit). It is now recommended that the mesher be avoided. Per Choonster, the mesher.

Not sure if it matters, but your capitalization is inconsistent in your jsons. Mod names should be all lower case all the time to avoid problems where it matters.

I have a custom walls mod that extends BlockWall in 1.8. What issues did you run into? I ask because I wonder what I might need to know when I get around to upgrading to 1.9.4+

Define "doesn't work". Post the latest crash report. If there's no crash, then step through the misbehaving method(s) in the debugger and tell us what you see versus what you expected.

This is an old problem going back to 1.8 or earlier. There's a default behavior that replaces the TE for any state change, no matter how minor. Override shouldRefrsh, but you don't want to return a simple false. There really are many cases in which you do want the TE to be replaced, so test for them. PS: Never forget that when you hit a snag, Google is your friend.

Hmmm... If all you care about is coords, then you don't need all those block states. Just run through the coords in the config looking for points whose calculated distance is less than radius from player. Vanilla Minecraft already has methods for distance. For each hit you detect, spawn particles, perhaps after checking the blockstate for anything that would interfere. You'll fetch far fewer blockstates that way, and you'll be less likely to run out of memory. PS: If you search radius 10 from a position at y=2, what does your code do? What happens if it passes y=0 or y=-1 in that method call? And what would happen then? (maybe nothing, but it looks dangerous)

I'm befuddled by a couple things. First: if ( stateList.contains( state ) ) { stateList.add( state ); } If the state is already in the list, why would you add it again? And if the list starts empty, will this test ever allow a state to be added? Second: Why is there a posY in your loop code for x? Third: Why are you getting so many blocks in a solid volume? Look through World to see how vanilla Minecraft scans for things. You may find a method already out there that will suffice. In any case, there must be a more efficient algorithm (find the next path block at radius one, then find one adjacent to that etc). Fourth: What is going to happen if your player is ever near y=255 or y=1? Or in a superflat world with even tighter constraint on y?

Have you even played Minecraft before? Have you ever written any program in any programming language? Start your suggestion by expressing it in English words (arranged in complete, grammatically correct sentences) to explain what new behavior you'd like to see in what game feature. Then post that suggestion to the Minecraft Forum's Suggestions Subforum. Come back here after you've learned programming + Java and are looking for help with the idiosyncrasies of Forge integration.

Draco and I are looking at the problem from different directions. He's thinking of how a neighboring block should respond to a call. I suggested that your bluestone dust look at each neighbor and avoid calling canConnectRedstone on blocks for which you have your own rule. The strategy you pursue will depend on what you see when you fire up the debugger to step through that method (and whatever method calls it). You will see your opportunities more clearly than any of us can. Run in the debugger and start stepping.

No, you need to walk through the connecting process in the debugger and spot where one of your bluestone methods is making the decision. At that point, it should notice that it is looking at another block of itself and decide to connect rather than calling the canConnect method.

To get all entities in the world, I think you need to load all chunks in the world. That would be a nightmare (in an old MP world that has been widely explored, you'd exhaust memory and/or choke the CPU). However, there may be a way to tease out some knowledge of all entity IDs in the world and pick one before getting the entity itself. Unfortunately, except for players, that might not tell you where the entity is so you can load its chunk and teleport it. Perhaps you'd consider a less ambitious effect: If there are 2 or more players in the world, and if they are a minimum of ~200 blocks apart, then swap a mob near one with a mob near another. Then you'd only need to deal with loaded chunks. Also: Chunks without players tend to despawn their monsters, leaving only passive mobs. If you want more mayhem, then you want to work close to your players anyway.

And your main class, especially where it mentions/annotates your proxies.

For anyone else wondering what just happened: Bookshelves do not give off particles. Enchanting tables do (in the presence of shelves). The table's particles just happen to look like they're coming from the shelves because they spawn near shelves and arc toward the table. However, if you design your own block to mimic a shelf, then I suppose you could give it particles of its own to arc toward nearby enchant tables.

Yeah, sometimes behavioral (non-crash) problems are best investigated by running in the debugger and stepping through suspect sections of code (and stepping into method calls).

I have an even better idea: Just generate in stone. Don't even worry about dirt and gravel. If your generator is written correctly, then whenever it runs into something it can't replace, it can reroll the randomizer and try again. Oh, and what D7 said about programming is correct. While I could come to MC modding with about 30 years programming xp with no Java, I don't think anyone can jump in with zero programming. You need to learn the essential concepts so you can even understand the words used to offer you help. This forum is not here to teaching beginning programming. It's not here to teach Java. It's here to teach the idiosyncrasies of decompiled Minecraft code and the Forge wrapper written to mod it. As an analogy, this ain't a high school study hall, and it isn't even a undergrad college lab. It expects people to arrive with that knowledge, ready to learn an advanced specialization that builds thereon at a post-graduate level. The web has other resources to help you become ready. Go find them.

Um, you may as well say "I want my car to go places, so why would I need brakes?" Coding an exact match to achieve an override is tricky enough that it's one of the most common sources of error brought to this forum. Also, because a flawed override may leave a parental method running in place of what you expect, the runtime effects can be unpredictable and subtle, making them difficult to diagnose, especially at a distance when we try to help. Finally, and perhaps most important, Minecraft's code does shift with each new version. When you port a mod to a new MC version, there will often be methods in your extended classes that were correctly overriding their parents in the prior version but are not proper matches in the new version. Believe me when I say that it is a blessing to have the Eclipse IDE call them all out in bright red rather than having to diagnose a whole bunch of subtle misbehavior at runtime. Therefore, always always always put the @Override annotation on absolutely every method that you as designer intend as an override. Do not ever skimp on any of them, not even one, not ever.

Are you using Eclipse as your IDE? If so, then it should be helping you to see syntax and semantic errors. Between Eclipse's bright red X's, its power features, and your knowledge of Java, you should be able to get pretty close to compiled before coming here. If not, then tell us what's still marked red in Eclipse so we can point you toward the Forge class / method that you need to pick up. If you're using Eclipse correctly (and have an uncorrupted decompiled workspace), then gradle will never give you compilation errors. PS: If you're using Eclipse for Java but it's unfamiliar to you, then take time out to go walk through an Eclipse tutorial.

Uh-oh, then the TE might never go away even when it should. I think Choonster is on the right track, and for some kinds of mods, one might even want more conditions controlling whether to replace the TE.

I posted an almost identical thread back in the fall. What I discovered was that nobody else ever even tried to migrate an existing world with modded blocks in it. You may upgrade your mods and create a new world. You might even get away with upgrading mods, installing them only on clients, and then logging into an existing 1.8 world server. However, a modded world created in one MC version of Forge and subsequently opened in another will always be vulnerable to gross memory-structure errors (such as block shuffling). I gave up. The good news: I discovered that if I reverted to a Minecraft 1.8 version of Forge, I could reopen my world, and the riot of random blocks seemed to have gone back to normal (I didn't notice any permanent corruption). Sorry I couldn't offer a migration solution, but maybe I saved you some wasted effort in a lost cause. My recommendations are: 1) To continue playing your existing 1.8 world, upgrade Forge to the latest build for pure 1.8 and park it there permanently. 2) To upgrade mods, jump up to 1.9.4 and then create a new world. Don't bother creating a new world for an intermediate release. BTW, If you know your Linux, you can setup multiple server worlds, each running a different build of Forge out of a different subdirectory. They can run simultaneously; just give each its own port number and remember to forward all those ports to the host machine.

To sum up: 1) You may offer your new block / item as a generalized ingredient by registering with the "ore" dictionary. 2) You may write recipes for your new wonders using ore recipes that accept other mods' generalized ingredients. 3) You may add your own specific ore recipes to use generalized ingredients to make things you know about. but... You can't force your ingredients upon as yet unknown mods (at least not without some wicked post-init on-the-fly analysis and replacement of the game's recipes that could screw up everything in an installation you didn't foresee). Good luck!

Bektor, I think the custom here is to continue existing threads probing a problem rather than starting new threads for various aspects of a problem. Otherwise you plunge new readers into a problem without the context that has been built in the earlier thread (and if you're new to this conversation, then you might find context there).

What do you mean by "all the pngs are worded the same"? A png is an image file. There are no words. What did you really mean to say? "Everything" may look right to you, but if you're writing to use, then you should let us have our own look. Post your code (using code tags or paste bin etc). You say "lost" their textures. Does that mean that at some time the textures actually rendered? If not, then you probably never did them correctly. Texturing blocks and items was radically changed for MC 1.8. Most helpers here are trying to forget the paradigm of 1.7.10 because it just gets in the way. Set a break point in the misbehaving renderer and then run the debugger to step through and see what's really happening. If still want help here, then you must give much more info about what you've done and what you see when running. PS: When you figure out what help you really need, please change the subject line in the OP to be more specific. Being specific can attract the reading from those who can best help with a particular aspect of Forge.