As Dev Mode has a graph node GUI, would it perhaps be a good idea to use it for more things in the future? For instance, instead of tediously specifying a FUEL_SYSTEM Trigger or an ELECTRICAL Procedure as a text line of parameters with separators, one could set up arbitrarily complex triggers and procedures as a node graph.
Possibly even the horrible RPN coding in XML could alternatively be done using a node graph. But sure, that would have drawbacks, too. I am not 100% sure I would like doing that instead of writing RPN, despite all the flaws of RPN.
Just look at Blender, where the node graph concept is being used for more and more functionality, very usefully. Shader nodes, geometry nodes, and more coming. (The “Everything Nodes” concept in their roadmap.)
Hi @tml,
Being able to edit plane systems (fuel, electrical…) through a node graph is on our roadmap indeed (for what it’s worth, RPN isn’t). No ETA for now.
Best regards,
Eric / Asobo
3 Likes
Please make sure they can still be edited and sensible diff viewed in plain text format.
1 Like
I would just like to say that I love the RPN in xml. It just makes sense and is unambiguous.
Do you have any experience of other programming languages?
Only some embedded C and assembly 
Sorry, There was supposed to be a second half to that reply. I don’t know what happened to that. I
think it’s a great idea to have more node based coding for the sim. It makes it a lot easier to see the available functions without having to look up in the SDK all the time. Especially fuel and electric systems would be great to have as a visual node based system for organization.
I fully support this suggestion.
Yes, having a textual version-control-friendly format for files where node graphs are stored between editing sessions is crucial. (I am too lazy to check whether the visual effect node graphs are stored like that right now…)
1 Like
Let me elaborate: For instance, the topological relationship between nodes and the physical placement of their representations on screen should be stored separately, either in a different part of the text file, or at least on separate lines. Also the behaviour settings of a node should be on a line of itself. So that if you move nodes around on screen or resize them for cosmetic reasons, but don’t change their relationships and behaviour, only the lines describing their locations and size on screen change. Or if you change only values for how a node behaves, only those lines change.
(I haven’t used the visual effect editor, but I really should try it out, maybe it isn’t even possibly to freely place and resize nodes but the program always does it automagically?)
The VFX node editor creates one xml file with the actual code part, and one xml file containing the visual placement in the visual editor, like you describe.
The created code xml file is not human friendly like the current cfg files. It’s all segments linked together by GUIDs.
Here’s a screenshot of a VFX xml.
1 Like
Still, even if it really isn’t human friendly, it consists of separate lines with one “thing” per line, so if you want to check later from version control what you actually did, you at least get some idea what the change affected from the diff, assuming the diff is small.
Odd that no developer-assigned names to the objects show up in the XML, don’t the node graph have such?
1 Like
VFX editor does not allow you to name anything. You can create comment rectangles behind the nodes, but those are saved with the visual layout xml, not the code xml.
1 Like
OK. As you notice, I really need to actually try the node graph editor before talking more about it;)
