I'd like to suggest there will be a LuaUI-based scriptable main menu system that will replace the aGui-based main menu which starts on running the spring.exe and spring-multithreaded executable files currently.

A LuaUI-based scriptable main menu system can provide multi-mod support.

When the gameplay session is running for the first time after the program is run, if the user "aborts" the gameplay session, it will return to the main menu.

This is more like the extended in-game GUI of test spring executables, but with more extended single-player and multiplayer and mod-changing abilities. For example, for single-player campaigns and its related missions and maps (whether solo or co-op), a briefing screen is displayed (but after an FMV event is played). As for single-player skirmishes, bots can be added, just like SpringLobby.

If possible, include 3D graphics, with amazing shader effects and materials, just like the one seen in Command & Conquer 4: Tiberian Twilight.

As in SpringLobby, it has an improved ability to load and switch between maps. It is being demonstrated on the game Kernel Panic, but the Spring game engine window closes and reopens. That is the problem. This will fix it.

If anyone could find a way to implement it, it would be better and easier for game developers and it could change the way players running the Spring engine.

I wa working a bit with chili these past few days on a project of mine. Let's just say it's not yet ready to be used on something grand like a lobby, and I don't know if any of the other current GUI frameworks are any better.

And tbh, I don't think it really matters. There are commercial games out there that have a seperate lobby client as well.

But anyhow, this is probably something that a few devs are looking into, with the recent addition of luasockets (lobby communication?) and that lualobby speculation.

spring is an engine. Not a game

Basically all of this is in jk's long term plans I believe (loadscreen changes were the first of many steps).

An engine that doesn't let your game join multiplayer games without an external program, some of which don't work on all platforms where spring goes, and so on with singleplayer, missions, campaigns (in previous versions even game settings), etc.

It is true that some commercial games have external lobby, for instance - but this just invokes the 'different != useful' argument again. The proprietary world has a lot of blunders too.

So, at least from me,


Are more than welcome. In fact, wheeeee!

I don't believe this statement is true but things may have changed over the years someone else can bother to correct or validate your statement.

"Spring" being an engine or more doesn't change much. If you look at any big spring mod/game you will notice it using at least a few common lua scripts. The same applies for some mods/games using existing lobbies, map and mod formats and so on.

Let's not get arguing over definitions "engine/game", "mod/game", "scenario/mission" and so on. Let's look at best ways to make common resources available to all mods without losing any of the abstractions (no TA-isms f.e). Whether those resources should be in the engine, lua, lobbies, lobby infrastructure, rapid, SD, site or w/e doesn't matter as long as they're not restricting modability (well it may matter a bit, lua scripts may have some limitations exporting information to other scripts/AIs(?)).

If new modders can come and use any of the existing resources to make games faster and better, we all win. It's the "standing on the shoulders of giants" that allows people to create good games.

Because his assuption is that they are based off of the same stuf. Some of the structural changes going on in 1.28 of gundam make it partially structurally incompatible with most spring games.

If you are not sure about this new LuaUI-based extended proper GUI, please see this attached image file.

http://www.moddb.com/games/gundam-rts/i ... u#imagebox

play something other than ba before you start demanding features you think spring games don't have