Laike_Endaril

I've been delving into the potion-related code in MC and it *seems* like custom potion effects on the player should automatically sync to the client, but for some reason my potion effect only exists server-side. The potion itself works, and the particle effect is spawned, but I must be missing something to allow the existing synchronization system to sync my potion effect, because iterating through + printing the potion effects shows the effect server-side, but not client-side. Potion: Registration (added to event bus in main mod class constructor): Test (For vanilla potions, both debug messages print. For my own potion, only the server message prints):

If you want the companion to be visible to other players, it needs to be server-side. If you want the companion to interact with the world, in some cases it *could* be done client-side, but in the massive majority of those cases, it would be considered a client exploit / hack mod on many servers, so it should be done server-side. Note that I'm not counting basic physics here; if you want it to hop around on the ground using blocks the client knows about to collide with, that's fine. If this is purely visual, and does not interact with the world in any way that could be considered a client hack / expoit, then it might be viable to do client-side, but note that no other players on the server will be able to see it. If you're fine with these circumstances, I would actually say that in this very specific case, it's better to do this client-side than to do it server-side, as it won't use server resources or cause any additional network traffic. As for *how* to accomplish it, I'm not helping with that part! Good luck! XD

This is probably just a legacy code thing. Minecraft wasn't originally made for modding; mod support was added later, so you'll be finding a lot of things that are not as easy to mod as they could be. But yeah, that's a pretty annoying one. I don't have a good solution for you there, because... ...you can't alter the method directly without a bytecode edit ...you can't override the method unless you use an AT and extend the villager, and even if you do this, it will cause all kinds of incompatibility with other mods Actually, I can think of one way to do this; you can write your own completely separate pick-up code somewhere else in a tick event, which checks if a villager is near your chosen item(s), and if so, makes them pick it up. This is probably the easiest, most flexible, and most compatible solution, though not necessarily the most efficient at runtime. You can minimize the performance impact by eg. using rectangular distance checks instead of circular distance checks (direct x and z comparisons instead of actual distance)

No problem, though to be fair, @larsgerrits gave most of the useful input! This was as educational for me as it was for you lol

Did you make sure to delete the old world before testing? Because the world itself would still contain the corrupt NBT data from the old version of writeToNBT()

Alright, so I made a dumb mistake and used enableAlpha / disableAlpha instead of enableBlend / disableBlend for one of the first, most simple methods of accomplishing this. The following works just fine... Yep...on the bright side, now I know how to use ATs due to my dumb mistake. Thanks to Tama on the MMD discord for smacking me in the face

In your writeToNBT override, move the compound.setTag line above the super method call But in the readFromNBT, keep the deserialize below the super call, as you have it now

Oh right, I haven't touched them yet, but that would certainly work. I'll look into this after I fix a bug I found

You also need to set the encouragement to 0. Set both flammability and encouragement to 0 and you should be good. It's been a while since I messed with fire last, but I think what you should be using to accomplish this is something like... Blocks.FIRE.setFireInfo(yourBlock, 0, 0); Think your block may need to be registered first, so maybe try that right after registering your block and see if it does the trick Given, you can probably also accomplish this by keeping your overwritten getFlammability() method and also overriding getEncouragement() to return 0 as well

But unfortunately I hadn't realized GlStateManager.AlphaState only has a private constructor, and so I cannot extend it. So that's about as far as I got with my bright idea lol While I was at it, I also tried what you suggested @Cadiboo, but had no luck there either: @SubscribeEvent public static void preRender(RenderLivingEvent.Pre event) { GlStateManager.disableAlpha(); GlStateManager.color(1, 1, 1, 1); GL11.glEnable(GL11.GL_ALPHA); GL11.glColor4f(1, 1, 1, 0.4f); } @SubscribeEvent public static void postRender(RenderLivingEvent.Post event) { GlStateManager.enableAlpha(); GlStateManager.color(1, 1, 1, 0.4f); GlStateManager.disableAlpha(); GlStateManager.color(1, 1, 1, 1); } This code had no visible effect (and yes, that class was on the event bus; other, unrelated events in the class were firing on the client) I'll probably put this feature on hold for now and maybe come back to it later and try one of the other approaches

I actually considered this, but was iffy about it because I have no way of knowing for sure what it will be set to for some random mod's mobs (though surely in most cases it will be 1; fully opaque). One other issue would be if the alpha settings are set more than once between when I set them and when the entity is rendered, because there's no way for me to prevent GLStateManager from passing it if it changes twice. HOWEVER, by suggesting it you got me to go look at the GLStateManager class again, and made me realize something extremely useful, so thanks, Cadiboo! Specifically this, which I am quite excited about now: All the cached openGL states it uses are *OBJECT INSTANCES!* I can most likely extend them and reflect-replace to accomplish my goal. I also doubt this would have many (if any) compatibility issues with other mods, since I wouldn't expect many people to be messing with these (I can accept the off-chance of 1 or 2 incompatible mods). I'll tinker with this after I take care of a couple other things, and post back here after I try it!

Unfortunately I have had no luck. I've been using the Nature's Compass mod to help debug, and by default I get the same behavior you do. If I add the kelp forest biome to BiomeManage.oceanBiomes then it does not generate at all afaik. I feel like this step is necessary but something is missing; probably something difficult to figure out. I don't think I can be of much help here, but if you can do this using structure gen instead of biome gen, you may want to look into that approach as it may be more workable (after all, structures generate inside specified biomes; you could use the ocean monument as reference if you did it this way)

It may not be extending OceanBiome directly, but the only reason I mentioned that was for getTempCategory(), which you're already overriding with the same return, so I don't think that's the issue (unless MC is checking class inheritance for biomes somewhere, but I doubt it). I'll try tinkering with it a bit and see if I learn anything.

Yeah, what I tried before was a temporary test; I'm decent with openGL so I (usually *cough*) make sure to push/pop or reset parameters when I'm done. Dang, was hoping I had missed something handy, but so far it seems about as much trouble as I thought it would be...I may poke around like you said and see if there's anything global-ish that I can intercept (if it doesn't do *all mobs* or at least nearly all mobs then it wouldn't be worth doing). I'll be sure to post if I find anything workable that doesn't involve loads of incompatibility issues

Yep, and like I said if you're on intelliJ, use that middle click to poke around at things. It's extremely useful. I haven't used eclipse in a long while but I imagine it has a similar feature. Not sure what the shortcut for it would be though.

When I tested using the event mentioned, my mod was the only one loaded, so I'm automatically both LOWEST and HIGHEST, since there are no other mods loaded to add event subscribers. But yeah, I've had to solve some mod compatibility stuff using priorities before, and it is something I will keep in mind for compat if I get this working on vanilla first.

You should be able to do it either way. The nice thing about extending is that, for the most part, you can leave what you like as-is, and change what you don't like (with some exceptions). For example, if you like how most of TileEntityChest works, but not how it handles a certain method, you can override just that method (if you have access to it). That aside, you could *instead* extend a more basic class, such as TileEntity, and would have to write code yourself for anything you want but it doesn't have. Going with that same logic, you could, in many cases, write a class completely from scratch without extending anything. What it comes down to in most cases is finding the class which most closely reflects what you want to accomplish, extending or copying it, and then editing. I can't give an authoritative answer on what's best in your case in the long run, but at a minimum you will need to extend TileEntity. TileEntity or one of its subclasses, because the AnvilChunkLoader only calls the readFromNBT() and writeToNBT() methods for TileEntity instances (including any instance of an object which extends TileEntity). I suppose if I were in your shoes, I would copy the entirety of the EntityTileChest class as-is, rename it, and edit as necessary. The field used for storage in TileEntityChest is set to private access, so you won't have direct access to it if you extend TileEntityChest, which in turn means you probably won't be able to use TileEntityChest's built-in NBT methods as they are, but you can certainly use them for reference to see how they do things. All in all, if the only feature you don't have working it disk save/load, then just keep what you have now, copy/paste TileEntityChest's two NBT methods in, and then edit them (you can copy it straight out of my previous post, in the spoiler). Again, I haven't actually made a container myself, I'm just going off of what I see in the vanilla code and what I know about how MC handles data in general, so I can't really get any more detailed than this atm, though I'm sure someone else could (someone who has done it). You could also try to find a mod on curseforge which adds a container and is open-source, and take a peek at their code for an example. Edit: Forgot to answer your last question about !this.checkLootAndWrite. First, just to be clear, the method itself is checkLootAndWrite(). The exclamation mark is negation, which means if !checkLootAndWrite() is true, then checkLootAndWrite() is false. And the "this." part just means that we're calling it from "this instance", which in most cases is redundant, but can sometimes prevent confusion and errors involving fields/methods with the same name from other classes/instances. And yes, you could extend TileEntity and write that method from scratch...*OR* you could extend TileEntityChest and overwrite that method, which would replace its functionality. In this *particular* case the result would be the same, because that *particular* method is only called from TileEntityChest and its subclasses (not from any of its superclasses, and not from any other external classes). In intelliJ, you can see where a method is called from (or just in general, what connects to what) by middle clicking it or by setting the typing cursor on it and pressing ctrl+B But yeah, maybe someone else can give you a more specific answer, or check out some repository code of an open-source mod with a working container

Have a mod which could benefit greatly from fading mobs in and out, alpha-wise, but haven't found a solution I like yet. If it were just my own mobs it would be easy, ofc, but I'd need it for *all* mobs. The obvious answer (if you're familiar with openGL) is to set the openGL rendering settings correctly, but I tried this in RenderLivingEvent.Pre and did not get any results (enabled alpha and set color to (1f, 1f, 1f, 0.4f)). If someone has tips on hacking this method to work I'd appreciate that. I know a shader would work, but I'm trying to avoid that so as not to break compatibility with other shader mods. Replacing vertex data in existing models would also work in theory, but would probably be extremely inefficient, since I'd need to generate (currentModelCount * alphaSteps) models, right? In any case, looking for the most "normal" way to accomplish this, if there is such a thing. Edit: I made a dumb mistake and used enableAlpha/disableAlpha instead of enableBlend/disableBlend. This code works fine:

Saving and loading to/from disk is all in the two NBT methods you mentioned afaik. Don't think you're getting anywhere until you get those 2 methods straight. Ofc I would just try copying the code from TileEntityChest, and altering it as necessary. Actually, I would probably have just extended TileEntityChest if possible. In any case, here is the code from TileEntityChest: If your TE is registered correctly, those 2 methods should be called automatically, or at least that's what it looks like from browsing the AnvilChunkLoader class

Yes, it's one of the common issues with modern gaming, along with the server sending the client data extending beyond that which the player is supposed to have access to. If your case I wouldn't worry about anything beyond some basic server-client mod matching checks as you said. If you wanted to go all-out you would have to completely rewrite MC's control model, which I don't suggest (mostly due to how much work would be involved, plus all kinds of possible compatibility issues)

After a quick code browse, it looks like TileEntityLockableLoot supports not only inventory, but also a locking function and loot tables, ie. can be made to spawn naturally with loot already in it using said loot tables. TileEntityLockable is similar, but without the loot tables. If you don't care about locks or loot tables, you probably don't need either one, so a basic TileEntity should be fine, especially if you already have it working as intended (which it sounds like you do?)

Alright, well I may or may not be on tomorrow, but after a little code browsing it looks like as long as your biome class is extending OceanBiome, it should only spawn where Ocean can spawn, unless there's a piece to the puzzle I'm missing.

Does your biome class extend BiomeOcean? Does your biome set its height? You should post your class code and the code where you declare/initialize the field "kelpForest" so ppl can get a better idea of what may be wrong.

Here's how the deep ocean (an ocean sub-biome) gets registered: registerBiome(24, "deep_ocean", new BiomeOcean((new Biome.BiomeProperties("Deep Ocean")).setBaseHeight(-1.8F).setHeightVariation(0.1F))); I actually haven't done anything with biomes so far, but I'm pretty sure you can apply part of this. If I had to guess, I'd say any height less than 0 is underwater.

Currently adding a custom set of attributes to all LivingEntityBase for my Dynamic Stealth mod (ie. adding a custom attribute to vanilla / unknown mod entities). Had some trouble before I found a usable event for doing so, but I believe it's working now, so figured I'd chime in: The event for doing such a thing (by which I mean, the ONLY event that works, when the entity is reloaded from disk, afaik) is EntityEvent.EntityConstructing If there is another event with the correct timing, I do not know of it. the join world event is too late to add attributes to the attribute map without warning spam in the server log. Hopefully someone finds this useful