jeffryfisher

I only know that I have seen threads in this forum asking for help with such mods. Seek and you (or your favorite search engine) will find them, possibly linked to github repositories.

Ah, the Nether is tricky because the normal gaming space is all enclosed. I think the OP's problem is that a flying algorithm written for an open-sky dimension (such as the End) will try to get above the Nether's bedrock ceiling. There's not much up there except patches of mushrooms (and the occasional zombie-pigman grinder ). @TheRPGAdventurer, I think you will want to write your own custom method to detect large open spaces within the nether. You'll probably also want your dragon to fly through netherrack without destroying it (the way vanilla dragons fly through endstone). You have some logic to work out, but you might find hints in the projects of others who have built villages in the nether (so they also had to figure out how to detect open spaces and where there floors were). Try searching out discussions and code from those other projects both here and at github.

That sentence makes no sense -- A sword IS an item. Please describe in more detail what game feature you are trying to achieve.

Start with ItemColored and tell us if (when) you run into trouble.

Well then it's time for you to become familiar and comfortable with the debugger. Force yourself to dive in, play with step, step-into and step-over. Look at local variables and class fields as they change. Set breakpoints so you can skip ahead. Figure out where your program is getting stuck by sneaking up on it. PS: Is it kosher to remove a pylon from pylons while iterating the list? I vaguely recall that there's a right way and a wrong way to do it. Make sure you're doing it the right way.

These loops are suspicious, esp since the takeMana method can return mana unchanged. Set a breakpoint entering the loop and step through.

nextInt will always return 0-(n-1), so its result will never equal n.

How much time have you spent stepping through your code in the debugger? Invest an hour or two doing that and then come back with your observations (if you even have any remaining bugs).

In other words, look at how large structures (fortress, mine, stronghold) are generated. Devise a way to generate only the portion within the called chunk and the neighboring edges of the chunks to the South & East. Even when generating within the called chunk, take care to avoid changing any blocks along the north or west edges. Alternatively, it might be possible to cheat by setting a flag while generating a vein and clearing the flag after the vein and all of its chunks are complete. Don't allow a new vein to generate if the flag is already set. You'd have to experiment to see if this would contain the spread. Even then, it would mean that your world would be non-deterministic in that the positions of these veins would depend partly on the order in which players explore the world.

There's also a thread around here (probably the same mod). IIRC, the strategy was to implement something like the front-view camera (hit F5 a couple times) and skin the mirror with what it is seeing. Just make sure that mirrors can't see each other.

The takeaway lesson here: Use your IDE to explore and walk through the vanilla classes to see: A) What's on offer. B) How vanilla uses things

I suggest that you search for a simpler air pocket and then enlarge the pocket to accommodate your structure (or include surrounding air as part of your structure). Also, if you see stacking, then your search needs to be reprogrammed so that block-changes made by one insertion will affect the results of the next search (preventing overlap).

First: Please tell us, in game terms (not programming), what game feature you are trying to implement. Second: What you have described so far sounds BAD. When a block changes type (e.g. furnace to air), the tile entity needs to be deleted. Otherwise obsolete tile entities accumulate in the world. There's got to be a better way for you to use your soon-to-be-deleted TE's data without screwing with the TE paradigm.

Look through the vanilla Minecraft classes, especially the ore blocks. I think you'll see them extending a vanilla BlockOre class, so you don't need to reinvent it.

If you use your IDE to explore the vanilla class hierarchy, then you'll see opportunities for more elegant solutions. Keep an eye out for a sound class with "continuous" in its name. Finally, be sure to honor the client-server architecture. The server makes decisions, and the client renders. I'm not sure what kind of mod you're making, but it shouldn't be one where a client "goes rogue" and renders data not authorized (decided) by the server. That's the path to the dark side (e.g. "X-ray" mods and their ilk). I can imagine an auditory diamond-finding mod... Don't go there.

Patience young padawan, all will be revealed in its time. Learn programming first, in any language. If you want to learn more than is in the course syllabus, then go to your professor and request extra reading, online tutorials, personal instruction, guidance to the right follow-up course (including independent study) etc. Speaking of guidance, that's what guidance counselors are for. Both professors and counselors should be thrilled to see a student latch onto an internal motivation, so you have a high probability of receiving advanced, possibly off-catalog instruction... but you need to pursue it. If you're burning my tax dollars, please get my money's worth by making my volunteer work here easier.

Yikes! See the forum rules (like the part that says "This is not a Java school...). Do yourself a favor and go learn enough Java so you are never tempted to offer that excuse again. You should arrive here comfortable enough with Java and Eclipse (or other chosen IDE) so that you're up to learning Forge in the programming jargon that volunteers are using. If any of the words or concepts are mysterious to you, then you should go out of your way to Google and read before asking for more effort to explain prerequisites.

Check carefully. If any methods needed turn out to be static or private, then you won't be allowed to override them.

Minecraft sound handling can be confusing because decision code for the server and "rendering" code for the client are partly mixed together with similarly named methods. Take some time to trace both the execution and data flows with an eye toward logical client-server separation. Then look for a client-side vanilla classes with "continuous" in their names (I hope they haven't changed too much since I used them in 1.10). Finally, look up other threads about changes to Minecraft sounds in 1.12. I think there's some info on sound in 1.12 in the Forge docs area too.

In case you're curious, the reason Eclipse can work while a built jar doesn't is because a certain OS is NOT case sensitive while Java treats resource "files" inside a jar as if they are.

If the error is repeatable, then get into the debugger, set a breakpoint at line 63 in renderPing, and examine all variables there to see what's null.

If you don't mind having your world depend on the order of player exploration, then you could limit your code to generating only one complex at any given time (e.g. use a static field in one of your classes as a latch). Initialize it to "ready", then check it before starting one of these structures. if "busy", then exit without starting a new complex. If "ready", then set it to "busy" and commence generation. Do the whole structure, loading as many chunks as it needs; any further would-be structures triggered would be suppressed by the field being set to "busy". When done, clear the field back to "ready". Of course, if you're willing to do the work to map overlapping structures, then that's probably better (and repeatable).

Your TE class might need to override shouldRefresh().

Use Eclipse to look into source code of vanilla entities . See what they do to make sounds, especially from server side decisions.

I never got multi-mod installations to work, so I gave up long ago. Instead, I copy files (gradle, java, resources) in and out of my workspace so there's only one mod at a time inside. I keep the master copies in a nearby folder. Eclipse never seems to mind the fact that all its source code sometimes changes under its feet. It sounds tedious, but I've swapped mods so enough times now that I can do it in under 30 seconds, which isn't much trouble for something I do only a few times per month.