-
Notifications
You must be signed in to change notification settings - Fork 94
vp_limits
title: Entity Visual Properties: Item Limits description: published: true date: 2023-03-16T23:01:18.201Z tags: editor: markdown dateCreated: 2022-03-11T00:09:41.304Z
title: Entity Visual Properties: Item Limits description: published: true date: 2023-03-01T05:20:08.150Z tags: editor: markdown dateCreated: 2022-03-11T00:09:41.304Z
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.