Requests: Menu improvements

hedgefield

Hey there,

I just spent some time populating a menu with buttons of various size, states and placements (and had to do it all over again when I realized I had made them all labels instead of buttons, GAH ha), and I wrote down a few features that I would have liked to have there.

• would it be possible to swap the kind of element after you created it? It would have been convenient to batch-change some labels to buttons while keeping their common settings intact.
• if not, being able to copy menu elements like you can with actions and menus themselves would be a real time-saver.
• the ability to assign a font to the menu itself that applies to all its children instead of specifying the font on each element seperately would be handy if you ever wanted to swap fonts across the whole UI.
• bug: button labels do not wrap their lines based on the size of the element like actual labels do, making the text fall outside the shape.
• bug: button labels are rendered behind the background graphic and the highlight graphic for some reason. fixed in 1.32
• bug: adding a new element to a manually-sized menu resets the specified menu size to some small and seemingly random value. fixed in 1.32
• bug: a menu that is manually sized to cover the whole screen seems to have a one- or two-pixel offset on the left side, revealing the scene background. not a menu-related problem
• implement the newline break functionality for strings in menu labels

Harkenin

hedgefield hope you wont mind, i have few things to add on my own

• request: If we could have "selected" option like highlight. It would be wonderfull. So if a person selects an option, it would be visible from the GUI instead of assuming they did. We could load "pressed" button graphics which will appear if selected.
  

hedgefield

Sure no problem, throw in whatever you want to suggest.

I have another point that I noticed today:

• bug: I have a menu that I marked as "start locked off", then I unlocked it via an actionlist in scene 3. When I then go to the next scene, the menu is locked again. It doesn't stay unlocked. Fixed in 1.33

ChrisIceBox

Sure no problem, throw in whatever you want to suggest.

Lucky me

Can't speak for all the suggestions, but certainly the bugs will get fixed ASAP.  I'm not sure about the two-pixel offset bug, however.  Seems to be an Editor-only issue for me - does the error persist for you in Built games?

@Harkenin: I'm sorry, but I don't understand what you mean by "selected".  Please elaborate.

skitt2501

It seems to me that he wants a "pressed button" function, where if you toggle a button, it appears as "pressed" after clicking. 

I think we can already do that with actionlists though. Just hide the previous "unpressed" button element and show the new "pressed" button element when it is clicked. I guess a simpler solution would be nice though. 

hedgefield

Haha, just thought we'd keep you busy

Well rad, no problem, the bugs were the biggest eyesore anyway, the rest are nice-to-haves. I'll check up on the editor-only offset you mentioned, I haven't gotten around to making a new build yet so it could very well be that it is gone there.

And yeah I think what Harkenin is asking for is a pressed state for buttons, which for instance could be useful if you have a menu with tabs and when you press one it stays selected while it's open.

ChrisIceBox

Thanks, that seems likely it.  If that's the case, better to just improve the Toggle element, since that's already got an "On/Off" state, only it's a label rather than a texture that shows off it's state to the player.  With a Toggle type of "Custom script", you could show/hide other elements accordingly with a simple script.

The thing I've always said about menus is that, no matter how much dev work goes into it, it'll never be good enough to cater for everyone, so you should be aware that custom (simple, though!) scripting is the way to get what you want when it comes to particularly complex menus.

hedgefield

I can imagine, there are so many variables and so many things you could want to do with it that I'm very impressed it is already this versatile. I'm also working with the GUI styles that Pixelcrusher's Dialogue System uses, and so far your implementation is far more user-friendly. That is to say you get what you see, and that is very valuable.

I did a quick build and the edge is still there, but I think it is caused by something else, because even when the menu is closed I see an edge, and on the other side too. I think it has to do with the secondary camera I use to draw a scrolling background behind the scene, I'll have to investigate.

Harkenin

Hey @Skitt2501 thanks. Thats what i meant realy @hedgefield well yes thats another use for this feature as well. In short this is a great feedback to the player. It would show he/she did interract with the button rather than just hearing about it.

@Chris, that's a great suggestion. I'll try toggle option ofcourse. But, still this "feature" would be usefull for normal buttons as well. Considering we have a "click sound". The Click Sound basicly does what im asking in audio.  If we could add a "click texture"  it would be a more compleate feedback all together.

I'll try to find custom script to do this, if i can manage it , will share it at "extending the editor"

by the way, it should go without saying that AC is already a terrific tool. This little requests are in no way undermines the ease  AC's provides to non coders .. So many thanks yet again to Chris.