Node suggestions

  • Increment and Decrement nodes to add a fixed value.
  • Get and Set WindowSize Nodes
  • Set Vector Node
  • Disable node that works with a state and disables another node. This way a state and branch could be used to disable keyboard input/mouse in cutscenes for example
    -Boolean Operations Node
    -Vector math Divide is missing
    -Mouselook & object rotation node with pitch yaw and roll
    -Merge down on keyboard/mouse and keyboard/mouse state nodes into one single node with bool connector

Post more and I’ll add them to the list.

As you already said, Set Vector node is already done by Set Variable, and Get Window size by by Window Info. I don’t quite get what your first suggestion is, a loop that does ++ until a threshold is reached?

Kinda like the one in blueprint:
If you can get the window info how do you change the size with nodes?

I don’t think you can Set the screen size yet, MAYBE you have luck with hooking the Window info node up to a set variable node and changing it this way.
So this thing does ++ and print the variable whenever “H” is pressed ? There isn’t a dedicated ++ node, but yes I agree maybe one node that can switch between all those double-sign operations (++,–+,=+,…) would be useful. It would certainly save space over the current Armory method.

Simple logic, it can be made with actual nodes, but i don’t like how it’s named and made.

“Boolean logic” node :
Two boolean inputs , one boolean output.
List modes :

Perhaps i’ll find time to code it.

The “Gate” node already has that functionality! Just set it to And/Or, power its red input with “On Update” and the remaing slots with the concerning booleans. The other gatters are still missing. So should the be a seperate node for that with all the gatters or should the missing ones be added to “Gate”?

I’d add the rest to gate and if there is enough time add them as single nodes too.

Gate name is not appropriate.A new boolean as i suggested is more simple.
Usability, yes usability matters.

For example, there is two main categories with anything inside : Values, Actions.

Instead there should be domains like Vector 3, Object and so on with their own actions and getValue, SetValue should be actions.
The node menu is really weird in organization when you used other node systems outside of Armory.

I think I once made just exactly that node. I just didn’t upload it yet, because I thought nodody would need it.

1 Like

Blender 2.8 won’t integrate the new node system in the works, it’s for lot more later.

Will actual nodes we add will work when Blender will get the “everything nodes” update lot later" ? Is work and effort put on nodes worth it ?

I’m not 100% sure how things will change with the new Blender, but right now the nodes don’t actually represent a huge amount of code, so I think we continue with what make sense now and change it later if we decide to. Logic Nodes, as far as I have seen on this forum, are the top used and asked about feature of Armory. Additionally, it is very easy to add new nodes and to do what we need to right now to improve them. The system and the code is very simple, so I’m going to start implementing improvements as I can and if we decide to change later, then we can do so.

1 Like

That’s it:


Why would everything nodes effect Armory. As long as the armory follows the structure already laid out in blender there should be no problem. The guy working on the everything nodes wrote the animation nodes project and it didn’t change a thing as to how bender works. Armory is an add on and is already using nodes just like the rest of blender. (compositor, material etc). All they are attempting to do is move particles and other such things over to nodes too.

If they update how things work then Armory just updates like every other add on has to do. Almost every add on in the world will have to be updated with 2.8 so this is no big deal.

All of the suggestions about changing how armory nodes work seems to be people trying to make it into another engine. Unity doesn’t work like Unreal and Godot doesn’t work like lumberyard. Why do several people keep trying to make armory into those other engines. The best thing about armory is that if you know blender you know armory (for the most part) It all works like the rest of blender. Yes there can be improvements but we need to let armory be armory within the blender program. Otherwise, we will just be arguing about what game engine to duplicate.

Instead to assuming armory can’t do something you need to see if it does it different. That is what you have to do when ever you move from one software to the another.

Lastly, Armory is completely open source so people can write what ever they want for it. If you know how to do that then go do it and share your results. If the community likes them, we can use them. If you can’t, you can ask for help or show how something isn’t working. But demand armory change is not appropriate.

Prefabs is not trying to become Unreal 4 or Godot, prefab is a must have or you’ll waste lot of time with work around while it should be simple to make and use prefabs.

Many nodes like Gate are counter intuitive, the new node is what people will use the most with booleans, it’s called improvement.

Not copy Unreal 4, but get lot better interface and usability is also something Armory should consider perhaps after first release.
A better separation from Blender, there is many Blender options and features mixed with Armory buttons and tabs. For example many particle and physics options are specific to Blender and are not used in Armory 3D engine.

Well … there is many small things once improved should make Armory even more better.

1 Like

The whole point is that armory will not be separated from blender. Lobos even is looking to make it work in Houdini. That was his point of the project. You are asking for things that are against the whole poiint of the project.

As stated prefabs are already in armory as proxies. If they are not working right then create a issue to solve it.

I find many things in other programs counter intuitive but almost nothing in Armory is that way to me because I am not a programmer and never used a different visual scripting system. Nothing will ever make everyone happy that way.

Please just accept that something will probably never be the way you think they should be and work with they way they are.

I am bringing this up because most of what your writing has been stated over and over and doesn’t seem to be producing much in terms of moving forward.

When i say separation i mean Armory things in their own tabs and color, does not misunderstand my statement.

For example on particles, all Armory specific options should have their own colors and tab, while we should be able to differentiate particle options that are Blender only and those that are used by both Blender and Armory.
Perhaps a specific background color for those that are used by both Armory and Blender.

It’s usability not changing Blender.

Some nice people here created some new nodes (look_at, boolean logic, function call) to help those using logic nodes, and that’s already making logic nodes even better.
I’m waiting for a solid stable prefab system in Blender, you can’t make a game without them or you’ll be very limited and need lot of work around.

I covered most game making aspects in Armory and reported all blocking bugs (physics, material rendering and others) or features that are not available, i will just wait for later releases and check when Armory will allow to make a full game.

Don’t worry, i don’t ask Armory 3D to become Unreal 4 :rofl::joy:
(I understand Armory options and tabs will stay mixed with Blender without knowing what is Blender only and what is used by both blender and Armory, what a confusion :joy: )

1 Like

I better understand what you are talking about now, but don’t hold your breath. Have you used blender long? Check out all the other add ons out there and I have never seen one do what you are talking about. Tabs for the add on itself yes but color changes and stuff are all handled with themes that are set for all the blender program. I am just saying to look at all those thing other have created and there must be a reason I have never seen these things before in my 8 years of using blender. Might just be a waster of your efforts.

I used Blender a lot to make content, but i didn’t worked in python or customize it, i don’t know anything about the interface code.

Able to change color or background color for options used by both Blender and Armory would help a lot.
This is a simple but the best improvment that would make things less confusing.
Perhaps it’s not possible i don’t know.

I think that just putting things in a separate panel for Armory might be a good UI improvement. It is a little bit strange sometimes looking around and not knowing which check-boxes or options are going to apply to Armory and which ones are not, but I think for now it is not a huge problem. If somebody makes an example of a different UI setup ( panels, colors, organization, or whatever ) that works well, then it would be worth looking into, but currently I don’t think it is that bad.

When you come into Armory for the first time, you find that some things don’t end up in your game like they were in Blender and you realize that feature just isn’t there yet, but after Armory matures, that may not be as much of a problem because Armory might support a lot of what Blender shows in its UI. I’m not for sure what the best approach will be in the end, but I think that right now we are doing very well and that we just continue to contribute and make improvements where we are able.


Is there some more information on how proxies work? All I can find is: It sounds kinda like a “prefab” but blenders linking is really really bad. I’ve worked with it and stopped using it since it created more problems than the advantages it offered. It needs to be as easy as clicking import and everything is imported. Without something that works like “Unity prefabs” or “flash symbols” or “ue4 blueprints” armory has 0 chance to become a mainstream gamedev tool.

I think armory has a ton of potential but atm the only real advantage it has is the blender integration, which is enough for me to drop godot. “Everything” else is done better by other engines though. To be fair many of them have been out for >10 years. Armory needs to keep up with the development though. There are many many game engines out there and the count is rising. Not implementing new tech is like sticking with turbo pascal and denying OO programming. But I wouldn’t change too much right now and wait for blender 2.8. I’m pretty sure the blender 2.8s collections will be exactly what is understood as “prefab” by indie game devs.

But I’d love to discuss improvements to the node system here since I have a huge affinity to visual scripting.
I can create much more complex scripts with visual scripting than with text based coding. If other node systems have good usability there is no harm in copying what they do. Best example for that is world of warcraft: what they did is copy everything good from other mmos, throw it together and improve upon it. That is why it was such a huge success. (+the lotr hype of course)

I like that armory stays as an blender addon but some highlighting or other tab like mentioned would be very welcome. I’ve spend a lot of time figuring out what works and what not, if there had been some color to indicate what is blender only and won’t work with armory that would have saved a lot of time (1-2 days). The easier something is to use the more people will use and support it.

1 Like