The_Fireplace

Ok, so my issue is that in the Config Gui, I have a config option which I used a class extending GuiConfigEntries.SelectValueEntry as the Gui for. When I click the option to open the Gui, it looks like this: However, in the example given by FML, the Gui adjusted so the title didn't overlap with the options, like this: Now, for my code: Now, does anyone know how I can fix this? Or did I do it correctly, and this is an FML bug?

Yes, I know the first one is easier, but the goal here is to download the player's skin while they are connected to the internet(I have that part working, so I didn't show it there with my code), and apply it to the player when the player starts the game and they are offline. So yeah, it has to be dynamic.

First of all, redistributing other mods' APIs within your own mod is a terrible idea. If you are trying to make your mod integrate with the other mods without requiring them, using the APIs is fine, but don't directly access them, and don't redistribute them within your mod.

Hey guys, I am trying to make the player's skin change, on the client side only, in single player. I have tried 2 methods, the first of which does nothing, and the second has an error in the console to go with it not working. Yes, I have the skin named correctly at the path I pointed the code to. First method: Trying to replace RenderPlayer with a custom one during RenderPlayerEvent.Pre Method 2: Replace the skin during ClientConnectedToServerEvent I apologize if how I am going about this is completely wrong or I am making a simple mistake; it is late and I have only been working on this for an hour or two. Any help is appreciated.

Use PlayerInteractEvent, check if the player is right clicking a block while holding redstone, and if they are, cancel the event.

Use OreDictionary.OreRegisterEvent and cancel the event if the item is redstone and the name being registered to it is dustRedstone.

Ok, tried that, it is not cancelable. EDIT: It appears that only Post is not cancelable, I will mess with it some more. I want an event to be called there so I can easily fill in item names. If I do it this way, it uses 41 less lines in the lang files(at the moment, it could save even more later) than the vanilla method. I already did this for the items' tooltips(see spoiler below), now I just need to do it for the name that shows up when changing items. As for the class minecraftforge.client.gui.GuiInGameForge, I was unable to find it.

It looks like RenderGameOverlayEvent might have what I need, if it is, how do I use it to accomplish my goal?

As it says in the title, I want to know if there is an event that I can use to change the text that appears above the hotbar when you switch to an item. EDIT: Solution: No, there isn't, but you can override Item#getItemStackDisplayName(ItemStack) to add the text you want there.

Hey guys, I am trying to get a list of OreDictionary names for an item and render it in the item's tooltip. I have the following code so far: When moused over, anything with 1 oredictionary name says logWood, anything with 2 says logWood and plankWood, and I haven't tested anything with 3 or more, as nothing in vanilla Minecraft has that many. Does anyone know how I can fix this? Any help is appreciated. EDIT: Fixed it. Here is the fixed code if anyone wants to see it:

The first part, I figured out in the time I was waiting for a response. The second part, I didn't notice, I put the byte in the wrong spot. Thanks. Now, for anyone else trying to do this, here is my completed, working code: byte i = 0; @SideOnly(Side.CLIENT) @SubscribeEvent public void onRenderTick(RenderTickEvent t){ Minecraft mc = Minecraft.getMinecraft(); if(mc.inGameHasFocus){ if(mc.thePlayer.getHeldItem() != null) if(mc.thePlayer.getHeldItem().getItem() == Item.getItemFromBlock(UnLogicII.coal_gun) || mc.thePlayer.getHeldItem().getItem() == Item.getItemFromBlock(UnLogicII.smart_coal_gun)){ mc.ingameGUI.drawString(Minecraft.getMinecraft().fontRendererObj, StatCollector.translateToLocal("info.coal_type")+": "+StatCollector.translateToLocal(EnumAmmo.getItem(ExtendedPlayer.get(Minecraft.getMinecraft().thePlayer).getAmmoType()).getUnlocalizedName()+".name"), 1, 1, 16777215); } } if(mc.thePlayer != null) if(mc.thePlayer.getEquipmentInSlot(4) != null) if(mc.thePlayer.getEquipmentInSlot(4).getItem() == UnLogicII.crystal_eye_headband){ if(i < 40){ i++; }else{ World world = mc.thePlayer.worldObj; AxisAlignedBB aabb = mc.thePlayer.getEntityBoundingBox().expand(8, 8, ; List entities = world.getEntitiesWithinAABBExcludingEntity(mc.thePlayer, aabb); for(int j=0;j<entities.size();j++){ Random rand = new Random(); Entity entity = (Entity)entities.get(j); mc.theWorld.spawnParticle(EnumParticleTypes.SPELL_MOB, entity.posX, entity.posY, entity.posZ, (rand.nextDouble() - 0.5D) * (double)entity.width, rand.nextDouble() * (double)entity.height, (rand.nextDouble() - 0.5D) * (double)entity.width, null); } i = 0; } } }

I want to spawn particles around every living entity within a radius around the player, only if they have a certain headgear equipped. That being said, I don't want them visible to other players not wearing the headgear. I think the simplest way to do this would be to spawn them on the client-side only. Now to the problem. I tried coding this, and it was a failure. The player couldn't see the particles. Now for my code: In my FMLEvents.class, which is registered to the FML Event bus: Am I doing this completely wrong, or have I just messed up a small portion of it? Any help is appreciated.

Thanks, guys.

I have followed coolAlias's packet tutorial, and I set it up so a packet is sent to the server when a key is pressed. When the key was pressed, I encountered this crash: And my code: The Packet Dispatcher: https://bitbucket.org/The_Fireplace/unlogic-ii/src/fed9cdf24bd839485aac7f9ce3cee887bb761449/src/main/java/the_fireplace/unlogicii/network/PacketDispatcher.java?at=master Any other code you need to see is there in the repository. Let me know if you have any other questions. Any help is very much appreciated.

All that did was cause the gui to center on 0,0; at least when it is in the constructor, it centers correctly when the screen is small.

Actually, after posting that, I went ahead and searched for a tutorial, and found the tutorials by you and diesieben. I read diesieben's first, and followed along, though I did encounter the annoyances which I later learned that your tutorial addressed. Also, according to what you just said, I set up the flow wrong, so I will have to go back and fix that when I follow your tutorial. If it isn't too much to ask, since you said you have made improvements to it, and just haven't updated it, can you update your tutorial?

It seems that when the player changes the ammo type they are on, it doesn't send that information to the server. That explains why the items disappear on the client side only, because the server is trying to use the default, but the client thinks they are being consumed, and why, if you have coal and the ammo you are trying to use, coal gets spawned instead of the ammo type you are on, and when you relog, the coal is missing from that. Big moment of realization I just had there. The explaination fits perfectly. Now for how to fix it. I am guessing this will require me to send a packet to the server when the player changes ammo type. Does anyone have a link to a 1.8 tutorial on how to do this, or want to explain it?

Isn't the type of ammo the player is using based on what they have in their inventory? Or are they selecting it from somewhere? If the latter, that would make sense to store it like you have. I had a look at your main class' registerEntity method, and there are a few things wrong with it: 1. Don't register your entity with a global entity ID - that is for vanilla only 2. If you don't need a spawn egg, there is even more reason not to use global entity ID, as that is its only benefit (well, and the /summon command) 3. Tracking update frequency and range values should be set based on the type of entity you are registering, not as a blanket value for all of them. Furthermore, NO vanilla entity uses an update frequency of 1, and you should not either. Always choose values closest to the most closely related vanilla entity you can find. You can find tracking values in EntityTracker, or online https://docs.google.com/spreadsheets/d/1nqqieNkw9r4NfI-WypIvgeuZnYB4_QU7BcDXptgzqnM/pub?single=true&gid=0&output=htmlhere, though I don't know when it was last updated. Generally, projectiles (except for arrows, for some reason) use (64, 10) and mobs / animals use (80, 3). Thanks for the information about registering entities, I will fix that. And the ammo is based on what the player has it set to, if they haven't set it yet, it is regular coal, they can press R at any time to change to the next type. The order is Coal, Charged Coal, Destabilized Coal, Restabilized Coal, Refined Coal, and then it goes back to Coal whewhen pressed again. The smart coal gun, when fired, automatically detects if you don't have any coal of the type of ammo you are on and, if you have any valid coal types in the inventory, it switches the player to the next coal type until it can fire. With the regular coal gun, the player has to select it, there is no automatic switching.

I will look again, I am fairly certain the entity is registered properly. As for the fact that it is outside the !world.isRemote, that just means it would be removed on both the server and client, and not only on the server, leaving behind ghost items in the inventory. As for the rendering, I know for sure that that is not the issue. There is no reason to be sorry, Tbh, I love it when people take the time to explain a better way of doing things than what I have. I will look in to what you have said and see about a redesign. The reason it is stored with the extendedplayer is so it stays consistant. This way, a player can disconnect and join again later, with the coal type they are on staying the same.

Once you have that done, to push to the server, you first need to commit your changes, then, push them to the server. In source tree, when you push to the server for the first time, you will have to check the box next to the word master.

For reading old schematics, Block#getBlockById(int i) should work for reading them as blocks. In 1.7.10, I believe blocks still have metadata, so you should be good there, unless you are jumping straight from 1.6 to 1.8, in which case Block#getStateFromMeta will also be helpful.

Ok, I have a Gui which renders fine when the window is small, but when the window is maximized/put in to fullscreen, it renders in the wrong spot. My setup is: the UtilityGui renders, then at the end of its render code, tells the overlay gui to render on top of it. Then, the foreground(just 1 item icon in the screenshots) renders over that. The foreground and UtilityGui render correctly, it is the overlay gui(GuiFireplaceCoreTab) that is in the wrong spot. Here is my code: GuiFireplaceCoreTab: https://bitbucket.org/The_Fireplace/fireplace-core/src/ae9361509a1bd65c5a09b5cdfaa1b7766a33b844/src/main/java/the_fireplace/fireplacecore/gui/GuiFireplaceCoreTab.java?at=master GuiModTab(superclass of GuiFireplaceCoreTab): https://bitbucket.org/The_Fireplace/fireplace-core/src/ae9361509a1bd65c5a09b5cdfaa1b7766a33b844/src/main/java/the_fireplace/fireplacecore/gui/GuiModTab.java?at=master UtilityGui(link to the line it makes GuiFireplaceCoreTab render): https://bitbucket.org/The_Fireplace/fireplace-core/src/ae9361509a1bd65c5a09b5cdfaa1b7766a33b844/src/main/java/the_fireplace/fireplacecore/gui/UtilityGui.java?at=master#cl-216

The issue is not that they are spawning at 0,0,0, it is that they are not spawning at all.

First, create the repository. Then, clone it, I recommend using Source Tree. Then, set up a new forge workspace in the folder you cloned the repository to. Next, you should probably create a .gitignore file, similar to https://bitbucket.org/The_Fireplace/fireplace-core/src/56815ff806fab68257cbcb79cd91ee3b348aa325/.gitignore?at=master . Next, move the contents of the src folder in your old workspace to this new one.

I have 2 items(Guns) that use ammo. The ammo is saved with ExtendedPlayer. When the guns are fired now, the ammo usually either a.) doesn't spawn or b.)spawns the wrong type of ammo. The Item of the ammo is consumed as it should be, then, when the player leaves the world and rejoins, it is there again, so it seems that the onItemRightClick is only being called on the client side for these items. Sorry if this explanation of the issue is vague. Anyways, here is the code: The 2 guns: https://bitbucket.org/The_Fireplace/unlogic-ii/src/2763b9479b2c4b875fe506e29ea2977ff68f2880/src/main/java/the_fireplace/unlogicii/items/ItemBlockCoalGun.java?at=master https://bitbucket.org/The_Fireplace/unlogic-ii/src/2763b9479b2c4b875fe506e29ea2977ff68f2880/src/main/java/the_fireplace/unlogicii/items/ItemBlockSmartCoalGun.java?at=master The ammo files: https://bitbucket.org/The_Fireplace/unlogic-ii/src/2763b9479b2c4b875fe506e29ea2977ff68f2880/src/main/java/the_fireplace/unlogicii/entity/coal/?at=master And a download of the mod, so you can try it out yourself without having to fork and clone the repository, then set up the workspace. The items are Coal Gun and Smart Coal Gun, and they fire the types of coal in the UnLogic II creative tab, and vanilla coal. http://ge.tt/api/1/files/5OCIQN32/35/blob?download