The "secret" project unveiled - Page 3

The "secret" project unveiled

Discuss the source code and development of Spring Engine in general from a technical point of view. Patches go here too.

Moderator: Moderators

UI Lua Mod system or traditional system?

UI Lua Mod system
30
50%
"Traditional system" with layout and looknfeel (skin) defined externally
30
50%
 
Total votes: 60

User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6240
Joined: 29 Apr 2005, 01:14

Post by FLOZi »

Lua is quite Python-esque iirc. Nothing like C. :shock:


Which makes it very simple to grasp the basics of. Yay for single-line 'Hello, World' programs!
User avatar
Caydr
Omnidouche
Posts: 7179
Joined: 16 Oct 2004, 19:40

Post by Caydr »

I just want whatever's simplest to work with. I have no knowledge of LUA, so I'm voting for CEGUI.
jouninkomiko
Posts: 436
Joined: 26 Aug 2004, 08:11

Post by jouninkomiko »

PLEASE LISTEN TO ME.

CEGUI will be used no matter what. The LUA system I propose will utilize CEGUI to draw the interface, and then use lua to implement the behavior of the interface.
User avatar
Pxtl
Posts: 6112
Joined: 23 Oct 2004, 01:43

Post by Pxtl »

Caydr wrote:I just want whatever's simplest to work with. I have no knowledge of LUA, so I'm voting for CEGUI.
Seriously, I'd think you'd be more for this LUA interface. It'll allow non-TA style orders to be embedded into the GUI - which I think you'd like for the GEM mod, for example.
jouninkomiko
Posts: 436
Joined: 26 Aug 2004, 08:11

Post by jouninkomiko »

I'm going to implement first without lua, and we can eventually migrate over. The control system needs to be redone first though... after the craziness of graduation (which is this Saturday) I'll kick off the work
User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6240
Joined: 29 Apr 2005, 01:14

Post by FLOZi »

Woo!

Now, noone mention the words 'new' and 'GUI' in the same sentance until it's done. :shock:
User avatar
SwiftSpear
Classic Community Lead
Posts: 7287
Joined: 12 Aug 2005, 09:29

Post by SwiftSpear »

FLOZi wrote:Woo!

Now, noone mention the words 'new' and 'GUI' in the same sentance until it's done. :shock:
You mean like you just did?
patmo98
Posts: 188
Joined: 09 Jan 2006, 17:51

Post by patmo98 »

SwiftSpear wrote:You mean like you just did?
Meaby he meant in the same word?
Last edited by patmo98 on 12 May 2006, 16:55, edited 1 time in total.
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Post by AF »

Those words should be put through the forum word filters.

I'm all for lua based behaviour, if it's too much for you I'm sure that we'll helpout once you've got a basic API and an example or two.. Just make it accessible through the AI too. And expose the lua core while you're doing tht as it'd be nice not to have to spendages trying to get a second lua setup in a globalAI but rather include the ehaders and ask for a link through handlecommand()
Radtoo
Posts: 50
Joined: 12 May 2006, 14:21

Post by Radtoo »

I like the lua API idea more.

Simply FYI, there's also a python binding for cegui 0.4.1 in the works and already being used with the game project that develops it, over at http://svn.projectxenocide.com/xenocide ... iptModule/.
hawkki
Posts: 222
Joined: 01 Jan 2006, 19:47

Post by hawkki »

I think the problem here is that people vote without understanding what they are voting about.

I'll try to explain.

method 1 "lua": The gui is something like the current AI's. You have a way of communicating between the "outer program" and "spring engine" and using that way you do (tell the engine to do) different stuff. You could code mods that tell the engine to completely alter the look&function of the gui without touching the spring engine code at all.

method 2 "cegui": The GUI system would be coded in the engine of spring, looks&feels could be defined by setting&layout files but all modifications on how the gui works should be made by the spring developers to the engine. You could request them to add a option but you could not code it yourself as a mod.

Thats why i see method 2 as more reasonable, if something is really really needed for the gui, i think it can be added to the engine in the next release.

Now it can be that i am totally wrong but this is how i have understood this with my lacking english and coding skills :/
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Post by AF »

I think that 1 is better.

Just look at the sheer amount of requests there are tugging at the devs time without havign GUI additions there.

n#1 means we can do ti ourselves imediatly and get instant results without waiting for a enw release of spring.

#2 means we have our feature requests shunted to a lengthy waiting list which could take months to get even halfway along.....

How would you like it if mods and maps where only released when a new version of the engine was made, and had to be hardcoded in? Or if AI's where hardcoded in?

Another aspect of using the lua option for this is we can choose our own GUI style and setup, our own extra knick knacks, rather than beign forced to conform to a specific engine and just change the sounds and skin of it
alik83
Posts: 82
Joined: 08 Sep 2004, 15:32

yeah

Post by alik83 »

Yeah probably option #1 will provide more possibilities to add custom Gui elements for helper AI for example,
also how about implementing some SupCom options: make the minimap have units as icons in Nato notation like in SupCom with possibilities to give orders and drag and drop waypoints on map and minimap, that would be so sweet ;).
jouninkomiko
Posts: 436
Joined: 26 Aug 2004, 08:11

Post by jouninkomiko »

WHY THE ASDFAS!@!@$!@#!@#! WONT ANYONE LISTEN TO ME.

"method 1 "lua": The gui is something like the current AI's. You have a way of communicating between the "outer program" and "spring engine" and using that way you do (tell the engine to do) different stuff. You could code mods that tell the engine to completely alter the look&function of the gui without touching the spring engine code at all.

method 2 "cegui": The GUI system would be coded in the engine of spring, looks&feels could be defined by setting&layout files but all modifications on how the gui works should be made by the spring developers to the engine. You could request them to add a option but you could not code it yourself as a mod. "

BOTH USE CEGUI.

One has the implementation hard coded into spring, the other has the implementation outside. geeeezus read the frickin thread
User avatar
SinbadEV
Posts: 6475
Joined: 02 May 2005, 03:56

Post by SinbadEV »

Don't worry, I understand, and I'm the only person who matters. I like both ideas, and see that, as you say, it would probably be easier to impliment the "skinning" variety then the "programming an interface that interacts by api with the spring engine"...

the confusion I'm having is where the CEGUI implementation is going to be... in the case that we are just skinning the gui, and only have access to the parts of the engine that have been made expressly available to us it's inside the engine... I don't understand where the CEGUI handleing code is in the api implimentation... would it basically be in lua-bind, and basically spring would load a customer lua "script" that would define and build both a GUI and set up the hooks between the engine and said gui? so, as an artist you would have to program a GUI instead of just designing an XML document to change the look and feel.
jouninkomiko
Posts: 436
Joined: 26 Aug 2004, 08:11

Post by jouninkomiko »

Well, basically CEGUI allows a layout for a gui to be defined completely in an xml file, which is how I plan to have the gui look done in either case. Furthermore, the skin will be defined in other xml files, called scheme, and looknfeel files, which are defined at cegui's wiki. The only part that would be lua based is the registration of a new gui component, as well as the implementation of how that component would react with spring.
User avatar
SinbadEV
Posts: 6475
Joined: 02 May 2005, 03:56

Post by SinbadEV »

okay, and what's the difference between a hard coded api that defines what I can access of the spring engine and hard coding the engine to define what I have access to... they both effectively do the same thing in the end, so you might as well just do whatever's easier.

edit:

wait... I think I figured out what your talking about... I like the one where you give me a bunch of variable and I can attach whatever scripts I want to buttons and sliders in the gui to read and modify those variables... unless it's impossible...
Egarwaen
Posts: 1207
Joined: 27 Feb 2006, 21:19

Post by Egarwaen »

You have two options:

jouninkomiko's option 1) Mods can completely rip apart and replace the UI. A simple example: a mod that switches to a TA:Kingdoms-style build interface, or adds the directional factory buttons from the OTA Uberhack.

jouninkomiko's option 2) Mods can make the GUI look different, but can't seriously alter the way it works. A simple example: the various race interfaces in TA:K or Starcraft.

I think that's how it works?
jouninkomiko
Posts: 436
Joined: 26 Aug 2004, 08:11

Post by jouninkomiko »

SinbadEV wrote: edit:

wait... I think I figured out what your talking about... I like the one where you give me a bunch of variable and I can attach whatever scripts I want to buttons and sliders in the gui to read and modify those variables... unless it's impossible...
pretty much, yea. What I'm going to do is redo the control system to prepare for me putting in a new ui. Then I will put the ui in ala option 1, but in such a way that the transition to option 2 won't be rough.
User avatar
Das Bruce
Posts: 3544
Joined: 23 Nov 2005, 06:16

Post by Das Bruce »

Egarwaen wrote:You have two options:

jouninkomiko's option 1) Mods can completely rip apart and replace the UI. A simple example: a mod that switches to a TA:Kingdoms-style build interface, or adds the directional factory buttons from the OTA Uberhack.

jouninkomiko's option 2) Mods can make the GUI look different, but can't seriously alter the way it works. A simple example: the various race interfaces in TA:K or Starcraft.

I think that's how it works?
1 is the only option. 2 should be stricken from the records.
Post Reply

Return to “Engine”