Topic Experiment: Interaction Menu
This board is threaded (i.e. has a tree structure). Please use the Reply button of the specific post you are referring to, not just any random button. If you want to reply to the topic in general, use the Post button near the top and bottom of the page.
In Response to Clonkonaut
Disclaimer at the beginning: Many of my answers will include the reason: 'because scripted GUI cannot really do that'. I am currently limited by what is possible with these and what not. Every other feature would need more changes in the engine which I am not capable of doing.
Yes, that would be nice. I tested around with something like it but gave it up. The reason is: The GUI cannot really do that.
I can have a a variable height but cannot really include a maximum height and have elements below that variable element. I can have one element with a variable height but cannot define a maximum height in addition. So I need to nest it into another (invisible) element with a fixed height. This means that the invisible element will still occupy the screen area and other elements (the description box) cannot dynamically occupy that area.
The next problem is:
The big elements are measured in relative units (screen area percentage), the small elements (Inventory, Production, Damage) in a fixed unit (em). I cannot convert one into the other, so I don't how much space a '2em element' will occupy on the screen. So I cannot calculate the menu height and position other element accordingly. And because pixel-perfect positioning is impossible (px is not a unit the GUI knows), I couldn't include spacers for frames, I would have to give it a safety measure in em (I currently do that, there is a right margin in the two big menus of 0.25em, otherwise they'll partially overlap the frame).
I can't control the camera in any way but yes, that would be nice. Since it's impossible, it can only work with what I have - I can't tell where the clonk is on the screen and can't position the camera. Regarding the height of the menu: Also possible but I would include a lot more scrolling because even the most simple information of most buildings (Inventory, Production, Damage - even worse with buildings the Foundry which has all the pipe control elements) exceed half the screen with 1080p and standard font size.
It's possible to filter that tab but it's only just one tab.
Yes and no. First of all, the height of the menu is the most critical problem about it and moving tabs to the top means a higher menu. Then there is the problem of having too many tabs. Vertical scrolling is very inconvenient with the GUI (a 'cannot really do that' argument here). There are problems with scrollbars not being displayed properly (clipping would occur), so many times you probably wouldn't be aware that you can scroll vertically). Mouse wheel scrolling does not work vertically (I think), so you'd have to drag the scrollbar. And there is more tab space in height than in width, so less tabs visible.
Bigger? Opaque? The icons of everything would have to be more self-explanatory (like Surrounding). But yes, the names can be left out (like it is when you disable Headings using the settings button - can be seen in the example screenshots I did).
Can you be more specific? The GUI can't do shadows or fancy effects, so I don't really know what you mean.
Yeah, I agree. But since these elements were made by other people (Zapper and Maikel, I think?) I didn't really modify these. The menu elements are generated by any individual object and are customisable via script. My compromise was the 'Grey' settings buttons to filter out the colours. Spacing is a problem because it adds more height.
Because the entries are customisable, there are more than just the standardised entries of Inventory, Production and Damage and the meaning of a sub-element isn't necessarily obvious at first glance. But I included the settings button for that reason because experienced users do not need the explanation.
Yeah. I kept it from the previous version that someone else (Zapper?) did but made it less big. You can always compare everything to the top screenshot in this thread to see the version before I ever began working. And yes, a progress bar is uncommon here.
Because that's a real problem. With the clonk, it's fine (5 slots). But even then, the inventory space of a clonk is fully customisable and having to show many slots would look weird. Then take the chest in my examples. It has 50 slots! Always displaying 50 slots would look extremely bad. Many containers are also limitless (most of the buildings), so 'slots' don't fit there.
Slots also give the illusion of having drag&drop support. I don't want to give that illusion because the script GUI can't do dnd. I would love to have drag&drop support though!
Well, yes! But, script GUI can't really do that. I can not show the box as long as it's empty. I tested that. But it's a useless effort because the box shows something in 80/90% of all time using the menu. Most elements have a hover tooltip (Inventory shows a description, Production shows that + building material, Damage is a tooltip etc.). The tooltips of the script GUI are unreliable and not very organised (can't be customised, so it's just a text). Very bad for something like production material dynamically showing what is missing or similar. I can't display a windows where the cursor is at (a typical tooltip position) because I can't get the screen coordinates of the cursor (first problem) and I can't use pixels as a unit of positioning (or sizing) for the GUI anyway (second problem). So the 'tooltip' needs a fixed position (like it is now) and would be displayed at almost all time (like it is now).
Edit: In summary: you do have valid points but I am working under very harsh constraints.
> There is so much blank space that overlays the possibly very important information of what's going on in the game right now. Idea: the menu could grow in size by the content that needs to be displayed.
Yes, that would be nice. I tested around with something like it but gave it up. The reason is: The GUI cannot really do that.
I can have a a variable height but cannot really include a maximum height and have elements below that variable element. I can have one element with a variable height but cannot define a maximum height in addition. So I need to nest it into another (invisible) element with a fixed height. This means that the invisible element will still occupy the screen area and other elements (the description box) cannot dynamically occupy that area.
The next problem is:
The big elements are measured in relative units (screen area percentage), the small elements (Inventory, Production, Damage) in a fixed unit (em). I cannot convert one into the other, so I don't how much space a '2em element' will occupy on the screen. So I cannot calculate the menu height and position other element accordingly. And because pixel-perfect positioning is impossible (px is not a unit the GUI knows), I couldn't include spacers for frames, I would have to give it a safety measure in em (I currently do that, there is a right margin in the two big menus of 0.25em, otherwise they'll partially overlap the frame).
> But all in all, I in my opinion the menu should never obscure more than half of the screen (and the clonk is centered in the free half)
I can't control the camera in any way but yes, that would be nice. Since it's impossible, it can only work with what I have - I can't tell where the clonk is on the screen and can't position the camera. Regarding the height of the menu: Also possible but I would include a lot more scrolling because even the most simple information of most buildings (Inventory, Production, Damage - even worse with buildings the Foundry which has all the pipe control elements) exceed half the screen with 1080p and standard font size.
> having the name plus icon of the container on the tab but the name of the container on the first line of the menu as well seems duplicate.
It's possible to filter that tab but it's only just one tab.
> Couldn't the tabs be moved to the top
Yes and no. First of all, the height of the menu is the most critical problem about it and moving tabs to the top means a higher menu. Then there is the problem of having too many tabs. Vertical scrolling is very inconvenient with the GUI (a 'cannot really do that' argument here). There are problems with scrollbars not being displayed properly (clipping would occur), so many times you probably wouldn't be aware that you can scroll vertically). Mouse wheel scrolling does not work vertically (I think), so you'd have to drag the scrollbar. And there is more tab space in height than in width, so less tabs visible.
> and maybe made more prominent?
Bigger? Opaque? The icons of everything would have to be more self-explanatory (like Surrounding). But yes, the names can be left out (like it is when you disable Headings using the settings button - can be seen in the example screenshots I did).
> Imo there is to much usage of shadows
Can you be more specific? The GUI can't do shadows or fancy effects, so I don't really know what you mean.
> different colours per row
Yeah, I agree. But since these elements were made by other people (Zapper and Maikel, I think?) I didn't really modify these. The menu elements are generated by any individual object and are customisable via script. My compromise was the 'Grey' settings buttons to filter out the colours. Spacing is a problem because it adds more height.
> Also, I wonder if the titles for the rows are really necessary.
Because the entries are customisable, there are more than just the standardised entries of Inventory, Production and Damage and the meaning of a sub-element isn't necessarily obvious at first glance. But I included the settings button for that reason because experienced users do not need the explanation.
> Also, i have never seen a progress bar for how full an inventory is
Yeah. I kept it from the previous version that someone else (Zapper?) did but made it less big. You can always compare everything to the top screenshot in this thread to see the version before I ever began working. And yes, a progress bar is uncommon here.
> Or, why not do it like many other games do and show the slots?
Because that's a real problem. With the clonk, it's fine (5 slots). But even then, the inventory space of a clonk is fully customisable and having to show many slots would look weird. Then take the chest in my examples. It has 50 slots! Always displaying 50 slots would look extremely bad. Many containers are also limitless (most of the buildings), so 'slots' don't fit there.
Slots also give the illusion of having drag&drop support. I don't want to give that illusion because the script GUI can't do dnd. I would love to have drag&drop support though!
> Regarding the box at the bottom, isn't this something that could best be displayed (and often is in other games) as some kind of tooltip?
Well, yes! But, script GUI can't really do that. I can not show the box as long as it's empty. I tested that. But it's a useless effort because the box shows something in 80/90% of all time using the menu. Most elements have a hover tooltip (Inventory shows a description, Production shows that + building material, Damage is a tooltip etc.). The tooltips of the script GUI are unreliable and not very organised (can't be customised, so it's just a text). Very bad for something like production material dynamically showing what is missing or similar. I can't display a windows where the cursor is at (a typical tooltip position) because I can't get the screen coordinates of the cursor (first problem) and I can't use pixels as a unit of positioning (or sizing) for the GUI anyway (second problem). So the 'tooltip' needs a fixed position (like it is now) and would be displayed at almost all time (like it is now).
Edit: In summary: you do have valid points but I am working under very harsh constraints.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill