BinaryAura

Thanks, this does what I need. Took me a while to figure out how to do it though.

Ok, I've been able to use this well for everything except, title/subtitle and record title They are related to the world instead of the player and the fields are protected under ingameGui. Any ideas on how to get this data? title/subtitle is through the packet system and the record seems indirectly called by the jukebox block.

Is there a way to cancel the original HUD via this event?

I looked into ClientConnectedToServer, which works for my purposes. However, if you wanted to do anything in the Main menu before the game itself, this would not work.

I'm trying to make a new version of AdvancedHUDMod. Mainly because 1). The original author has handed off the project. 2) Has not been made for 1.8 that I'm aware of. 3) I'm planning to make improvements to the API, 4) I want to make the mod as a whole more flexible, with more options and tools. I call the mod Customize, it can be found here. I wanted to have the mod to be able to allow customization of all ingameGUI objects from chat, to helmet, to portal, to the health, and experience bars. It would create one centralized location where HUD items could report to and allow for player customized layers and modder customized options for each individual options. It also further abstracts this part of the code which, of coarse, is good for module-based code. In order to do this however, because of private methods and methods without API render Flags (e.g. Tooltip, Chat, etc.), I need to replace the ingameGUI method used in the Minecraft class. Since this is a Client Side mod, I can't use Server Side Events such as ServerStarting and I've tried using ClientConnectedToServer, which says it's being launched at the Client yet does nothing. What I want can be done by listening to the TickEvent or RenderTickEvent and changing the ingameGUI then, but only if it isn't already an instance of the new class. However, this new method would needlessly be called every tick (or every other tick in the case of RenderTickEvent). This would slow the code down. Not much in this example, but imagine if there are other things you wanted to do here. ingameGUI is not the only var modders may want to change. If there were other vars, and those vars initiated large loops (honestly, I don't see this, loops should be taken care of during init) then it would slow the code considerably. onInitalizationComlete is an FML class that is called after all the minecraft vars have been assigned and it is before the runGameLoop, so it wouldn't be called multiple times. That's why it would be a good location, either in the method or around the call.

I was told by one of the main contributors on github to submit my idea here. Currently I'm working on a clientside mod. However, due to it's nature, I have to change the ingameGUI. However, the only way that I have found to do this is to use the TickEvent or the RenderTickEvent. Both of which are constantly going off. The reason for this is because there is no Event in between the definition of the ingameGUI and the runGameLoop method. There is an excellent location for such an event to be called in the FML classes: FMLClientHandler$onInitializationComplete this method is called toward the end of the Minecraft$startgame method after ingameGUI is set. along with many other variables that are set that modders may want to replace in the code.