Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Choonster

Forge Modder
  • Content Count

    5102
  • Joined

  • Last visited

  • Days Won

    75

Choonster last won the day on September 9 2020

Choonster had the most liked content!

Community Reputation

1652 Excellent

6 Followers

About Choonster

  • Rank
    Reality Controller

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Java doesn't have ref either, but does have tuples (from Minecraft and Apache Commons Lang).
  2. Thanks, I think that makes sense. I've tried to follow this advice and clean up all my DistExecutor code in this commit, does this look correct?
  3. I have a packet that's sent to the client to open a GUI, which I'm using DistExecutor to do. The packet's handler method does the following: DistExecutor.safeRunWhenOn(Dist.CLIENT, () -> ClientOnlyNetworkMethods.openClientScreen(message)) ClientOnlyNetworkMethods.openClientScreen currently looks like this: public static DistExecutor.SafeRunnable openClientScreen(final OpenClientScreenMessage message) { return new DistExecutor.SafeRunnable() { @Override public void run() { ClientScreenManager.openScreen(message.getId(), message.getAdditionalData(), Minec
  4. Yes, that probably would have been a useful feature. It's a shame that the author didn't have time to complete it.
  5. Part of the idea with my system was to allow syncing capabilities attached to arbitrary items, not just items that know about their capabilities. What would you recommend for capabilities attached to items from Vanilla or another mod?
  6. I've had a brief look at this and can't see any easy way to work around it, so I've created a suggestion thread for a change here: I'm not sure if it will go anywhere.
  7. I have a system for syncing item capability data that uses ICapabilityListener, as explained here: I discovered in that thread that this pull request for 1.12.2 back in 2017 partially broke my system by changing Container#detectAndSendChanges to only call IContainerListener#sendSlotContents if a slot's Item, count or share tag has changed; which often won't be the case for capability-only updates. The change does make sense for Vanilla IContainerListener implementations to reduce unnecessary network traffic, but would it be possible to allow modded IContainerListeners
  8. It looks like Forge patches Container#detectAndSendChanges to only call IContainerListener#sendSlotContents if a slot's Item, count or share tag has changed; which often won't be the case for capability-only updates. I may need to re-evaluate the IContainerListener system to see if there's any way around this. This change was actually introduced in August 2017 for 1.12.2, six months after I created my system. I thought it was working more recently than that, but I must not have tested it properly.
  9. With my system, each capability type that needs to be synced to the client has several sync-related classes: A single update network message (extending UpdateContainerCapabilityMessage) that syncs the capability data for a single slot of a Container. A bulk update network message (extending BulkUpdateContainerCapabilityMessage) that syncs the capability data for all slots of a Container. A "functions" class containing static methods used by both the single and bulk update messages. A container listener class (extending CapabilityContainerListener) that sends the singl
  10. The OP is asking about Vanilla loot conditions and functions, not global loot modifiers. I'm not 100% sure if it's the correct time to register them, but I do it on the main thread after FMLCommonSetupEvent (i.e. inside a lambda passed to event.enqueueWork). I use the Vanilla registries, just like in your example. I'm not sure if it's necessary to register non-Forge registry entries at any specific time like it is with Forge registry entries. This is my FMLCommonSetup handler, this is my LootConditionType registration and this is my LootFunctionTyp
  11. Thanks, I saw the Supplier overloads but didn't think to use them for lazy/deferred references. I realised after posting that my issue was actually with a SurfaceBuilder rather than a Feature (I could have moved the Feature registration since it wasn't being used in the Biome), but the same solution applies: use the Supplier overload instead of trying to pass the ConfiguredSurfaceBuilder directly. For future reference, I fixed the original issue and a few related worldgen registration issues with this commit. I decided not to go with the JSON route since my
  12. I'm trying to register a Biome with a Feature from my mod, but I'm having difficulty because Biome registration happens before Feature registration. This is the relevant registration code: Feature (DeferredRegister) Biome (DeferredRegister) ConfiguredFeature (Vanilla registry, called from here in RegistryEvent.Register<Biome> with HIGH priority to run before Biome DeferredRegister). The game crashes on startup because the ConfiguredFeature registration runs before the Feature has been registered: java.lang.NullPointerException: Regi
×
×
  • Create New...

Important Information

By using this site, you agree to our Privacy Policy.