You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
on some not very rare cases an entity might be missing the angles property and that breaks expressions that read it or its component e.g. angles.yaw.
my suggestion is to always have implicit default value for angles of 0 0 0. This is what the game engine already does in a way, both origin and angles are implicitly 0 0 0 if absent.
The text was updated successfully, but these errors were encountered:
Properties like origin, angles and scale are indeed special, but I'm a bit hesitant about automatically inserting them because of possible unintended side-effects. For example, the get_attr function should still return the actual parent entity properties, excluding any special properties that were automatically added. I'll have to think about this some more.
But another thing is that, in my vision, a robust template entity should take into account that any property may be missing or have an invalid value. In a local template, properties can be added to the macro_template entity, and those properties are then available to entities within that template, so that's a good place to list all the properties that the template expects and to set default values for them. In a template map, the map properties serve the same purpose, but you can also use a single macro_insert at the center of the map for the same purpose.
In this case, that would mean adding an angles key to the template map properties, with a value like {angles || [0, 0, 0]}.
This could also be made more user-friendly by throwing an error if angles doesn't have a valid value, although that does make it more complicated: {angles ? assert(is_array(angles) && angles.length == 3 && angles.all(is_num), 'angles must be an array of 3 numbers') && angles : [0, 0, 0]}. Maybe I should add a utility function like bool is_angles(any value) to make that easier.
Another approach would be a type annotations system for entity properties. For example, marking angles as none|vector3 would trigger an automatic type-check that verifies that angles is either none or an array with 3 numbers. Maybe something for later - a higher-level entity definition format with proper type annotations and rewrite rules that can be used to generate various .fgd dialects...
on some not very rare cases an entity might be missing the
angles
property and that breaks expressions that read it or its component e.g.angles.yaw
.my suggestion is to always have implicit default value for angles of
0 0 0
. This is what the game engine already does in a way, bothorigin
andangles
are implicitly0 0 0
if absent.The text was updated successfully, but these errors were encountered: