Spring RTS Engine

Similar to the default build menu?

There is a old tutorial for how to make one and an example that needs updating at https://springrts.com/mediawiki/index.p ... ldid=29556.

(The current version of that wiki page simply says TODO, and is on my todo list...)

No, and I don't think there should be.
GUI is not something that's easy to make in a way that can be ported to multiple games. It's important to have good base components (e.g. chili) and functionalities implemented, which should make creating any sort of game UI easy.

Is there something you think is missing that's making the build menu creation difficult?

Maybe the fact that I don't know lua and therefore and trying to figure out what to use (currently the default).

RedUI is crap, but it has a separated orders/build menu widgets. Why is it so bad to have that for chili? I would prefer not to have super hacky crap (2 luaui frameworks) just for the sake of very basic functionality.

Why does everyone here seem to think that putting basic functionality out of easy reach is a good thing?

Edit: Thanks silentwings, at least that gets me in the right area.

Why does everyone here seem to think that putting basic functionality out of easy reach is a good thing?

They don't; that's why there is a lua tutorial, good quality documentation of the lua API, and a chili tutorial. The general feeling (as inferred from what is available) is that game devs needing to use lua and chili should learn both of them.

Speaking as someone who wrote one, a good build/order/state menu is easily amongst the most difficult things games use lua/Chili for, its not a suitable task for a newcomer to lua/Chili.

Forboding Angel wrote:Maybe the fact that I don't know lua and therefore and trying to figure out what to use (currently the default).

Maybe the real problem then is that UI needs to be created entirely with code which is hard. If only we had an ingame GUI editor

Forboding Angel wrote:Why does everyone here seem to think that putting basic functionality out of easy reach is a good thing?

Because there is no single, uniform "build menu" that will work for all games. I worked a bit on making something for MCL and it's completely different than what you'd want for ZK, Evo or BA. Essentially, it's a lot more important that you're provided with base components so you can make the UI for your game with little difficulty.
For the same reason I think chililobby's GUI won't be portable to all games (and that's OK!), and it's much more important to provide core functionality correctly.

PS: Thanks to Silentwings for going through the effort of making a good tutorial (I haven't reviewed it yet).

That is an unreasonable expectation and sets to bar of entry high enough to the point that you discourage all but the most dedicated (or terribly bored). Considering our current lack of people, that is not a good thing.

It isn't unreasonable to want all the basic UI pieces to have chili counterparts in the most basic form, especially since chili is basically endorsed as the UI framework for spring. Spring's default UI is very limited. By having chili widgets of the exact same thing you still get the same end result (Visually at least), but they are far more malleable and invite tinkering (maybe someone wants to figure out how to add more columns, or change the spacing, etc -> Tinker turns into knowledge -> Knowledge turns into more knowledge -> Rinse and repeat).

gajop wrote:Because there is no single, uniform "build menu" that will work for all games.

If that's the case, then why does the default ui exist? Your argument defeats your point.

The default UI will work (not terribly well) for at least 90% of the games built on spring currently. That's a pretty good ratio.

That is an unreasonable expectation

I think asking that anyone wanting to work on non-art aspects of Spring games should learn lua, and asking that anyone wanting to work on Chili based GUIs should learn Chili, are unavoiable and entirely reasonable expectations.

It isn't unreasonable to want all the basic UI pieces to have chili counterparts in the most basic form

It is not, but they don't and afaik no one is currently writing them - so realistically your most productive short term option is to gain a sense of altruism and start writing them.

Silentwings wrote:

That is an unreasonable expectation

I think asking that anyone wanting to work on non-art aspects of Spring games should learn lua, and asking that anyone wanting to work on Chili based GUIs should learn Chili, are unavoiable and entirely reasonable expectations.

You and I have different definitions of how chili should be used apparently.

Silentwings wrote:

It isn't unreasonable to want all the basic UI pieces to have chili counterparts in the most basic form

It is not, but they don't and afaik no one is currently writing them.

Yep, that seems to be the case, which is highly unfortunate.

Silentwings wrote:...gain a sense of altruism...

You have a lot of nerve saying some shit like this to me.

Forboding Angel wrote:

gajop wrote:Because there is no single, uniform "build menu" that will work for all games.

If that's the case, then why does the default ui exist? Your argument defeats your point.

The default UI will work (not terribly well) for at least 90% of the games built on spring currently. That's a pretty good ratio.

The problem with providing a uniform "chili build menu" is that no serious game will use it without drastic modifications. The original will not get any fixes and improvements and will end up diverging like most things do. It's troublesome to even have game-agnostic libraries and frameworks updated (I'm seeing a small number of contributions sent upstream), so one can expect game-specific things such as GUIs to fare much worse in that regard.

The only rational approach is to add and improve libraries and frameworks*, so creating things like GUIs from scratch doesn't take time and allows you to create some good looking stuff. These things *can* be maintained and updated from upstream which is the important difference.

*I think chili could use an improvement in support for lists and tables, the "layouthandler" and "control" do a poor job there.

Since you brought up the engine UI... that thing needs to die. An *engine* shouldn't have a UI. There's no benefit in providing it, and it certainly shouldn't be used by any game. There's a reason we have it completely disabled by default for all LD games.

Forboding Angel wrote:You have a lot of nerve saying some shit like this to me.

Moderator voice: Please stop attacking Silentwings, he's giving you decent feedback. (Also do not begin a discussion regarding that here).

Then don't accuse me of not being altruistic. Are you kidding me? With the amount of shit I have done for this place asking nothing in return? Don't you dare accuse me of that.

gajop wrote:

Forboding Angel wrote:

gajop wrote:Because there is no single, uniform "build menu" that will work for all games.

If that's the case, then why does the default ui exist? Your argument defeats your point.

The default UI will work (not terribly well) for at least 90% of the games built on spring currently. That's a pretty good ratio.

The problem with providing a uniform "chili build menu" is that no serious game will use it without drastic modifications. The original will not get any fixes and improvements and will end up diverging like most things do. It's troublesome to even have game-agnostic libraries and frameworks updated (I'm seeing a small number of contributions sent upstream), so one can expect game-specific things such as GUIs to fare much worse in that regard.

The only rational approach is to add and improve libraries and frameworks*, so creating things like GUIs from scratch doesn't take time and allows you to create some good looking stuff. These things *can* be maintained and updated from upstream which is the important difference.

*I think chili could use an improvement in support for lists and tables, the "layouthandler" and "control" do a poor job there.

Since you brought up the engine UI... that thing needs to die. An *engine* shouldn't have a UI. There's no benefit in providing it, and it certainly shouldn't be used by any game. There's a reason we have it completely disabled by default for all LD games.

My point was that it would make sense to bundle the latest version of chili (at the time) with the engine release in basecontent. Along with it, you could recreate all the engine ui in chili in a very basic fashion, and have it be the "default ui". It kills several birds with one stone.

I said that the engine shouldn't have a default ui over 7 years ago. *A peoples didn't take too kindly to that suggestion.

If new people want to tinker with some chili then they should look at the widgets which are used by current games. A small default UI will get outdated if nobody uses it and probably not work, this is awful for new people.

Google_Frog wrote:A small default UI will get outdated if nobody uses it and probably not work, this is awful for new people.

This. The problem is not providing a "default UI". It's the fact it would fast become useless.

We need to be able to create a good GUI easily, and is what we should aim to improve if it's still too hard or time consuming.

A small default UI will get outdated if nobody uses it and probably not work

In the case of build/order/state menu, that's exactly what already happened but Chili is much more stable now than then, so I will update sunspots old example one day. (I do not intend to make a full example UI.)

Silentwings wrote:https://springrts.com/wiki/Chili:Example_3

Comments:
1. Don't specify the name for chili controls unless you're going to search by name. It's not required, and besides taking extra time, might cause you to create name conflicts by accident.
2. Not necessarily bad, but you can specify the parent control instead of using the :AddChild method.
3. You don't need parentheses in Lua's if statements or for/while conditions, e.g. "if (index) then" can be written as "if index then". This is a general Lua thing rather than chili specific.

1. Don't specify the name for chili controls unless you're going to search by name. It's not required, and besides taking extra time, might cause you to create name conflicts by accident.

Actually, I'd give the opposite advice. In general, name controls because it makes debugging massively easier; Chili error messages identify controls by name and a non-helpful name (e.g. button483) is given if you don't specify one.

2. Not necessarily bad, but you can specify the parent control instead of using the :AddChild method.

And it says so in tutorial that I wrote https://springrts.com/wiki/Chili:Tutori ... g.2FHiding - in fact you can see both methods used in that example. Afaik they are equivalent. I tend to use AddChild for when I'm adding a temporary child, and parent= for something permanent; I am not sure if others have a convention.

3. You don't need parentheses in Lua's if statements or for/while conditions

Mhm, I didn't write that line... removed them.