jabelar

Although your main problem is with the custom constructor, as mentioned above, I think you still don't get the full scope of what I was explaining. There is the entity class and then there are instances of the entity class. For every entity that spawns in the game, there are actually two instances -- one on client and one on server. The fields in these instances can only be synced up through network packets. The built-in fields like position are automatically kept in sync through built-in packets. Furthermore, the syncing isn't necessarily in both ways. Like if you update the position only on the client, it won't take effect for long because the next time the server sync's it will return to the old value. So, from within a client side class like the renderer, you cannot actually change things like position, at least without sending a custom packet and handling it on the server. It may appear to work for something that is visual like orientation because the visual effect is processed on the client. For example, if you had a custom field in your entity that controlled whether the entity glowed, if you set that on the client the glowing would probably work. However, if you save the game, you'd lose that glow because the save information only happens on the server side. Not sure if that was clear, but it is an important concept. Basically the thing to remember there are two entity instances running in parallel and the server side is the master and they won't be synced unless you use custom packets. One last important thing, if you ever spawn an entity from the client side, it might appear to work but is really just a phantom that isn't fully recognized by the game. This is actually okay for something like a particle that is a temporary visual effect, but generally better to have server aware of all entities.

I like the idea of substitution but only last tried it while it still wasn't working. If it's working now that is great news. But previously the way I did this was also fairly easy to maintain -- I simply intercepted the placement of the block using events and placed my block instead. This at least works for blocks that will appear during world-gen. If you're worried about creative mode where there will be custom tab with list of all blocks, you'd have to intercept that too to show your custom block. So not that hard to intercept. But again a working substitution system would be better. Just wanted to say how we used to do it when substitution didn't work.

Awesome. That makes sense.

The renderer is only on client side. So if you do anything to the entity in the renderer code it will not take effect on the server without using packets. Possibly this is causing your issue.

I tried EntityInteractSpecific and it does exactly the same thing. Weird. I guess I might do the work to create a new mod that only handles these events to make sure there is nothing else in the mod causing this. But I have a lot of experience with modding and event handling so generally know how to debug these issues... but I am a bit rusty so maybe I made a mistake somewhere. Anyone else have any ideas? Especially anything that might have changed since 1.8?

Okay, I'll try. But do you have a reason, or just guessing. It seems to have exactly the same call hierarchy as EntityInteract does.

I have some tips on setting up Eclipse, Java, and a git source code revision system for modding here: http://jabelarminecraft.blogspot.com/p/quick-tips-eclipse.html Regarding learning Java, as JeffryFisher said you can only learn Java by modding if you're already good at several other programming languages. Otherwise, I actually recommend learning from a book. A book is better than online learning for programming because people tend to skip the fundamentals when they do online learning. A book makes sure that you learn the boring stuff which is actually often the important stuff. However, most programming books are quite scary (very thick and easy to get lost and bored). So I recommmend a book called Java in Easy Steps. It is quite thin and friendly but still covers all the basic, important stuff to know.

Hi, I've been away from modding for over a year and I'm stuck in China for a few weeks so had some down time to try porting my 1.8 mods to 1.10. It is mostly going well and now I'm working through the new bugs that have cropped up. The issue I'm looking at now is that I have an interrupt handler that converts an ordinary cow into a custom cow if you right-click on it with a golden carrot. This worked fine in 1.8.9 and I didn't do much at all to convert to 1.10.2 but it is behaving differently -- if I interact it creates two of my custom cows for just one click. So to debug I added some println statements to help trace the code. And it seems that the EntityInteract event is being called twice on each side. I see it print out that the interaction happened on the client twice and then on the server twice. I checked on a few theories on why this is happening. Theory 0) I thought maybe I wasn't handling fact that the event fires on both client and server, but my console output shows that I'm properly handling the server case by short-circuiting the execution. Theory 1) I thought maybe the EntityInteract had been extended to have some sub-events, like a Start and End event, such that it is now called twice but I couldn't find any such thing. Theory 2) I thought maybe I had some duplicate event handling somewhere due to cut and paste or something. But I only have one EventHandler class and searching and checking for duplicate methods doesn't come up with anything. Theory 3) I thought maybe EventInteract was actually constructed twice now. So I traced the call hierarchy and found the following: 1) The EntityInteract event is only constructed in the Forge Hook for onInteract() 2) The onInteract() method is only called in one place: the EntityPlayer#interact() 3) The interact() method is called in two places: a) PlayerControllerMP#interactWithEntity() b) NetHandlerPlayServer.processUseEntity() Now that all makes sense because the interactWithEntity() is called on the client and in same code a CPacketUseEntity is sent, and the NetHandlerPlayServer handles the packet when received at the server. So that is the client and server side. I can't figure out why all this is happening twice then! Any ideas? Here is my EventHandling code: And here is the console output:

But only if you override the save / load methods properly.

If you want the list of all the possible overrides, I'd use the Type Hierarchy feature in Eclipse. With that you can expand the class to see all fields and methods all with indications of their "scope". In Java, anything that is public or protected scope is override-able, where as private methods are not. It is good to familiarize yourself with all the override-able methods because it can often give you ideas for your mod and generally someday the familiarity with the methods will help you quickly plan any feature you want to implement.

Yes, a lot of people don't realize that the conversion from the cryptic "SRG" names like P_354533_1 happened over time and the downloadable forge for some reason often has an old mapping in the build.gradle file. So it is a good idea to update the mappings every month or so. On this tutorial page under the "Using Latest MCP / SRG Mappings" section I explain how to do this: http://jabelarminecraft.blogspot.com/p/quick-tips-eclipse.html

It's just personal preference, and something drilled into me by my work. Variables start with lowercase, functions start with a capital. Really? For Java? That isn't really typical. Of course the compiler doesn't care and so the code will work fine, but whenever you share code (like how you're asking for help here, it hurts the other human's ability to quickly read your code).

What Ernio was so nicely trying to explain is that creating the new instance of EntityCow simply constructs the data for the cow in memory, but doesn't actually add it to the world to participate in the game. To do that, you need to spawn the cow in the world, and furthermore make sure the position is correct. Note also that you must spawn the cow on the server side, otherwise it creates sort of a "ghost" entity that will look right briefly but then do weird stuff.

Well his English is better than our Korean! I don't think English is the problem, I think he just isn't that familiar with modding, especially event handling, and maybe programming.

As mentioned, whenever you are trying to intercept vanilla behavior you should see if there is an event that can help you. Forge has provided a lot of events for the common things that people would like to modify such as breaking blocks, interacting with entities, joining a world, and so on. In this case the event you need to handle is EntityInteractEvent. You need to write a handler method that is annotated to subscribe to the event bus, you need the class with the method to be registered as an event handling class, and inside the method you can take the event parameter that is passed in and look at its fields. It will tell you the entity that is being interacted with, and you can then check what class the entity is. I have a tutorial on handling events: http://jabelarminecraft.blogspot.com/p/minecraft-forge-172-event-handling.html

I find that the easiest code logically for this is to take a cube (or square) that is big enough to contain the entire sphere (or circle) and then just check (using simple Pythagorean theorem math) every position for distance to the center. If it is within a certain distance you can destroy it. If you want a ring instead then you would only destroy it within certain range of distances. This is a lot simpler than using vectors, or sine / cosine, etc.

As Draco mentions, Minecraft mods are just Java so anything you can do with Java you can do in your mod. So you should just look up how to do files in Java. File handling can be a bit tricky looking if you haven't done it before. One of the keys is that you need to open and close the files, and usually you manipulate the data in a "stream" that resides in a "buffer" (an area of memory where data is waiting to be accessed, usually in first in, first out order). There are all sorts of variations on how this can be done in Java, but basically it is up to you how you want to pack information into the stream. You basically need a "parser" that you write based on the information you wish to read. For example, you could make a different file for each guild and simply pack it with a list of player UUIDs. Or you could create one file that lists a name of a guild, a number that indicates how many players are there, then the list of player UUIDs, then name of another guild, and so on. Anyway, again just look up Java file processing to understand all this better.

That doesn't happen automatically. If code on one side (like server) is changing the EEP without similar code running on client, then you'd have to use a custom packet I think to sync it. Also, are you doing this for your own custom entity or adding EEP for vanilla entities. For your own custom entities you don't really need to use the EEP system, but rather can directly override the writeToNBT() and readFromNBT() methods. But again, to sync client to server you need a packet.

I think that you should try making your own world save converter. Make a command or something that opens previous world save but you parse it yourself and make sure everything moves over. Then start a world with nothing in it, convert the save, then save in the new version.

You're right that is likely an issue. The canPlaceBlockOn() method he has is: @Override protected boolean canPlaceBlockOn(Block block) { return block == Blocks.farmland; } Instead you need to check for both the case of farmland below, or same crop below with farmland below that.

Well, you need to just do standard debug process. The addition of the next block happens in your updateTick() method so you just need to trace through and see why the condition to place the block isn't happening as expected. I usually trace things using console or logger output, where I put a line to indicate that each code path is executing and also output any key values. Like before you check if the next block should be placed, I would put a System.out.println() statement that outputs the values for meta as well as confirmation that there is farmland below and air above (i.e. the condition you are checking). It should be quickly obvious why the condition isn't being met if you trace it like this. You can also use debug mode and breakpoints in your IDE to do similar sort of tracing of code execution.

Did it change in 1.8.9? Because if not then you can use tutorials like mine: http://jabelarminecraft.blogspot.com/p/minecraft-forge-1721710-modding-tips_29.html

if you scale you always need to also translate because otherwise the entity will scale into the ground. So you have to translate by the eye level then translate back by new scaled eye level. I figured out the formula for that: GL11.glTranslatef(0F, 1.5F-1.5F*scaleFactor, 0F); Maybe that is the issue you've been facing -- the model origin is offset from the entity origin by the eye level? Not sure about your entity flying away problem though... Instead of events, if this is for your own custom entities only, you can @Override the preRenderCallback() method in the custom Renderer class for your entity. I usually do my entity scaling there. Or you could also do it within your Model class. If you want to do the scaling for all entities then yes you need to get the events working for you.

I think your pushing and popping of the matrix is probably screwing up. You have them both happen conditionally, but what if one of the conditions isn't true? You might do extra pops or pushes. Furthermore, I'm not certain what happens if you push in the Pre event and pop in the Post event because these events are called for ALL the entities. So what will happen is that it will push, push, push, and then pop, pop, pop. I think you shouldn't need a matrix at all because I believe the render event should already have a matrix that is focused on the entity of interest. So I'd try just scaling directly.

Hold on. Setting the acceptedMinecraftVersions might prevent it from complaining about the version, but how do you actually make a mod work with multiple versions? For example, you couldn't just take a 1.7.10 mod and make it 1.6.4 or 1.8.8 compatible just by adding those versions to the acceptedMinecraftVersions. The features, approaches, and many methods and field names are different between versions. So how would you code against multiple versions?