BatHeart

Thanks everyone. I believe I understand it better now. My .addListener() calls were never doing anything. Everything was handled by the @SubscribeEvent and the MinecraftForge.EVENT_BUS.register() calls. I have now taken out all of the .addListener() code, and Forge now loads my mod, and the mod still works. Batty's Mod does not end with 1.15.2! This will be good news to my 'customers' who have been asking me why it suddenly stopped working 😄

Thanks @CAS_ual_TY Much appreciated! I think I am registering to MinecraftForge.EVENT_BUS. I think the problem may be with how I am adding my listeners. For example: final IEventBus modEventBus = FMLJavaModLoadingContext.get().getModEventBus(); modEventBus.addListener(battyUI::renderPlayerInfo); but when I register it: MinecraftForge.EVENT_BUS.register(new BattyUI(Minecraft.getInstance())); And in the BattyUI class: @SubscribeEvent public void renderPlayerInfo(RenderGameOverlayEvent event) { I think the problem may be that I am getting the wrong type of mod event bus before I add the listener. As you can see, I am getting an IEventBus. I think I need to find a way of getting an IModBusEvent. Or am I still confused?

I'm not trying to prove a point. Honestly. I just want to know what I should be doing. My mod displays coordinates, a timer and some other information on screen. I've been maintaining a Forge version of it since Minecraft 1.0.1. I need an event that fires when the game screen is being rendered, to call my code to display this information. Am I understanding correctly, that the only events that I can subscribe/listen to are those that implement IModBusEvent? Because there don't seem to be any of them that are connected with screen rendering. It would be a sad day if I had to stop my mod at version 1.15.2, having maintained it for 7 years, but I can see that's where we're heading with this conversation.

I'm sure it must have been firing, or the information I'm displaying on screen would never have appeared. My code would never have been called. So, could you tell me which event I should subscribe to and listen on if I want to display something on screen whenever the main game overlay is being rendered? I would be grateful for any practical assistance.

Well, it's been registered the same way through all the prior versions and was working fine up until 32.0.88. Then this change was made and it no longer works, but I'd like some advice as to how to set a listener on the RenderGameOverlayEvent. Just saying I did it wrong is not very helpful to me.

My mod has always had listeners on various events, one of which is RenderGameOverlayEvent. Since 1.16.1 - 32.0.90 and the introduction of IModBusEvent, my mod fails to load because the listener for this event is not a subtype of IModBusEvent. I can see this described in the Changelog as Introduced IModBusEvent as a marker interface for events on the ModBus. Expect exceptions if you use the modbus for events not listened there. However, I am unclear as to how I should fix the problem (...or even if I can fix it yet. Maybe I have to wait for further code changes in Forge?) Any advice would be greatly appreciated. Thanks

After working on restructuring my whole mod, to bring it as close to @Cadiboo's example as I could, this still wasn't working. (But my mod was so much better structured. Thanks, @Cadiboo!) Then I discovered what the problem had been all along. I had been using an old convention available for KeyBindings, which evidently worked up to and including 1.12. My categories were named 'key.category.batty'. This must now be 'key.categories.batty'. I also had the KeyBindings themselves named e.g. 'key.batty:infodisplay' and this should now be 'key.batty.infodisplay'. One or the other (or both) of these were responsible for my problem. It's very strange, because the whole key binding worked fine while I was in game. It's just that it forgot the key bindings which had been changed the next time I entered game. Anyway. All solved. I just thought I would post this in case anyone else wanders into similar problems. It's all in the name!

Ah. Thank you. Just to confirm that I have got this right - we are both doing exactly the same things, but you do it all in your ClientProxy, whereas I have been doing it in my base mod, and tying them to particular events. Evidently you do not see this problem, so I shall try to replicate your method in my code and hopefully ...

Apologies if this has been asked elsewhere. I looked, but didn't find it. In versions of my Forge mod up to 1.12.2, I was handling KeyBindings like this, and it was working fine: 1. Declare the KeyBindings 2. In FMLPreInitializationEvent, registerKeyBinding 3. Detect the bound keys being used, using a KeyInputEvent, within my code I realise things are slightly different in 1.14.3: 1. I still Declare the KeyBindings as before (but have to use key codes instead of the Keyboard. shortcuts) 2. There is no FMLPreInitializationEvent, so I registerKeyBinding in FMLClientSetupEvent 3. I Detect the keys in virtually the same way, but KeyInputEvent is no more, so I use ClientTickEvent instead All of this basically works in 1.14.3 the same as it used to, but with one problem. If I change a keymapping in-game (on the Controls screen) then it works just fine while I am in-game, and even writes the new key code to the options.txt file, but the next time I go into game, the key mappings are back to the default ones. This didn't happen in 1.12.2. It's as though it is not reading the mappings from options.txt - or is it reading them and then overwriting them with the defaults? Has anyone else experienced this problem in 1.14.3, or maybe you know what I am doing wrong here and can help? Any help would be much appreciated.

Thanks. I'd pretty much worked that out back in Feb. I'm prepared to wait. I wasn't going to say anything more, but then I saw the question Vistaf was asking me, and had to clarify.

I couldn't update them in game. As I say in that post, I don't think the in-game config button is implemented yet, so I just updated the toml file manually. However, since I made that post, I've been shown that the Forge config really wasn't working at that point. Hopefully it's now better, and I'll have another go at including it. I've had to tell people that basically there is no configuration possible of the 1.13 version of my mod.

We've all had to work it out for ourselves, or ask each question as it arises. The readme files in the latest MDKs for 1.13.2 have been updated, so they do describe the new way to set up the workspace for eclipse or IntelliJ. The link at the top of the page "1.13 Update Notes for Mod Creators" is worth looking at for details of many of the major code changes in 1.13.x Minecraft and Forge.

... and now this is broken again ... I've tried with builds 25.0.47 and 25.0.48 and it appears to be the same - you have to run gradlew genEclipseRuns before the Run Configurations appear. However, now the Client launch fails - even if you try to run it with just the examplemod. The problem is a NullPointerException at net.minecraftforge.fml.ModLoader.buildMods(ModLoader.java:161) We can go back to using gradlew runClient - but that's not ideal especially if you want to debug.

Oh. I see your example. Well, the problem I get when doing that is I get a run time error saying there is a conflict between my mod's config and itself. It's as though it sees each of them as my mod, and doesn't allow duplicates of the same mod to have config. The log file shows the error as: [22Feb2019 14:20:01.027] [modloading-worker-1/ERROR] [net.minecraftforge.fml.config.ConfigTracker/CONFIG]: Detected config file conflict coordinatesplusmod-client.toml between coordinatesplusmod and coordinatesplusmod [22Feb2019 14:20:01.028] [modloading-worker-1/ERROR] [net.minecraftforge.fml.javafmlmod.FMLModContainer/LOADING]: Failed to create mod instance. ModID: coordinatesplusmod, class battys.coordinatesplusmod.BattyBaseUI

Difficult to describe without screenshots, but I have too many options to put easily on one screen, so in all of my previous versions I split them up into 3 screens. So when you click on Config the first thing you see is the choice of 3: "Coordinates Options" "Timer Options" or "Infopanel Options". Clicking on "Coordinates Options" brings up a page of just those options, etc. I implemented all this in 1.12 using the @config annotation system, which allowed this kind of structure (outer-level config, 3x inner-level configs) I just don't see whether the new ForgeConfigSpec system permits you to do this.