Jump to content

Zetal

Members
  • Posts

    113
  • Joined

  • Last visited

Everything posted by Zetal

  1. Block blockfromlist = Block.blocksList[<BLOCKID>]; Will return the Block of a given id. Using this, you can get name/icon, etc anything else you could possibly need for your verification needs. This should solve your issue.
  2. Hey Guys, I've been developing a modpack for what must be a couple years now. I just finished getting 1.5.2 wrapped up for release, then in a couple of days got 1.6.2 up to snuff as well. However, I find myself having a great deal of difficulty getting my Minecraft to run my reobfuscated code. I'll be honest here and say that staying out of vanilla classes has never been my top priority- compatibility is completely unnecessary with this particular modpack and using all of the various workarounds to maintain that slows down progress substantially. In previous versions, I've simply resorted to directly modifying the jar file, rather than fiddling with the coremod functions (since they were not, strictly speaking, necessary for my particular goals). Now though, I get a great deal of errors I'm sure the fine people at Forge are uncomfortably familiar with now, if my searches have enlightened me at all to the popularity of this kind of thing. I'm not interested in spending hours porting my mod to 'safely' modify all of these classes only to find that there are probably endless other bugs associated with the new changes. I know that I have works, now, as I've been able to test it in Eclipse. I understand fully the current attitude now is 'Don't touch the jar!' so, with that in mind... Simply put, I would like to know what the new methods for overriding vanilla Minecraft classes are for 1.6.2, since I am not to touch the jar? I used the installer, and forge runs nicely, but I need it to use my mods. Thank you! Zetal
  3. I actually just figured it out thanks to you! I didn't catch it the first time super.drawScreen(par1, par2, par3); // draws buttons this.drawGuiContainerBackgroundLayer(par3, par1, par2);//draws background this.drawGuiContainerForegroundLayer(par1, par2); // is empty But in this segment, I only just caught on that the 'draws buttons' comment you added was to suggest that the super.drawScreen(par1, par2, par3); should go AFTER my call to draw the background. *facepalm* Anyway, I moved that down without really thinking about it, and that worked. I only afterwards caught on that that was what you were trying to tell me.
  4. I initially had the buttons created in the foreground method, but when that didn't work I checked out the code for other GUI's. Many of them had the buttons added in the 'updateScreen' method, so I tried putting it in that method instead. No matter what method I put it in, and no matter what order the buttons are rendered, the background image still appears on top of the buttons. I understand where you're coming from because in theory it seems like it should be working (so we seek out some minor unrelated issues) but regardless of those changes, it still does not render correctly. Thank you for your attempt regardless.
  5. Thank you for your efforts but unfortunately the changes are not entirely applicable. The buttons, even in my messy code, still appear and function. However- the problem is that they are BEHIND the this.drawTexturedModalRect(k + x, l + y, 0, 198, 72, 58); rectangles. For clarity, the rectangles being created are not for the purpose of button rendering, but are background images that are drawn to the screen out of necessity.
  6. Despite rendering/adding the buttons after the background image, they still insist on hiding behind it. I'm honestly just not sure why. I'm using GuiButton guibutton = new GuiButton(6, k + x, l + y, 72, 20, myStringArray[0]); guibutton.enabled = true; guibutton.displayString = myStringArray[0]; this.buttonList.add(guibutton); for buttons and this.drawTexturedModalRect(k + x, l + y, 0, 198, 72, 58); for the background images. Everything is where you would expect it, but the buttons hide behind the textured rectangles for some reason. Rect's are added in the 'background' phase- buttons are added in the 'foreground' phase. Am I missing something obvious? I've exhausted all of my options.
  7. Y'know, I think you're spot on. I didn't realize the bounding boxes handled when the models get unrendered- I also haven't finished coding the bounding boxes! Thanks!
  8. Sorry for the flashy title but I needed a laugh. So I added this new custom block renderer, blah blah nothing new here. It gets in game and it's rendered all fine and dandy, but for whatever reason it has a tendency to completely vanish near the edge of the players screen. It's fairly random, but it's like the game is saying that it's offscreen before it actually is. Very odd.
  9. You got me on the right track with that moveEntity method, so thanks! In the end, I wound up having to do: int distance = 5; float f1 = MathHelper.cos(-this.rotationYaw * 0.017453292F - (float)Math.PI); float f2 = MathHelper.sin(-this.rotationYaw * 0.017453292F - (float)Math.PI); float f3 = -MathHelper.cos(-this.rotationPitch * 0.017453292F); float f4 = MathHelper.sin(-this.rotationPitch * 0.017453292F); double i = this.posX; double j = this.posY; double k = this.posZ; this.moveEntity(distance*f2*f3, distance*f4, distance*f1*f3); So for anyone interested, this is how I had to do it. It works great!
  10. Well, like the title says, I'm trying to initiate a short range teleport (limited 3-5 blocks) in the direction that the player is facing. It would ideally be usable in any direction, including upwards, but I'm having some difficulty getting the block to teleport them to. I tried using the rayTrace method contained within EntityLiving but that only works if there is a block targeted and also doesn't work server-side so isn't really applicable.
  11. Well, right when I thought I was going to just go ahead and be insane, I found where they handle it. Unfortunately for me, they handle it by literally just not rendering the player, which doesn't work too well for 50% transparency. Oh well. Onwards, to blaze my own trail! I guess.
  12. Can anyone point me to where the EntityPlayer 'Invisibility Potion' effects are actually handled? Ie, where it makes the changes for a player to be invisible as a result of drinking the potion? I've been looking for nearly four hours now, did a global Project search for 'invisibility', 'invisible', etc and still nothing. I have absolutely no idea how this is handled, and I need to replicate something similar, so I was looking for an example on how Minecraft does it already. Apparently they keep it well hidden. Goal: 50% Player Transparency When Sneaking
  13. For those having the same issue: MathHelper.wrapAngleTo180_float(this.rotationYaw) Use that for the rotationYaw to make sense.
  14. I mean I'll get values ranging from up to 680, down to a minimum of -300 or so. And it depends entirely on when I start the game, or something. Sometimes the values make sense, other times they don't. I actually just tested with two players, so I had complete control over their facings, and both players facing the same way had 600 and -170. Just...What?
  15. So I'm trying to make a functional 'backstab' sort of mechanic, but I'm having some difficulties wrapping my head around the values that the rotationYaw for entities produces. I figured that it would be universal based on where the entity is facing, ie I compare the rotationYaw of the attacker and the defender, and if they're the same within + or - 60 degrees or so, the attacker is behind the defender. But for whatever reason even if both the attacker and defender are facing the same way, the values can be wildly different. Granted, I've only tested this on mobs so far, but it seems really weird, regardless. Can anyone help explain this, or a method to standardize the values?
  16. To be frank I just don't really know- it's only a suspicion. You should add in a lot of debug statements to make sure that every variable is what you think it is- and if it's not, that might be your issue. Try setting motionY to 0, just as a debug. See what happens, I guess? Sorry I'm not much help atm.
  17. I understand you think so, but anything the client see's is purely what the server tells it to see. If it's twitching, it could be that your rendering code told it to twitch, which I seriously doubt since I think you know what you're doing in that regard, or because it's on the rails, the server is sending asynchronous update packets with partially invalid position coordinates. The fact that it does this on HalfSlabs as well makes it seem like there is a rounding issue in where it's trying to set it's position- the entity wants to be lower, the server pushes it up, and it twitches. That's just my theory, anyway.
  18. Do you have a PacketHandler clientside? I'm not sure how to do it using Forge Hooks (I'm pretty sure there is) but for all my mods I modify NetClientHandler in the receivedEntityPacket method.
  19. Take a look at the EntityLargeFireball class as an example.
  20. If I'm correct, you need to add in read and write NBT methods, so that information about the entity can be transferred.
  21. Yea, that's what I figured. It sounds like your worldObj isn't being updated. There's your problem. =) Good luck!
  22. If I had to take a shot in the dark, I'd say that it might be because the worldObj variable isn't set in time for the onImpact to know what it is. Try adding System.out.println(worldObj); in the onImpact method.
  23. When you update the entity's position client-side for rendering, do you do any rounding?
  24. If you're sending anything between Server/Client, you need to use Packets and their appropriate Handlers. Open up NetClientHandler, NetServerHandler, and the net.minecraft.network.packets area to see what I mean.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.