Make Visual Nodes Great Again


#21

Yep it is very nice how it is. It doesn’t need to change necessarily, but it was worth thinking about.


#22

I never said i find it nice as it is :joy:

This small change would make it so much more clear

https://github.com/DevMagicLord/Godot3/blob/master/Armory/newArmoryUI.jpg?raw=true


#23

To me this whole discussing depends on who you aiming at to be the main end users. Having everything in one place (inside blender) makes learning so much faster. It probably does hold back features that would compete with the big boys but you just cant over ride the learning curve and massive frustration of working with multiple interfaces.

Maybe Armory will never create the greatest MMO in the world but so much can be done with just a slightly less game engine. Keeping everything together has allowed me to actually accomplish more in the last few months than in years before. No export errors, no changing the textures because they don’t work the same. No opening software back up, fixing, exporting and importing when something is just a bit off.

Working with all the same interface in my opinion is so important for young (and old) learners. We don’t have to figure out how to implement thing from 8 other programs. We can accomplish 80 - 90% of the art right here as you could for a AAA game and then never export a single file if you don’t want to. With some of the new texture painting that is coming in 2.8 you may never need to leave blender to create a damn nice game.

And for teams, everything can be in one file, all the textures, animation, bones, armatures, rigs or what ever and ever part came be moved into any other file with append just like that and know it will work because it is coming from the same software. Honestly, over time no other game engine is capable of this type of a working environment.


#24

Yes I think that @Monte_Drebenstedt does sum up well a large part of what makes Armory great and innovative and different. Blender itself is a picture of putting everything in one spot and making it amazing. Armory is yet another step in that direction by borrowing the amazing UI and utility of Blender and adding the ability to make great games. If we feel like we need to split Armory away from Blender, maybe we just need to work more closely with Blender to give it the little bit of extra push that we need. It is amazing how Armory has worked so well already. We just need to keep pushing it.

I think it’s on the right track. :slight_smile:


#25

Back to the main topic. I think there have been a bunch of great suggestions though out the forums on changes to the nodes. Adding out to the loop break is just one that comes to mind. Perhaps, someone would like to try to gather them and start a thread we could vote on for them or something. Or just grab one and start a thread. We already have the Logic pack on Git hub that we can use to put them in and test them out. Perhaps if you change one just add LP (for Logic Pack) to the name and if it works right @lubos may switch it out in the full engine.

I will try to see what ones I have had problems with outside the loop break and create threads. Coders please jump in as you can. I promise I will add them to my video series on nodes and mention you ( and you project or whatever) in those videos, if that helps at all.

I personally am begging for some help with the UI, Can we get nodes to effect the Font, color, size ect. I would love to know if the slider can change according to game input and not just from player input. I will be working on these if no one else does once I finish up the few things I already have in the fire.

If anyone at all can make HaxeUI work and get nodes that would but awesome. Sorry I am just not enough of a coder to figure that out yet. Also, let’s be nice to the non coders if they need help pushing these nodes up to github ( because I probably will at some point).


Visual Nodes Suggestion
#26

Alright, I am starting new thread. So, please no offtopic everyone.


#27

The problem is nodes are changing for 2.8.
It’s like all nodes we use and nodes documentation is already obsolete.

While Haxe is not dependent in Blender , so Haxe users are fine contrary to nodes users.

How Armory will do if object or scene tabs get changes ?

About physics in particular, Armory should have it’s own physics panel, there is too much Blender things that are not related to Bullet Physics, it’s really confusing.
Use Blender to setup Physics volumes, but get a specific Blender window or tab to setup all Physics Bullet properties.

There is definitively the need to separate Armory 3D engine features from Blender and not mix them, while keeping Armory in Blender.
Separate tabs and window i guess is possible in Blender.

Change presentation and not mix Blender and Armory in same windows and tabs is a must need for clarity , organization and usability.


#28

how will nodes documentation will become obsolete ?
Nodes documentation is on what a nodes function do, how will it become obsolete.


#29

When node system will change in B2.8


#30

But what does it have to do with the function for nodes. Or are you talking about Images?


#31

You’ll have to redo the whole code behind and perhaps nodes images representation will also change.

I guess all you can do is follow Blender 2.8 changes when they appear.


#32

I think i am misunderstanding here, which doc are you talking about?
This -> https://armory3d.org/manual/#/logic_nodes/reference
Or this -> https://armory3d.org/manual/#/dev/logicnodes


#33

I mean if Blender makes new changes to the node editor and how it works and it’s graphics, then the actual documentation will become obsolete.
But perhaps nodes will stay the same and won’t get changes in Blender 2.8 or next versions after 2.8 release.


#34

Which Doc are you talking about, 1 or 2???


#35

About the second doc logic nodes.


#36

Ohhh then you are right. I thought you were talking about 1st doc.


#37

Are you ok for asking Lubos 2 more categories in this forum , one for Logic Nodes and one for Animation ?


#38

(:white_check_mark: : Done, :x: : Not Done)

Node Doc:

Logic: :white_check_mark:.

Event: :white_check_mark:.

Action: :x:.

Value: :x:.

Variable: :white_check_mark:(Almost!).

Input: :white_check_mark:.

Array: :x:.

Animation: :x:.

Physics: :white_check_mark:.

Navmesh: :white_check_mark: .

Sound: :white_check_mark:.

Native: :x:.

Canvas: :white_check_mark:.