Which makes it very simple to grasp the basics of. Yay for single-line 'Hello, World' programs!
The "secret" project unveiled
Moderator: Moderators
-
jouninkomiko
- Posts: 436
- Joined: 26 Aug 2004, 08:11
-
jouninkomiko
- Posts: 436
- Joined: 26 Aug 2004, 08:11
-
SwiftSpear
- Classic Community Lead
- Posts: 7287
- Joined: 12 Aug 2005, 09:29
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()
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()
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/.
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/.
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 :/
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 :/
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
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
yeah
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
.
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
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
"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
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.
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
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.
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...
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...
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'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
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.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...
1 is the only option. 2 should be stricken from the records.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?