Probably the error: sonnet.core: Missing trigrams for languages: QSet("en_NZ", "en_ZW", "en_IE", "en_AU", "en_TT", "en_CA", "en_ZA", "en_NA", "en_AG", "en_NG", "en_GH", "en_SG", "en_BZ", "en_PH", "en_JM", "en_BS", "en_DK", "en_HK", "en_GB", "en_IN", "en_BW" ocurred because i had tested the file in the Desktop and my OS language translates it for a special character language.
But, can you test the clicking if it is working fine for you? Looking in your code i see 3 states (clicked, clicking and click me!).
Before i click, it shows “Click me!”
While i click, the message “Click me!” come back
And after i click appear “Clicked”, but never “Clicking”.
Everything is fixed now, you’ll need to update your Armory to the changes including this PR and the logic node package was updated again. Sorry for that mess.
Replace Activated by Active in the script and it should work again, the examples are updated
I can confirm that everything works as expected now!
Created using nodes:
Some feedbacks i got for now:
The Wiki is very clean and well designed. Well documented even for the initial state.
Well structured and uses a friendly programming language (Haxe).
Very professional. Looking forward for upcoming features.
I don’t know other UIs for Kha, but probably is one of the best. Couldn’t easily tell what it is missing yet.
Planned features are really very interesting. Animations, controller/touch and themes support are amazing.
Cons: The only con i had see is related to the nodes nomenclatures. They are a bit technical, but nothing that documentation can’t solve! I have not too much understand of English, but i suggest for nodes:
Instead of New Element maybe Setup Element or Prepare Element. For me setup an element is like preparing it before “spawn” and by new element i understand by a new element that will be created in that moment. There is other crazy names that i don’t know what mean now, maybe they can be more user friendly in the future, only small details.
I also suggest a new subcategory for these nodes, inside a Custom Nodes category, because a user can have a lot of custom nodes types. And for last, i suggest to remove Koui: from the node label when they have a own category or put (Koui) in the last, it is just to leave it more readable and “searchable”.
In the future, if you are interested in challenges, i suggest the possibility to integrate some basic 2d physics engine. As far i know, UIs can be used to make 2D games alone.
If you don’t plan it yet, i suggest support for multi touch (don’t know if it is included in the touch support).
Don’t limit it for games, there is a lot of more functionality for UIs.
Don’t let it die and always post updates and spread it around!
I will provide a stress test as soon as possible in Android when i download Android Studio.
Thank you very much, that means a lot I’m glad that you could get it to work.
I should indeed rethink some node names. The big problem is that the nodes should depict the entire Koui API (or most of it) so it might get technical sometimes. This is also where the New Element name comes from, an element would be declared in the code like var button = new Button("label"); for example. What do you think of Create Element? What are those other crazy names you mentioned?
I will do that tomorrow, thanks! Maybe appending (Koui) is indeed the better option, removing it altogether would probably cause confusion for some nodes.
In the future, if you are interested in challenges, i suggest the possibility to integrate some basic 2d physics engine. As far i know, UIs can be used to make 2D games alone.
I don’t think that I will ever run out of work to be bored enough to start implementing this^^ Joke aside, if you really wanted to do this you could “just” write an interface between Koui and some 2D physics engine. I don’t think that Koui will profit a lot from this.
It’s included in the touch support
In theory you can use it for everything you want, but most UI’s do very clever optimizations on when to draw something. Koui doesn’t have this and this would need a big change of the underlaying system. Maybe someday in the future.
I take a look in each node to give a better feedback of the Koui nodes. Indeed they are very different then what i am used. But this is more from your side, because spliting some of these nodes can be more user friendly but can increase the work.
These are my doubts looking into each node, you can expect silly questions but i think it will be the case for many users. Maybe it could help in the documentation. Below will this topics will have a resumed text about the nodes.
AnchorPane Add: What is an AnchorPane? Is a group of elements? What exactly should i put in AnchorPane input?
Button Set Label: Don’t work for all element types?
Why there is a Button input in the same color as Element? It expect a element or a button?
Checkbox Active: How a checkbox is active? Active is not the opposite of Passive? Is not better the old Is True? Or Is Marked/Checked?
Element Position: Why the In and Out have (Set)? Should i be aware with this?
Why there is a Input to Get the element position? It will not work without an input?
Equals Mouse Button: What exactly is it function? Is to know if two mouse buttons are pressed at the same time? It is not already possible Armory nodes?
Event On Focus: Event On Focus have a Focus Event input, i get embarrassed here. What should i connect here to get it working?
There is some cool outputs but what should each one do? Where is the
Active output as in KeyCharPress?
KeyCharPress Event: another event? What is a KeyChar? Here i see is better to don’t specific when some input/output is event or not, because it get confuse.
The same from above: what received, activated, active mean? I would know with some time thinking, and i understand how useful they are. But a beginner will?
KeyCodeStatus: What they are? It is some kind of combo of elements?
On MouseClick: how a mouse click is cancelled? Something cutoff my finger? There is some example?
On MouseHover: Here the inputs and outputs are well nammed, apart from knowing what each output do (Received, Activated, Active, Deactivated). The only problem is in some nodes have more outputs like this ones than others. Why? And Mouse Hover may be how the function is called, but the more suggestive is mouse over.
On MouseScroll: the same goes here: receive what? I miss the Out output. What is Scroll delta? It is the delta time of mouse world?
Init: Because of the bugs i see in Zui, crashes before the Zui loads, i understand the need of this node. But what comes from this AnchorPane output? It is the last AnchorPane loaded?
New Element: These outputs are to control the events of the created element? Because i even can’t see it before i Add it.
New RadioGroup: I don’t know what is a radio, i would like to know. But this nodes looks really simple, not too much doubts.
Set Padding: Padding? I don’t even know this word, i will go to translate to find out. Looks like it is a thickness? It is how we call it in noob world.
Generally:
I would suggest to remove all Events words, because they are being just one more word in the middle of a lot.
When there is a boolean, is easy to know what is coming from it (a true or false) but our brain can be slow sometimes. For this case i would go for instead of “Active” to “Is Active”.
Looks like you mixed nodes like Get and Set. This is a bit confuse, because i would not know if the Get will work without an input connected to it.
I see there is some nodes with really useful outputs like Receive, Active, Activated, Cancelled (this one i don’t had understood). But some nodes don’t have the same outputs from this genre. Is there a reason for it? Or it will have in the future?
Is better to write some documentation for yourself and contributors (if there will be possibility to contribute with nodes) to follow a “pattern” that works. If you leave it to be done in the future, will have too many nodes to “fix”.
I’ve explained above what an AnchorPane is and this is nothing that can be improved with the node, it just needs appropriate documentation.
Button Set Label : Don’t work for all element types?
Why there is a Button input in the same color as Element? It expect a element or a button?
It works for all element types that have a label - not every element has that. I’ve chosen to create multiple smaller nodes for every element because it makes it a lot easier to understand which element has which properties. For a label this might be easy, but usually you don’t just see directly what element has which properties.
Regarding the socket color: I didn’t want to use a lot of different colors, so one is used for all elements, but in this case a Button is required (which is a subclass of koui.Element). It’s just the way object orientation works.
I agree that active might not be a good name for the checkbox state, I will change that, thanks.
Element Position : Why the In and Out have (Set)? Should i be aware with this?
Why there is a Input to Get the element position? It will not work without an input?
Yes, this is a node that’s too complicated, especially for such a basic purpose. The problem is that there will be a lot of nodes and I try to keep the menu size small, but you’re right that this should better be splitted into two nodes. Currently it works like this:
If In (Set) is activated, the given values are set and Out (On Set) is activated to signal that the operation was done. If a node reads a value from the other outputs, the currently set values for the element are outputted.
Equals Mouse Button : What exactly is it function? Is to know if two mouse buttons are pressed at the same time? It is not already possible Armory nodes?
Nope, mouse events hold information about the mouse button that triggered that event, so this node is used to check whether the event was triggered using the correct mouse button (for example you want to test whether a button was clicked with the right or left mouse button).
Regarding all the event questions and the event names (which are confusing but I really thought a lot about how to name them, it’s oriented at Kha), please have a look at the wiki page about events. It is not that you create the events, the events are created by Koui and you can react/listen to them. They hold the information about what happened. The event states are inspired by how events worked in the BGE back then (and they probably still work like that in UPBGE). KeyChar events store information about a character, KeyCode events have the keycode (integer) saved.
On MouseScroll : the same goes here: receive what? I miss the Out output. What is Scroll delta? It is the delta time of mouse world?
The output thing is explained above and Scroll delta is the amount that was scrolled in that frame, if you scroll fast, the delta is bigger, the sign of the integer describes the direction. “Delta” as a word is used a lot in such contexts, it just means “difference”.
Init : Because of the bugs i see in Zui, crashes before the Zui loads, i understand the need of this node. But what comes from this AnchorPane output? It is the last AnchorPane loaded?
Actually that is not directly related to the Zui bug. With Zui, you already have created a UI with an UI trait (CanvasScript.hx). The Init node resembles this functionality.
The AnchorPane output is the default, global layout. All elements or more layouts are children of that layout (yes, you can nest layouts).
New Element : These outputs are to control the events of the created element? Because i even can’t see it before i Add it.
The outputs are fired when their respective events occur. They send an event object (you can see this at the red square socket) which can be read by a specialized event node (On mouseClick e.g.).
New RadioGroup : I don’t know what is a radio, i would like to know. But this nodes looks really simple, not too much doubts.
A radio button is a checkbox which usually is round instead of a square. If used together in groups, only one button can be checked at the same time within that group. Different groups are independent of each other.
Set Padding : Padding? I don’t even know this word, i will go to translate to find out. Looks like it is a thickness? It is how we call it in noob world.
Padding is the spacing between the border and the content. This term is used a lot in UI’s and in HTML (in combination with margin, which is the space between the border and other elements around)
In general, Koui is more powerful than Zui but also more complex.
@E1e5en , it will be possible in some way even with bullet physics in Armory, after we fix Screen To World and World To Screen nodes. We just need to translate the locations of invisible rigid bodies into the UI. But only in practice to tell how much this will be possible
If I’m not mistaken, then in the Pick Object node, the translation of screen coordinates to 3D works fine, which means that you can look towards the function from the iron.math.RayCaster class:
public static function getDirection (start: Vec4, end: Vec4, inputX: FastFloat, inputY: FastFloat, camera: CameraObject) {
// Get 3D point form screen coords
// Set two vectors with opposing z values
start.x = (inputX / iron.App.w ()) * 2.0 - 1.0;
start.y = - ((inputY / iron.App.h ()) * 2.0 - 1.0);
start.z = -1.0;
end.x = start.x;
end.y = start.y;
end.z = 1.0;
PInv.getInverse (camera.P);
VInv.getInverse (camera.V);
VPInv.multmats (VInv, PInv);
start.applyproj (VPInv);
end.applyproj (VPInv);
}
I prefer Is Checked. It is more common for human brains. If you type: checkbox is checked in Google search you will see that it is common. Can’t find a better reference. I also had applied these changes in all Armory nodes, i will post a preview image in the other post to get feedbacks.
Did a fast test between Canvas and Koui performance.
Unfortunately the APK using Koui crashes on starting. I will test it without creating elements on init (using a touch to do it), to see if is a problem while creating the elements or just by having Koui on its files. If there is someway to debug it properly and get error messages or something like that, you can tell me
I also need a way to toggle the visibility of the elements in Koui if it is already implemented, to test if the impact of the elements in performance is reduced while it is invisible.
Details:
Using 2d/baked render path for both UIs.
Koui APK have 7.65 mbs
Canvas APK have 7.16 mbs
Both APKs have 6 button elements.
For now i will already post the FPS results for canvas:
My opinion is that the problem is in Canvas, because debug console don’t seems to cause the same FPS impact as Canvas, and it is a more complex UI element. I hope that Koui don’t have this issue
I didn’t test Koui on Android yet. Do you have a stack trace or some error message from Android Studio?
Also, there is a way to make elements invisible (elements have a visible attribute) but it isn’t implemented as a node yet. I will create a new node for it later or tomorrow so that you are able to test it
I don’t know a way to get error messages in Android Studio. I think it is only possible to get it using a built in emulator. At least in the build process i don’t see any error using Koui, but when i install an emulator on Android Studio i will confirm this
Did you already tested in a C export? Maybe the crash also happens on it
About the visible node it is welcome but no need to rush it just for this purpose, we even will not be able to use it before we found the crash issue.
I’m not sure if I tested HL/C yet (probably yes but it was a while ago), I will do that again in the next days. Robert pushed a fix for building for Android, maybe you can try Koui with the latest Kha version.
I will push the new node later (edit: done), unfortunately custom sockets seem to be buggy since the node replacement updates for Armory…
Then i suspect that this bug in the sockets can be the reason for the crash. I will test it more with the updates soon also for Linux C and i will return the result
This is strange, what may be the reason for this? The only difference between this two paths is the material from solid to mobile. But the black screen don’t even have materials on it.
I don’t know if the debug console is part from Zui, but appearly it don’t have any performance impact. Did you see a performance decrease by opening the debug console?
I did not notice on Redmi, it will not work quickly on another device.
The DebugConsole.hx file uses Zui packages. There are no other means of rendering UI in Armory.
I’m glad that you could get it to work.
