jabelar

i think this is a known issue. While it is possible to remove advancements it takes a lot of work. If you remove the recipes you get the error. Instead of removing the recipe, many people replace it with a "dummy" recipe instead. That gets rid of the error, but brings up a different message (warning about "dangerous prefix"). If you're interested in trying this though I describe it my tips on recipes here: http://jabelarminecraft.blogspot.com/p/minecraft-modding-ore-dictionary.html

instead of the populate chunk event you might have better luck with the chunk load event. I was looking at this recently (and will probably file an issue about it) but there really isn't a great event for replacing the results of generation. There are events where you can fully replace the entire chunk provider, or biome and such, but if you want to let the normal generation happen and then replace selective blocks the populate chunk happens too early (also seems you can run into issue with concurrent modifications) and the other events tend not to pass the chunk primer. But I found that chunk load actually happens almost exactly where you need it to. So try that instead.

Our point is that a tile entity is NOT inefficient, it is actually super efficient. If you want a block to do something every tick, then you need to scan the world every tick to find all the blocks, then fire their update() code. To find all the blocks you'll want to avoid cycling through all the blocks in the world so you'll create a collection to keep track of all the locations where you placed a block. Once you've done that you've basically created the tile entity! Basically you can't do what you want to do any more simply or efficiently than using a tile entity. Also, why are you mentioning that you "like the look of the block and want to keep it as a viable building block"? Having a tile entity doesn't prevent that. A tile entity is really just a way to tag blocks (that can also act like regular blocks) as also having tickable code. That's it. I think you think tile entities are complicated because some people do complicated logic with the tickable code. For example, you can run a container to make a furnace, or you can create an animated model. But even if you just want a simple variable to record the player that placed the block, you should use a tile entity.

That should do almost exactly the same thing as instanceof, although instanceof has the advantage that any subclasses (like if some other mod extends BlockLeaves) would be recognized. But if it works then alls good. The main point to remember is that equals() depends on the implementation but often compares all the field values as well as the general class. If you want to match type you really want instance of, or compare actual class.

IYes. I believe that what happens is that each registry event happens across all mods, then all the objectholder annotations for that type of object are processed. So the injection does happen after all mods are registered. In fact if you look at the link the example shows exactly how to do this. You just need the modid in the domain of the annotation. Either the entire class annotation or the individual field annotation can specify the domain.

Why don't you want to use a tile entity? This is exactly what they are meant for. There really isn't a more efficient way, because you'll end up basically making your own tile entity system. You can't get around the performance impact of having multiple blocks checking multiple locations around themselves every tick. When people say that tile entities cause performance problems they don't mean that tile entities themselves are a problem, it is just that whenever you want lots of blocks doing complex logic every tick it costs performance.

instead of equals maybe try instanceof. That should cover all the variants, whereas equals() depending on how it is implemented could vary based on the field values.

Cool. See that is progress! Once you have observability pretty much every programming problem is easy to solve. Just keep working back and testing your assumptions on how things are working. With regards to creating too many of something, just check out every where the constructor is called and ask whether it is really needed. You'll find that either you do need that many references but maybe instead of creating a new one you can retain one for reuse. Or you'll find that the whole section of code that is constructing it is being called unnecessarily. Sounds like you're on track. But keep the thread posted. And if you get truly stuck of course we'll pitch in to help.

I've updated my PR, since you're actively working with fluids I'd appreciate you checking it out and making comments. https://github.com/MinecraftForge/MinecraftForge/pull/4619

That's not the way I would typically go about drawing a button. Normally you create an actual GUI class and add the button to that, then you open the GUI when you want it. Also, the draw screen executes every frame so by calling it in the keyboard input event I'm pretty sure it will simply flicker and go away.

Yes, it probably sounds accusatory (sorry) but was meant more as "tough love". Teaching you to learn things yourself. I'm only suggesting this because I feel you're ready for pushing to the next level of self-sufficiency. There are two types of problems -- common ones in an area of general modding interest, and esoteric ones that are mostly personal interest. There are also two types of people asking questions -- those who are weak in programming and those that are strong. You have an esoteric interest and are a strong programmer so proper help is to teach the skills to debug. If you were asking a common question and were weak programmer I'd spoon feed you the answer... No core mod is required. So I think you misunderstood my suggestion. Even though you don't suspect your own code, it is still most likely that the problem originates there (or in the way that it hooks into the vanilla code). There are certainly possible bugs in vanilla code (found one yesterday), but even then your code must have exposed it. So start with instrumenting your own code. By the way, this is a good habit to get into anyway -- a proper code validation needs to confirm every code path. With your own classes confirm that they are (a) being called as expected (b) not taking excessive time in their own right. If it is an actual memory leak, your IDE has ability to monitor that. Depending on your development environment google some instructions on debugging Java memory leaks. For example, Eclipse has the Memory Analyzer Tool. https://eclipsesource.com/blogs/2013/01/21/10-tips-for-using-the-eclipse-memory-analyzer/ Lastly, if you really need to modify the vanilla classes you just copy them and add your stuff -- replacing chunk providers is a standard modding activity. This is just standard debug practice and worth learning, especially since tracing the execution of the vanilla code teaches a LOT about how Minecraft is architected. But you can also use the debugger in your IDE and set breakpoints. Also, there is a built-in profiler that times some sections in the vanilla code which can help tell you if things are taking longer than expected. So again sorry I sounded rude, but intended to be more like a sports coach yelling at you to push harder to get to next level. You can do it! I promise if you do the above suggestions you'll feel significant advancement in your programming prowess.

You're right. That is a bug. You should report it as an issue on github MinecraftForge project. EDIT: I've gone ahead and logged the issue: #4617

So, I've gotten similar crashes recently when trying to handle the PopulateChunk event. Code I had that worked in previous versions for placing a bunch of blocks (kinda like what you're doing) crashed with concurrent modification exceptions now. I suspect it may actually be a bug because the point of the event is to allow some block editing at that point. But in any case, concurrent modification errors often arise when dealing with Java collections and iterating through them unsafely -- perhaps another thread is doing that at the same time you (or me in my case) were trying to place blocks. From inspecting the vanilla generation code, it seems that the safe way to do it is to use a ChunkPrimer class. If one already exists at that point use it, or create a new one. Fill that up with block placements and then use the whole thing to create the chunk. Look at how ChunkPrimer is used in the vanilla code for ideas.

I don't know why people write code, watch it behave badly, and then start asking others what might be wrong when you can simply debug it yourself. Basically you simply need to trace the execution. I tend to do this by adding console statements (System.out.println()) statements at strategic locations of the code. I usually put such a statement in each method I want to confirm is being called (usually printing out the parameter values as well), and I also put statements inside any conditional statements to check that my if-statements and similar logic are executing as expected. You can also use the debugger in Eclipse by setting breakpoints and such, but I personally find that less useful because much of what I want to watch is repeated operation during actual gameplay. I'm pretty sure that by adding such traceability to your code it will be quickly apparent what is going wrong -- in this case you might see things being called more frequently than expected, or chunks being generated when not expected, and you can simply keep working backwards to find the source of the problem. It is really hard to ask people on a forum to debug something like this because it is usually a very specific logic bug or typo/mistake that is really your responsibility to track down.

It doesn't auto-register the block. It actually does the opposite -- you register the block and it will go back and inject an instance to all the fields that match name. Whether you use it depends on your coding style. I don't necessarily name my fields the same as the registry names so have to add the additional matching name, and so I don't find it really provides me a lot of convenience. But some people really like to use it.

One thing I'm confused about in your code is that it seems you spawn particles in two different places. Are those intended for different effects, or is that because you were trying to debug? In terms of code execution is also the tracking distance of the actual throwable to consider as well. how are you registering the throwable entity? Note: I think your link to your github repository is out of date, because I couldn't find any entity code there. The other things to check is that when an entity is "invisible" there are three possibilities: 1) The entity is no longer tracked by the client. This is related to tracking distance. So code doesn't even run on the client. 2) The entity is tracked but the rendering isn't happening. 3) The entity is tracked and would be rendered but the position isn't where you think it should be. I don't think this is your case, but in many cases where someone says "my entity isn't spawning" it actually is but just at wrong location. To debug this, it is a good idea to add console statements (System.out.println()) at critical parts of the code so you can debug the execution. That way you can determine if the updates are continuing to fire and so forth.

You're using the wrong spawnParticle() method. If you look in the World class you'll see there are lots of variations. The method you're using will limit the range unless the particle type's getShouldIgnoreRange() method returns true. So one fix would be for you to use custom particle type that does that. But the easier way is to use the a different spawning method. There is a method called spawnAlwaysVisibleParticle() which ignores the range. There is also another spawnParticle() which takes a boolean field for ignoring the range.

extending gui is fine the way you're doing it because you're not replacing any gui. My point was that one way people might do HUD is to actually replace the existing one, possibly extending it depending on how different they want to make it. You're not replacing a GUI so it is fine.

Well the way you're using the GUI class isn't exactly the way GUI are generally used. For example usually they are opened explicitly and have a drawing update. You're just using it to have some helper classes, which is fine, but not the same as actually opening a GUI where you do your code within the screen update methods. There are different types of incompatibility. You can't avoid some other mod wanting to draw over top of your stuff, but you can do things to avoid the other mod from preventing your stuff from being drawn. For example, if you chose to make your own custom ingame GUI that extends and replaces the forge one then if someone else used the same technique then they would end up replacing yours (or you'd replace theirs depending on the order the mods load). However, if you both handle the overlay event then both of you will get to draw what you want. Do you see the difference? -- if you're replacing something then there is more chance of conflict. If you're adding something there is less chance.

The rendering events are already in a GL11 rendering mode/matrix so you can use GL11 and related helper classes (like GlStateManager) to draw on the screen. You can look at the code for GUI draw methods to get ideas on what to do, or look for tutorials on making HUD mods. The RenderGameOverlayEvent is fired inside the GuiIngameForge#renderOverlay() method. The reason why you want to use the correct render event is that they are fired in certain orders and if you draw in the wrong one then it will be drawn under other things that are drawn (and you might not even then see what you've drawn). You can also do your own GUI, but I think for overlay it would require substituting your own version of the ingame GUI which in my opinion could be potentially less compatible with other mods.

If you're trying to draw a HUD (overlay information) you usually do that in the RenderGameOverlayEvent. As mentioned by diesieben07 you should check events to make sure you handle the phase and also check for any sub-class events that are more specific for your needs (that simplifies the coding and improves performance). For EntityPlayer, as diesieben07 also mentions, it may not be obvious but the MP sub-class is for the server. So ideally you'd use the client side sub-class but also in this case it would be okay to simply use the parent class, EntityPlayer itself, since all the methods you're calling on the player instance are common.

Yeah, that's exactly the sort of thing I've been worrying about. And like you mention there you need habits to keep a pristine copy available to ensure selective changes only make it to your commits.

I notice that your package name and resource location are using "morediscsid" not "morediscs". You didn't include the code for your ModInfo class so it isn't clear, but maybe you have a mismatch between your actual modid and your folder naming.

Okay, cool, that's what I figured for each case.

So I've only done a couple PRs and am doing my first one that requires generating patches. I screwed up my repository on my first attempt and so am trying to start again fresh, and proceeding more cautiously. So I did the following -- I downloaded latest Forge MDK and ran the setupForge and sucessfully imported the Clean and Forge projects. I created a branch and did only two very simple changes. 1) added a single test mod file, 2) modified the Material class in the Forge project. Before I generated the patches I made a commit. Interestingly the git showed that two files changed -- the added test file as expected, but also a jsons/1.12.1.json. I looked in the file and the changes seemed to be related to the sizes for a couple assets entries. I'm certain I didn't touch these files myself. Why did they show as being changed? Should I commit it or have it in gitignore? But the bigger issue is then I did a genPatches. That completed successfully but now git shows that in addition to the expected patch to Material there is also patches to unrelated stuff, specificaly EntityList and Item classes. The changes are simply the diff annotations. For example it will say something like: - @@ -435,11 +445,704 @@ + @@ -435,11 +441,704 @@ Why the heck is genPatches creating patches for EntityList and Item that differ when I haven't touched either class?