Jump to content

desht

Members
  • Posts

    244
  • Joined

  • Last visited

  • Days Won

    13

Posts posted by desht

  1. 2 hours ago, Cadiboo said:

    I would do this by extending the squid and adding an AI task that swims towards a "target". I would also override the update method and periodically recalculate that target. I have no experience with AIs, so I'm not sure if that's the tight approach, but that's what I would start off with. If you keep checking my example mod, I'm planning on adding an AI that charges at players to my Wild Boar as soon as I get some spare time.

    Pretty much, but one important point: mobs actually have two different goal types (NB: in 1.14+, "entity AI" objects are referred to as "goals") - a main goal, and a target selection goal.  Check out MobEntity, and a subclass method such as ZombieEntity#applyEntityAI(); you'll see separate types of goals for choosing a target, and actually doing stuff in-world.

    So in the case of this custom squid, one approach would be a subclass of the vanilla squid with a targeting goal to find nearby boats or players (NearestAttackableTargetGoal won't quite work here since it only works for living entities which excludes boats), and another goal to make the squid move toward its target and attack it when in melee range (should be possible to extend MeleeAttackGoal for that, but no promises...). You'll probably also want to remove the squid's FleeGoal too if this is meant to be a hostile entity.

  2. 19 hours ago, Blazer Nitrox said:

    Hunh, well I'll be. It also turned out that I didn't need the `data` fields (which I suspected but couldn't prove).

    If you need proof, look at ShapedRecipe#deserializeItem(), where the "data" field is explicitly disallowed.

     

    This is due to the Flattening: item and block data is no longer a thing as of Minecraft 1.13 (which is great).  See https://gist.github.com/williewillus/353c872bcf1a6ace9921189f6100d09a#whats-the-deal-with-metadata

  3. Assuming https://github.com/DragonGamerDevelopers/NewFantasyMod-1.15.1/blob/master/src/main/java/mod/dragonita/fantasymod/init/ModItems.java is your up to date code producing that error, then it's wrong.  You're registering your entity type directly in the (vanilla) minecraft Registry in a class constructor which is called before any registration is happening.  That's always going to fail, and you should never be touching the vanilla registry directly.

     

    Entity types work with DeferredRegister just like any other Forge registry entry.  As an example, see PneumaticCraft entity registration here, which works fine: https://github.com/TeamPneumatic/pnc-repressurized/blob/1.14/src/main/java/me/desht/pneumaticcraft/common/core/ModEntities.java

    • Like 1
  4. 2 minutes ago, DJ1TJOO said:

    So my model is against a wall so I should put it on the west or east side correct? Instead of on the north side

    Again, don't know what you mean. Why would it being against a wall have any effect on anything?  Just have the model face north or south.

  5. Another useful example is any vanilla rotatable block (furnace/dispenser/etc.).  If you inspect the models for those in your IDE, you'll see they all ultimately use block/cube, and block/cube defines the #front texture as the north face of the (unrotated) block.

  6. 1 minute ago, DJ1TJOO said:

    how do I unrotate the z axsis?

    No clue what you mean by that, sorry.

     

    Edit: if you're referring to the "unrotated model" I mentioned, what I mean by that is the model data as loaded from JSON, or OBJ, or wherever.  Have the default facing be along the Z axis, and you can get all six orientations with one rotation about X or Y.

  7. Vanilla blockstates don't allow a rotation around the Z axis at all.  It's doable with Forge blockstates, but you should avoid using those in 1.14.4, and you can't use them at all in 1.15.x.

     

    As for a rotation around the Z axis: you actually don't need it, as long as your unrotated model faces along the Z axis (i.e. the default facing is either north or south).  If that's the case, you can get any of the six rotations with a single rotation around either the X or Y axis.

     

    Example: https://github.com/TeamPneumatic/pnc-repressurized/blob/1.14/src/main/resources/assets/pneumaticcraft/blockstates/aphorism_tile.json

  8. 9 minutes ago, DragonITA said:

    Okay, thanks a lot. This should be the last question, do I have to register it before the items or after? To understand what I mean please look at Github.

    If you're using DeferredRegister, it really doesn't matter; just make sure you register in your constructor, i.e. before any registry events are fired.  Forge will make sure everything's done in the right order.  If you've been paying attention, you'll have noticed that DeferredRegister does everything via Suppliers, so it's all lazy - nothing's actually initialized until the events are fired.

    • Like 1
  9. The basic entity size (width and height) is defined when you create the EntityType registry object (example).  This was also the case in 1.12.2, and hasn't really changed.

     

    This width & height is used to set up the entity's bounding box in Entity#setPosition(), which is used for the vast majority of entities (other than paintings, picture frames, leash knots and shulkers, which have their own setPosition() implementations).  This bounding box is centred on the entity's X/Z position, with the Y position at the bottom of the bounding box (e.g. your player bounding box is centered horizontally at your feet, on the ground).

    • Like 2
  10. Nice write-up!  That mysterious final int parameter to the PointOfInterestType#register() call you mentioned is related to pathfinding - I actually encountered this from the other side when porting PneumaticCraft's drone pathfinding to 1.14.  As I understand it, it's passed to Path#getPathToPos() and shortens the returned path by that number of blocks, so at a guess would make the villager move to a position that is 1 block away (by default) from the POI.

     

    I suppose if a modded villager had a point of interest which was part of a big multiblock structure, you could increase that parameter so the villager doesn't try to navigate into any other parts of the structure.

  11. 3 hours ago, diesieben07 said:

    The docs site is great, but it does need 1.14 and/or 1.15 branches to be created.  1.13.x is basically dead now, and 1.12 is no longer supported.  This was even mentioned in a recent pull request: https://github.com/MinecraftForge/Documentation/pull/239

     

    On the same topic, even though there are a few recent pull requests, the last commit to 1.13.x was 5 months ago.  I'm not having a dig at anyone here - I know everyone has busy lives - but it does suggest that the docs site could benefit from one or more dedicated maintainers.

     

    (Hey, once a 1.14 branch is created, I'll write up pages on particles and container/gui registration :) )

    • Like 1
  12. 13 hours ago, Kenneth201998 said:

    This thing of getting the progress bar to update still eludes me. Know any example code? 

    I will refer you to my previous comment in this thread.  Go and look up McJty's tutorial that I linked (although it's for syncing an energy value, the same principle of syncing an int value applies).  And also take a look at the vanilla furnace code, which uses that tracked int system.

  13. You do not need to be messing with events at all.

     

    Firstly, I'd recommend using SoundType.CROPS rather than SoundType.PLANTS.  It's a more appropriate sound type.

     

    Secondly, overriding onBlockHarvested is the wrong way to do this, and is the reason why you are hearing nothing.  That method is responsible for playing the block-break effect (sound and particles).  It's not responsible for dropping items and you shouldn't abuse it in this way.

     

    You shouldn't be hard-coding your block drop logic in 1.14.4.  It should be done in a JSON loot table for the block now.  Look at the vanilla loot tables (e.g. data/minecraft/loot_tables/blocks/beetroots.json) for an example, bearing in mind that modded loot pools also need a "name" field with some unique name for the loot pool.

    • Thanks 1
  14. Just to note, for simple data like an integer progress value, you can take advantage of the vanilla Container#trackInt() method to automatically sync values from server to client while the container is open.  The vanilla furnace uses it, and McJty has a tutorial about it here: https://wiki.mcjty.eu/modding/index.php?title=Tut14_Ep5 ("Showing Energy in GUI").

     

    But beware - despite the method's name, it will only sync up to 16 bits of data - see SWindowPropertyPacket.  Shouldn't be a problem in this case, however.

    • Thanks 1
  15. 2 minutes ago, StefanDeSterke said:

    Ok, but since I don't have a tileentity class, where would I implement INamedContainerProvider? (I don't have one because I don't need to store inv data to the block)

    Er, what are those slots in your GUI in your very first post for, if not for displaying your block's inventory?  You need a tile entity and there is absolutely no way around that.

  16. There is in fact a such a mod now: https://github.com/TeamPneumatic/pnc-repressurized/tree/1.14

     

    I will say first that the mod is in an extremely broken state right now (I only got it to compile a few days ago), but particles do actually work.  I added an air particle type which takes one float parameter controlling the particle's rendering alpha.  See the following:

     

    For lots more useful info, also see https://gist.github.com/williewillus/353c872bcf1a6ace9921189f6100d09a#particles

     

  17. 16 hours ago, Simon_kungen said:

    The EnumFacing.UP is most likely the one I need as you mentioned, but I have no idea in what context. In your code, you use a class getTanksToRender with a function including a BitSet object, which I do not know is used for

    The TankRenderInfo class just tells the rendering code where the tanks are in the model and which faces of the fluid AABB to render.  That bitset is just a compact way of storing which of the 6 faces need to be rendered; the FastFluidTESR class is abstract and implemented by the renderers for various tile entities, each of which have differing rendering requirements (e.g. some only need to render the top face of the fluid, some need to render the sides too since the block model has transparent sides, and some have multiple tanks to render, like the Refinery with both an input and output tank).  You don't really need that extra code if you're only ever planning to render the top face of the fluid.

    • Thanks 1
  18. (I'm the author of the code in PneumaticCraft: Repressurized).

     

    I think where you're going wrong here is order of quad definitions.  It looks like you're trying to render the top face of the block, right?  (And skipping the others because they aren't visible in your block).  So, looking at my code for EnumFacing.UP, the vertex order goes:

    • minX, maxZ
    • maxX, maxZ
    • maxX, minZ
    • minX, minZ

    ... which is not the order you're using.  The vertex order is vitally important, and should wind clockwise if you're looking at the face from the outside (e.g. for the UP face, when you're facing downward).  Get the order wrong and the quad will look screwy.  The same applies to the UV coordinates; they also have to wind in the same way.

     

    Finally, you probably do need to light the quad; the PNC:R code shows you how (with the .lightmap() method).

  19. Fluids are indeed very much changed in 1.13+ vanilla; Forge didn't remove the modded support on a whim.

     

    Fluids are now full-on registry entries with support for tags, like items or blocks (or nearly everything else in 1.14), and on top of that we now have blocks able to hold both a BlockState and a FluidState (which is how 1.13+ allows for waterlogged blocks).  Needless to say, it's all really really different internally.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.