Locking interface = bad idea

[MidKnight]

We were debating this in the CA channel. A mysterious figure appeared and delivered some grains of wisdom:

<smoth> Fact of the matter is
<smoth> test is not meant for live games
<smoth> PERIOD
<smoth> it is a test build
<[1uP][ai]MidKnight> yes
<[1uP][ai]MidKnight> it's there so we can break stuff
<smoth> bitching because it is imperfect is WRONG
<smoth> it is because you players act this way that the gundam test builds are NOT public
<[1uP][ai]MidKnight> :'(
<[1uP][ai]MidKnight> same with s44
<smoth> and I get asshats coming on the forum saying "gundam is dead" because I have not shown any progress
<smoth> so you can either have a closed dev model
<smoth> or an open one
<smoth> if you do not want to use the stuff that is broken don't play the test one
<smoth> it isn't my fault or ca's fault that players are stupid and think test means anything other that a fucking test build
<[CAT]ceiling> i'm not bitching, i'm giving constructive critique from a players point of cview
<smoth> godamnit
<smoth> I am not bitching at you
<smoth> i am saying "players" for a reason
<smoth> your point is that it would turn players off to ca...
<[CAT]ceiling> it's no ones fault but it's how it is, so if you want to keep your playerbase, you need your mod to be playable when it's released..
<smoth> IT IS PLAYABLE
<smoth> IN STABLE
<[1uP][ai]MidKnight> TEST IS NOT RELEASED!
<[1uP][ai]MidKnight> TEST IS NOT FOR PLAYERS
<smoth> TEST IS A TEST
<[1uP][ai]MidKnight> TEST IS FOR TESTERS

Later...

<[CAT]ceiling> did you read my posts? if you still think i'm not trying to be constructive, i really don't get it
<[1uP][ai]MidKnight> I think you're trying to be constructive
<[1uP][ai]MidKnight> we appreciate that
<[CAT]ceiling> yeah, clearly
<[1uP][ai]MidKnight> but you're giving feedback on the test rev and treating it as if it's a bona fide release

[Regret]

text

You can't really blame people for bitching that test release is fucked up as this is the first time when there is a notable difference between test and stable. So far stables were just another 'test' version.

[MidKnight]

Pretty true, for the last 6-ish months.

But now they aren't! Be wary!

[R-TEAM]

Hi,

dislike this too ....
It is not that i musst use a modifyed advplayerlist widget* (it is imho
needed for the game options..) or that i should use other metall/energy
resource bars - this is different in gundam as example too ...

BUT that i cant use my console (IceUI) or my minnimap/control field
(IceUI too) that i like and see REALLY no advantage from the chillygui
parts, or the widget list i really dont need (was happy with the old i know and found all on his place ..)....

And the disabling of "non mod widgets" is IMHo a bad move ...
This was the reason i stoped play SupremA .... and this will stop me to
play CA too.

So i hope this is still in Development and not final ...

*= it is still at latest version updatet ..

Regards
R-TEAM

[luckywaldo7]

Yes there have been some pretty wonky things in test.

Maybe games on Oxygen also shouldn't count toward elo, as those games could be considered more testing then actual gameplay.

Also, is marking menu on by default now? I had to enable it the first time I tried it. Its seems to be a widget people will either love or hate. I think that moving away from just remaking the spring ui is a good thing, but some long-time players probably will have difficulty adjusting, so at least they should have the chance to use their own ui.

[reivanen]

Heheh, maybe you need another widget, a "warning: beta" widget that just plonks a big warning on the screen during startup (similar to the commie widget) that explains "you're running the test version of CA - please don't hate us for anything annoying in this. Stick to the Stable version if you want crap that we actually think might work".

This is actually a really good idea. Like the build watermark in pre-RC windows builds on the desktop.

"You are playing Complete Annihilation TEST version 6666
Normal games should be played with STABLE releases."

[SpliFF]

So in the end local widgets will be disabled unless you do soemthing special, like putting file called "i_know_what_am_i_doing.txt" containing your name into your spring folder.

But of course n00bs who don't know what they are doing will just add this file anyway and the basic problem remains unchanged. It might be preferrable in the long run to open up a dialog with the spring devs regarding a standard method of installing user widgets on a global or per-mod basis.

SupCom had an approach where a mod could define other mods it conflicted with so the user could not activate both at once. It also allowed you to specify dependencies and whether your mod should load before or after another. It never worked properly so it wasn't really used but I wrote a patch in lua to fix it for my own mods. Point is the concept is sensible so it may be something we should look at for Spring gadgets/widgets.

[Saktoth]

We appreciate your feedback and will take it into consideration. Have a nice day.

[Argh]

SupCom had an approach where a mod could define other mods it conflicted with so the user could not activate both at once. It also allowed you to specify dependencies and whether your mod should load before or after another. It never worked properly so it wasn't really used but I wrote a patch in lua to fix it for my own mods. Point is the concept is sensible so it may be something we should look at for Spring gadgets/widgets.

LOL.

Look, it's not really complicated. Lock down Widgets, and if people want to use their Widgets with CA, they can submit them for testing. If they don't conflict with CA's UI, then they can be used.

The problem is, people expect UIs not to conflict, as if by magic, but there are no ways to prevent that, at a technical level. I suppose all major UIs could adhere to some sort of standard, whereupon if one is started, the other ones are sent a message and will quit... that's a thought. It'd require cooperation between all UI developers, though, and somehow I don't see that happening.

[Regret]

Lock down Widgets, and if people want to use their Widgets with CA, they can submit them for testing. If they don't conflict with CA's UI, then they can be used.

Damn, you really have a knack for coming up with some of the worst solutions.

It would be much more logical to let the user decide whether he wants to use conflicting widgets or not, no sense in having devs go through countless widgets.

[Argh]

Good game design is not about making every possible user happy. A game's stock UI should not be expected to play nice with every possible attempt at a windowing system, etc., that's an insane requirement.

If CA's real goal is to make a nice clean nub-friendly interface... there is no reason not to be pretty strict about it, and keep focused on that goal.

However... one idea I thought of might help reduce the level of QQ. Make a smarter Widget management system, where Widgets can list other Widgets they conflict with, and if you enable A, and it is incompatible with B and C, then it automatically shuts them down, instead of creating a mess. That might be the most elegant way to solve stuff long-term. Short-term, though, I really think CA should make an Official UI that doesn't suck, and quit listening to the whiners for a while.

Lastly... what "countless Widgets" are you referring to, Regret? There are maybe 30 that are really all that polished, and do something unique.

[Regret]

Good game design is not about making every possible user happy.

As many as possible to maximize potential users, you are the last person that should be talking about good game design.

I won't get into a debate with you about this as you show no sign of a worthwhile discussion.

Countless widgets because there is an infinite amount of new possible widgets to come out.

[Argh]

you are the last person that should be talking about good game design

If we're talking about dominance of the online play on the Official Server, sure. Some of us use different yardsticks, such as whether we get distributed internationally, and sell copies of our game.

I won't get into a debate with you about this as you show no sign of a worthwhile discussion.

No, you won't debate because you're not going to win, if we have a straightforward discussion about end-user requirements.

Fact is... there is no reason for CA to support un-official Widgets at all. They have more than enough programming talent to build everything they actually need in-house, or if an outsider builds something really nice, to incorporate that code.

Again, your QQ is pretty dumb. If you want your attempt at a UI to be their standard, or the alternate, then get serious about supporting their game design, and show them how it will improve the end-user's experience vs. what jK's building... but don't tell me that "endless choice" is a requirement, that's just plain stupid.

Countless widgets because there is an infinite amount of new possible widgets to come out.

Then they can get reviewed and included in the next service release, lol. Drop that straw man, it's totally un-convincing, in the context of a game with frequent service releases. It takes me maybe 5 minutes to review a Widget and decide whether it ships with P.U.R.E.

[Regret]

you are the last person that should be talking about good game design

If we're talking about dominance of the online play on the Official Server, sure. Some of us use different yardsticks, such as whether we get distributed internationally, and sell copies of our game.

I won't get into a debate with you about this as you show no sign of a worthwhile discussion.

No, you won't debate because you're not going to win, if we have a straightforward discussion about end-user requirements.

Fact is... there is no reason for CA to support un-official Widgets at all. They have more than enough programming talent to build everything they actually need in-house, or if an outsider builds something really nice, to incorporate that code.

Again, your QQ is pretty dumb. If you want your attempt at a UI to be their standard, or the alternate, then get serious about supporting their game design, and show them how it will improve the end-user's experience vs. what jK's building... but don't tell me that "endless choice" is a requirement, that's just plain stupid.

Countless widgets because there is an infinite amount of new possible widgets to come out.

Then they can get reviewed and included in the next service release, lol. Stop it with the stupid straw man- it takes me maybe 5 minutes to review a Widget and decide whether it ships with P.U.R.E.

Nothing to add here, you pretty much proven my point

[Argh]

Glad to see you've surrendered

Seriously, people. Are we going to listen to the very few people who've decided that a UI they installed a year ago is the only UI they want to use for every Spring game, or build a decent UI that focuses on the newbie experience?

A really decent UI should not need additional Widgets, unless they add directly to the gameplay experience (healthbar enhancements, AoE displays, etc.). It should be feature-complete, and solve all of an end-user's requirements, using the same graphical style.

If one of those requirements is that it's flexible, and allows for repositioning / rescaling of elements, that's fine- that's a requirement. But quit kidding yourselves that you can have your cake and eat it, too. You can't have a UI that's basically a complete experience, but in chunks, without risking creating a very bad end-user experience. And if they dragged their Widgets in from BA or wherever, and they conflict, and they're too nub to understand all that... they'll conclude that it's your fault... not some guy who wrote a crappy windowing system that doesn't auto-detect other Widgets that conflict and shuts down gracefully...

Meh. That's pretty much all I have to say about this. I just felt like expressing the arguments for a standard UI, since most end-users who are Widget lovers will QQ if you interfere with their freedom, even if it doesn't make for a coherent newbie experience.

Just as a for-instance, though... I'll bet that it'd be pretty easy to include alternative UI schemas that automatically shut down all the other UIs, so that Chilly / RedUI / IceUI could all get along with one another. Less QQ, and less mess for end-users.

[R-TEAM]

Hi,

have now played with the "new" chilly GUI (actual test version ..)

Musst say ... for ME the new resource bar is a fail.
I realy dont need to know why i have low metall/energie and which resources come partly from which sources .. this is a nice eye candy ..
but in a fast realtime game i see rare sense of this.
And i like many more the IceUI resource bars.
The same is going for he chatwindow,to much gfx with now benefit for the user - like commercial games -> many gfx,low gameplay....
And the new build menue ... only usefull for regular CA players who know exactly who which building is.
(and i use Maya with this kind of menue - here i like it )

So ATM i stuck with my lovely IceUI and if this not available on CA,
i musst play other mods.

Regards
R-TEAM

[CarRepairer]

Musst say ... for ME the new resource bar is a fail.

This is a work in progress, see the thread

The same is going for he chatwindow,to much gfx with now benefit for the user

What gfx? It's just lines of text and a small strip on the right.

And the new build menue ... only usefull for regular CA players who know exactly who which building is.

Let me correct you. "The new build menu is only useful for CA." IceUI is great (I have been using it for a year) but CA is different from most every other mod you see because the buildmenu for each constructor is complete and very long. Spring's default menu setup (which is how IceUI lists the menu items) is no longer compatible with CA because people have to go through pages and pages of things to find them. CA requires a nested solution with categories. Licho has done an amazing job with the gesture menu so far, but it's not yet complete. It's the opposite of what you say, it helps people who don't know what the buildicons are by categorizing them so they don't have to go through pages of stuff in a linear way.

[Regret]

Let me correct you. "The new build menu is only useful for CA." IceUI is great (I have been using it for a year) but CA is different from most every other mod you see because the buildmenu for each constructor is complete and very long. Spring's default menu setup (which is how IceUI lists the menu items) is no longer compatible with CA because people have to go through pages and pages of things to find them. CA requires a nested solution with categories. Licho has done an amazing job with the gesture menu so far, but it's not yet complete. It's the opposite of what you say, it helps people who don't know what the buildicons are by categorizing them so they don't have to go through pages of stuff in a linear way.

There are only 2 pages for me.

[CarRepairer]

Except that your lolui isn't compatible with CA so be gone. I was talking about IceUI and spring default menu. Let me know when your lols work with CA and I'll check it out.

[Regret]

Except that your lolui isn't compatible with CA so be gone. I was talking about IceUI and spring default menu. Let me know when your lols work with CA and I'll check it out.

This is RedUI, and it is fully compatible as you see since I use it with CA every game.