|
From: James T. <ja...@fl...> - 2022-01-13 07:30:07
|
> On 13 Jan 2022, at 00:59, Josh Davidson <jos...@gm...> wrote: > > Hi James, > Property-path sounds fine to me, I wonder if there would be use in adding this to other things like animation or expressions also. Autopilot components have a slightly better defined structure for this, which unfortunately can’t be re-used in animations / expressions (autopilot lives in FlightGear, whereas animations/expressions/conditions are in Simgear). But, it’s still doable, and not so difficult, if we agreed it’s useful. In principle, the ALIAS system for properties could achieve this with no external knowledge, the problem is there are some odd interactions between alias-properties and listeners, I think. But maybe we should check if we could make aliased work 100% correctly, and gain some expressive flexibility in this area. (I think my coffee has kicked in, my memory is, the problem is aliased properties don’t listen to their source property, so change listeners don’t propagate through. Fix would be when defining an alias, to add to some private data on the source property, so we can forward-propogate change notifications) > > > so you can’t specify a non-existing node path and then create the node later > Not a problem for me. In nasal property dynamic is easy, so I don't really see that to be a bit limitation Right. > > > the input will be marked as disabled > Yes, good idea, I actually wondered about this > > > if there is a <value> defined, we will set it on the node pointed to by property-path > There is no reason to set a property and a value, so that's probably just fallback behavior which is fine by me Actually, I flipped my mind on this one, I think the ‘write back’ behaviour is a bit weird. I got the tests written, all seems good so will push to next later today, hopefully. Kind regards, James |