vp_limits - ryzom/ryzomcore GitHub Wiki

---

player_visual_properties.h

---

SPropVisualC is rarely updated (char customization), B and A regular updated (equipment etc)

There is room to add 2 bits for four SkinColor possibilities in SPropVisualC

---

SPropVisualA is currently full, but contains the bits used for weapons and so on

There is still some room in SPropVisualB, so bits from A might have to be moved to B

Example -> WeaponRightHand : 10; // max: 1024 current: 457

---

Not sure what Sex (gender) is doing under SPropVisualA...

---

There are currently 17 bits remaining under SPropVisualB. It's also being used for 16 bits of Name, not sure how this works. Not sure what RTrail and LTrail are for.

Model limitations are 'JacketModel', 'TrouserModel', 'WeaponRightHand', 'WeaponLeftHand', 'ArmModel', 'HatModel', 'HandsModel', 'FeetModel'; 8 different model types.

Using all remaining bits allows us to double each model count, bringing us at

JacketModel: 1024

TrouserModel: 1024

WeaponRightHand: 4096

WeaponLeftHand: 1024

ArmModel: 1024

HatModel: 2048

HandsModel: 2048

FeetModel: 2048

Likely a lot can be shifted from armor over to weapons.

---

A more realistic estimate can push right hand weapons, which will likely be most popular to change, way up

JacketModel: 512

TrouserModel: 512

WeaponRightHand: 262144

WeaponLeftHand: 8192

ArmModel: 512

HatModel: 2048

HandsModel: 512

FeetModel: 512

---

Except WeaponRightHand and WeaponLeftHand are also in SAltLookProp! Which only has 2 bits left. It maybe necessary to split up SAltLookProp in the future. This seems possible, as there's also an SAltLookProp2 that was used for some stupid event...

---

Visual properties defined in entity_types.h

Two types of properties: continuous and discreet.

Continuous

• 0: PROPERTY_POSX
• 1: PROPERTY_POSY
• 2: PROPERTY_POSZ
• 3: PROPERTY_ORIENTATION

Discreet

• 4: PROPERTY_SHEET (This is the .creature sheet)
• 5: PROPERTY_BEHAVIOUR
• 6: PROPERTY_NAME_STRING_ID
• 7: PROPERTY_TARGET_ID (refers to other entity, how encoded?)
• 8: PROPERTY_MODE (contains a timestamp plus MBEHAV EMode; there can be 256 modes)
• 9: PROPERTY_VPA (these three propagated as visual property A B and C)
• 10: PROPERTY_VPB
• 11: PROPERTY_VPC
• 12: PROPERTY_ENTITY_MOUNTED_ID (refers to other entity)
• 13: PROPERTY_RIDER_ENTITY_ID (refers to other entity)
• 14: PROPERTY_CONTEXTUAL
• 15: PROPERTY_BARS (HP etc)
• 16: PROPERTY_TARGET_LIST_0 (related to projectiles it seems)
• 17: PROPERTY_TARGET_LIST_1
• 18: PROPERTY_TARGET_LIST_2
• 19: PROPERTY_TARGET_LIST_3
• 20: PROPERTY_GUILD_SYMBOL
• 21: PROPERTY_GUILD_NAME_ID
• 22: PROPERTY_VISUAL_FX
• 23: PROPERTY_EVENT_FACTION_ID
• 24: PROPERTY_PVP_MODE
• 25: PROPERTY_PVP_CLAN
• 26: PROPERTY_OWNER_PEOPLE
• 27: PROPERTY_OUTPOST_INFOS (what...)

Important, must add under getPropText et initThresholdTable etc when adding entity props.

---

Visual properties are in a tree, see TVPNodeBase.

This tree is hardcoded.

How does this work? See distance_prioritizer.h ln 246 etc

Essentially you make a tree, and for every PROPERTY you set which tree root needs to be updated, this implies simultaneous updates for specific nodes.

---

These properties are also propagated by _Mirror.getDataSet("fe_temp") etc

---

Bit sizes of the properties are registered under

void CActionSint64::registerNumericPropertiesRyzom()

in action_sint64.cpp

---

Also need to add under

arbitrateCreatureDiscreetProperties et al under distance_prioritizer.cpp

---

SAltLookProp is VPA when used with NPC which has armor defined under .creature sheet.

---