• Recently Browsing

    No registered users viewing this page.

  • Posts

    • I Installed forge on http://files.minecraftforge.net/ like you said above, when I ran the .jar as an administration. Then I told it to install the client. Finally, it asked if I wanted to allow it to make changes to my device and I said yes so that it would complete. I used Twitch to open the minecraft launcher because I wanted to play RLcraft.  Here's the screen shot of what the launcher looks like when I pressed the button in Twitch which said 'play' underneath the RLcraft picture:  
    • Howdy   I'd suggest your entity unloading is the way to go - perhaps Entity.remove() or Entity.onRemovedFromWorld() override, perhaps you can mark the Entity in some way to kill it permanently, and respawn a new one to emerge from the hive.  Or after the entity unloads your hive block could track a virtual bee for a while and then respawn it with some logic to make it head towards the hive for a while.   I'm not sure that there is an "unload event", but perhaps PlayerEvent.StopTracking will work how you need.   I think the only way to make it truly seamless is to have a central bee controller instance which comes into existence whenever a hive or one of its bees loads.  Every few server ticks, the bee controller reviews its list of virtual bees, calculates their movement and location, and spawns or despawns them as necessary within a given radius of the player (eg the render distance). Might not be worth the effort from a gameplay point of view.   -TGG        
    • Do you know what's wrong with it?  It looks like it should work fine.  I use the same recipe format in one of my mods with such problem.   Do you have a link for how to use datagenerators?   -TGG    
    • As the Optional annotation has now disappeared in favour of capabilities, there is now no way to add optional features to non-TileEntity blocks. An example use case would be proper fluid handling for vanilla cauldrons, or handling of different blocks' "heat" values.   It would have to return a function (BlockState, IWorldReader) -> custom capability instance. And couldn't be cached without more work. The capability would also not be able to be serialisable to NBT (obviously non-TEs don't have NBT).   It would effectively be a mapping of blockstate -> capability. If we restricted it to readonly capabilities there would be no issues with modders caching the capability and modifying something they shouldn't, but it would for example allow extraction from cauldrons, but not insertion. The optimum solution would be for the capabilities to be cached when first accessed (Probably by calling World/Chunk#getBlockCapability(Capability, BlockPos)) which would then be returned every time afterwards (until the position was unloaded).   It would allow ModB to support ModA's X system, without having to inherit from an API which may not exist at runtime.   This post is intended as the starting point of a discussion, if it is an idea that no-one is interested in, that is fine. The alternative is to just ship ModA's API with ModB, or at least the interfaces you are implementing in your block, but that has no way of adding capabilities to blocks which you don't own (e.g. vanilla cauldrons, torches).
  • Topics

  • Who's Online (See full list)