Caffeinated Pinkie

I've tried everything I can think of at the moment to register a configuration file for one of my mods in 1.15. I've looked at a bunch of source code from other mods to see what I am doing wrong, but I can't tell what's different. I run this code during the FMLCommonSetupEvent: ModLoadingContext.get().registerConfig(Type.COMMON, commonSpecPair.getRight()); which references this: private static final Pair<Common, ForgeConfigSpec> commonSpecPair = new Builder().configure(Common::new); and creates an instance of: private static final class Common { private final DoubleValue heightWeight, metallicityWeight; private final BooleanValue realisticLightning, spawnFire; public Common(Builder builder) { builder.comment("Common settings").push("General"); heightWeight = builder.comment("TODO").defineInRange("Height Weight", .5, 0, 1); metallicityWeight = builder.comment("TODO").defineInRange("Metallicity Weight", .5, 0, 1); realisticLightning = builder.comment("TODO").define("Realistic Lightning", true); spawnFire = builder.comment("TODO").define("Spawn Fire", true); builder.pop(); } } However, the configuration file is never created and no log messages are given that could give me a hint as to what is going wrong. Update: I've only found one workaround that makes it generate correctly. I don't think it's the proper way to do this, so I'm hoping for a better method. I just have to run this after registering the config. ConfigTracker.INSTANCE.loadConfigs(Type.COMMON, FMLPaths.CONFIGDIR.get());

I'm looking to get a list of all vanilla and modded recipes registered in Minecraft Forge during runtime. I'm not sure where to look for some sort of registry that has this data, or rather where I am supposed to look.

After opening up JEI and searching "Graphite Dust", I found 3 different graphite dusts with 3 different ore dictionary names. One of them is easy enough to get. The one I actually need is insanely difficult to find anywhere. I'm considering making a mod that allows the user to manually select multiple ore dictionary names and mark them as the same thing. On doing so, they can specify what the merged name should be, i.e. using dustGraphite for the different graphite dusts. Maybe there could be an option to guess at the names, for example dustGraphite and graphiteDust could be combined since they have dust and graphite. The reason I'm posting this here instead of just starting on it right away is because I'm not sure if there is already some obscure mod that does exactly this, or just a feature in Forge that can already be changed without a mod. So I'll start working on it soon if I don't find this mod. Any suggestions would be appreciated.

Yeah, I found those. I'll see if they work. weatherEffects -> field_73007_j effectOnly -> field_184529_d Edit: I built a version of it and stuck it into a minecraft mods folder. It works so far. Edit 2: I can say for certain that the Local Weather, Storms & Tornadoes mod is not compatible with this. This is because they replaced EntityLightningBolt with their own version, among other things. I'll be working on making the two compatible. Edit 3: Done. Found out also that Minecraft spawns fires around the strike point during the construction of the lightning, so I had to remove them and then readd them in new places after.

I found ObfuscationReflectionHelper. I think that takes care of the obfuscated variable names.

I had not actually considered that. I suppose that will have to fixed now. I can possibly just use a loop or recursion to get the class that declared a field in that case. I'll make sure to change that. Is there a specific way that I should crash the game besides System.exit(0)?

The name of the mod is "Lightning Tweaks". I do not have a release page for it yet, but I plan to make one in the near future. As far as I have been able to test (without any other mods), the lightning is correctly attracted to the blocks I specified before and entities. Most of the values used in this math is customizable through the in game config UI. I have yet to add the block to convert lightning to energy, but some placeholder values are in the config file. I put a work-in-progress build of the mod below along with its source. Every method and variable is public and every method and class has documentation. You may use it in a modpack. This is WIP build and has not been extensively tested with or without other mods. lightningtweaks-1.12.2-0.0.4.0.jar lightningtweaks-1.12.2-0.0.4.0-sources.jar

I don't really see the harm in doing this, so I'll give a brief description. The majority of the mod is causing lightning to act better. By better I mean it will strike with a preference to taller objects, things made of metal, less cubelike blocks like iron bars, and entities. I'm also going to have a block that, when placed near anything that acts as a lightning rod, will absorb the lightning that hits it and convert that to RF.

I'd like to inform everyone that I've figured out how to redirect the lightning. Basically, I noticed that in WorldServer.addWeatherEffect(), before sending a packet, super.addWeatherEffect() is called. So I used reflection to set World.weatherEffects to an ArrayList with the add() overridden to set the position of an Entity when it is added. I just did this on the WorldEvent.Load when the world is not remote. I essentially added in a listener to when a lightning bolt is added to weatherEffects. @SubscribeEvent public static void worldLoaded(Load event) { World world = event.getWorld(); if (!world.isRemote) FieldAccess.set(World.class, world, "weatherEffects", new ArrayList<Entity>() { @Override public boolean add(Entity e) { BlockPos pos = SearchBlocks.search(world, e.getPosition()); e.setPosition(pos.getX(), pos.getY(), pos.getZ()); FieldAccess.set(e, "effectOnly", BlockAttributeConductive.isMetallic(world.getBlockState(pos.down()))); return super.add(e); } }); }

I do want to point out that I have tried the onEntityJoinWorld event and it does not include EntityLightningBolt. I was initially using WorldTickEvent to just get the latest Entity in World.weatherEffects. It could work, but it is fairly roundabout. The position of lightning is not kept in sync, and I have to send a packet to the client, or directly access the lightning from the client side to change the position. The main issue I had with WorldTickEvent is that it only calls from the server side. I can modify lightning and everything there, but the client side gets the lightning a couple ticks later. By the time ClientTickEvent calls, the lightning has already been rendered client side and gets a glitchy rubber band effect or just jumps. Edit: I did also try EntityConstructingEvent and lightning is called for it. The problem there is that it is called at the end of the Entity constructor. EntityLightningBolt calls super then afterwards sets its position and other variables. Also, by that point Entity.getEntityWorld() is null.

I am creating a mod that intercepts the strike location of a lightning bolt. The only way I could get the lightning strikes is with WorldTickEvent and even then the client renders lightning before I can move it. The best, and most efficient, way I can see to combat this is to intercept the argument for WorldServer.addWeatherEffect(Entity). All I would need to do is set the position and one of the variables in the Object. What is the best way to get the instance of the Entity being passed in before the method code is executed? Here is the code for the method if it would help. I want to get entityIn before the method starts executing. /** * adds a lightning bolt to the list of lightning bolts in this world. */ public boolean addWeatherEffect(Entity entityIn) { if (super.addWeatherEffect(entityIn)) { this.mcServer.getPlayerList().sendToAllNearExcept((EntityPlayer)null, entityIn.posX, entityIn.posY, entityIn.posZ, 512.0D, this.provider.getDimension(), new SPacketSpawnGlobalEntity(entityIn)); return true; } else { return false; } }