Purplicious_Cow

No, I know my own ModId, ha ha I'm talking about getting the ModId from another mod's item. The code above provides that in 1.7.10. I'm looking for a way to do it in 1.10.2

In 1.710, I had this nifty piece of code that could pull the ModId from an item. In 1.10.2, GameRegistry has changed, and with it, it seems, is the path to get ModId. Can anyone point me in the correct direction? I use the modid for various purposes. 1.7.10 code that worked: public static String getModId(Item item) { GameRegistry.UniqueIdentifier id = GameRegistry.findUniqueIdentifierFor(item); return id == null || id.modId.equals("") ? "minecraft" : id.modId; } public static String getModId(ItemStack key) { return getModId(key.getItem()); }

More investigation into this. The error messages/adjust player location are actually NOT related to flight, just moving quickly into new chunks while they are loading. It can be caused by even normal movement as well (non-enhanced). You just see it more often if you enhance speed. I don't understand the current solution Mojang put in place. Teleporting the player backwards is very strange.

In 1.9, I am getting the dreaded Moved Too Quickly error (on Server only) for an Item that provides custom fast flight, or speed boost. In addition to the error, it also moves the player to the expected position, quite annoying. What I've read is that this is Minecraft's anti-cheat system, which is great, but I feel like you should be able to mod around it. Here's the error: [00:40:06] [server thread/WARN] [net.minecraft.network.NetHandlerPlayServer]: Purplicious_Cow moved too quickly! 5.442742797143968,5.636337631967919,-8.100770737214162 [00:40:08] [server thread/WARN] [net.minecraft.network.NetHandlerPlayServer]: Purplicious_Cow moved too quickly! 5.38715140427751,4.072398597727329,-8.015775277311803 Here's my code for allowing flight, simple enough: if (itemchk != null && itemchk.getItem() == InventoryPets.petCloud && itemchk.getItemDamage() < 3) { entityplayer.capabilities.allowFlying = true; } I imagine there's away around this, but I can't seem to find a solution. I reviewed how Elytra is handled, but it appears to be an item-specific exception. I've also set AllowFlight = true on server, but that only allows flight at normal speeds. I've noticed that custom servers (e.g. Spigot, Kcauldron) have allowances to remove/adjust movement check, but I did not see one for Forge Server. Any advice appreciated, or just a simple point in the right direction. PC EDIT: Just saw this listed as a bug @ Mojang: https://bugs.mojang.com/browse/MC-90062. Still should be a way around it.

Worked like a charm. Thanks, as always, diesieben07.

Old code, used in 1.8.9 (does not work in 1.9) if(!worldObj.isRemote && (itemstack.getItemDamage() < 3 || entityplayer.capabilities.isCreativeMode)) { worldObj.playSound(entityplayer, entityplayer.posX, entityplayer.posY, entityplayer.posZ, ModSoundEvents.black_hole, SoundCategory.NEUTRAL, 1.0F, 1.0F); } New code, used in 1.9 (only way I can get the sound to play is to call it from client side as well) if((itemstack.getItemDamage() < 3 || entityplayer.capabilities.isCreativeMode)) { worldObj.playSound(entityplayer, entityplayer.posX, entityplayer.posY, entityplayer.posZ, ModSoundEvents.black_hole, SoundCategory.NEUTRAL, 1.0F, 1.0F); } The same applies to vanilla sounds if I try to use playSound.

Old code, used in 1.8.9 (does not work in 1.9) if(!worldObj.isRemote && (itemstack.getItemDamage() < 3 || entityplayer.capabilities.isCreativeMode)) { worldObj.playSound(entityplayer, entityplayer.posX, entityplayer.posY, entityplayer.posZ, ModSoundEvents.black_hole, SoundCategory.NEUTRAL, 1.0F, 1.0F); } New code, used in 1.9 (only way I can get the sound to play is to call it from client side as well) if((itemstack.getItemDamage() < 3 || entityplayer.capabilities.isCreativeMode)) { worldObj.playSound(entityplayer, entityplayer.posX, entityplayer.posY, entityplayer.posZ, ModSoundEvents.black_hole, SoundCategory.NEUTRAL, 1.0F, 1.0F); } The same applies to vanilla sounds if I try to use playSound.

As mentioned, sounds worked, but only if invoked client side... I'll try updating and see if that does anything, for the record, using 1.9-12.16.0.1865. It's an earlier version, from 15 April. Will report back. Edit: Updated to 1.9-12.16.1.1934, but it didn't change the result. Still need to call from the non-server side to get sound to work.

As mentioned, sounds worked, but only if invoked client side... I'll try updating and see if that does anything, for the record, using 1.9-12.16.0.1865. It's an earlier version, from 15 April. Will report back. Edit: Updated to 1.9-12.16.1.1934, but it didn't change the result. Still need to call from the non-server side to get sound to work.

I've been messing around with sounds today, upgrading one of my mods from 1.8.9 mod to 1.9. I managed to finally get the sounds registered correctly, and there were no errors in the console, but the sounds were not playing. Then, on a whim, I decided to switch the new PlaySound to run on the client also, instead of just the server (literally, I just removed !worldObj.isRemote from the conditional), and voila, the sound played. It has always been counterintuitive to play the sound on the server, but it has been this way since 1.6.4. The problem is, my code does a bunch of things on the server side, which is also where I play the sound, and now I will need to rewrite a lot of code to get the sounds playing correctly (that, or use packets). Before I rewrite everything, can someone confirm my discovery, that sounds will not play if invoked from the Server anymore? PC

I've been messing around with sounds today, upgrading one of my mods from 1.8.9 mod to 1.9. I managed to finally get the sounds registered correctly, and there were no errors in the console, but the sounds were not playing. Then, on a whim, I decided to switch the new PlaySound to run on the client also, instead of just the server (literally, I just removed !worldObj.isRemote from the conditional), and voila, the sound played. It has always been counterintuitive to play the sound on the server, but it has been this way since 1.6.4. The problem is, my code does a bunch of things on the server side, which is also where I play the sound, and now I will need to rewrite a lot of code to get the sounds playing correctly (that, or use packets). Before I rewrite everything, can someone confirm my discovery, that sounds will not play if invoked from the Server anymore? PC

Thank you, as always, diesieben07.

Thank you, as always, diesieben07.

I poked around EntityPlayer but all I see now is canEat, which is not the same thing.....

I poked around EntityPlayer but all I see now is canEat, which is not the same thing.....

Replying to my earlier hijacked thread post. I unearthed my old code and tested again. Cancelling the event works fine and is reliable on servers. One change, however, to diesieben07's note above, is that you need to use the sub-event 'Pre' (i.e., RenderPlayerEvent.Pre). My problem (in case anyone cares) was how I was using NBT data to trigger the event, which was just plain wrong. PC

Exactly.

@diesieben07, does this event work reliably when playing on a Forge Server? I've found it to be inconsistent in 1.7.10 in some limited testing, where it sometimes canceled all players rendering (regardless of whether or not the item in question was being worn), and sometimes rendering wasn't cancelled at all. In Single Player, there were no issues.

More info on this: - It only happens once, the first time you scroll through NEI - It only happens in the dev environment

Having an issue with some NEI API integration. I've finally got the library correctly placed in the build path, and I've got my API working to hide a few items. Class: Everything appears to be working properly and items are hidden. However, it spits out the the following error when paging through the entries in NEI. I've read a few posts that recommend updating to the latest recommended builds of CCC and NEI (which they are, so no help there). Anyone have a clue what might be causing this? Error:

I know this forum can't get enough of this topic , so one more thing to add, building on Jabelar's idea above. You can use the below as your PlayerTick Handler (or just add the code to your own) and see the overall tick performance of your mod. It basically checks the system time every loop through the player tick, and shows the difference since last loop. Using this while playing the game may give you clues as to where a performance issue could be. For the most part, the number is a steady 0. If you see it spike above 1 for a few ticks in a row, it could be a clue there is something else going on. Please note, I see a regular spike every second or so, even in Vanilla, so keep that in mind. This is not definitive by any means, just something to help if you are looking. Please also note, as diesieben07 pointed out, if it ain't broke, don't fix it. There's no need to go down this route unless you are seeing or hearing about problems. public class PlayerTickHandler { private long millStore = 0; @SubscribeEvent public void onLivingUpdateEvent(LivingUpdateEvent event) { System.out.println("Total loop execution time: " + (System.currentTimeMillis() - millStore) ); millStore = System.currentTimeMillis(); } }

FWIW, and for those tracking this one, here are the optimizations I found and implemented: - The change to the achievement check shown above (medium gain, across all items) - I re-organized the player tick so it had to go through fewer conditions and fewer loops (this turned out only to be a tiny gain) - Items were checking in onUpdate every tick to see if they needed fuel. Changed this to every 20 ticks. No perceptible difference to user. (medium gain, over several items) - One item was mistakenly looping through OreDictionary every tick in onUpdate if durability was 0. This would have only caused lag if multiple people were using it in their hotbar and the item was at 0 durability. But still. (Lex has warned me about this before, so I only have myself to blame). (small gain, when using this item only) - Optimized loops in WorldGen structures (combining checks into one conditional) - small gain - Removed a BreakSpeed Handler which was slow (during testing) - small gain Performance is much better after these and the above optimizations. If I had to summarize, the big fixes consisted of changing checks in onUpdate: if a routine wasn't absolutely necessary to check every tick in the Item onUpdate, then I added a loop counter so it checked between 10-20 ticks instead. Note that the performance problem did not surface until the mod was being put into large modpacks and played on moderately trafficked servers. Will find out more after the update is published, but I am calling this one closed. Thanks to delpi, diesieben07, Ernio, and Jabelar for the ideas and assistance. Edit: Added two more optimizations I had forgotten to list

Sorry I wasn't clear. This is exactly what I'm doing. I update extendedproperties during onUpdate in the Item.

The typical Minecraft triggers didn't allow for a way for me check accurately the information I wanted for the achievements. The only reliable way I could find was through Item onUpdate, though I wasn't very efficient about it. By my 'achievement system,' I mean I needed a way to check if a user had: - collected an item (through finding or crafting) - collected all of the items in the same group - collected all of the groups - collected one item from each of the groups - collected a certain number of items, triggers at 1, 5, 10, 20, All As far as I know, there's no way to track this without using NBT Data. And it went into the Item, as onUpdate in the Item is the first time we see the item appear in an Inventory (which was what I was looking for. If you have an alternate solution, I am all ears...). However, there is absolutely no reason this needs to be checked every tick. Nor stored every tick. Both of these things will be changed. EDIT: Saw a decent uptick in the 'onUpdate' performance (using Jabelar's timer) by making the above change. Will definitely help overall, but will keep hunting.

Perfect. Yeah, not seeing any more gains here, using Jabelar's tester. Once per pet in inventory, per tick. Worst case scenario, that's likely several hundred on the server mentioned. Ok, maybe I was too quick to dismiss the 'packet' discussion. What about NBT Data? Right now, my achievement system leverages NBT Data and is checking (and then storing) NBT Data every tick for every item in onUpdate. Could this be a contributor? Here's what I'm going to do, regardless: - Only have it check every 20 ticks - Read only to check and then only store if something has changed (duh)