The "secret" project unveiled

[jouninkomiko]

Okay, after spending time learning Lua, tolua++, and the new CEGUI from their latest stable development trunk (which is quite different than the 0.41 thats out at the moment), I'm ready to embark on my formerly "secret" project, which deals with the new gui. As I see it, there are 2 options I've come up with, and I'm turning to the community to see which is the desired option. World of Warcraft utilizes a lua-based UI mod system which includes an api for modders to create an interface, obtain data from the game, and interact with the core executable. I was thinking of doing the same for Spring, but the far greater amount of work will be feasible only if the community has a need for it, so I set up a poll for it. Here is a description of the 2 options:

1) Extendable Lua based UI mod system
-- Each UI component registers to events Spring issues
-- Responsible for drawing itself using what CEGUI has to offer
-- Spring exposes an api for getting data as well as issuing commands
-- Doing this requires that an api be made, which will limit the things the UI can do, and the data it has access to
-- Potential for mods to be made giving access to data it normally shouldn't have
-- Will take alot longer to make than doing it the normal way, due to the need for an api
-- Slower

2) CEGUI, the normal way
-- GUI interaction defined mostly in Spring
-- Layout and skin can be defined externally in Lua, but there won't be a means of extending functionality
-- Faster
-- Faster development time
-- Interface can be "richer" due to it having access to ALL spring data
-- Limits cheating that can be made present using the other method

These are serious considerations, so please discuss!

[NOiZE]

I would choose for faster.... Spring isn't that fast now, so we wouldn't want to slow it down anymore would we?

[Zenka]

I have little knowledge of lua.
But seeing the pro's and cons, I say option 2: CEGUI.
You mention it's more customisable, faster and faster to make.
The only reason not to use it, is becouse you cannot drasticly alter the GUI?

[Machiosabre]

As cool as lua sounds I have to go for cegui aswell.
Unless some mods want to do anything awesome that would require a customisable gui.

[Targ Collective]

I'm assuming that modders can create thier own GUIs using the 'normal' way?

[Machiosabre]

I think the difference is that they can make it look different but they can't add any new stuff.

[FizWizz]

that's what I got out of it.

[jouninkomiko]

I think the difference is that they can make it look different but they can't add any new stuff.

That is correct. From what I heard, the speed difference isn't drastic, unless you do some stupid stuff. Furthermore, both options use CEGUI, since CEGUI has lua hooks in it as well. Basically, the issue here is customizability and extensibility (option 1) vs richness of UI (option 2), but both options allow skinning and the layout in external files

[jouninkomiko]

Either way, we need people going to http://www.cegui.org.uk/wiki/index.php/Main_Page and learning Falagard (the skinning system for CEGUI) as well as schemes etc. Check the wiki and the tutorials, since I still will need people designing each part of the UI and creating skins since the ones CEGUI comes with definitely don't serve our purpose. In option 1, my job will be to provide an api and the community will need to rewrite each UI component as an external "mod", whereas in option 2 I can implement each part and let the community create a new skin and help with the layout xml files.

[Pxtl]

Fantastic. Now I can embark on my suicidal personal project - Arcade-Spring (warning, requires God's own display screen).

the goal: fit a whole RTS on one screen. No scrolling. No jammers. No fog-of-war. Why? Because all the players share a single screen, a-la-super-smash-bros. The gui would of course have to be totally rescripted, because each player get's their own pointing device, menus, etc.

Would be a very tricky project - keep units teeny-tiny and barely visible, but still discernable from long range. Shorten firing ranges because shooting more than one screen is pointless.

Of course, playing with a screen smaller than a projector is suicide.

[jouninkomiko]

Wow. Yea the functionality to do that WONT be there

[alik83]

Great that you are working on the GUI system again, jouninkomiko;)
What exactly means in option 1)
"- Potential for mods to be made giving access to data it normally shouldn't have"
And how it differs from option 2) when " -- Interface can be "richer" due to it having access to ALL spring data"

What I really want is a customizable GUI that interacts with all kind of regular spring data (gui elements, mouse, ingame variables), and customizability means for ex. that you can tie some event or variable value to a key or button(maybe defined in xml file?),
PLUS the possibility to tie gui elements to custom variables (or/and even custom events) .
For example you define some variables in text file for your AI or helper AI or for yourself(Player) like percentage of buildspeed per resources, AI agressivness or whatever variable you need, and later you can specify (in xml file?) a gui element(Button, slider) for that custom variable.
This would be extremely usefull for creating helper AIs, making any custom information available to player and providing any kind of specific controls a player needs.
And I beleive a simple version of that wouldn't be EXTREMELY hard to implement.
That's all I can think of now, probably other people would like that "custom variables tied to gui elements" option too
Alik

[jouninkomiko]

What exactly means in option 1)
"- Potential for mods to be made giving access to data it normally shouldn't have"
And how it differs from option 2) when " -- Interface can be "richer" due to it having access to ALL spring data"

Well, the lua scripts will have access to whatever we give them through the api.. for example:

GetResourceInformation(resourceId) or
GetUnitInformation(unitId) or
IssueCommand(unitId, command) etc.

Depending on what the API exposes, a mod can be written to give users of that mod an unfair advantage, such as enemy unit information (if that is included in the API for whatever reason), LOS details, etc. What I meant for option 2 is that... based on what decisions we make about the API, lua scripts will have limited functionality. So if we want to do something "crazy cool" using hard to get internal spring information and issue a series of complicated commands, that will be difficult or impossible since the API for lua scripts is limited. Its a tough problem rooted in figuring out what the API should expose, and how it should be exposed.

**NOTE** Lua can call c++ class member functions as well, if we choose to expose them

I personally LOVE the idea of having it all scripted, but realize its a daunting task. Furthermore, more and more customizability will ALWAYS be desired, which makes it a tough problem to solve right from the getgo. However, I can see an evolutionary API that changes with each release and adds additional functionality enabling the UI to do more and eventually replace the "old ui". If the community will make use of this, then its worth the work, which is why I'm asking in the first place ^_^

[Pxtl]

It depends who defines the mod. If the gui-mod is part of the game-mod, or something otherwise controlled by the admin, then it only makes sense that the gui mod could have enemy unit info. It only becomes a problem if different users are using different gui-mods (which, I assume, was your original intent of the moddable gui).

[alik83]

Well as long as it will have regular customizable gui elements (defined in xml file?) plus an option to draw custom gui elements tied to custom variables(from some text file) that would be all I want

[AF]

I demand a lua API that i can draw widnwos with using GroupAI's, instead of resorting to drawing image son the map, which will be far slwoer.

That and I thought the CEGUI lua stuff was more than simply just hooks? Is there no inbetween allowing us todo 2 but have some of 1, and overtime we can add n# 1 should we need ti but use #2 for the core stuff most people use????

[PauloMorfeo]

... Lua ...

Didn't Lua had issues with working on Linux? How did that ended up? New version is fine on Linux?

[Comp1337]

Wouldn't nr 1 attract lots of ... skilled people to the Spring project?
Simply being able to make your own totally unique GUI is very rare for something this advanced, and opensource. (As far as i know.)
Also AF demands an API, you heard the man!

(All respect for that jounin doesn't have infinite time on his hands. You rock. All the devs rock.)

[diggz2k]

I say go with the faster one

I don't see an awesome group of modders trying to make a real free highquality mod that differs that much from our standard ta and ta-like games.

If such a group exists or comes into existence that needs the additional functionality then go with number 1.

P.S. What kinds of things can you do with the first one that you can't do with the second?

P.P.S. Did I make sense?

[jouninkomiko]

I guess I wasn't very clear... so I'll make an attempt to explain better:

In the first case, everything the GUI can do is compiled in with spring, but the layout and looknfeel and everything is abstracted outside in xml files and scripts. Therefore, you can't extend the gui per se, but you can change how it looks.

The second option defines both the look AND the behavior externally. That is, NONE of the gui is compiled in spring, and we define UI components (like a resource bar) as a mod which hooks in to spring. An example of this could follow something like this:

A resource bar "mod" can draw both energy and metal bars similar to what is in spring now, and register to the SPRING_RESOURCE_UPDATE event, linking it to a lua function. When the resources need updating (which will happen often) the lua function is called and is passed the appropriate data, so it can update the component to reflect the change in resources. Another mod, like the command bar to the left, can call a function in spring from the lua script when a button is clicked to issue the appropriate command, etc.

So the primary difference is that behavior is moved to lua scripts, but the data it has access to and the calls it can make to spring are limited to what is exposed by the api. In either case, you control the look and layout of the GUI externally.