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

Everything posted by desht

  1. 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 enti
  2. 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. I also wonder which MC version OP is using, given EntityLightningBolt doesn't exist in 1.14.4 or later...
  4. 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 registr
  5. 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.
  6. 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.
  7. 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.
  8. 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/pneum
  9. 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.
  10. Recipes go in data/<modid>/recipes/, not assets/<modid>/recipes/.
  11. 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
  12. 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 par
  13. To be fair, McJty's tutorials are pretty good, although they're for 1.14.4. But, 1.15 rendering changes aside, they should work pretty well for 1.15.
  14. 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 wr
  15. 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.
  16. 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.
  17. 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.
  18. 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.
  19. 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: Registering the particle types: https://github.com/TeamPneumatic/pnc-repressurized/blob/1.14/src/main/java/me/desht/pneumaticcraft/common/core/ModParticleTypes.java - note I register two particle types whic
  20. Just for a bit of extra reference, McJty did a tutorial episode on this recently: https://wiki.mcjty.eu/modding/index.php?title=Tut14_Ep9
  21. 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).
  22. (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,
  23. No, this forum does not just "type you code". You haven't actually stated what you're trying to achieve, so how could anyone possibly tell you what to type? Why can't you just refer to the original source code? Do you have permission to republish this deobf'd code?
  24. 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 Privacy Policy.