PhilipChonacky

Stop me if I'm going down a rabbit hole, but using SSpawnObjectPacket as a reference, I need to implement IPacket<IClientPlayNetHandler> which has a limited set of handlers for vanilla SpawnPackets (Object, Mob, etc.) Can I extend something simple like SSpawnGlobalEntityPacket (which has a method in IClientPlayNetHandler) or would it be better to implement a Client Side spawning method [in place of implementing IClientPlayNetHandler?] I may be getting in over my head as IClientPlayNetHandler seems to implement several Thread safeguards that I'm not familiar with. Bonus question: SSpawnObjectPacket seems to use a deprecated methods for identifying/retrieving the EntityEntry so it can be serialized and sent to the Client - is there a preferred method? The only thing I could come up with is retrieving the entire map from the [Forge] Registry and transmitting the key for lookup on the Client side (which could be just reinventing the wheel) thanks again. /P

I have a fairly simple laser entity based on Arrow abstract classes which I have been trying to troubleshoot to no avail. The entity is spawned, but the renderer does not fire on the client. No errors are thrown, it just doesn't appear. Laser cannon (Item) fires Laser (Entity) on a right-click (similar to an arrow, but no pre-load) ItemLaserCannon is extended from Item EntityLaser is extended from AbstractArrowEntity RenderLaser is extended from ArrowRenderer So far I have determined the following 1. The entity is being created and runs in Server Thread (caught breakpoint in Tick method, confirmed interaction with player) 2. The renderer appears to be successfully registered (caught breakpoint registry event injection) 3. No errors or anomalies are being registered in the logs. 4. Renderer does not appear to be running in Client Thread (breakpoint in "doRender" method is not caught) I think I have registered everything correctly, another entity I created in the same mod is functioning as expected. I used this Item/Entity in 1.12 and it worked fine, but in that case I copied the rendering code instead of extending an existing class My Code TIA /P

Controlling how blocks face are configured in blockstates and model [JSON] files, In the Eclipse "Package Explorer" view, look for Referenced Libraries -> Forge Src 1.12 ... -> assets.minecraft.blockstates --> 'birch_log.json' for an Example (Birch Logs) The models listed can be found in assets.minecraft.models.block The base Class for logs is in net.minecraft.block.BlockLog . which you can probably use natively or extend to get the effect you are after. Basic concepts are covered here: https://mcforge.readthedocs.io/en/latest/blocks/states/

Just wanted to add this one last item: MCP mapping lists can be found here: http://export.mcpbot.bspk.rs/snapshot/ Modify the "Mappings Channel" line to match the datecode part of the snapshot name (This applies to MC 1.13 and newer) Example: if the line reads: mappings channel: 'snapshot', version: '20190704-1.14.3' and the snapshot export name is: mcp_snapshot-20190706-1.14.3.zip, then modify the line to read: mappings channel: 'snapshot', version: '20190706-1.14.3

Thank you - I just figured out how to update the mappings by editing the 'build.gradle' file and rerunning the gradle scripts. I had been updating Forge, but neglected the mappings.

I have been modding with the latest MCF version for MC 1.14.2 [1.14.2 - 26.0.63] and finding the level of Obfuscation almost unbearable (It seems to have been getting steadily worse since 1.12). Are there any tools/workarounds out there to help deal with this (or any notions if/when this will get better)? Or should I just go back to modding 1.12? I keep older versions around to use as reference, but as some of the structure has changed sufficiently that the classes don't always line up without going through long sessions of stare-and-compare. /P bonus question: Is Forge still relying in MCP for code deobfuscation?

What I have found from my own experimentation (and I hope someone will correct me if I'm wrong) is that model rendering space starts 24 units above the y location of the entity and goes up as you go down, so the origin would be at 0 and 24 would be at the y location (thus you are rendering from the top down). Entity height (as defined in your EntityEntry) is defined from bottom up. Eye height measures from y location up, and is usually defined as a percentage of entity height (but can also be defined as an absolute) Hope this helps. /P

Logs?

When you declare a texture, don't add the "PNG" suffix, it's implied [example here] Also, your setup method seems a rather roundabout way of simply adding a .setRegistryName to your registry entry [other example]. I'll have to leave the GUI question to someone else as I haven't tackled on of those since 1.7 /P

You might want to supply some more specifics if you want an answer 1. What DLL are you trying to load? (and why?) 2. In what manner did you add the library (screen shot?) 3. What have you done to troubleshoot so far? 4. Some code?

This is what I get with the Referenced Libraries/client extra.jar, I vaguely recall a generic error like the one you describe before I set a handler for the file, but I definitely don't get one now.

I'm a little unclear where you re coming across this. Do you have a screenshot? Below is a shot of my preferences showing the handlers for JSON files. JSON Editor is a plug-in I installed that structures the view of JSON files

Which IDE are you using? I use Eclipse which has a generic text editor, or a plug-in for JSON files.

You need to avoid putting static fields in your registry events. Build the EntityTypes in the RegisterAll parameter list. If you need to cross-reference between your EntityTypes and renderers, use ObjectHolders Here's a snippet from my [simple] mod where create my Events for 1 block (and its BlockItem), 1 Item and a custom [Mob] Entity //Mod Event bus for receiving Registry Events) @Mod.EventBusSubscriber(modid=ChickenMod.MODID, bus=Mod.EventBusSubscriber.Bus.MOD) @ObjectHolder(ChickenMod.MODID) public static class RegistryEvents { public static final Block test_block=null; public static final Item test_item=null; public static final EntityType<EntityProtoChicken> protochicken=null; @SubscribeEvent public static void onBlocksRegistry(final RegistryEvent.Register<Block> blockRegistryEvent) { blockRegistryEvent.getRegistry().registerAll( new Block(Block.Properties.create(Material.IRON)).setRegistryName(ChickenMod.MODID,"test_block")); } @SubscribeEvent public static void onItemsRegistry(final RegistryEvent.Register<Item> itemRegistryEvent) { itemRegistryEvent.getRegistry().registerAll( (Item)new BlockItem(test_block,new Item.Properties().group(ITEMTAB)).setRegistryName(test_block.getRegistryName()), new Item(new Item.Properties().group(ITEMTAB)).setRegistryName(ChickenMod.MODID,"test_item") ); } //Register Entities @SubscribeEvent public static void onEntitiesRegistry(final RegistryEvent.Register<EntityType<?>> entityRegistryEvent) { entityRegistryEvent.getRegistry().registerAll( EntityType.Builder.create(EntityProtoChicken::new,EntityClassification.MISC) .setShouldReceiveVelocityUpdates(true).setTrackingRange(24).setUpdateInterval(60) .build("protochicken").setRegistryName(MODID, "protochicken") ); } ...and this is where I register the renderer: private void doClientStuff(final FMLClientSetupEvent event) { // do something that can only be done on the client RenderingRegistry.registerEntityRenderingHandler(EntityProtoChicken.class,RenderProtoChicken :: new); } YMMV /p

I did finally find a fix for this by copying all my code into a new fresh project folder. I'm not sure what happened, but I had one previous gradle run produce an unusable project. [go figure]

I saw that the run configuration was correct and did not modify.

Here's what I found: It's somewhat generic and does seem to say what the issue is. The only other information seems to be from 2 lines above the EventBus.shutdown. I also checked the debug.log and didn't find anything useful there

This is where the application is crashing. I put a breakpoint at this location in the code [return mods.size();] and the debugger is telling me that 'mods' is null This would seem to imply that Forge hasn't find the mod, but I'm not sure where to go back to next. I should note this was running correctly under 1.13.2, so I thinks the structure of the mod is generally sound. I needed to rename some imports and classes, and the rendering classes needed type invocations.

I've been through it several times now, and checked the copy in the build folder to to be sure. I'm going to start disabling parts of my mod and see if that makes a difference.

I already updated mods.toml

Hello all, Im trying to port a simple mod which worked under 1.13. Minecraft bombs out at the title screen ("Rendering Screen") with a null pointer exception I read a couple threads with similar symptoms where the issue was the mods.toml file having the wrong version numbers, but I updated mine The latest.log file did not show anything, so I have resorted to posting the console output below, The top of it rolled out of the buffer, but crash is clearly visible My repository is here Thanks as always /Philip

net.minecraft.block.Blocks

is a generic exit code and doesn't say anything as to why Logs can be found in the runs\logs folder within your project Look there and post details of you want help.

That was the solution that worked for me. [solved] 1. Created an EnttyType<> object holder in my registry class @ObjectHolder(ChickenMod.MODID) public static class RegistryEvents { public static final EntityType<EntityProtoChicken> protochicken=null; ... 2. Created an Override of getType() which returns object holder in the Entity Class @Override public EntityType<?> getType() { return ChickenMod.RegistryEvents.protochicken; }

This would seem to be a problem because the EntityChicken constructor doesn't include the right overload (EntityType, World)