Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add implicit angles #10

Open
mfaizsyahmi opened this issue Jan 30, 2024 · 1 comment
Open

add implicit angles #10

mfaizsyahmi opened this issue Jan 30, 2024 · 1 comment
Labels
enhancement New feature or request

Comments

@mfaizsyahmi
Copy link

mfaizsyahmi commented Jan 30, 2024

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.

@pwitvoet
Copy link
Owner

pwitvoet commented Feb 1, 2024

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...

@pwitvoet pwitvoet added the enhancement New feature or request label Feb 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants