ObjectProperties

Introduction

To customize your vehicles by adding a key, license plate, or even a radio, you need to add what are called properties to your objects. Here's how to do it.

Tip

It is strongly recommended to read the introduction to pack creation to understand how the DynamX loader works.

Adding Properties to Objects (Vehicles, Wheels...)

Adding Your Class Containing Custom Properties

Danger

This part is not up to date for version 4.0.0. It will be updated soon.

These properties are grouped in SubInfoType and are loaded by reading the configuration files of various objects (vehicles, engines, wheels, etc.).

You need to create a class implementing ISubInfoType<T> where T is the type of object that will have the new properties (see below for a list).

Your preferred IDE will then ask you to implement the appendTo(T owner) function, which should add the properties to the object (usually owner.addSubProperty(this)).

To register your SubInfoType, you will need to use the SubInfoTypesRegistry. Here is an example of how to use it:

DynamXObjectLoaders.WHEELED_VEHICLES.getSubInfoTypesRegistry().addSubInfoType(new SubInfoTypeEntry<>("wheel", PartWheel::new, false));

DynamXObjectLoaders.WHEELED_VEHICLES is the loader for vehicles, to which the wheel loader is added. Many other loaders are available in the DynamXObjectLoaders class; it's up to you to see which one you need. Only "ITEMS" and "SOUNDS" loaders do not accept SubInfoType.

The "true" parameter in the SubInfoTypeEntry allows any name in the configuration file, as long as it starts with "wheel", which corresponds to this configuration code:

WheelFrontLeft{
   //Propriétés à mettre ici
}

Tip

Know that it is possible to create your own registry; objects must implement ISubInfoTypeOwner.

Adding Properties to Your Class

You can add as many fields as you want to your class, and you must annotate them all with the @PackFileProperty annotation. Here's an example:

@PackFileProperty(configNames = "RotationPoint", required = false, type = DefinitionType.DynamXDefinitionTypes.VECTOR3F_INVERSED_Y)
private Vector3f rotationPoint;

Variable	Description
configNames	Name of the property in the configuration file
required	Optional, defaults to true. Marks the property as required and displays an error if it is not provided
type	Optional, the type is automatically detected except for Vector3f. The list of types is available in DynamXDefinitionTypes

Other properties exist; see the code and javadoc for more details.

There are other possibilities with the DynamX loader to discover on your own.

Using These Properties in Events

All events are called on the Forge event bus.

They are called on different "sides": "server side" events are always called on the server side, "client side" events are always called on the client side. "Simulation side" events are called on the server side if you are in single-player mode and on both the server and client sides when in multiplayer. "Simulation thread side" events are on the same sides but can be called in a different thread than the main one.

Here is the list:

Name	Side	Description	Cancellable
ContentPackSystemEvent.ContentPackLoadEvent	Common	Called before (PRE phase) and after (POST phase) loading or reloading packs.	No
PhysicsEvent.PhysicsEntityAddedEvent	Simulation thread	Called when an entity is added to the physical world.	No
PhysicsEvent.PhysicsEntityRemovedEvent	Simulation thread	Called when an entity is removed from the physical world.	No
PhysicsEvent.StepSimulationEvent	Simulation thread	Called on every physical world update, every tick of the game.	No
PhysicsEvent.PhysicsWorldLoad	Simulation	Called when the physical world is created, when a Minecraft world is created.	No
PhysicsEvent.ChunkCollisionsStateEvent	Simulation thread	Called when the collision state of a chunk changes, allowing, for example, to add or remove collisions to a chunk.	No
VehicleEntityEvent.VehicleInteractEntityEvent	Server	Called when a player interacts with an element of a vehicle.	Yes
PhysicsEntityEvent.AttackedEvent	Server	Called when a physical entity (car, prop) is damaged by a player. If the event is not canceled and the player has an item to destroy the entity, it is destroyed immediately.	Yes
VehicleEntityEvent.MountVehicleEntityEvent	Common	Called when a player mounts a seat.	No
VehicleEntityEvent.DismountVehicleEntityEvent	Common	Called when a player dismounts a seat.	No
PhysicsEntityEvent.PhysicsEntityUpdateEvent	Common and Simulation thread	Called on each update of a physical entity. There are two types of updates: update on the Minecraft thread: PhysicsEntityUpdateType.POST_ENTITY_UPDATE and update on the physical thread: PhysicsEntityUpdateType.POST_PHYSICS_UPDATE. ServerPhysicsEntityUpdateEvent: Server-side variant. ClientPhysicsEntityUpdateEvent: Client-side variant.	No
PhysicsEntityEvent.PhysicsEntityInitEvent	Common	Called after the initialization of a physical entity (pack information and physics if enabled on this side).	No
VehicleEntityEvent.SaveVehicleEntityNBT	Server	Called when a vehicle is saved.	No
VehicleEntityEvent.LoadVehicleEntityNBT	Server	Called when a vehicle is loaded.	No
VehicleEntityEvent.RenderCarEntityEvent	Client	Called when a car is rendered, before and after rendering for the chassis, wheels, parts, and particles. Called after the debug rendering of a car (POST phase).	Yes
VehicleEntityEvent.DrawVehicleEntityHUD OUTDATED	Client	Called when a vehicle's HUD is rendered.	Yes
VehicleEntityEvent.UpdateVehicleSoundEntityEvent	Client	Called when the engine sounds of a vehicle are updated.	Yes
Modules TODO

Using These Properties in Entities: Module System

There are two types of entities in DynamX: vehicles and props.

Vehicles, inheriting from ModularPhysicsEntity, work in a modular way. Currently, three types of modules are implemented, but it's easy to add your own. The entity class must implement IHave<NomDuModule> and add its modules in the createModules function. See CarEntity or TrailerEntity for examples. To modify an entity's modules, you can use the CreateVehicleModulesEvent. Modules must implement the IPhysicsModule interface, which provides functions called by ModularPhysicsEntity. Some modules also have another interface to implement, see below. Modules related to physics must also have a "PhysicsHandler" that links to the physics engine. This PhysicsHandler can only be created if the client (or server) simulates the physics itself (not in single-player mode, for example), in the initPhysicsEntity function of the module.

Modules Implemented in the Mod

These basic modules can be added to any ModularPhysicsEntity, and their synchronization is automatically