jabelar

I already tried the validator and posted the result. You have an error (I think missing a comma) in your JSON. But it is good to get familiar with it yourself.

No that is the way to do it. You need to know the endpoint and the code in RenderFish is the same sort of code you need. Certainly you could write your own code if you're good at rendering but it would end up basically being the same as copying the RenderFish. I think you need to just figure out what is going wrong. You can go into debug mode or use console print statements in your code to output information to confirm that the code is executing the way you expect. In any case, people can only help you if you post your code (ideally as a repository on someplace like GitHub). Because these problems are usually just mistakes in your specific code and we have no idea what exactly you wrote for your code.

You should always run your JSON files through a JSON validator since the Java IDE doesn't really flag errors (although there are probably JSON editor plugins for that). So I always put it through a web-based validator. It is really easy to miss a comma or bracket in a JSON and have it messed up. I put your fig_box.json JSON file through a validator (https://jsonlint.com/) and it has an error: Error: Parse error on line 10: ..., 26], "to": [1 2341, 0.1, 10], " ----------------------^ Expecting 'EOF', '}', ',', ']', got 'NUMBER'

There should be a warning about missing block state or texture in your console. Can you post that? Generally, in your inventory it only looks at the inventory state and processes the model for that, but your actual block might have multiple other states and something is probably wrong in your block state file or your model file or your associated texture. Usually just a typo or mal-formed JSON.

Well, I know it is nice to make everything "algorithmic" where you can create sets and have nice methods that embody the functionality, but obviously it also created a chance to introduce bugs. Instead of getting "fancy" with a set of entity entries, why not (at least for now until you get it working) just do it all flat and in-line (like don't even create a collection or loop, just make entry and register, make next entry and register that) right in the single registry handling method. Get THAT working first, then re-organize your code.

Sometimes it makes the most sense to just do your testing in the final build environment. I mean you can start mucking around with dragging things in and out of your dev environment, but it doesn't take that long to just build and test either. I think if you want to do it your dev environment I think you'd set up the mod as library outside the mod folder. During the run it would look for mod jars in the mod folder but in the development environment it wouldn't complain about it not being there. But other folk here know more about such things than I do.

Wait, what are you trying to achieve? Are you saying you want your mod to run okay even if the user doesn't have the other mod at all? Or are you just asking how to add the mod into your Eclipse run? If you have code that references a mod that might not be loaded, you have to do special things to make that work properly such as using the @Optional annotation or creating a special proxy system. If you just want to know how to add mods to your development environment, I think NolValue is correct except I think (might be wrong) that the version of the other mod's JAR needs to be the deobfuscated one. You can often ask the mod author for this, or can find it linked wherever the mod's download repository is.

You shouldn't have to compare :all the way up to now". Assuming that the bug is definitely introduced going between two commits then by deduction the bug must be related to the commit. So you should focus on that one change and compare that. Note though that the new commit itself might be okay -- a properly coded new commit might just be exposing a bug in existing code. But the new commit should still give you clues based on what existing code it interacts with. So in order to properly narrow this down, which commit exactly resulted in the bug starting to occur? (In your compare I'm not sure whether it was the first or second commit.)

Yeah makes sense.I wasn't really arguing that you're wrong. I just wanted to be clear about the part of the conversation where Cadiboo is "learning" that classes load when used. Which is supposed to be true, but technically "it depends".

Yeah, same idea. But I don't know that it is safe to assume generally assume a class isn't loaded unless a method from it is invoked. It depends on the class loader implementation and possibly the JVM implementation. Some class loaders do actually do lazy loading in advance, not sure about Minecraft's. There is also technically a difference between loading and initializing a class, so need to be careful when reading info about "loading" as some information on the web is confusing the two -- initialization definitely happens when first access to a symbol in a class happens, but loading may happen before. Lastly, even if you can trust that class isn't loaded until used you have to be careful that there are no other initializations or static references as well that might trigger it -- for example, I don't know but I suspect that having annotations like client-only annotation might cause loading. Someone with more knowledge of the Minecraft class loader would have to weigh in... If we could rely on classes only loading when referenced then we wouldn't really need the client proxy system... I think explicitly handling the mod loading in pre-init like in the tutorial is more generally "safe".

Firstly you're not using the proper way to register entities for 1.12.2. You should be using the registration event with the entry builder technique. The entry builder has addSpawn() method that can directly take an array of biomes. I have an example here: https://github.com/jabelar/ExampleMod-1.12/blob/master/src/main/java/com/blogspot/jabelarminecraft/examplemod/init/ModEntities.java

There's a way to make your own proxy system that depends on what mods are loaded instead of which side you're on. I have a tutorial here: http://jabelarminecraft.blogspot.com/p/minecraft-modding-system-for-optional.html The basic idea is that you would have methods that in case that a certain mod is loaded would do one thing (which is safe to reference that mod's classes) and otherwise do nothing (i.e. not referencing unloaded classes).

If you have code that may depend on a mod that may or may not be installed you might want to try using the @Optional annotation. There is a good explanation here: http://cazzar.net/tutorials/fml/optional-annotations-the-usages/

I am not positive but I think you have to create a fluid block as well. And the color/texture from that gets used. Or something like that.

Don't your particles "die" after a couple seconds? I think the vanilla system just relies on the fact that a small number of short-lived particles are in the world at any time. If you're producing particles faster than they die then that would be a problem no matter what. And the steady-state memory usage depends heavily on the ratio of rate of particles emitting versus particles dying.

Capabilities are the way to add new fields of information to vanilla entities including the player. And events can be used to override the vanilla behavior or rendering if needed.

We know what he wants. We don't know his problem. Does he even know how to set up Forge? Has he followed any tutorials for doing the things he wants to do? Is it not working and if so what is wrong? He needs to show his code so far so we can determine what kind of help he needs.

I totally understand the mirroring method of Cartesian rotation. And it isn't that hard but the problem with the swapping method is that there are a couple details in calculating the center with potential for causing some confusion. Maybe not confusing for you, or me, but for the average modder probably. Imagine your matrix is a 5 x 4 matrix: A B C D E F G H I J K L M N O P Q R S T And you're rotating clockwise by 90 degrees to get: P K F A Q L G B R M H C S N I D T O J E So I believe, correct me if there is simpler way, the steps for your algorithm are: find center block of the base matrix. Easy right -- just divide the dimensions in half so it must be 2.5, 2. But wait if I look at the array the center is really at the 3rd position across and 2.5 down, so isn't the center then actually 3, 2.5? Okay, but wait in computing we start counting at 0 so the center is really at the array index 2, 1.5. Now we can start swapping. We'll create an empty new array and populate it. The dimensions should be a 4 x 5 array now. For rotation we want to implement it by transforming (x, z) to (-z, x). The first element in the base is at index 0, 0 but we need to convert that to a relative coordinates from the center so let's say the first element is at relative position -2, -1.5. We swap that so it is now 1.5, -2. Also the swap results are now relative to the new array center at index 1.5, 2 so we add them and get index of 3, 0. Yay, it worked! Now I admit that isn't that hard, but you have to imagine the "average" modder on this forum implementing this without the hints I gave above. Wouldn't you bet that we'd be getting questions where it wasn't working because people screwed up by not figuring out the center properly? By the way, the point of my recommendation was to "pre-rotate" the structures. I'm not at all against using this algorithm for doing it in advance. I just think people will muck it up combining the rotation into the loop that does the actual checking. P.S. Thanks for taking the time to make the animated pictures!

The concept is obviously simple, but the implementation really isn't so much. I entirely know how to code it, but why bother? You're glossing over the fact that every block needs to move a different amount. If you have a 4 x 4 structure, each corner has to move 3 blocks in a straight line, but one edge block on each side needs to move 3 blocks plus 1 block over, and one edge block on each side needs to move 3 block plus 2 blocks over. Then the blocks on the inside each just move 1 block. So every block has to move differently. It is conceptually simple, but it is a pain. And because these are blocks which are discrete, the movements are different for odd versus even. And anyway, calculating new positions at all is more processing than needs to be done with a pre-rotated structure -- which needs none. So performance-wise an algorithmic rotation is always going to suffer a relative performance hit. I agree it is totally possible to do it your way, but fail to see any advantage in doing it algorithmically, especially if you want to generalize it for arbitrary size. My way is literally 10 lines of code or less, less likely to have a bug, and performs faster.

The logic for rotation isn't that simple, as the movement needed for each block is dependent on the size of the overall structure and distance of each block from the center. You also have to do different math for structures that have odd number of blocks on each side (in which case there is a center block) versus even number of blocks on each side. And if your structure isn't same size on each side you have to add logic to "pad" out the short side during the rotation. But even if you consider the rotation logic simple (and for you Draco18s I'm certain it is relatively simple), that is already too much thinking. Furthermore it is also a performance hit. Having the structure pre-rotated with simple looping is less lines of code and can be super efficient. The other problem with clever algorithms is that they are much more prone to bugs and harder to debug. It would be pretty hard to screw up looping through a pre-set matrix.

The best thing to do is look at the Type Hierarchy of the related classes and scroll through all the methods that are there and it is usually obvious what the new name is. Sometimes it is just a new name, and sometimes it is changes to the parameters or return value, since a method needs all three to match. But in any case usually pretty easy to figure out. If you really get stuck, then what you need to do is load the old version and see where the method is called from, then load the new version and go to same place to see what is now being called. Hope that makes sense.

I know you solved it, but just in case other people come to this thread: Whenever you're handling an event that is client-side only you are free to use the Minecraft.getMinecraft() method to get the instance of the Minecraft class. From there you can access all sorts of client-related things such as the player, keybinds, mouse movement, rendering stuff and so forth. So you'll notice client side events often don't pass much information in the parameter because they know you can access it directly through Minecraft class.

Yeah, I would do it that way. Have a matrix (or whatever format you have for your template) for each possible orientation and just check them all (efficiently like we discussed above). Otherwise you'll do a lot of coding (and probably bang your head over bugs) trying to perform the math to rotate inside the loops.

The GameSettings class has public fields for all the vanilla key bindings. For example there is field keyBindLeft, keyBindRight, etc. To check for these you should handle the KeyInputEvent and since it is client-side only you can use the Minecraft class to get the GameSettings instance then get the keybind then call method to check if it is pressed. For example: if (Minecraft.getMinecraft().gameSettings.keyBindLeft.isPressed()) { */ Do something here /* }

Okay, in that case I would add a bunch of console statements throughout your code and then trace what happens. Like add a statement in each method and then you can confirm that every method is being called as expected. Of course in your print statements you can print out any values of interest as well to aid the tracing. It should be quickly obvious what the problem is once you trace it.