jabelar

Actually you already got help here and it isn't specific to 1.7.10. And you said you already know Java. So there shouldn't be any problem. All we're saying is that you need to take the mod that doesn't have an API and make an API that does the same thing as the other API you have. Then you can work with both systems in the same way. So take the RF API and make a list and then figure out how you would do the same thing with the other power system code. That's it.

Wait, what exactly do you want to do? Even if you use the world Random with a specified seed, it doesn't necessarily provide predictability in the rest of the game unless you use it only during world generation. In other words, if you use it later in the gameplay you won't know how many other things have called for random numbers. If you want your own sequence of pseudo-random numbers with a controlled seed I personally would generate my own custom Random sequence.

I've made a list of a number of things that I found changed when I was upgrading my mods to 1.10.2. It's not a complete list but should give you several ideas that will help. http://jabelarminecraft.blogspot.com/p/minecraft-forge-upgrading.html

I didn't try that tool but upgraded my mods by hand. I have compiled a list of the types of mapping changes I found when updating my mods. You can see the list here as it might help: http://jabelarminecraft.blogspot.com/p/minecraft-forge-upgrading.html

If you want help you need to say more about what you tried, what you have thought about so far. Otherwise it looks like you want us to write it for you. For example, tell us your plan for your own power system as a start. By the way, in 1.10.2 there is now a Capability called EngeryHandler which can be used for this. Anyway, code something and then ask us for help fixing it. Or tell us a detailed strategy and ask us questions about the strategy. You can't just ask "how do I do this."

By the way, if you're uncomfortable with trigonometry (it is even more of a pain in computing if you aren't comfortable with with concept of radians) you can actually do repetitive motion without any actual math. Instead of math you can take some graph paper and find the points on the path you want and then put those into a List data structure and then cycle through that. I use this a lot in animating entities where calculating the trigonometry is complex or where the motion does not follow a simple equation. This is the same technique that "stop motion" animation uses -- you just put the object in each position and then run them together to make the illusion of motion. Since Minecraft uses 20 ticks per second, if you wanted the circular motion to take 1 second then you need 20 points from a circle in your list. And since you want the motion to be around another entity, you would just add the values from the List to the position you want to orbit around. In most cases of animation, using this method (a List of positions) will give better results and take very little time than trying to calculate the positions.

I've posted a bunch of the stuff I encountered when upgrading my mods from 1.8.x to 1.10.2 here: http://jabelarminecraft.blogspot.com/p/minecraft-forge-upgrading.html

I kinda liked your idea of using a regular entity for this. Control and coding would be really easy, and frequent updates and lighting would work well.

Kokkie, You are missing some fundamental ideas about how the client and server work. In most multiplayer games, including Minecraft, the server is the ultimate determiner of what happens in the game and the client(s) just allows interaction with the user. So the client primarily is responsible for taking in input, rendering graphics and playing sounds. However, it isn't quite so simple because if that was all the client did then it would look really glitchy because the network would not be able to smoothly transmit all the data needed. So most gaming clients also provide some "tweening" (smoothing out the gameplay between syncs with the server). This means that the client also runs some game code so that it will mostly be correct until the server syncs up again. But despite the client running some of the game code, the server must always get the information from the client via networking before it can take action on it. When you play single-player it is actually still running a client and a server. However, in Minecraft it is a bit "goofy" because both run in the same Java instance. So it looks like only one program is running which can hide the fact that your Java programming won't work when the client and server are actually separate. For example, as diesieben07 pointed out in single player you could have a static field that could be accessed by both client and server (because both are running in the same instance) without any network activity to sync it. But that is still bad because it will break as soon as you run actual mult-player. To fix this, you need to make sure a packet is sent to sync up the information. Any time user input happens the client needs to send it to the server, and any time the server updates something (like the position of an entity) it needs to send a packet from server to client. Now there are many cases where the packet will automatically be sent for you. For example, if you place a block on the server there is already packets that get sent to update the client. However, if you're doing something custom you probably need a custom packet. So in your case, you need to set up a networking system (see any good tutorial) and whenever the condition in the GUI happens where you want to award the XP Cookie, you should send a custom packet to the server. The server will know which player it is because it knows which client the packet came from. I've got a tutorial on networking here if you're interested: http://jabelarminecraft.blogspot.com/p/minecraft-forge.html This is an important concept and takes every modder a while to really understand. But it is worth it to understand or you'll constantly be getting "weird" behavior in your mods due to lack of synchronization.

While it is certainly good to develop habits of using efficient approaches, generally with a modern computer efficiency isn't a big concern and rather it is more important to code in a structured way that is readable and simple. Then if performance does become a concern, it is usually something you can tackle using the Pareto principle -- meaning that usually just a couple things are causing significant impact. You can identify those areas and just tackle them when they are a problem With that being said, if you're doing crazy things like big loops iterating through complicated data structures, or if you're doing things like creating memory leaks that stress out the memory manager or networking, it is best to avoid those in the first place. But generally: 1) Don't do obviously taxing things (2) tackle optimization only when needed.

It always amazes me that people ask questions about how to make cool-down timer type functionality. I think people forget that modding is just programming and anything you can do with Java you can probably do in your mod. While items do have a built-in system for cool-down (as mentioned by Choonster) I feel compelled to point out that this is a very basic programming problem. You simply need an int field that gets set to a value (since Minecraft works on 20 steps per second, it would probably be set to 20 * the number of seconds you want for cool-down) whenever the action starts and decrements by one in some method that runs every tick (like updateLiving()) until it reaches zero (then stays there). Then whenever you want to start the action you just check to make sure that field is at 0 and do it all over again.

It will not be the same for every game run, if it is random. On the second run, the game would load the mod and call registerModEntity again with a new value. It is only random if you make it random purposefully. And it would be a bit of work to make the IDs both random and unique. Pretty much every mod I've ever seen or written, I simply start at 0 and increment by 1 for each mod ID as I register the mod. I can't imagine any reason you would randomize it.

CraftingManager::getRecipeList can be modified. Note that of course you need a code-based way to figure out which recipe(s) should be removed. I usually do that by searching for the recipe output matches (i.e. remove all recipes that can make a certain something). The code could look something like this: It is a bit trickier with Crafting if you want to make sure all recipes for an item are removed, you'll need to iterate through them all like this. (Note this is from 1.7.x and is an example of removing a furnace so you should replace that with what works for you but you should get the idea): Iterator<IRecipe> iterator = CraftingManager.getInstance().getRecipeList().iterator(); while (iterator.hasNext()) { IRecipe recipe = iterator.next(); if (recipe == null) continue; ItemStack output = recipe.getRecipeOutput(); if (output != null && output.itemID == Block.furnaceIdle.blockID) iterator.remove(); }

To be clear, you set the ID when you use the EntityRegistry.registerModEntity() method. The third parameter is the ID. They are unique per mod. Most people simply increment the ID but as long as they are unique within your mod you can do what you want with the ID. The ID will be the same every time you run the game and will be the same for anyone who runs the game. Again you are the one setting it.

For crops, this usually happens when you construct / register the seed item before you construct / register the crop block. So you need to control the order they are constructed / registered. But as JeffryFisher says you should practice your ability to debug this sort of thing yourself. Find the null pointer then think or trace back why the thing that is null is so at that point in the execution.

no hacks and ASM needed just edit the log4j confit You mean edit the configuration file directly in the Minecraft JAR in your workspace, right? That's what I had to do in the past when I changed the log level, and the pain with that was I had to update it every time I updated Forge. Or did they fix it so you can put your own log4j directly in your project?

For the ragdoll part don't you need a custom model? And your entity will need some sense of momentum (maybe per part but at least for the body) stored in a field. So then you can calculate all the angles of the model parts according to the physics happening to the body. To emphasize the ragdoll effect you might want to consider making the arms and legs have elbows and knees. And you might want to scan the surrounding for blocks and adjust the angles based on model parts that hit those blocks.

Your repo is pretty much just the examplemod. What exact steps did you use to setup your workspace? you ran both gradlew setupDecompWorkspace and gradlew intellij command line instructions? Can you post all the output from those commands? Then you imported the project properly? I use Eclipse so maybe there are some other tricks with setting up IntelliJ but that would be all that is needed with Eclipse (except also need Java setup properly of course).

Another approach for any case where you're worried about world saves staying up to date is to do an explicit conversion -- basically check versions and if you detect an upgrade that you know requires conversion process the world save data (or replace directly in the world as it is loaded) accordingly. This can even be done for major Minecraft upgrades and such. it's a bit of work but is a fully managed way to accommodate upgrades while retaining your favorite world saves. If you're really ambitious you can also handle downgrades as well.

Look at the way that vanilla Minecraft handles child entities -- like baby cows, slimes and such. They basically look up a field in the entity (isChild()) and then do GL scaling as suggested by Ernio.

Okay, I think you're saying that AABB isn't good for you because you don't like how it is axis aligned. Well I would say that that is most of Minecraft's charm -- that it is blocky and grid based. However, if you're saying you want to affect all entities a certain distance from where the projectile hits, what you can do is first find all entities in an AABB that is big enough to contain the "circle" that represents the range you want to check. Then for all the entities in that list, loop through and calculate the distance (simple trigonometry using sum of squares) between the entity and the center of the weapon effect and then keep those entities that are in range.

Okay, I guess that makes sense. It wasn't too hard to fix, but I really don't think I did anything that should have caused it but maybe some keyboard shortcut or something was inadvertently pressed.

I was just "happily' working in Eclipse (Neon) and had multiple projects loaded, which is the way I always have worked and suddenly my files started getting red-lined with lots of errors indicating my imports weren't recognized and I looked at the referenced libraries in each project and the no longer had the forgsrc libraries. I thought that maybe Eclipse just got buggy so I restarted Eclipse and also restarted computer, but it did not help. I reran gradlew setupDecompWorkspace and gradlew Eclipse and that fixed the problem. But had to run it on each project (and I've got dozens of them so it was a pain). Why would the referenced libraries get screwed up on all my projects simultaneously? I understand the class path of one project getting screwed up, but all of them?

Hey Bloopers, sorry you'r having trouble following my tutorial. In terms of extended reach, the idea is you need to send a custom packet and that requires some knowledge to do that (which isn't specifically described in that tutorial because different people have different approaches to it). I do have a separate tutorial for custom packets: http://jabelarminecraft.blogspot.com/p/minecraft-forge.html Note that this was written for 1.8 and haven't had time to do any updating that may be necessary for 1.10. So you might want to look for tutorials on 1.10 custom packets.

It helps if the new stuff is in the same class. Like if you're following a tutorial that used the BlockModelRenderer.renderModelStandard() method and saw it wasn't available any more then you could look at the methods listed in the same class (BlockModelREnderer) and you'll notice that there is a method called BlockModelRenderer.renderModelFlat() and if you look at that method you can guess that it is used in the same way. However, Type Hierarchy won't help you for the two issues you have because a) geMouseOverExtended() is a method from my tutorial so has nothing to do with version, and b) MovingObjectPosition is a class not a method or field. Assuming you copied all my code, you actually have the getMouseOverExtended() method already. However, Eclipse might be complaining about it because it returns a MovingObjectPosition value which it doesn't recognize so then it also won't recognize the method. So actually you only need to fix the MovingObjectPosition and that should also fix the getMouseOverExtended() as well. Now when a whole class gets changed, it means there was a more extensive change that probably needs more thought and can be tricky to figure out. The best way to figure it out is to compare the source code from the older version and the newer version. For example, load a project in 1.8 into Eclipse and check where MovingObjectPosition is used in the Minecraft source. Then also look at your the 1.10 source and look in the same place and see what is now there. It is usually pretty obvious. Anyway, that is what I just did. And I found that MovingObjectPosition has been renamed RayTraceResult. I haven't looked further to see if the class itself has changed, and I'll do that when I get time, but this should give you a good clue on how to fix it.