Get System Name - to get the name of the system while the application is running.
Output parameters:
System Name — displays the system name as a string;
List systems for quick comparison.
Please check on Linux. I’ll check the rest myself.
Do you need to add other systems (HTML5-Worker, Flash, Java, NodeJS, Unity, WPF, BSD, Solaris - these are all the names that I found in the engine, I can’t check them)?
I am not sure about the possibility of this, but is not better to name it as Get System Data or similar? Then we can add more system specs in the future without need to rename the node or create a new node.
I also don’t know your intention with this booleans, they seems to took too much space in the node. Considering this node useful for “display” the system info, i think just the name should be sufficient. Anyway, maybe you have some other plan for this.
I think it is quite convenient to have those boolean outputs, this way you can easily do stuff for some systems without having to lookup the exact name for that system.
Now there are nodes Window Info, Display Info, which are also related to the system. It might be worth combining them by adding the output of the system name.
Depending on the platform, you can use one or another functionality or settings (save files/data in different places, show part of the interface or not, etc.) and this can be foreseen by creating a fork and at the same time have one project (type Boolean for shortening with the addition of conditional nodes).
To make the node smaller, you can make a drop-down list.
Let’s keep the boolean outputs, if you need e.g. three different configurations on three different systems you would need to use three of your nodes to do this. With separate outputs you need only one node for that.
Currently the booleans do not affect in nothing because the node still small. But if other outputs are added to it, it will become too much huge (like Get Rigid Body Data).
Considering the usability of this booleans i think they deserves a single node like “System Mask” and the system name must stay in Get System Data together with the display and window info. I don’t know if there is a possibility to get the GPU name, CPU, etc. but this kind of info should fit in this node.
Anyway i think is possible to use get system name and switch node for the same purpose as this booleans, maybe you may confirm this.
And i don’t know if mixing this nodes is that good, because in this case i think there is no way to keep compatibility with older logics, because the sockets will be changed. Or there is away to define which sockets will be connected?
Either there are many “small” nodes, or long links … this is all subjective. I am satisfied with both options
GPU, CPU is Hardware Info/Data. Is this planned?
My goal is to give quick access to the operating system/platform definition. Therefore, the gorge is “merged” with the Switch node. The user, as @timodriaan wrote, will have no questions about what he will receive:
I came up with a compromise, to dynamically add output parameters, when adding such a parameter, the value will be selected from the drop-down list.
What do you say to that?
For me the version in your screenshot in the first post is perfect. It’s clear what it does, how it works and the node has a good size, it’s not too big and has everything one needs (I also wouldn’t combine this with other nodes, Get System Name is a good node name). We shouldn’t overthink such small things But that’s just my opinion.
Regarding your proposal: I’m afraid I can’t really follow what you mean with that, but it sounds complicated for the very basic functionality this node has.
But it turns out to be not easy. While there is no desire to waste time on this, by default there is no such opportunity.
Therefore, I stick to the option or the first post.
But that’s just my opinion.