Creating Vehicle Entities

[thick totem]

I'm relatively new to Minecraft as a development target (did a mixin for elyta flying a few months back) and now looking to implement a rideable entity akin to a boat or minecart. The wiki has gotten me as far as an entity I can spawn that has a shadow and hitbox, but I can't seem to get it to render for the life of me.

I'm probably missing something stupid here, but the available reference material only deals with entities deriving from LivingEntity. I am looking to derive from VehicleEntity as the boat and minecart do. The wiki mentions that doing this requires implementing a spawn packet handler, but I'm not sure what that would entail, or if it could be responsible for my rendering problem. Since I am seeing a shadow, I'm pretty sure it isn't. It would be nice to be sure though so I can cross that bridge when I get to it.

Any direction on this rendering issue, and on VehicleEntities or entities in general would be much appreciated.

Code found here, apologies for the random commented blocks; still trying to figure out how to actually work with minecraft. This is being done with split sources, if it matters:
https://github.com/DecoFox/DynaSoar

[thick totem]

Alright, I've gotten this to work. Summarizing here for the benefit of posterity

I arrived at this by throwing everything out and starting over, working entirely from the wiki entry for entities, including the use of PathAwareEntity, MobRenderer, etc

Getting that to work was fairly trivial

I then went back through and swapped my entity to a VehicleEntity, and made adjustments to the Renderer, Model, and initializer until I had worked the errors out, paying reference to the boat and minecart.

The crux of my problem came from not fully understanding how Renderers worked, which I had suspected might be the case. If you're following the wiki, you'll notice that MobEntityRenderer accepts the model as an argument, and that's all there is to it. But The same cannot be said for EntityRenderer, VehicleEntityRenderer, etc. They only refer to context.

At first I tried to figure out what Minecart was doing instead, but got lost. The answer was actually there, but I didn't know what I was looking for.

The way I actually found the answer was by stripping through MobEntityRenderer's superclasses. It turns out that the model argument is eventually found as a field in LivingEntityRenderer, but, paradoxically, EntitityRenderers are not responsible for actually rendering entities. Rendering is actually a feature of the model class itself. All EntityRenderers do (with respect to literal rendering) is invoke .render() from the model class.

So, if you're working with a Renderer subclass type that doesn't take a model argument, you have to call .render() on your model from your Renderer's own render() function rather than passing to a super

[thick totem]

>So why is any of this like this?
Entity classes were designed to be very scalable, and, outside of the mob family, are actually quite low-level.

It makes a lot more sense when you consider the respective behavior of the boat and minecart. If you rotate a boat with A or D, the boat rotates, and so do you, the player. If a minecart rotates on a track, the minecart appears to rotate, but you, the player, do not. This is possible because Boat and Minecart implement model.render() very differently.

At a glance, they look similar: a bunch of matrix math is performed, and then the resulting transformation is passed to the model.render() function. If you read the matrix transformations though, you'll see the minecart does quite a bit more work than the boat does. Both implement wobble for things like damage, but the minecart goes on to also implement a bunch of rotation math for attaching to rails, ascending and descending, yawing, etc. This is because, while a minecart is moving on a track, the actual minecart entity does not rotate. This is why your view direction remains free. Instead, only the model of the minecart is rotated. The boat, however, implements model.render() (or, in this case, CompositeEntityModel.render()) very directly. The boat entity itself rotates, so the boat model need not rotate on top of it. This is why your view does turn with a boat.

The philosophy here is that Renderer classes are basically a framework for relaying the render event to models. It makes sense to do it this way because you might want different entities to render in very different ways, like the boat and minecart do. It's actually pretty simple when you figure out how the "chain of custody" for models works.