jeffryfisher

Try rewriting the block's active / not active manipulation without getting any data from your TE. The blockstate at pos should have all the data you need. The only thing you might need to do to the TE is tell it what the new state is, and you might not even need that (depending on how your TE is ticking).

Did you download the Forge SDK? Did you run gradlew setupDecompWorkspace? gradlew eclipse? After that, just create a package folder under $ForgeDir/src/main/java and start dropping java files into it.

For starters, just to make your code more readable, try assigning your new BlockPos just once and then using it in each function call where needed. Try setting a breakpoint on destroyBlock and then step through, both when you use your stick and when some vanilla action (such as an explosion) destroys a block. Does your usage look like the vanilla usage? Try to trace vanilla to where the server sends packets or marks chunks as needing to be updated to the client. When you see how vanilla handles things, your design should become clear.

Since this forum is for help with Forge and not Java, the best place to look is outside, for sites offering more general Java help. As Ugdhar said, Google is your friend. When you find a good Java help site (or thread or tutorial), bookmark it for future reference.

Did you Google minecraft forge ore generation?

If you can spot the error in your log file, Google the relevant phrase to find prior threads where other coders have asked this help for you. If not, then post the log, and the block's blockstates.json, and the java where you register it. Most common fix: Make sure that your modid and all resource names are pure lower case.

It's impolite to request free labor. The volunteers here will answer Forge and Minecraft design questions, but that's all. You're expected to know programming, Java and your IDE (e.g. Eclipse) or find other external resources to learn them. Have you setup a Forge decomp workspace? If not, then go to the tutorials and start reading. If you're set up, then dive into the Minecraft classes and find where key-presses are processed. Good point. My first go at this would be to define a new abstract key (that a user could reassign). Then I'd try to find a way to translate that key's complete press (down & up) into a sneak-key-down action (if such a thing exists). If that tricks Minecraft into thinking that the sneak key is down and not yet released, then you'd be sneaking continuously until you tapped the real sneak key (its release ending the sneaking).

The log file often has more info about loading problems (warnings), so don't rely on the console. In addition to your block class, mod class and registration, also show blockstates and the alcm:block/blockarouradark json files.

StackOverflow suggests accidental recursion. I ran into that myself with tile entities. Some of their methods are non-intuitive, making it possible to fall into a recursion trap. If you encounter StackOverflow again, step through TE construction to see what methods get involved when. You might then see an unexpected call that leads to recursion.

Try running Minecraft with the mod installed. Watch the console (or read the log afterward). There should be loads of loader info in there. Turn on in-game debugging (F3 in my version) and examine items/blocks. You should also peak inside the mod's JAR file. Even if the java source isn't in there, you should still be able to see all of its resources such as the language file(s) and blockstates files etc. You can learn a LOT from those. This is Minecraft; learn to dig

In that case, team up with someone (friend, family member, friend's older sibling...) who has some programming experience. The help you need is more comprehensive and foundational than this forum's focus. In other words, you're missing a prerequisite for this course.

Ah, but you're close. Talk to an advisor before the end of the year. You may discover that there are opportunities that are not widely advertised. Find out what your school (or next year's school, or summer programs) can do for you.

Aha... Forge modding is a bad place to cut your programming milk teeth. That and this forum assumes Java proficiency so it can focus on the idiosyncrasies of Forge and Minecraft (which is plenty). Please take at least one formal programming class that teaches an object-oriented language, and then study Java (e.g. read a book). You can do both at once if you can find a Java class. When you come back in a few months, keep an online Java reference bookmark handy, and consult it on every mystery error before posting here.

Then you need to step through that string list getter to see what it's doing to you.

I think it would be better to line up your AI tasks in priority order similar to the way vanilla entities do. Then write your logic into the tasks' should-run and should-continue methods. I think those are what decide whether a particular AI task should "swap out" so something else can run. In other words, AI tasks shouldn't be unplugged, they should merely give up control.

What's your XP level writing Java? Using other O-O languages?

When you ran it in the debugger, what was null on that line?

Oh no... I sense Jean-luc Picard, head in hand. Also check the existence and permissions on mcmod.info

Where is your 'new' expression, where you try to create an instance? Did you supply arguments?

As the 7 implied, that's not what side-only means. Side-only is about class-loading, not mere class execution. If your mod (or code copied from it for another mod) is ever used on a dedicated server, it will crash during the loading phase, before it ever gets a chance to run. In single-player mode, your error may be hidden because SP has a virtual client that loads the client's side-only classes in the JVM. Because bad habits are hard to unlearn, we encourage modders to learn correct form (and understanding) from the start. Just look at how many class def not found threads there are in this forum and kindly not set yourself up to burden us with another..

Sounds like your randomizing seed is always the same. Set a breakpoint to see what it is in each instance, then take steps to change it up.

By "people", do you mean the editors of the other mods whose ores you want to manage? If not, then you'll have an uphill battle against other mods' idiosyncrasies (with some of them trying to control "other" mods, including yours). In other words, trying to trump another modder without his cooperation often doesn't go well because so many modders think their mods should rule the others.

Feed your json files to jsonlint, then pick through them looking for tiny errors (like errant underscores, capitalization etc), then post them here.

I think if you edit the 1st post, you can revise and extend the title (that's how some titles end up inserting "[SOLVED]" etc)

Go to the log file and look for JSON warnings. Better yet, set a breakpoint in the JSON loader (and anywhere else that looks informative) and run in the debugger.