'angle' property from trenchbroom not used for scenes instanced from point classes

[gRichardson108]

I noticed that 'angle' wasn't being parsed in qodot_map.gd for my scenes instanced by QodotFGDPointClass instances. I had to add some code to get it working on my end like this:

func build_entity_nodes() -> Array:
    # ... snipped to line 449 ...
    # existing code for processing origin
    if 'origin' in properties:
        var origin_comps = properties['origin'].split(' ')
        var origin_vec = Vector3(origin_comps[1].to_float(), origin_comps[2].to_float(), origin_comps[0].to_float())
        node.translation = origin_vec / inverse_scale_factor
    else:
        if entity_idx != 0:
            node.translation = entity_dict['center'] / inverse_scale_factor

    # new code for processing angle
    # note that angle 0 in trenchbroom seems to be angle 90 in godot?
    if 'angle' in properties:
        node.rotation_degrees = Vector3(0, properties['angle'].to_float() - 90, 0)
    else:
        # must specify for default value of 0, because there's no 'angle' key
        node.rotation_degrees = Vector3(0, -90, 0)

    entity_nodes.append(node)

    if should_add_child:
        queue_add_child(self, node)

    return entity_nodes

Sorry this isn't just a pull request. I wanted to document before I forget about it. I'm wondering if I'm nuts and missing something, or if nobody really uses point classes enough in a way that the rotation matters?

[Shfty]

The idiomatic way to do this is by having a tool script assigned to your point class, having it read the angle property at build time (i.e. in the setter for an exported properties dictionary which Qodot will write to) and applying it to your instanced scene form there.

Not every point class is going to use angle as yaw - one example being the light class using it for spotlight angle, and instead using the mangle property to store euler rotation - so having QodotMap apply it globally as you suggest is a naive solution that will break more than it fixes.