Spring RTS Engine

Hi,

have IceUI on all mods (besides CA :\ ) and i am happy with it.
But IceUI can going better ..

First:
#Per mod config file
With the improvement of the spring widget config system that remember the config for the different mods seperate - have many different widgets that active in different mods per config and no need to change widget setting for every mode come true - IceUI still lack this impovements...
As example:
In kernelpanic i dont need resource bars but disable it here, disable it global .. this is not nice
#More flexible resource bar system
Nearly all current spring Games comes with 2 resources - so 2 bars enough - but S44 have different naming and handling of the rersource bars and it would be nice is this implement in IceUI.
With the only mod i know with 3 resources (Gundam) the bar system musst be flexible enough to add new bars with naming.

Thats all ATM from me - with the rest i am realy happy with IceUI.

Thanks for additional suggestions
R-TEAM

ICEUI is a widget. Therefore, install the widget and disable the mod's built in gui. Don't be a idjit.

Ice UI is pretty old now compared to a lot of the other UI's. Also, Meltrax (It's developer) isn't around much any more so it hasn't had a proper updated it ages.

However, I'm using and it's still 100% fine for me.
Seriously, I have 0 problems with it and it does waaaay more than I expect it to.

It's flexible, very easily customizable, pretty, efficient, helpful, great for gameplay and all the other nice words you can throw at it.

I can be a very criticising person, and this thing gets a 10/10 from me which an amazing achievement. I've been using it for ages and me and Ice UI are closer than friends now. It's a part of my soul.

I LOVE YOU ICE UI.

He's just cranky because CA has gameplay features that aren't supported by UIs designed for standard Spring features.... and suggested that CA's gameplay should be embedded as engine features so that they're supported in a standard way. Because after all, that would make everything better.

Also, lol @ the idea that every possible Spring mod could be handled by a single GUI package without scripting so much mod-specific stuff that you'd be practically coding a new GUI per-mod anyways... which, shock, is exactly what they do.

Pxtl wrote:Also, lol @ the idea that every possible Spring mod could be handled by a single GUI package without scripting so much mod-specific stuff that you'd be practically coding a new GUI per-mod anyways... which, shock, is exactly what they do.

It could if it was designed for it.

I.e. if it was a set of skinnable / tweakable controls (NOT complete widgets) that can be combined into arbitrary forms / static GUIs in the games.

Then its not a GUI but toolbox/framework for making GUI - and there are already such things..

Meltrax isn't around...? Isn't he that guy that's been competing with me lately to see who can make the most useless posts?

Ice UI isn't all that great, from the handful of times I've used it or looked through its code. Miles ahead of the standard GUI but slow and lacking in a few features.

edit: Sorry, "Meltrax", "Tribulex", they all look the same to me.

R-TEAM, go into CA's ui widgets. Take the relevant workarounds and make a version of IceUI for CA. Off the top of my head I can only think of the E storage workaround in resource bars.

Hi,

wow - nice react of the user - dont have thinked of so much answers

@Forboding Angel
he,he - i know THIS
but ->
a, it is still not nice if i use IceUi with KP (with no problems!) and disable
the resource bars as he is not needed - then i musst enable it manualy again if i play another mod.Like in the old spring days ...
The same applys for Gundam (need 3 res bars and so i use the gundam res bar system) or S44 (other naming of the resources).
So i suggest a per mod config for IceUI ..
b, dont play with CA

@Pxtl
no - i am not "cranky"
I play CA the last month after i have managed the UI running like i like... mhhh ... ZERO times ....
Now i have read of the Pyhlons (nice idea - realy - but this was NEVER the problem of CA - have IMHO most times the best nice new ideas and GFX improvements from all spring mods that publicaly available) and think "give it a try and play an game ..".
Then i DL the latest test version .. and as i have writen in the CA mod-subforum cant get the UI to work - even without IceUI .. so i give up.It is only sad that a nice mod with superb GFX, revolutionär ideas* and new fantastic stuff is so bad in UI things.I realy think, if CA is playable with the UIs the users alrerady use, much more user would play CA.
(*= i dont like the flat techtree from CA much - but others like it maybe it is simply the "CA-way" it uses this)

@Tobi
yea - right.
Look at the available UIs .. she all look like -> The only diff is the buttons underground and mouse-pointer and maybe the one have rounded edges and the other not.
Additional come other widgets like defenceRange and unit-groups on the right side of the screen.
So i realy dont understand the "every mod need a own gui" thing ...
The only available differences i have listet in my first post.
(more than 2 resources and different naming of the rersources,additional come the CA hacking to reflect his energy/metall system - but this i have suggestet to built in engine code to have a more flexible way to doing such things ...)

@Google_Frog
he,he - it is not that i am unhappy with the CA UI - it looks nearly the same as IceUI (have rounded egdes and more colors to look more modern ... all things that in an RTS who i musst concentrate on many things and have no time to look of nice details from the UI i dont say i prefere it over the IceUI look ....).
But have not managed to get it work even without IceUI.

Am I the only one still using default gui?

Yes.

Hi,

I think it is anything basicaly wrong with the Ui system on spring ...
The main reason to have different UIs is not the different look,(she all
look nearly the same ...),it is the problem to get the right data for the mod to the UI ...
This is nice - but the FULL wrong way to handle different UIs !
A Ui act as a Link between the user and the programm ...
Who is handled or generatet intern variables have the UI not harm !
In an ideal way - the UI become over an standard API his parameters.
The radar view.
The unit buttons.
The resource bars.
The Tooltips.
The Chat window.
If this all come over an standard API - the different UIs can easy switched without problems.
But ATM - its look no API exists (or is too old or/and to unflexible) and
every Ui make her own system who is more ore less compatible with the rest of UI widgets .....
SO we need an actual API for an UI system who let the UI doing HERE job (act ONLY as an graphic interface to display the data and get input from the user) and the engine his job - or os this not possible,
add an aditional Layer between the UI and the engine to reflect mod specific handling but get an standard UI API to let the user use HIS UI he like ...

When you lay out the spec of that API, make sure it accounts for stuff such as:

- Not showing metal & energy in KP, in all the places they would usually show up. Cutting the clutter of default GUI was one of the main motive behind customising the GUI.
- Showing KP's shield info, in a way appropriate relatively to which ONS type is used.
- Showing KP's team buffer, but only on unit that can dispatch.
- Showing KP's airstrike and firewall buildup (or charge time?)
- Showing KP's "memory" in SoS/SoM gamemode.
- Specific the UI to use greenish computerish style in KP: if the UI was using graphic of woodden button for instance, it really wouldn't do it. And having bland grey everywhere would be sad.
- Showing KP's tip dispenser, in a place visible but not disruptive.
- Showing KP's ingame menu to load game, start skirmish, pick map, etc...

- Showing Gundam's three custom resources.
- Showing Gundam's fourth resource, power.
- Showing Gundam's mecha loadout.
- Showing Gundam's tech levels.

You see, the trouble is that Spring games like to be more than a reskin of TA, and no, it's not just a matter of swapping the resource name, mods custom resources sometimes behave differently and have to be represented differently. Also, the interface is part of the game, having a nice polished GUI designed specifically for the game feels much professional that trying to bend the TA interface into displaying what it was never meant to. I'm afraid complicating things with an intermediate layer won't help at all having the degree of freedom and of control and of interaction necessary between the mod and the UI.

Out of curiosity, can I see screenshots of what it looks to play KP and Gundam with IceUI? (If I tried it, I'd set it up wrongly, so it wouldn't be fair.)

so is meltrax still around to improve it?

IceUI is a framework too, adding a third ressourcebar should be really easy, it has controls: combobox, progress bars, windows,labels, tabs etc

Yeah, good luck coding for it - you cannot force people to use something for their widgets. Threads like this are completely pointless.
Chili is the only framework for which most of the widgets are coded by other people than author (and it has superior design and performance), but still it's sometimes hard to convince even CA devs to use it.

In a perfect world every game would have their own UI, that you wouldnt need to modify at all.

Teutooni wrote:Am I the only one still using default gui?

No.

JohannesH wrote:In a perfect world every game would have their own UI, that you wouldnt need to modify at all.

Or even get to.