Dev meeting minutes 2011-03-21

[Pxtl]

@knorke - no, it's not an either or, but to me the big benefit of getting Assimp into the engine is the fact that Assimp provides a vector for loading animation and skeletal data. But without the engine features to consume that data, Assimp doesn't bring much to the table we didn't already have with the existing model objects.

So if I had to choose where to go from here (and I'm neither in the place to make the choice nor the user that will consume the result) I'd want to see Assimp support taken to its logical conclusion and finally see some human models with elbows and knees that actually bend - after all, if not animation, what's Assimp for? Stopping here and jumping onto another project seems to stop short of the point where all of SpliFF's previous hard work starts paying out some massive dividends.

I mean yes, Assimp adds some convenience and hopefully will streamline the import pipeline, but that isn't so much new features as it is tightening up the existing ones.

[Forboding Angel]

^^Makes an excellent point.

[Google_Frog]

I don't understand how librocket will be easier to use than chili. All I see is a difference in how windows are defined and this is a relatively simple part of a UI.

How is the coder going to gather the information for something like a resource bar? Will they need a widget to gather this information and pass it to their librocket UI? If they have to write a widget to pass values to their UI librocket is barely easier than chilli. If instead librocket has it's own spring callins there is suddenly a lot more to maintain. Would this even work with custom resources implemented in gadgets? How do game developers know that this UI does not have access to things lua does not? There is another cheating issue here that requires a lot more work for game developers to check.

If a UI element wants to interact with the game (like a command menu) the widget is far harder to write. The hardest part of this command menu is not creating the windows with chilli. The command menu widget has to set active commands, give commands to units and mess around with factory build queues. I do not see how creating this with could librocket be any easier without sacrificing flexibility.

So I am worried about where librocket UIs will get their information from and how they will perform actions on the game. The 2 alternatives that I can see are either widget -> librocket communication which doesn't actually make writing the UI any easier or an entire duplicate interface that creates all kinds of maintenance issues.

[hoijui]

@SirMaverick
i am pretty sure that spliff never advertised librocket as a replacement for chili. that must have been bad interpretation by someone. his personal reason to want librocket is, that he wants to write GUI stuff, and he does not like chili (as it is now). apart from that, it is technically not really possible, except you start removing Lua functionality from the engine for no reason, which would hurt more then just chili (when removing draw support for Lua, for example).

@Google_Frog (edit: woops, sorry :D)
widgets come with HTML, which is visualized by librocket, and the logic part is done in Lua. how is that not clear by now? and what is more complex on that then with chili?
librocket uses well known standards, and it supports MVC (which is planned for chili, according to jk). if you do not get why it would be useful, read my example (koshi quoted it).
in my eyes, there is only one way for chili to truly and fully make librocket obsolete: it would have to support the same two formats (that simplified HTML and CSS, although i do not care for the later at all), and you have to be able to bundle it with a widget, so the widget will work no matter what the game/user is using. the later is also planned for chili, if i got jk right, but the two format(s) will be different ones.
maybe we should make a poll where we explain what will be possible with chili when the planned changes are done, and what will be possible with librocket, and see how many would still want librocket. yes/no?

[Petah]

+1 for some sort of html/css gui functionality

[Licho]

Well im just trying to warn from wasted effort (and possibly adding bugged unused bloat to engine)..
Weight posts by number of lua widgetry stuff person done and you get pretty clear picture what real experts think..

Engine has lots of issues. I would rather see voice integration, fast pathing, working multithreading, model compatibility, bone animation system, custom loading screens, better win/lose control and ingame join, less OTA hacks and more control over game etc..

[hoijui]

ZK is looking quite good by now. Licho, you should stop working on it and work on the engine instead.

[zwzsg]

Google_Frog makes a good point.

GUI that have no information and perform no action are useless.

The I of GUI stands for Interface. Librocket would need input and output to interact with the engine. What would it be?

If that interfacing is done via Lua, then, having to learn Librocket HMTL/CSS in addiction to Spring's Lua would certainly make things alot harder for modder, not simpler.

If that interface is some custom one, it would need, well, years of work, and would still be lagging behind in functionality compared to Lua widgets.

And even in the idyllic case where a ton more work is poured in librocket interface than in Lua interface, you still won't have the same level of power, versatility and cleaniness that a real programming language like Lua can offer.

[knorke]

btw the last two pages were really a repetition of the original librocket thread: http://springrts.com/phpbb/viewtopic.php?f=21&t=25589
just saying.

[hoijui]

HTML and CSS not being as powerful as Lua is actually a good thing there, cause it enforces MVC, which as it sounds like, you do not understand, Z.
there was never a doubt left on that the logic would be in Lua. that is not a question.

[zwzsg]

So librocket would only do the V, while the M and C would remain Lua?

[Petah]

So librocket would only do the V, while the M and C would remain Lua?

thats how i envision it

[SpliFF]

hoijoi has covered most of the points raised so I'll just focus on what's left. Mainly this additude that developer time will be wasted as in these examples:

Finishing assimp sounds MUCH more valuable both short and long term.

Stopping here and jumping onto another project seems to stop short of the point where all of SpliFF's previous hard work starts paying out some massive dividends.

Right back when I started the Assimp project I made it perfectly clear I would not develop any animation capabilities. This has nothing to do with how my time would be best spent and everything to do with how I want to spend it. I'm not good at maths, ergo I'm not the person most able or interested in developing a maths heavy subsystem like animation.

In fact making this argument of librocket vs feature X shows a complete lack of understanding of how open-source software works. Developers are not paid, therefore they work on the things they want to work on, regardless of the community's best interests. No argument is going to change this.

Furthermore the argument implies that overall developer mindshare is lost as this unnecessary feature gets implemented. That's actually two arguments which I will address separately.

1.) It's an unnecessary feature
That entirely depends on your skillset and how you intend to use the feature - which boils down to the goals and priorities of individual projects and their team members. Arguments in this debate so far have tended towards personal preferences on both sides which means there is a very real likelihood that the productivity of some content devs will be increased by providing them with a choice.

Lets see, what else bloats the spring engine and takes up developer time in the name of choice? Perhaps it's the 6+ languages offered to AI developers? Oh yeah, that's an unnecessary feature since developers can just use the original C++ interface. What about the multiple lobbies, get rid of them too right? Perhaps starting with the ones that only run on Windows?

2.) Loss of developer time
Well sure, if you completely discount its benefits and then go on to completely ignore the 1000's of developer hours spent on librocket itself and the 1000's of hours that will be spent on it in the future by people who have never even heard of Spring. I mean by that logic why haven't we written our own OpenGL, OpenAL, SDL, 7zip, Vorbis and Boost? Hell we could get rid of C++ and Lua while we're at because you know, a lot of time went into assembly and it's so much faster. Fuck, we're just wasting time left, right and center! All you devs need to get cracking on this right away!

[smoth]

So librocket would only do the V, while the M and C would remain Lua?

thats how i envision it

but is that how it would work. I don't know if it would be that simple, seems like a lot of work would need to be done to make this work out.

I just want to reiterate the point sirmav made. even if the ui is easier to control there is no guaranty that the users will have access to the data their ui needs and may need to do lua coding all the same. Right now spring is going towards lau for almost everything. This makes learning what you need to know much easier. Adding a level of easy visual interface where people can quickly whip up ui is not really going to help speed up any ui work as the real work has to do with the actual underpinnings of the ui.

Not pro or con librocket I just feel this point was relevant to the discussion and seemed largely ignored.

[hoijui]

jk was mentioning in the meeting, that there are plans to do MVC in chili too. instead of HTML, he thinks of using XML (and i guess also XML instead of CSS, though he did not mention anything about that).

[Pxtl]

@spliFF

Sorry, I didn't realize you'd never planned on doing animations using the new framework. I had kinda assumed that was the point from the start.

And yes, I realize that a big part of open-source development is the interest of the developers - a dev working on a feature he likes will be infinitely more productive than one on a feature he doesn't.

Just remember that new features have cost beyond their implementation. They create bugs that other people will have to fix, they have gaps that require new features to be massaged in. That's why folks often cringe when somebody has a great new feature idea.

[smoth]

jk was mentioning in the meeting, that there are plans to do MVC in chili too. instead of HTML, he thinks of using XML (and i guess also XML instead of CSS, though he did not mention anything about that).

That's fine as chili is lua and it will be easier to communicate. Librocket is not, so some sort of interface or communication would have to be coded.

[SpliFF]

I get the feeling there's an awful lot of complaints based on misinformation and/or generalisations about "things" without examining the facts. I'm going to try again to clear some of that up.

The librocket website has ample information on the scripting integration and the Kong game I mentioned in the main thread has ample examples of that theory in practice. 90% of the objections made to date are based on a complete failure to listen to what is being said and/or establish the facts independently. Then people come along and quote that misinformation as fact and then blame me for not explaining things, when things were explained but simply ignored.

Has anybody objecting here even played Kong and looked at it's scripts?

To complain about librocket you have to understand it. To reiterate, Librocket is a UI middleware that uses a subset of HTML/CSS and Python script for the interactive aspects. According to the librocket authors the Python scripting was designed to be interchangeable with other languages - ie, Lua, C++ or Javascript for example.

You design the interface using common web design tools then you integrate it with your actual game using your script language of choice. In our case that's Lua and the UI component would have full access to the Lua state and all it's functions and globals. Data and function calls can be passed back and forth like with any UI.

Since your UI can call scripts, and pass events to scripts, you are no worse off than with Chili - excepting the key difference being you can still VISUALISE your UI without scripting it - ie, the scripting is independent of the design, the design is not dependent on the script. In fact the design is also largely independent of Spring itself. To put it another way, you do not require more than a simple Lua statement to load and display your design.

When you, (with you being a designer), are happy with the design you can pass it to a team member who is a competent Lua coder to make your design functional and to adapt to the changing state of the game - or you can do it yourself.

DESIGN and FUNCTION are entirely independent in librocket - just as they are with HTML/CSS/Javascript. That is NOT the case with Chili. If you want to visualise a box that's 300px by 500px, that has flowed content wrapped around an image, and can be stretched up to but no more than 700px, has shadows and rounded edges and scrolls when it overflows you better believe you're coding that in Lua with any existing framework. With librocket these details are handled in CSS using well known properties. With Chili it's a sort of mish-mash of object creation, function calls, function parameters and scripting.

In both cases you will need Lua at some point. What's being ignored is that with librocket the person who does the design need not be the person who does the Lua.

Some people here are saying that is true of Chili. It is not. There is a considerable amount of work between the Photoshop stage and the UI that the examples given completely gloss over. This stage is provided by HTML/CSS in librocket without any need to code Lua.

Librocket is designed to be lightweight and have minimal impact on existing code. You are not going to see massive framerate drops, you're probably not even going to see any framerate drop. You're also not going to have conflicts with Chili, librocket operates on a lower level. It's entire unique functionality could easily be encapsulated in a namespace, meaning as long as you don't use the word 'librocket' in your code you won't even know it's there.

Now jK can go through with his XML / MVC pattern whenever he likes but:

A.) That hasn't happened yet, and
B.) The XML format would probably be less intuitive to designers familiar with HTML/CSS and completely incompatible with the tools of the trade, and
C.) Would probably suffer a performance hit if implemented in Lua rather than C++, and
D.) Would likely lack features due to jK's time constraints and priorities versus those of the librocket team.

I would have thought all this stuff was pretty obvious. hoijoi had it figured out from his first post.

I only ever put this forward as a feature request. Since it's clear no other devs are keen to develop it I have only 2 options: forget about it or do it myself. I *MAY* do it myself. If that happens, as with the assimp project, it will happen in an independent development branch. It would ONLY be merged with Spring if the consensus was there but at least that consensus would be based on solid evidence rather than the half-arsed and outright false evidence being presented in this thread.

In short, if people feel the need to object then do it based on reality not some fucking fantasies put forward by people with no goddamn clue of how librocket works.

If and when I have librocket integrated then everyone will be free to try out the experimental builds and make their own decisions. At least then the decisions being made will be informed.

But don't take my word for it...

SpaceDude sent word that the freeware 3d shooter has now integrated libRocket into his freeware game Kong.

I now have a GUI which is easy to maintain and doesn't contain much boilerplate code if any.

- Martin Sherburn (Kong Lead Programmer, after switching from CEGUI)

[smoth]

In most examples they are using the ui code directly with their engine. Lua interfaces via callins and callouts. So there are variables that are going to be sitting in lua such as custom economies or other game related things. How will librocket interact with them.

I am not arguing that it cannot be scripted in lua, I am outright putting forth the question how will it have acess to any lua tables that the user has defined as part of their gadgets.

I am saying that the game logic will still have to be in lua.
I am saying that librocket handles ui but not interfacing with spring's specific lua setup.
I am saying that sure they might have a neat ui but then the underpinnings still have to be done and as it may require a whole new setup for actually reading gadget data may be more complicated.

so rather than be obscure and just push my question aside why not discuss it? how would this work out? Don't give me some rebuttal about my ignorance or how I just don't understand it.

[zwzsg]

I am saying that ...
I am saying that ...
I am saying that ...

They are saying it is a plus.

Separating design from coding is good.