Jump to content

Draco18s

Members
  • Posts

    16559
  • Joined

  • Last visited

  • Days Won

    156

Everything posted by Draco18s

  1. Don't bother trying to render an actual block of fire. Just grab its texture and render it onto some quads yourself. The main reason to do this is because Fire renders differently based on the surrounding blocks.
  2. You mean quotes. ( is a parenthesis. http://en.wikipedia.org/wiki/Parenthesis#Parentheses_.28_.29
  3. I figured it out yesterday, pure guess. The rendered YAW is based on entity.rotationYawHead.
  4. speedModifier = 60D !? You realize that values greater than about 2 will cause the mob to effectively teleport, right?
  5. There's also Item#itemInteractionForEntity
  6. You still haven't called Items.registerRecipes() anywhere.
  7. You are trying to run client-side code on the server. The server does not contain the class EntityClientPlayerMP because that is a @SideOnly(Side.CLIENT) class.
  8. The crash is not in your config: 2013-11-09 15:32:16 [sEVERE] [Minecraft-Server] Encountered an unexpected exception OutOfMemoryError java.lang.OutOfMemoryError: Java heap space at net.minecraft.util.AABBPool.getAABB(AABBPool.java:50)
  9. Look at NBTTagCompoundList (IIRC the class name correctly) Essentially it's a list of tags that you can add to a tag, then each one of the tags in the list can hold the mob name and the count.
  10. Not to sound completely full of myself, but you did what I told you to do, FINALLY.
  11. That isn't actually printing the value of redstonePower nor the code that increments the variable.
  12. Of course... Doubtful, the folks monitoring the Mojang bug tracker are refusing to recognize it as a legitimate bug.
  13. Code is a bit messy, but essentially I'm waiting for an event, then calling readyTickHandler(). It waits a specified number of ticks (renderDelay) before performing the render. This is to allow time for the world to load. However, due to the delay, I do not want to render from the player's location after the delay, but rather from their original location and orientation. Here's the problem: Even though I'm setting the temporary entity's orientation, it's being ignored when the render happens, it's treated as always 0, regardless of its actual value. If I use the actual player as the temporary agent, then it gets rendered with the correct orientation values (that is, where the player is looking at the time). What do I need to change in order for the temporary entity to make it render correctly? public void readyTickHandler(World w, EntityPlayer pl) { world = w; p = new EntityRenderNode(world); world.spawnEntityInWorld(p); p.posX = pl.posX; p.posY = pl.posY; p.posZ = pl.posZ; p.rotationPitch = 0; p.rotationYaw = pl.rotationYaw; System.out.println("Yaw: " + pl.rotationYaw); renderDelay = 20*30; } @Override public void tickEnd(EnumSet<TickType> type, Object... tickData) { if(renderDelay > 0) { renderDelay--; } if(renderDelay == 0) { renderDelay = -1; System.out.println("Render Yaw: " + p.rotationYaw); //this is the function that handles the rendering. int[] data = renderWorldToTexture(p, 0.01F); //now we save the data. ByteArrayOutputStream bt = new ByteArrayOutputStream(); DataOutputStream out = new DataOutputStream(bt); try { //omitted for irrelevancy. } catch (IOException ex) { } //remove the temporary entity p.attackEntityFrom(DamageSource.outOfWorld, 100); } } private final int[] renderWorldToTexture(EntityLivingBase player, float renderTime) { GameSettings settings = mc.gameSettings; // dont want to access these fields every time EntityRenderer entityRenderer = mc.entityRenderer; RenderGlobal renderGlobalBackup = mc.renderGlobal; EntityLivingBase viewportBackup = mc.renderViewEntity; int heightBackup = mc.displayHeight; int widthBackup = mc.displayWidth; int thirdPersonBackup = settings.thirdPersonView; boolean hideGuiBackup = settings.hideGUI; int particleBackup = mc.gameSettings.particleSetting; mc.gameSettings.particleSetting = 2; int width = 128; int height = 128; mc.renderGlobal = mc.renderGlobal; mc.renderViewEntity = player; mc.displayHeight = height; mc.displayWidth = width; settings.thirdPersonView = 0; settings.hideGUI = true; int fps = EntityRenderer.performanceToFps(mc.gameSettings.limitFramerate); if (settings.limitFramerate == 0) { entityRenderer.renderWorld(renderTime, 0L); } else { entityRenderer.renderWorld(renderTime, (1000000000 / fps)); } int k = width * height; int[] dataarray = new int[k]; IntBuffer databuffer = BufferUtils.createIntBuffer(k); GL11.glPixelStorei(GL11.GL_PACK_ALIGNMENT, 1); GL11.glPixelStorei(GL11.GL_UNPACK_ALIGNMENT, 1); databuffer.clear(); GL11.glReadPixels(0, 0, width, height, GL12.GL_BGRA, GL12.GL_UNSIGNED_INT_8_8_8_8_REV, databuffer); databuffer.get(dataarray); reconfigureArray(dataarray, width, height); settings.thirdPersonView = thirdPersonBackup; settings.hideGUI = hideGuiBackup; mc.displayHeight = heightBackup; mc.displayWidth = widthBackup; mc.renderGlobal = renderGlobalBackup; mc.renderViewEntity = viewportBackup; mc.gameSettings.particleSetting = particleBackup; return dataarray; } //I actually have no idea what purpose this function serves, but Vanilla uses it with screenshots. private void reconfigureArray(int[] dataarray, int width, int height) { int[] aint1 = new int[width]; int k = height / 2; for (int l = 0; l < k; ++l) { System.arraycopy(dataarray, l * width, aint1, 0, width); System.arraycopy(dataarray, (height - 1 - l) * width, dataarray, l * width, width); System.arraycopy(aint1, 0, dataarray, (height - 1 - l) * width, width); } }
  14. It's what I've heard, that they were depreciated in favor of move/strafe.
  15. motionX/Y/Z is no longer used. Use moveForward and moveStrafing
  16. I'll take a look. I do have my system fully functional using 4 packets right now (the first one locks in data editing until the fourth one from a matching source comes through) and other than some positioning data getting corrupted slightly between "saving the result" and "loading it from disc to send back to the client" things are working. (As in, the destination is getting offset by 1 block, preventing the server from locating the existing render)
  17. Leave the main class alone! Move the TEXTURES.
  18. PACKET SIZE is the limiting factor, not what KIND of packet.
  19. Yup. I'm doing a plugin. Working on increasing my texture size. 64x64 is just NOT enough. But that means breaking the data into smaller packets. >..x
  20. If you don't know, then leave it alone. It has to be there for your mod to load correctly, but if that's all you do with it, then that's fine.
  21. Nope, just leave it like that. You can reference it if you want to, but you don't need to set it or do anything else.
  22. That's how Forge / ModLoader knows how to find your mod and access it.
  23. Earlier test: http://s18.postimg.org/5leo4j8ih/2013_11_08_13_35_01.png[/img] Render occurred before the client had block and weather data, so all it managed to screenshot was the dimension's two suns. But it totally worked.
  24. But your assets shouldn't be inside your main package at all. Should be: src/stormcassidy/morecolors/MainModClass.java src/assets/morecolors/textures/[etc]
×
×
  • Create New...

Important Information

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