How should we go about streamlining and optimizing CA's Lua?
Make disabled at start/delete these widgets:
Code:
ally cursors auto skirm auto swarm auto group build bar build eta building starter calayout camerashake ceasefire chili marking menu cloaker guard command insert dc icon darkening ghost site jumjet gui land fly lasso terraform gui local widgets config minimap events noduplicateorders prospector rank icons retreat satellites selection send selection buttons selection circle2 shield guard smoothscroll resetstate statereverse toggle stereo3d stockpiler transport ai unit mover voices
Are you kidding? Disable at start? Some of those widgets are important or even essential to CA gameplay - the Jumpjet GUI, land/fly, etc.? Seriously? And is anybody out there really complaining about Ally Cursors?
The problem is how the Widget list is organized - it's cluttered up and a player can't crawl through them. It feels messy. CA is reorganizing the widgets into a nice, user-friendly "options" menu.
Are you kidding? Disable at start? Some of those widgets are important or even essential to CA gameplay - the Jumpjet GUI, land/fly, etc.? Seriously? And is anybody out there really complaining about Ally Cursors?
Yes seriously. Those are all the widget (excluding lups) that bother me about CA. I play without them and they are in no way essential.
i agree that the list should be better. for example, when i play on a pc with low tech graphics card, i would like to see easily which widgets are graphics only. then there could be a list of widgets that may be CPU intensive.
For the future, the player shouldnt have to even look at the widget list. The widget list is a programming-side thing. Everything should be accessible through the menu.
The current crudemenu setup is pretty bad though, some parts of the menu have very little under them and others are buried 5 levels deep.
I'd like to try to avoid scrolling for menus, you'd have to scroll down every time you start over. That doesn't save you any time over deeper menus. One is more clicking and one as more dragging.
It does save a lot of time! You assume people know in which branch it is. But they dont. So they have to explore each branch without easy way to go back.
Its very frustrating. Compare that with scrolling which is intuitive since it exists everywhere.
Menu has 3 submenus, the first two with two options.
Menu > settings has 7 submenus.
Lowest Settings has one option.
Video has 9.
Menu > Settings > Video > Graphic detail (4 levels deep). 13 options. These are only for 3-4 options in 3 settings, and would be better served by radio buttons or a drop-down list. The menu is rife with this kind of stuff, actually.
View is similiarly huge.
Effects, however, is back to only two options.
Menu > Settings > Misc > Mouse Settings is large, 4 levels deep.
Okay, so there are none 5 levels deep.
Game, on the other hand, has 10 options and one submenu.
So what does crudemenu need from chilli?
A. Drop-down menus.
B. A way to display toggle buttons on the button itself (All these buttons marked 'Toggle X' is bad, a light or tick boxto the left of the panel or such would be better).
C. Tabs for the menu. You shouldnt have to scroll through options then be taken to a second page, the categories should be on the side or top, with the options in a main panel. You can use a technique other than tabs but you need some way of organizing them. Ideally, you should never have to go two menus deep, everything should be categorized properly. Hell even springsettings does this. A few exceptions may have to be made for things like the Night widget, but all the important stuff should be on the main page.
Modern options often use treeview on left displaying categories and pane on right category content. Problem is it needs someone to code simple chili treeview which is some 4 hours of work and then integrate it into crude which is *nobodybutcarknowshowhard*
Honestly, a treeview doesn't seem worth that effort - I usually find treeview-based options panels to be annoying, since you never know whether the options you seek will be located on parent or child levels of the tree.
Users browsing this forum: No registered users and 2 guests
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum