Skip to main content

Crate IDs — the serial printed on every box

Every hauling box, pallet and cargo box should be identifiable at a glance: crates live their own life and are never destroyed, so each one carries a unique ID printed on its faces (e.g. ARES-HAUL-8C44B2F9). This page explains where that ID comes from and how to add it to any crate.

Two Ares Hauling boxes in-game, each printed with its own id — ARES-HAUL-0FEC7731 and ARES-HAUL-8D2B2524

The ID is the prop's UUID (it already exists)​

Every networked prop — anything carrying a PropSync child node, see Writing a generic prop — and every Vehicle already has a UUID: generated on the server, persisted in the ScyllaDB items table, replicated to clients, and stable forever. That UUID is the crate's unique identity: reload the world and the same crate keeps the same id.

So the ID system does not invent a parallel identifier — it just makes that UUID visible, with a readable "company / type" prefix.

The serial shown on the crate​

The on-crate text is COMPANY-TYPE-UUID, for example ARES-HAUL-8c44b2f9-…:

  • id_company and id_type are two @export fields on the prop (defaults ARES / HAUL), set per scene in the Inspector — a pallet could be ARES / PAL.
  • The UUID is the real unique key. On a small face it is long, so id_short_display = true shows only its first block, uppercased (ARES-HAUL-8C44B2F9); the full UUID stays the identity.

The whole string is computed locally from the UUID, so there is no extra database column, no new network message and no service change — the crate already carries its UUID. The rule lives in one small class, PropSerial (scenes/globals/prop_serial.gd): format() builds the serial, fill() writes it on the frames. GenericProp.serial() and Vehicle.serial() both call it.

The serial lives on GenericProp, the UUID does not

The UUID comes from the PropSync child, so every networked prop has one whatever its body type. The printed serial — id_company, id_type, id_short_display, serial() and the label filling below — lives on GenericProp, which only RigidBody3D props extend. A shelf or a warehouse therefore has a perfectly good UUID and no printed serial: to give one a label, that short helper has to be inlined the same way its networking facade already is.

Displaying it: the prop_id_label group ("id-frames")​

To show the id, drop a Label3D node into the group prop_id_label somewhere in the scene — an "id-frame". GenericProp fills every node in that group with the serial as soon as the UUID arrives, so you can put one frame per face and they all show the same id.

The hauling box scene tree in Godot with five IdFrame Label3D nodes, and the Groups panel showing the selected frame belongs to the prop_id_label group

The group is the trigger — not the node name

Detection is is_in_group("prop_id_label"), not the node's name. Name your frames however you like (IdFrameFront, …); just make sure each one is in the group prop_id_label, or it will not be filled.

Adding IDs to a new crate​

  1. The prop's root script extends GenericProp — which requires a RigidBody3D root, and is where the serial lives. (A PropSync child gives it a UUID; GenericProp is what prints it.)
  2. Add one or more Label3D on the faces, each in the group prop_id_label, positioned and sized on the surface (non-billboard, oriented outward — one per face).
  3. Set id_company / id_type on the root (or keep the defaults), optionally id_short_display.

No code per scene. Two reference examples:

  • scenes/_universe/props/containers/hauling_box.tscn — 5 id-frames (front / back / left / right / top).
  • scenes/_universe/props/vehicles/engine_t1.tscn — a T1 motor, id_type = "ENG" with id_short_display = true on 2 faces. Not a crate: anything that is a carriable RigidBody3D prop can be serialised, and a part you fit into a vehicle benefits as much as a box.

An engine part on the ground, its serial ARES-ENG-B4D1151C printed on the top and on the side, each above the engine pictogram

The hauling box in the Godot viewport with an id-frame on each face, showing the ARES-HAUL-XXXXXXXX placeholder before runtime fills in the real id

Vehicles: the registration plate​

A vehicle carries the same serial, as a registration plate — the truck's reads ARES-TRUCK-C9FCA1B1. It is the same mechanism, not a second one: a Vehicle is a VehicleBody3D, so it cannot extend GenericProp, but both hand their uuid to PropSerial.

The back of the truck in game, a light plate on the tailgate reading ARES-TRUCK-C9FCA1B1

  • The plate is a Label3D in the group prop_id_label, in front of a light QuadMesh (the PlateRear node of truck.tscn, on the tailgate). Add another one in the group for a front plate.
  • id_company / id_type / id_short_display sit on the vehicle's root, in the Inspector group Registration plate (defaults ARES / TRUCK / short): a full uuid is far wider than a plate.
  • The plate is written when the uuid arrives — on a client that is before the vehicle enters the tree, so Vehicle fills it from its uuid setter and from _ready. A vehicle with no uuid (a bench scene) keeps the placeholder text ARES-TRUCK-XXXXXXXX.