Ernio

How do people even find 220 mods to make a whole?! It's most certainly not Minecraft's, nor Forge's fault. At least one of your mods has stupid memory usage or even memory leaks (most likely).

Am gonna be pretty straight with you - you don't seem like the best coder there is (don't take it personally), so unless you update most of us can't really help you without seeing 1.8 files. Current state of Render classes (1.9+) is so much better and what you do there works on my 1.10. There is probably something messy in 1.8 about it. All in all - UPDATE (please?)

1st of all - centralize your code. Move event registration to one place. You do this: MinecraftForge.EVENT_BUS.register(new BLEventHandler()); and this: BLEventHandler event = new BLEventHandler(); MinecraftForge.EVENT_BUS.register(event); FMLCommonHandler.instance().bus().register(event); Which means you make 2 instances / 2 registers. Recommended design: Make 4 classes: CommonFMLEvents CommonForgeEvents ClientFMLEvents ClientForgeEvents ... place all common events in common class and register it from main mod (pre init) or common proxy. Place all client only events (which in this case is RenderLivingEvent) in client class and register it from client proxy. FML and Forge events can be recognized by package they are in (which in later versions of forge is merged). Now onto actual problems: 1. This should work: private final Render renderCat = new RenderOcelot(Minecraft.getMinecraft().getRenderManager(), new ModelOcelot(), 0.5F); ... but I'd pull Render instance from RenderingRegistry. 2. if(event.entityLiving.isPotionActive(BLFeatures.fungiPotion)) This will check if entity to-be-rendered has potion. When you want is to check is Minecraft.getMinecraft().thePlayer has potion effect (how to make custom potion effect deserves another thread if you can't find it already). 3. Don't ever use global event - use Pre or Post (sub-events of rendering events, look inside event class). Cancel Pre and render in Pre. In this case you don't have to touch Post. 4. Everything after seems fine. You cancel normal render and do ocelot. SO WHY IT DOESN'T WORK?! Funny thing - if my 1st part of post (about cleaning up event classes) will not fix it (because you might have some big mistakes that I can't see) - which I don't think it will, you my friend are fucked. During 1.8 code has been heavily refactored after 1.7.10->1.8 rendering updates. There is high possibility that RenderLivingEvent IS NOT CALLED at all (disabled) - because there was such time. You can be sure by checking callbacks on Pre and Post sub-event. If it has none - you NEED to update (there are ways to make it work but PLEASE consider updating to 1.8.9+ to do this properly).

Read what I said again - where the hell did you get all those methods... The ONLY thing you need is said event and what I described. Other problem at hand is this: Hallucinating has to be stored somehow - for that you can make your food apply custom potion effect on player or change some boolean that could be stored inside IExtendedEntityProperties - all that can be found on google, if you have any problems, ask.

This will fire anytime ANY player joins world. You need: if (event.entity == Minecraft#thePlayer) And ONLY that.

It most certainly can't be in client proxy - it is SERVER command. Did you put @EventHandler on it? It should be in main-mod file (where inits are).

Do you have "RenderLivingEvent" in 1.8? The PROPER approach is to use said event. 1. Check if you are hallucinating and if entity rendered is Dog. 2. Cancel event and render cat instead. 3. To render cat you will need ... and here are some problems. * Each Render class is designed to work specifically with given entity and render specific model. * If inside RenderCat (idk name) there are any casts of entity to cat entity and cat-specific fields are used, you can't really use it. So: * If there aren't - you can try getting instance of RenderCat from RenderingRegistry - look for getter methods or access map directly.] * If said render class uses some cat-specific stuff - you will need to recreate it. In that case: * Extend RenderDog or RenderLiving and copy most of code from render cat. to achieve same rendering. Now: In renders there are cases where Render class needs to store some entity render data in entity fields - let's say some render uses "currentLegMovement" saved in entity to rotate leg of entity. In this case this is probably not needed, but if you would need to store such additional data you can use IEEP to do so and write Render class to use those fields. Since dog and cat are pretty much same, I don't think it will be hard (where for some entities it is hard).

First I will ask - can you update 1.9+? You should. If not, I will try to answer because code differs and idk if you have access to specific events/methods in 1.8.

@Epsi This is ABSOLUTE basics of Forge API Yes - you want @SubscribeEvent to LivingHurtEvent and can extract attacker from DamageSource. Event fires on server side only! Eventually there is also LivingAttackEvent or other stuff. What EXACTLY are you trying to do? Describe.

EntityPlayer#addChatComponentMessage to write message from client-side to client-chat.

How is this changing anything? This ^ is your solution. Use CommandHandler to make your cmd server-sided. Call it from @EventHandler FMLServerStartingEvent.

Are we talking about world gens made by mod (so literally custom worlds) or sequence done by forge events (so generally world gen events and decorator events)? If it's 1st and someone hooks his generation to your world gen - then you can't really do much about it (well, unless cancel it altogether). If it's second - you can prioritize events in forge. In @SubscribeEvent you can put priority = Priority.HIGHEST for example (look up event annotation). Other than that - can't really do much about it, it all is very dependent to implementors (other modders). You could make an API, but then again someone has to use it.

What is this? DrawTooltipScreen(mouseX, mouseY); At least post full code. More description/screen would be nice too. #onResize is same shit as #initGui (onResize is top-layer which calls other stuff). Other: * You should be clearing your list on initGui if you plan on refilling it again. * Why no one uses "this" god dammit? Code is so much clearer/readable that way.

Holy shit. You are actually 1st person to actually get something (and show it) out of all the people who asked about replacing player renders. Not that big of an achievement but progress! Before I can even begin to analyze anything you give us - answer me this: You have: public class mycustommodel extends ModelBiped Then you have: public ModelMuscleMan() ... as your constructor. Since it wouldn't really compile I assume you renamed it while pasting or whatever. But just humor me and post updated and cleaner code. Other: * Please use Java conventions (capital classes and all that stuff). * Use [.code] [./code] on forum (without dot). Now onto more general stuff: Note: I already told you to study some vanilla! * RenderPlayer extends RenderLiving extends Render. * Going top-bottom: 1. Look RenderPlayer#doRender - it apples some stuff (quite important GL states). You pretty much need to recreate all required GL states - even if you don't understand what they mean (hold shit, you should), at least take your time and make them actually be what hey are supposed to be. 2. We have this piece of code (mentioned before): GlStateManager.enableBlendProfile(GlStateManager.Profile.PLAYER_SKIN); super.doRender(entity, x, d0, z, entityYaw, partialTicks); GlStateManager.disableBlendProfile(GlStateManager.Profile.PLAYER_SKIN); Which pretty much sets up states and goes down to RenderLiving which actually sets up EVERYTHING for you and just calls model#render. 3. Boom! If you look well enough you will notice that everything you actually have to do is return different model and different texture in #getMainModel() and #getEntityTexture(...) and/or MAYBE do some other magic - generally speaking. The code as it is now (trust me it is beautiful compared to what I had when I was working with renders), meaning 1.10 (probably similar/same as 1.9) is VERY CLEAR. You just have to follow line by line and recreate same behaviour while on the way inserting your model and your texture calls. 4. No point getting any further with this. Please - spend some time studying.

Whole logic behind it: * EntityPlayer has Capability assigned. * Data is (on server) created fresh (1st join) or loaded from player's NBT (later joins). * Data is parsed into your "Object". * Use PlayerLoggedInEvent to send packet to player that will contain your serialized Object. * Client handles packet and deserializes it into "Object" on client and puts it in client's Capability of player. Points of interest: * Caps: http://mcforge.readthedocs.org/en/latest/datastorage/capabilities/ * Setting up Caps: https://github.com/MinecraftForge/MinecraftForge/tree/1.9/src/test/java/net/minecraftforge/test Note: One of them is NoBedTest. * Packets: http://www.minecraftforge.net/forum/index.php/topic,20135.0.html * In 1.8+: http://greyminecraftcoder.blogspot.com.au/2015/01/thread-safety-with-network-messages.html * Forge Events: @SubscribeEvent and registering (google). * PlayerLoggedInEvent * AttachCapabilityEvent.Entity (or similar name, lookL links before). * NBT de-/serialization (Capability storage). Other: This will take hours to write it well, and only if you know Java and had experience with some of it in past.

This issue and outrages such as yours (humorously saying) is something that basically appears here once a month or more. Everyone who knows his shit (is an actual programmer, not wanna-be) has same opinion on this and it almost always leads to: * Empty waste of time posting opinions on this issue in thread created, which is basically everyone just saying "I CONCUR!". or * Some guy stepping in and deciding HE is the ULTIMATE solution and that HE is gonna CREATE THE ULTIMATE wiki/tutorial for EVERYTHING on HIS OWN. Just by looking at those "big" words you basically get the idea what I am saying - it end up being another piece of crap that covers ABSOLUTE basics of modding which have been done several times before and which again - are bad and incomplete. So yeah - "I CONCUR!" Now to the solution I always post: * If someone will take his time to WRITE it down on OFFICIAL WIKI (github one) - I can personally hold conversation on Skype explaining big part of Vanilla and Forge, especially when it comes to designing mod properly and using hooks which apparently people don't use (and blindly overload server with design choices that are totally not needed or are dumb). I could probably do it on my own, but what's the point... nah, but seriously - while it is nice to come here and read/answer some of questions, designing proper wiki page on something is totally different thing and requires preparations, time and editing.

Define "didn't really work" because that is the only valid way of doing it. Show what you tried? Also - you will probably want custom ray tracing method (I mean write one yourself that will take 2 entities as arg) to specifically be optimized to your particular needs. That is at least what I'd probably do.

Remember that statement about OpenGL and vanilla rendering system knowledge? That had Java included and Java also has Programming included which also has reading included (in this case reading of vanilla source). Why don't you tell me what what you did is supposed to do? You can't just randomly call some method from constructor with non-existent params and expect stuff to do anything and even not crash. So while class such as this can exist, it is not proper approach. EDIT So my answer to this is basically - learn vanilla rendering system (read code).

In event Pre allows you to cancel everything that happens between Pre and Post. If you cancelled it normal rendering doesn't happen (thus invisible) and you can write (where your println is) your own rendering. Now - as stated before, Entities don't really have models - they have Render classes which basically render entity directly from code (or rather Model classes such as ModelBiped) To render anything custom - you will do it from code level (GL operations) or you can make GL render some model for you (e.g: wavefront). In any case - again: Notice RenderPlayer and Render#doRender method. Args passed there are entity and positioning x/y/z. You will basically need to do same shit as in Render->RenderLiving->RenderPlayer (I am not in IDE, so idk hierarchy). Other options would be writing class CustomPlayerRender and amke it extend RenderLiving or RenderPlayer. Then simply make instance of it (render classes are singletons, so global static) and use that. After all this talk: Last time I had fun with renders I tried to replace player render in registry, but it didn't work, you can try it yourself. Make Factory and custom Render class and register it using RenderingRegistry.registerEntityRenderingHandler(EntityPlayer.class, new FactoryCustomPlayer()); Note - I also don't know if it's EntityPlayer or some of its sub, like AbstractClientPlayer maybe - check that. Also note - if this way works, you no longer need events (any). EDIT Okay, let me clear it up - you either: 1. Worth trying: Make CustomRender extend RenderPlayer and register it in preInit with RenderingRegistry.registerEntityRenderingHandler(EntityPlayer.class, new FactoryCustomPlayer()); where idk if EntityPlayer.class or other sub-class is valid. Note: This might not work (It didn't last time I tried - for players only, for other entities it works fine). 2. Valid approach: Make CustomRender extend RenderPlayer. Override #doRender to write your rendering code. Make global static field and make instance in mod's init. (Lookup how Factory class makes instances). Use that instance and call #doRender from your event (where you do println).

@SubscribeEvent to RenderPlayerEvent.Pre and/or Post. Cancel rendering and render your own model. Note: This will require intermediate understanding or Render.class and its sub-classes as well as general to advanced OpenGL knowledge. On a side - also pretty much everything about vanilla rendering systems. What help are you expecting? What model you want to use? What you want to render? What about animations (if you have different model, you need different animations, which you need to also code)? What about rendering vanilla other stuff such as armours and other "layers"?

Possible interpretations: 1. "How to properly code .json in forgeBlockstate format?" 2. "How to make block have multiple properties (using metadata)?" 3. "How to make block have more properties than metadata allows?" Which one is it? P.S: "multiple block states on one block" - phrasing, block has only one BlockState, it can have multiple properties/variants.

Yeah Thx u Np. - do you need any help there (you haven't stated it)? I have no clue what you are trying to say. Was that the mentioned "call for help"?

http://mcforge.readthedocs.org/en/latest/concepts/sides/ Few things: 1. If your mod will be client only - mark it with clientSideOnly="true". * This way pretty much there is no way it can be loaded by dedicated server and you don't have to worry about using client-only stuff ever (thus @SideOnly will not be needed anywhere in mod). 2. If your mod is sided: * I recommend separating code in packages such as "common", "client", "server" (where server will be almost never used unless you are writing private and/or server mods). * Mark all classes in given packages with @SideOnly(Side#side) to honor given side. 3. Why am I mentioning above? Aside from using @SidedProxy, you should make sure everything works as you want it to - here @SideOnly ensures you actually are not using stuff that doesn't belong in given place (because it will crash otherwise). Other: 4. Null-checks are pointless for pretty much any event (regarding entities, not e.g: BreakBlock). Note: "Minecraft.getMinecraft().thePlayer != null" is valid. 5. Please rename your method "onPlayerUpdate" - false, it fires for all entities (I recommend naming method "on"+eventName). 6. $readItem should take EntityItem, and casting should be made by method caller. Aside from that: * I don't see any damn logic in your approach so I will interpret it as code for testing. If that is not - tell your goal so maybe we could give better solution.

You could try RenderGameOverlayEvent.Pre and cancel rendering when ElementType == "something". (I think it is "TEXT" or something).

As far as I understand - the List you are talking about is not synced (present on server, null/empty on client)? You will need packets for that.