jabelar

In the console when it prints twice, I expect it is once on the client and once on the server? Which one is zero?

I think what you're asking for is essentially an uncrafting method, right? Like you want to take an item that was crafted and know what could be used to craft it again? Uncrafting is actually fairly complicated. I did work it out for 1.8 when I made an "uncrafting table" where you can put something in and get the ingredients out. Here is the code repository where I did the deconstructor recipe analysis. Look at all the classes starting with "Deconstructing": https://github.com/jabelar/JadensMod/tree/master/src/main/java/com/blogspot/jabelarminecraft/blocksmith/recipes The idea is that during post initialization of the mod (because I also want recipes from any other mod that is loaded), I use these classes once to go through the various crafting recipes and store their ingredients for future use. If you look into the classes you'll see they require some tricky programming, because there are several different types of recipes. One of the other things is that some crafting recipes produce more than 1 output. So you'll see that I have modes for my table that spread out the ingredients to be fair -- like you wouldn't want game to allow you to get more ingredients back than you used in the first place. In your case, if you just want to display the recipe, you might not care about that.

In a way it is, but it is dogma that is based on experience. Now maybe it doesn't matter so much in Minecraft which is only keyboard-controlled. But when I'm programming my own games I usually want to provide options where controls coming into the server can come from end users who are either local, remote, and using either gamepad controller or keyboard. In that case, it is easier to maintain a scheme where the server just receives functional commands ("move left", "strafe right", "jump") and the clients convert whatever the user happens to prefer for input to those commands. Technically though you can certainly do the conversion on the server. I think my main argument to you would be that people who play minecraft may play across multiple servers but prefer to have same keybindings on each. In other words, it is logically a setting that carries along with the client. So makes more sense to handle it in the client, store it as a preference on the client machine, and so forth. If the master information on keybindings was stored on the server, then user would have to go through extra work to configure on each server, and that might be a (minor) pain.

I guess I'm still confused as to your purpose. Why would "end user of the API" want to check this? The whole point of keybinding is to allow users to map keys without anyone else needing to know about it. And if you mean you want to allow another mod to know about it, well they can have their client-side code check out the keybinds directly.

Do you want your modded armor to also allow dyeing to different colors? Or do you just want a single color. If you want a single color, it might be easier to simply copy the texture to your own texture asset and color it in a graphics program to get it the way you like it.

Sorry, my second link was supposed to be: http://jabelarminecraft.blogspot.com/p/minecraft-modding-configuration-guis.html

I suspect you could, on the client side, somehow associate raw key presses with the keybindings being generated to figure out what the current association is. Then if really desired on the server you could send a custom packet to sync server. However, as mentioned by other people this is a very odd use case. The whole point of keybinding is to allow user to use keys without the server caring about it.

You should use git, but I recommend that you use it with SourceTree which gives a graphical interface so it is a lot easier to understand what you're doing and so you won't accidentally wreck your code with powerful git commands. I have a tutorial on using git and SourceTree for modding here: http://jabelarminecraft.blogspot.com/p/minecraft-forge-publishing-to-github.html Note that even with source control like git, if both of you work on the same class files at the same time it can be tricky to merge. So I suggest you divide up the work so you're working on different areas, and also make sure each of you checks in your work very frequently so you don't end up with large, complicated merge later on.

Client-only can work for things that are purely visual and temporary, like camera shake. But if you actually want the entity to turn or change actual position, the server needs to know about it.

flag 8 seems to be used in RenderGlobal.notifyBlockUpdate() which passes true as a parameter to RenderGlobal.markBlocksForUpdate() if flag 8 is set. markBlocksForUpdate() passes that flag as a parameter to the ViewFrustrum#markBlocksForUpdate() method which passes it as the only parameter to renderChunk#setNeedsUpdate(). So basically it tags the entire chunk for a rendering update it seems.

One reason I believe that Minecraft wisely limits both the block and entity bounding boxes is to aid path-finding (i.e. the logic to let entities move around avoiding blocks). Path-finding gets exponentially more difficult (more buggy and lower performance) if you allow arbitrary size and shape of the bounding boxes of either.

You might be able to adapt a method I used to speed up the generation of structures. I was working on a mod where I wanted to generate a castle way up in the clouds and found that due to lighting updates, blocks placed up high take a much longer (like minutes for full structure) to generate if you update lighting for each one. So after a bunch of work, I found a way to place blocks without lighting update. This is only temporary of course, and I purposefully invoke some lighting updates when my structure is finished. But maybe I can give you an idea where to look. The Chunk.enqueueRelightChecks() method seems to be one key. The comment for that method says: This method works on a private field called queuedLightChecks which seems to simply count from 0 to 4095 to step 8 at a time through all the blocks in a chunk. I think that by using Java Reflection you might be able to monitor and edit this queue. If you can edit it at the right time (you'd need to play around with various tick and render events to figure out the best place) you can probably prevent light updates in specific area. (You'll have to do some math to convert the block position (and surrounding area) to the figure out when you want to skip. So a bit of work but I think it is possible.

Worked like a charm. For those who might read this thread in the future, here was what I used to create a potion: ItemStack thePotion = PotionUtils.addPotionToItemStack(new ItemStack(Items.POTIONITEM), PotionTypes.LONG_STRENGTH);

Doh! Got it. You said NBT and for some reason I kept thinking metadata. Makes sense.

Thanks, it definitely seems that things have changed a lot. So I'm still a bit lost on how to simply create an ItemStack containing a specific potion. ItemStack still takes metadata so I need to convert to that, I think, unless there is some other potion util method for creating item stacks. The mob effects class seems to contain the basic effect (like FIRE_RESISTANCE) but not the combined (strong and long-lasting). Sorry for asking to be spoon-fed but it I tried various combinations of mob effects and potion classes and methods and can't seem to create an item stack for strong long-lasting fire resistance...

Yes, you might be running into an issue with the side. If you simply update the rotationYaw on the client, then the very next time the server syncs the player entity it will erase your change. You probably need to change it on the server and then let it sync back to the client naturally to take effect.

I assume you're following a tutorial like this one: http://www.minecraftforge.net/wiki/How_to_make_an_advanced_configuration_file Also, I have a tutorial on config GUI here: http://www.minecraftforge.net/wiki/How_to_make_an_advanced_configuration_file Both of the above were working for 1.8. I'm just going through effort to port to 1.10 so not sure if anything changed, although probably not.

Note that the drawing part is only one part of the problem you have to solve. The other part is knowing and remembering all the block positions that you have marked. So first of all you will need to extend the players to have the ability to remember a List (or similar Java collection) of BlockPos locations that have been marked. In older versions you'd use IExtendedEntityProperties but I think now you would do this using a custom Capability. Make sure that however you store this, it gets synced between server and client (unless you don't mind if it is temporary in which case you could probably just do all the marking code on client). I'm assuming maybe you will mark the blocks with a special tool. So you will need to make that tool item and then in the onUse() method of your item, if it has been used on a block, you would need to add the BlockPos to your list. Only then can you really use the stuff you're discussing above to draw the X on the blocks. Note also it can even get more complicated if you want to handle the case where a marked block gets deleted. Because you will then need to remove the BlockPos from the List, otherwise the air will continue to be marked. So instead of a List you might want to use a Map or similar where you index with BlockPos and record the type of block that was there -- then if that block changes in that location you can remove the entry from the Map.

Is it not working at all (not turning), or is it pointing to different direction than expected? Is your code running on the server or client side? Where is the code you showed running from?

Well, I tried some similar ideas. Your idea doesn't really work because getObject() returns something like "net.minecraft.potion.Potion@919086". And even if I just used the 919086 part it wouldn't be a proper potion metadata. There is though ways to get an id for the potion type using PotionType.getID(PotionTypes.FIRE_RESISTANCE) but that isn't a full potion definition since it could be strong, could be splash, etc. I'm pretty sure that doesn't give the metadata value. But could be wrong.

Okay, so I'm continuing to port my mods from 1.8 to 1.10 and have come up with another thing I can't seem to figure out. In my mod I generate a structure that has loot in it, in this case there is a brewing stand where the inventory already contains some potions. To create the potions, previously in 1.8 and earlier it worked fine to do the following: theTileEntity.setInventorySlotContents(slot, new ItemStack(Items.POTIONITEM, 1, 8259)); // should be fire breathing However, now in 1.10 when I open the brewing stand inventory it shows pink and black default textures in the slot where I put the potion, and if I hover over it says that it is water with no effect. Looking at how potions are created in the 1.10 vanilla source, I see that it now has a registry and is doing combinations with potion type to create a unique id. Anyway what is the proper way in 1.10 to create an ItemStack containing a fire resistance potion?

You shouldn't need Step #2. (Although I don't think it will hurt anything.) >> Choosing the folder "eclipse" in the forge-directory Do you mean Import Project? In Eclipse you will need to import the project in order to see it. I usually import by right clicking in the Package Explorer pane, choosing Import, choosing Existing Project Into Workspace and then browsing to find your project.

For vanilla blocks, the sethardness is only set in the block constructors and doesn't seem to be changed during the game as far as I can see. So I think you can just use the getBlockHardness() method. If you're really concerned that something might have changed the hardness using the setHardness() method, you can just read all the values during the mod loading (like in the post-init handling method) and remember them in a Map.

Yes, that's the kind of thing you would do in each event. However, in terms of the work that Koward is referring to, keep in mind that you also have to replace all behavior that the original block might have had. So there are lots of events you might need to handle. Like for example seed items might only grow on tilled soil, so if you replaced all tilled soil with a custom tilled soil, you have to handle that interaction. In other words, in terms of events you need to handle not just the initial generation of chunks (in the chunk populate) but also things like item right-clicking, block breaking, block placing, blocks and decorations creative tabs, and so on.

I do understand how substitution is better. In fact I'm one of the first people that tried the original substitution system! Just saying that before substitution worked, I usually used events. It was possible to organize the handling of multiple blocks fairly easily with switch or if-then-else statements. But as you mentioned it was definitely a bit of work to handle all the cases for sure and more work to maintain.