Jump to content

FlameAtronach93

Members
  • Posts

    76
  • Joined

  • Last visited

Everything posted by FlameAtronach93

  1. Lol. I guess you take the term Frequently Asked Questions very seriously. Who needs answers anyway? Made my morning.
  2. All that is irrelevant. Show us where you assign a value to / instantiate oreCrystalOre.
  3. Well that's interesting. Thank you. I found MinecraftServer.getServer().isSinglePlayer() which obviously didn't work as well. Good to know there are two of such methods... it's working now.
  4. Check your pre-init event handler, line 115. You're trying to register null as block. Minecraft doesn't like that. Eclipse doesn't know the method does not allow null objects as parameters. Of course it wouldn't show you any errors. It only highlights syntax errors and unreachable code (like while(false){...}), but it can't help flawed logic. That's up to you as the programmer. Darn it. Too slow.
  5. Hello, I have code I do not wish to execute on client side when connected to a remote server. I tried checking Minecraft.getServer() which is null until a singleplayer game has been started at least once. Beyond that point it will always be the integrated server instance - so this is not a viable solution. Also testing !Minecraft.getServer().isDedicatedServer() won't work since the returned server instance is still the IntegratedServer. Comparing the world name of Minecraft.getMinecraft().theWorld against "MpServer" doesn't help either since that world will always be the MpServer world. The same obviously holds true for Minecraft.getMinecraft().thePlayer.worldObj. I'm running out of ideas... I've read other forum posts, including one suggesting to check the server's player list size, but that depended on MinecraftServer.getServer() which we've covered above... may have worked in the past, but not here. So, how can one reliably detect on client side whether the player is connected to a dedicated server? Cheers and thank you in advance for any assistance!
  6. I thought so at first as well. Then I dug deeper and found that it has indeed been moved. I'm not sure what they did, but apparently it's associated with Resonant Engine.
  7. I dug around a little bit in the documentation of said 3rd party library and may have found a solution which allows me to dump the executor service completely... No, don't do what? You haven't addressed a single of my previous statements - did you even read any of them? I have done my research on the topic long before you created that account. Until I found above said potential solution there was no way to temporarily suspend the work of a third party library of which I have little control. Nonetheless I'd still like to know what I'm doing wrong with the thread pool.
  8. Hello again, thank you for your input. The weird part about the background tasks is that actually there is not a single constraint. The tasks are performed in due time, in fact the worker threads of the thread pool seem to be blocking according to the tool I've tried. (I forgot its name, also since I'm currently sitting in a lecture I currently cannot provide screenshots.) The tasks are prepared before the game starts. The necessary information is kept in RAM. The profiler tool I've used shows the heap is at the utter most 50% in use, CPU usage is around 25%. Screenshots to follow, maybe this night, otherwise tomorrow. Once again, if I run the tasks in the main thread everything is fine. Furthermore I simply use the threads/futures to allow interrupting the calculation in case it takes too long. In fact, I expect the result of the computation while blocking the main thread. Quite the irony. I reckon I am missing something... I suppose there is something to learn here for me. Cheers!
  9. The ITickHandler interface has been remodelled as an FML event. See TickEvent.
  10. Hello there! I've been working a bit on my mod which uses a number of threads "hosted" in a cached thread pool to do things in the background. However it seems I've introduced quite a lag to the server and can't quite find out why... I've tried adding profiler sections to crucial parts of my code but still haven't found any critical and unacceptable executions. So I am suspecting the cached thread pool to somehow be the cause of this misfortune especially since I've noticed the lag persists as long as the worker threads (2 so far) are alive, but also as long as the player is standing still (animals in the background suddenly move fluently, e.g.). I'm at doubt where the exact issue lies and thought maybe somebody here has an idea... Also I'd like to ask what the desired average tick should be? When the worker threads die (i.e. no player is on the server for a while) the average tick is around 1ms, otherwise without worker threads and the payload loaded directly onto the main thread the average tick is 15ms and with worker threads it's an average of 55ms - definitely unacceptable. Cheers and thanks in advance for any assistance! Edit: After some digging around I found the potential culprit. It had little to nothing to do with the multithreading but with particular data being permanently (until program termination) stored. I don't know what is causing this, possibly the implementation of the third party class I'm extending. Nonetheless I am working on a usable workaround. Thus I consider this thread solved.
  11. Thank God! Thanks to you and your tool I finally found the error. It indeed was the lack of Alpha Testing. Now that I set the flag OpenGL renders the intended background of the hotbar / inventory. This issue made me mad the last 4 days... Once again my issue could be solved within 3 posts, counting mine as well. Cheers!
  12. Every once in a while I reappear with an issue I can't solve which then is solved within merely 3 posts. I hope this is one of those. Anyway, my issue is that despite using Vanilla code under some circumstances Minecraft will render a "background" for my custom item. The background appears to be an approximately 10 times larger version of the rendered item. The conditions for this misbehavior are simple: if the first non-empty inventory slot is a non-block item, the background will be rendered. If, for example, I "pick up" the item, i.e. click it once in order to move it to a different slot, the background quickly disappears. Here's some relevant code. @Override public void render( ItemRenderType type, ItemStack itemStack, Object... data ) { IIcon icon = MiscHelper.getItemIcon("stick"); // Just trust me on this one. It gets the IIcon correctly as you can see in the screenshot... // Inventory coordinates go from 0d to 16d in both x and y coordinates. Plus we don't need to render the sides, just the image. if( type == ItemRenderType.INVENTORY ) { renderItemInInventory(Tessellator.instance, icon); } // Everything else goes from 0d to 1d. else { renderItemIn2D(Tessellator.instance, icon, 0.0625d); } } protected void renderItemInInventory( Tessellator tess, IIcon icon ) { // This call increases the scale for the first two methods here. // GL11.glScalef(16f, 16f, 16f); // Doesn't fucking matter if I use this... // renderItemIn2D(tess, icon.getMinU(), icon.getMinV(), icon.getMaxU(), icon.getMaxV(), icon.getIconWidth(), icon.getIconHeight(), 0.0625d); // Or this... // ItemRenderer.renderItemIn2D(tess, icon.getMinU(), icon.getMinV(), icon.getMaxU(), icon.getMaxV(), icon.getIconWidth(), icon.getIconHeight(), (float)0.0625f); // Or even my own algorithm to render the item in the inventory. renderItemInInventory(tess, icon.getMinU(), icon.getMinV(), icon.getMaxU(), icon.getMaxV()); // They all end up with an unwanted background under certain circumstances. } protected void renderItemInInventory( Tessellator tess, double u1, double v1, double u2, double v2 ) { tess.startDrawingQuads(); if( baseColor != -1 ) tess.setColorOpaque_I(baseColor); tess.addVertexWithUV( 0d, 0d, 0d, u1, v1); tess.addVertexWithUV( 0d, 16d, 0d, u1, v2); tess.addVertexWithUV(16d, 16d, 0d, u2, v2); tess.addVertexWithUV(16d, 0d, 0d, u2, v1); tess.draw(); } My code should differ in no way when only calling ItemRenderer.renderItemIn2D since that is ultimately what happens in the Vanilla ItemRenderer: Does anybody have an idea why this happens..? I could probably work this out without a custom ItemRenderer. After digging around somewhat in the code I found out that you can return a color from the ItemStack. Yet I really want to find out how and why this happens. Sincerely ~ Screenshot of the bug:
  13. Moving tile entities? Well that sounds interesting. Anyway, are you trying to inject that method into an existing GUI class or did you create your own one? I don't exactly understand where your problem is... Is it maybe that you're trying to call drawTexturedModalRect from outside a Thread with an OpenGL context? That would cause problems indeed. Well, the only solution to that would be to call the method from within such a thread. However there can only be one such thread, multiple threads associated with the same context would violate OpenGL rules... as would multiple contexts bound to the same render target. I still can't exactly imagine what you mean with "variables constantly change" since ultimately that's the nature of variables... Otherwise they'd be constants. Please clarify yourself.
  14. Too little information. What have you already tried? Are you using a Coremod and a Class Adapter? That's what I'd go with. If it's just a variable you need to adjust, I'd try using reflection instead. I avoid core mods as far as possible... Makes your coding life slightly easier. Also, do you see any error in the Launcher's output in a regular, non-dev environment? Last but not least, you might want to post some code...
  15. I just happened to have verified that loading the World class this early indeed leads to issues. I noticed this exception which only occurred using this detection: What a coincidence that that class is a World event... Thank you a lot, removing this faulty detection resolved the error. I know about the runtime deobfuscation. I actually had chosen that class as a dummy... I was going to replace it with a more suiting class later, but I'm going to stick to your proposal.
  16. Thanks a lot for the deeper insight. I had figured it to happen like that. As I said, I temporarily removed the ASM transformers and everything else... I previously had cpw and net.minecraftforge packages listed in transformer exclusions, so that can't be the reason. A new project with a rewritten Coremod and copied transformers seems to work. I suspect it to be some issue with the project setup... I can upload all the code I have including the eclipse project to GitHub. Since I cannot quite tell where the error lies, this should be the best way. Although the "rewritten" project does work now, I'd still like to know where the error originates in so I know what to avoid in the future. Here's the repo.
  17. While that may explain when cpw's Player is used, it still doesn't help me at all. The exception occurs even in the "purest" form of my mod, i.e. when everything is commented out. Moreover, the only thing I'm currently doing in the mod is make changes to several piston related classes, such as TileEntityPiston and BlockPistonBase. It has nothing to do with any packets yet. That's why I'm completely clueless as to why this exception even arises... I'm going to try to rewrite the code. If I'm lucky, the error just simply disappears... Thanks anyway.
  18. Hello there. My coremod's generating a fairly unrelated exception that I cannot find the cause of: I am not modifying either of the two classes, but several piston related classes. Without the mod, everything runs just fine. On a side note, I don't even exactly understand how it is possible to cast net.minecraft.client.entity.EntityClientPlayerMP to cpw.mods.fml.common.network.Player... The exception arises when attempting to load an existing or create a new world. I am able to load up the main menu. I recall that I had this error before, but I do not remember how I fixed it. What could be the cause of this? Since I have no idea where the error originates in, I don't want to overflow this post with loads of source code. If you need any more information or code, feel free to ask. Any leads are appreciated. Sincerely Update: Even with class transforming disabled (getASMTransformerClass() returning an empty array) I still get this error... On the strange side, another coremod I had developed earlier still works without any issues. The funny thing being that that coremod served as the basis of the current one, most files having been copied over, slightly changed and renamed. Following is the crash log: Solution: Due to runtime deobfuscation, do not attempt to load a Minecraft class ahead of time, not even for detecting whether you're in a deobfuscated development environment. Instead, use Launch.blackboard.get("fml.deobfuscatedEnvironment") . Source:
  19. When the user right-clicks with the staff, set a flag to false. Then start a Timer which sets that flag back to true. The user may only use the staff when the flag is set to true. Additionally I'd render some kind of update, for example the staff is slightly illuminated when usable.
  20. You'll need to create a world generator and register it using GameRegistry.registerWorldGenerator(). Your custom sapling would then use that world generator in its overridden growTree method to replace the sapling with a tree. I suggest looking into the following classes: net.minecraft.item.ItemDye net.minecraft.block.BlockSapling net.minecraft.world.gen.feature.WorldGenTrees Relevant methods regarding the sapling are markOrGrowMarked() and growTree(). I suppose things changed with 1.7.x, and since I have not updated yet, I cannot give further leads. However, I guess it's still not as easy as simply creating a new BlockSapling and overriding those two methods. You'll have to examine the applyBonemeal() method of the ItemDye class to find the best way...
  21. Sounds like the most reasonable solution. You could simply derive the furnace and change its mechanics, or replace it in its entirety (maybe not such a good idea...).
  22. I have to say I never used ForgeDirection.VALID_DIRECTIONS. Instead I used ForgeDirection.values() and skipped over ForgeDirection.UNKNOWN... which has all offsets set to 0 = this block. Thanks for that though. Back to your problem. Since your loop does not feature any exit conditions, there are only two possible answers to why your loop could possibly end before all 6 "rounds" have been completed. To confirm, do some more logging... but unconditional, just to refresh your basic counting skills. One of these reasons ist that Forge.VALID_DIRECTIONS doesn't contain all valid directions in the first place, which would be total non-sense and thus the idea is trashed. The second answer would be that you have an uncaught exception causing your method to terminate. But I guess you'd notice that one, unless you have somewhere an ingeniusly placed try {} catch (Exception ex) {} wrapper in your base code... Given all this, we'd need more information on what happens internally. Do some real debugging... By the way, when we say "Debugging", we're not talking about printing messages to the console. Of course that too is a technique in debugging, but is more useful to quickly check where the malfunctioning occurs: before or after the logged message. At least that's how I use it when pb]actively[/b] debugging. Instead Eclipse grants you the ability to walk through your code step by step or - even better - set breakpoints at which you want Minecraft to interrupt in order to go through only specific parts of your code. Whilst debugging Eclipse shows you the values of variables and allows you to evaluate code under the current conditions (i.e. return value of methods using current values of parameters). It's a highly useful feature and just invaluable to solving such problems.
  23. I have a lead for you. Something like this could help you out. This is completely untested and only based upon what I've found in the source code... you may have to adapt some changes. function isOwnerOnline( String owner ) { // playerEntityList is a generic list containing EntityPlayerMP. This cast is just for convenience... List<EntityPlayerMP> players = (List<EntityPlayerMP)MinecraftServer.getServer().getConfigurationManager().playerEntityList; for( Iterator<EntityPlayerMP> it = players.iterator(); it.hasNext(); ) { EntityPlayerMP curr = it.next(); if( curr.username == owner ) { return true; } } return false; }
  24. It's going to junk up you're smelting recipes, but I don't see any other way. You could try `FurnaceRecipes.addSmelting(int itemID, int metadata, ItemStack itemstack, float experience)` as the damage of the pickaxe is pretty much equivalent to its metadata. However, since, for example the diamond pickaxe, has a heck of a lot of durability, you may end up having thousands of recipes... But maybe there's a better way that somebody else knows of.
  25. I believe not necessarily, but it sure is the safest way: in case the block and/or item IDs change you won't have to change your code, too. `ItemStack`, which is used in the `CraftingManager.add(Shapeless)Recipe()` methods, internally uses references to the blocks and items only to retrieve the corresponding item ID by itself. Ultimately, if you know the IDs of those blocks and items you want to use in your recipe, you could resign using the actual references and directly pass the ItemStacks to your recipe. But as I said, it does imply having to regularly check whether its still compatible with newer versions of the mod you're depending on...
×
×
  • Create New...

Important Information

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