desht

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.

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

I also wonder which MC version OP is using, given EntityLightningBolt doesn't exist in 1.14.4 or later...

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

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.

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.

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.

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

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.

Recipes go in data/<modid>/recipes/, not assets/<modid>/recipes/.

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).

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.

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.

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 )

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.

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.

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.

Ah, ok. What diesieben said, then

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.

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 which use the same particle data (they only vary in their texture) The particle data class: https://github.com/TeamPneumatic/pnc-repressurized/blob/1.14/src/main/java/me/desht/pneumaticcraft/client/particle/AirParticleData.java - this handles serialization/deserialization of the data the particle needs (in my case just a single float). I need to move this to under common/ since both the client and server need to know about it, but when I added this I didn't fully understand it The particle itself: https://github.com/TeamPneumatic/pnc-repressurized/blob/1.14/src/main/java/me/desht/pneumaticcraft/client/particle/AirParticle.java - this handles the rendering and ticking of the actual particle instances in the client world. Also includes a Factory inner class, which will be used to create particle instances from the particle type. Registering the particle factories: https://github.com/TeamPneumatic/pnc-repressurized/blob/1.14/src/main/java/me/desht/pneumaticcraft/client/ClientSetup.java#L43-L47 And finally the particle JSON's: https://github.com/TeamPneumatic/pnc-repressurized/tree/1.14/src/main/resources/assets/pneumaticcraft/particles For lots more useful info, also see https://gist.github.com/williewillus/353c872bcf1a6ace9921189f6100d09a#particles

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

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.

(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).

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?

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.