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

desht

Members
  • Content Count

    244
  • Joined

  • Last visited

  • Days Won

    13

Posts posted by desht

  1. Expanding on this:

    • If you intend for your capability to ever be used by other mods (i.e. you're making it part of your mod's API) then using an interface is very strongly advised, simply as good programming practice (expose the interface, not the implementation).
    • If you only ever intend for your capability to be used for storing data for your own purposes, an interface is very much optional.  You might decide it's useful to have one, just for tidiness in your own code, but then again you're free just to use a class.

     

    • Like 1
    • Thanks 1
  2. Vanilla buckets know nothing about a modded block whose tile entity offers a fluid capability.  You need to code the bucket-filling logic in your block's onBlockActivated() method.  Tip: don't just check for a bucket, check for any item which offers the CapabilityFluidHandler.FLUID_HANDLER_ITEM_CAPABILITY, since that would also allow other mod fluids containers (tanks etc.) to be filled from your block.

  3. Yeah, I had this problem too in PneumaticCraft, but (with much thanks to Botania, which does it right with the mana pool particles), I got it figured out:

     

    You will need a custom particle render type, like this: https://github.com/TeamPneumatic/pnc-repressurized/blob/1.15/src/main/java/me/desht/pneumaticcraft/client/particle/AirParticle.java#L91

     

    And return that from your getParticleType() method: https://github.com/TeamPneumatic/pnc-repressurized/blob/1.15/src/main/java/me/desht/pneumaticcraft/client/particle/AirParticle.java#L71

     

    The important thing is the alternative GL blend function (GL11.GL_SRC_ALPHA, GL11.GL_ONE), and GL_GREATER rather GL_EQUAL in the alpha func.

     

    Update: just realised you're already using GL_ONE in a custom render type.  Have you also provided the finishRender() method in your render type?

  4. 15 hours ago, Alex Sim said:

     

    Wow that's an unnecessarily complicated change

     

    Thank god I can use Kotlin extension properties... And I'm already using reflection for registration ?

    A little more complicated, but not unnecessary.  It's down to how 1.15 handles rendering, basically by combining all operations for particular render type together, which greatly reduces the number of OpenGL state changes needed.  It's a big performance boost.

  5. 12 hours ago, HappyHippo77 said:

    Thanks for the help! Also, regarding this ^, I figured that would be it, but I do wonder how that ties in to the fact that that mod is dead (and seemingly, so too is the creator). Who would be the one to call me out if I did reproduce it? I am copying the textures from the mod to use in the recreation, but I'm actively acknowledging that they are Emoniph's creation, not mine.

     

    Is there somewhere where I can look at the specifics behind the license and everything for Witchery?

    Emoniph's whereabouts are unknown, as far as anyone can tell.  Not necessarily dead, but not reachable.  Unfortunately, just because the mod hasn't been updated, and the author can't be reached, that doesn't give you the right to use any of the assets, even with acknowledgementThe mod's licence very explicitly forbids that.  As for repercussions... well, you might or might not get a C&D notice, but I can pretty much guarantee that Curseforge (and probably other platforms) won't host it.  Someone else ported the mod to 1.12.2 not along ago, and posted an announcement to the feedthebeast reddit, and got deleted with 24 hours.  Maybe your efforts would be better spent contributing to Bewitchment, a spiritual successor which doesn't use any of the original mod's assets?

  6. JSON models don't support arbitrary rotations, only increments of 22.5 degrees on one axis.  See https://minecraft.gamepedia.com/Model#Block_models for a detailed description of the format (note the "angle" tag that elements have).  If you need something more flexible, an OBJ model is probably your best bet. I don't know offhand how Witchery did it - might even have been a TESR, though using a TESR for static models isn't a good idea.

     

    Regarding the legality of recreating Witchery: there's nothing to stop you using the code or assets privately, for just "practice".  But you cannot publish anything containing any code or assets from that project, since it's not open-source.  And you can't call anything you release "Witchery" either.

  7. Another useful Intellij shortcut here is Ctrl-N, the default binding for Navigate -> Class...

    Press Ctrl-N and type in the name, or part of the name, of the class you want to find (in this case TorchBlock). You might also need to press Ctrl-N a second time, to toggle on the "include non-project items" checkbox, since TorchBlock isn't part of your own project.  This works for any class known to your project, including all those in external libraries like Forge and (deobfuscated) vanilla code.

  8. Yeah, I think you're right that CookingRecipeSerializer.IFactory needs to be public to be able to extend it in any useful way.  I'd say a PR to Forge is needed there (just an AT entry to make IFactory public, so pretty simple).

     

    You do need to move away from statically creating your recipe type and serializer objects, though, same as for any other registry object.

  9. I haven't done anything with cooking recipes specifically, but all vanilla recipe serializers are now Forge registry objects.  So registering your own serializer is now done like any other registry object - either via RegistryEvent.Register<CookingRecipeSerializer> and @ObjectHolder, or (preferably) using the new deferred registry system.

     

    So it should (like I said, I haven't tried this with cooking recipes, only crafting recipes) be possible to register your custom cooking recipes with a registry name of (say) "mymod:my_recipe", and then have a recipe JSON in your data/recipes looking like:

    {
      "type": "mymod:my_recipe"
    }

     

    For an example of how I register custom crafting recipes, see https://github.com/TeamPneumatic/pnc-repressurized/blob/1.14/src/main/java/me/desht/pneumaticcraft/common/core/ModRecipes.java

     

  10. Regarding "unnecessary lag": if the sole reason for a tile entity is for rendering, your TE does not need to tick and thus won't produce any lag.

     

    Technically, the presence of any tile entities in a chunk mean a little more work to load the chunk, but if you have enough instances of your TE in a chunk to cause loading performance issues, then you probably also have enough to murder client performance with all the rendering that's going on.

     

    tl;dr non-ticking tile entities produce zero lag unless you grossly abuse the feature.

    • Like 1
    • Thanks 1
  11. 15 hours ago, DragonITA said:

    @desht, wow, thanks a lot! I simply cant see the Vanilla code, but thank for your help!

    If you can't view vanilla code from your IDE, get that fixed ASAP. It's absolutely critical to be able to see how vanilla and Forge code does stuff, not to mention being able to set debugging breakpoints. 

    • Like 1
  12. Have you looked at how vanilla animals (e.g. pig or sheep) do it?

     

    Mob entities (which include animals) have goals, which are registered and run by the entity's GoalSelector object.  Every mob entity has a goal selector, which is public, and the goal selector has a getRunningGoals() method to get all of the currently-active goals.  Take a look at e.g. PigEntity and find the obviously-named goal which controls panic behaviour. That should be all the info you need.

     

    It might actually be simpler just to check that the animal has a non-null getRevengeTarget()... depends on how much control you want over the process.  An animal can have a revenge target but not have a running panic goal if it can't find somewhere to flee to, for example.

    • Thanks 1
  13. Hard to know for sure without seeing your code, but I'm guessing you're doing the "consume" operation client-side, and that's not to going to work.

     

    When the button is clicked, the server needs to know; in other words, send a custom "this button was clicked" packet to the server, and do the inventory change there.  Changes don't get magically sent to the server if you modify a slot client-side; if you look at vanilla code, you'll see packets are used to handle this (take a look at PlayerController#windowClick() for example - modifying the container slot and sending a packet to the server are done separately).

  14. On 2/7/2020 at 6:08 PM, cat ote said:

    but how should i do that? the fleegoal is located inside the original squid ai, and i cant edit the original squid ai.

    As Cadiboo pointed out, you're not editing the original AI - you're editing the AI in your subclass, which inherits the original AI.

     

    SquidEntity.FleeGoal itself has a private constructor, so you'd need to use reflection to access it.  But if you simply want to get rid of it, the cleanest way is probably to override SquidEntity#registerGoals() to simply not add the FleeGoal in the first place. The base registration method also adds a SquidEntity.MoveRandomGoal, which you may or may not want to keep.  If you do, it's conveniently public.

×
×
  • Create New...

Important Information

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