Spring RTS Engine

I've seen seen a couple of RCSS rules that don't exist in CSS3 but on the whole a standard HTML WYSIWYG is going to give a pretty reasonable approximation.

For the other questions the answer is basically yes, all those things are supported. The full list of elements and styles is on the librocket website. Yes the UI can be modified using scripting, yes things like drag and drop are supported, and yes, it should be integrated in a way the whole engine could use it (for built in settings, lobby, frontend etc).

the way i imagine it, this is most useful for independent widget creators that need GUI stuff.
lets say, i write a widgets with a small GUI; a graphical native AI spawner. you choose the team from a list, the AI type (AAI, KAIK, ...), and then press the [Run] button. I write this GUI in HTML without any style/CSS. This could then be used in BA and ZK, which both supply their CSS to make it visually fit in. maybe we can even find a way so the game can define a dedicated place on the screen where 3rd party widgets would place their GUIs, so it would not mess up the games default GUI stuff.

nice to hear you may jump into this spliff!
finishing assimp first sounds like a good plan though.

This sounds like a huge waste of effort.

And yes, chili does support automatic resizing ...

Improving chili is much more cost effective way, and games are already using it (ZK, S44, Gundam, EvoRTS, Cursed).

hoijui wrote:I write this GUI in HTML without any style/CSS. This could then be used in BA and ZK, which both supply their CSS to make it visually fit in

+X, where X >> 1

I understand that you are personally quite attached to chili and feel it is sufficient but I have to be frank with you - I think it's a pretty average GUI. Your comments assume that the underlying limits of the GUI can be solved with the same amount of effort it would take to hook up librocket but you really can't back that up nor can I dispute it so it's a pretty pointless argument to get into.

Again though you are completely ignoring the fact that Lua and chili are both completely alien concepts to most designers and any reliance on them means a steep learning curve. This fact alone makes librocket superior. If you then factor in that librocket also appears to be better documented and contains a richer set of style and widget options then the gap just widens.

If you feel chili is sufficient I can't change your mind but at the same time I simply don't buy into your claim. I am very impressed with the time and effort that has gone into all of Spring's existing GUI frameworks but all else being equal I would pick librocket for my own game every time.

I'm afraid to get excited about this because my main worry is that my cock gets all hard and I end up with blueballs.

Suffice it to say, I'm pretty sure that most of us less talented content people would repeatedly blow loads over the functionality.

I'm pretty sure that most of us less talented content people would repeatedly blow loads over the functionality.

What makes you think "less talented content people" know enough about webdesign to make this work? Its not so easy either.

knorke wrote:

I'm pretty sure that most of us less talented content people would repeatedly blow loads over the functionality.

What makes you think "less talented content people" know enough about webdesign to make this work? Its not so easy either.

Yes it is... You could probably learn to make HTML in your sleep and while initially frustrating, css is simple enough for your mother to learn.

Now... I'll grant that it's no easier to make it pretty it would be easier for you to find a talented web-designer then a talented "Lua programmer who is also a GUI programmer"

Because of what sinbad said, and I, being one of those less talented, know php/css/html.

Hey, while you're at it, replace lua with php

The sample here: http://springrts.com/phpbb/viewtopic.ph ... 9&start=19 seems a bit more complicated then <h>My first Heading</h1>
Spring.Echo ("my first echo")
What I do not see in that example is something that decides where on the screen that menu gets drawn?

Just to understand, the above link would be a teamselect.html for example.
And on the widget side?
Like this? (just guessing)
in teamselect.lua: Passing Lua variables to the html part would be possible too I guess, how would that look like?

But overall sounds like it would be a very usefull addition. If the documentation on how to make it work is good, I am sure it will get used.

after many thinking:

in short: +1 for librocket in the engine:

for new game devs, it would be much more interesting, to learn how to create a gui in librocket as in chilli. chilli is spring only, the knowledge of librocket can be reused in other games, too. there is/are also more documentation + examples. also it uses github: https://github.com/lloydw/libRocket

i'm unsure how much time it would take to integrate it into spring so that it is useable, thats a really big con.

i think its good, to see what happens with the assimp-support, so maybe lets wait a bit befor doing work here.

i don't know much about technical stuff: could/does librocket increase performance in comparison to chilli?

I was sure I wrote more here. I still see it as a huge waste of effort and a potential source of instability.

The core reason for librocket seems to be "To make it easier for new game devs to make games". This is the statement I dispute.

Of course it is easier for someone who knows html but not lua to make a UI mockup. Unfortunately this does not translate into an advantage in ease over chilli when writing the UI. Most of the complexity in chilli widgets is in the interface between Spring and the state of the widget. Actually displaying the information and taking user input is very simple for the widget writer as the chilli framework handles it. I get the impression that librocket will interact with widgets which then interact with Spring so I do not see how this part of writing the UI is easier.

So from what I have heard, to get a working UI a game dev team will need someone to code the interaction with Spring in lua. Chilli is dead-easy for someone who knows lua enough to code the UI backend, for them defining the UI elements to display is chilli is basically no extra work.

Then the counter-argument follows that the designers has more control if there is a clear separation between what they do and do not understand. But I am not convinced that it is particularly important, the html-only competent person could easily make a design layout image for the lua coder (which I still have reason to believe must exist).

Anyway in the entire process of creating a game someone will have to know lua. So while librocket may be more applicable elsewhere, lua is necessary for a large part of the rest of the game. So there will be a lua coder somewhere. Also if you know enough lua to write a unit script you can edit window locations and sizes in a chilli widget.

jk himself agreed upon it being good to split the design from the logic (which is, btw, a defacto standard through the MVC pattern). he said he plans to do that with Chili too (i think he said something about some well known XML based format for UI design).
for me, that functionality in Chili would make librocket obsolete, but for others it may still not be a totally clear thing (eg. simplified HTML vs XML).

Well a while ago I dared to make a widget... learning lua sounded okay, learning spring api was a challange. I thought, but it was actually a horror since there was no complete documentation and only finished it cause I had Niobium at mumble (which I didnt even know he was spring dev before).
Meeting with opengl code in lua was scary and just hearing about chilli doesnt ease my mind yet.

As a webdeveloper...
Hearing about HTML+CSS integration is an enlightment, and a thought I had when coding in lua. But... still... The greatest effort of writing a widget still lies in the horrible api documentation. HTML + CSS wouldn't change that a single bit.

A good point could be that the game/mod could adjust the apearance more easily I just guess by applying diffrent classes. But... still... the shape would quitte stay the same apart from coloring/texturing.

Getting the layout in lua isn't the pain it is the code beneath. I could hammer my entire ui out in 2 evenings but getting all the relevant data and functionalities months man.

Has anyone seen a good tutorial on implementing librocket(not in spring)? I'm struggling to make heads or tails of their examples.

basic integration: http://librocket.com/wiki/documentation ... rinterface

+ http://librocket.com/wiki/documentation ?

imo their documentation is a good tutorial.