The "secret" project unveiled
Moderator: Moderators
For the love of God, please just choose the option wiyth less GUI-lag... the GUI response time is terrible and is a big wall in the way of OTA players adapting Spring- commands dont appear instantaneously is the biggest thing; there's a quick wait before you 'see' your action, and this is a huge frustration, especialyl at the fast pace of more competitive games.
If we do one, could we have 2 but using dll's? Thus allowing us to compile groupAI's, globalAI's that modify the GUI?
I can imagine a GroupAI that modifies the GUI totally form say OTA style to Generals style.....
As long as I can create windows and components using GroupAI's and globalAI's, and issue custom signals/events between different groupAI's, then I'm Happy...
I can imagine a GroupAI that modifies the GUI totally form say OTA style to Generals style.....
As long as I can create windows and components using GroupAI's and globalAI's, and issue custom signals/events between different groupAI's, then I'm Happy...
-
SwiftSpear
- Classic Community Lead
- Posts: 7287
- Joined: 12 Aug 2005, 09:29
Can we get an example of what kind of thing would be made possible/impossible in the differing ground between option 1 and option 2?
From what I understand option 1 would take more development effort and be less customizable for mods, and possibly create more speed robbing processes through it's lua implimentation... I don't see any advantage to this at all, it seems to be everything we don't want in a GUI.
I'd love to move away from the traditional system of development here at spring where if a modder wants the spring engine to do something new for them they have to bug the already overworked spring dev team to make whatever change they need. This is being overly propagated by the tag system, and it sounds like the lua method would end up being similar... Is the downside of the second option that it would create more work for modders in the end? Because I think that would be much much less of a problem once a few GUI content packages have been created that people can edit, rather then having to make a new GUI from scratch for each mod.
From what I understand option 1 would take more development effort and be less customizable for mods, and possibly create more speed robbing processes through it's lua implimentation... I don't see any advantage to this at all, it seems to be everything we don't want in a GUI.
I'd love to move away from the traditional system of development here at spring where if a modder wants the spring engine to do something new for them they have to bug the already overworked spring dev team to make whatever change they need. This is being overly propagated by the tag system, and it sounds like the lua method would end up being similar... Is the downside of the second option that it would create more work for modders in the end? Because I think that would be much much less of a problem once a few GUI content packages have been created that people can edit, rather then having to make a new GUI from scratch for each mod.
Look at the AI we have, and seehow that would be impossible if we had to work directly in the Spring engine.
Imo, we should have at least the ability to define dll's that modify the interface, at least then there's a wider range fo features we cna implement, for example an update notifier, or a chat window that allows you to chat in the lobby etc.........
Imo, we should have at least the ability to define dll's that modify the interface, at least then there's a wider range fo features we cna implement, for example an update notifier, or a chat window that allows you to chat in the lobby etc.........
-
SwiftSpear
- Classic Community Lead
- Posts: 7287
- Joined: 12 Aug 2005, 09:29
Is one of the UI options directly in the Spring engine? From the way it's being described it sounds like both UI systems are externally defined, just that one is being processed through lua... for some reason...AF wrote:Look at the AI we have, and seehow that would be impossible if we had to work directly in the Spring engine.
Imo, we should have at least the ability to define dll's that modify the interface, at least then there's a wider range fo features we cna implement, for example an update notifier, or a chat window that allows you to chat in the lobby etc.........
-
jouninkomiko
- Posts: 436
- Joined: 26 Aug 2004, 08:11
Both are externally defined insofar as their layout and looknfeel. The difference is where their implementation is located. In the implementation of a resource bar, here is a brief overview of how the 2 implementations would work.
In the first (non lua) the layout and looknfeel describing how the resource bar are located in xml files external to spring. Spring internally hooks into the resource bar (and will exit if it doesnt find one), and every frame, updates the numbers and sliders to reflect the current state.
In the 2nd (lua) the layour and looknfeel are done in exactly the same way. This time, however, Spring is not expecting a resource bar, in fact, one isn't even required. The folder containing the lua scripts is scanned, and this mod called "ResourceBar" is found, which registers itself with spring and also registers to a "RESOURCE" event, which is known to be sent every frame. Then, every time a RESOURCE event is sent by spring, all mods that registered that event get the lua function they bound that event to called, and the mod processes that event as it sees fit. In this case, it updates the sliders, all the numbers, etc. The only reason there is a resource bar in spring is because it found a ui mod that defined one and displayed it to the screen. In a sense then, ui mods could be made alongside the AI dlls, but we'd need to figure out how we'd let an AI dll extend the ui mod api so that it gets access to specific AI information that you might want displayed.
Right now it seems that a majority of people just want a gui now, and to leave extendibility for later. I think that might be a good idea too until we have a better idea of what is needed to grant extendibility. Maybe we can compile a requirements list somewhere, and we can get a general design going, while new gui work continues within spring itself?
In the first (non lua) the layout and looknfeel describing how the resource bar are located in xml files external to spring. Spring internally hooks into the resource bar (and will exit if it doesnt find one), and every frame, updates the numbers and sliders to reflect the current state.
In the 2nd (lua) the layour and looknfeel are done in exactly the same way. This time, however, Spring is not expecting a resource bar, in fact, one isn't even required. The folder containing the lua scripts is scanned, and this mod called "ResourceBar" is found, which registers itself with spring and also registers to a "RESOURCE" event, which is known to be sent every frame. Then, every time a RESOURCE event is sent by spring, all mods that registered that event get the lua function they bound that event to called, and the mod processes that event as it sees fit. In this case, it updates the sliders, all the numbers, etc. The only reason there is a resource bar in spring is because it found a ui mod that defined one and displayed it to the screen. In a sense then, ui mods could be made alongside the AI dlls, but we'd need to figure out how we'd let an AI dll extend the ui mod api so that it gets access to specific AI information that you might want displayed.
Right now it seems that a majority of people just want a gui now, and to leave extendibility for later. I think that might be a good idea too until we have a better idea of what is needed to grant extendibility. Maybe we can compile a requirements list somewhere, and we can get a general design going, while new gui work continues within spring itself?
hmm yet another compilation of what needs to be done, we already have the previous list still up on the wiki from when you last asked........
I'm thinking you should aim at getting soemthing similar to what the New GUi was originally meant to look like or what the current GUI is and then people can see that and figure out howto skin it from the example you've given and then create their own skins....
I'm thinking you should aim at getting soemthing similar to what the New GUi was originally meant to look like or what the current GUI is and then people can see that and figure out howto skin it from the example you've given and then create their own skins....
I've dug up the wishlist once made for a 'new' GUI.
http://taspring.clan-sy.com/wiki/New_GUI (this will be accesable in the wiki main page from now on).
Most of it can be solved by making the users possible to rearrage the build pics (mod bound) and customise the shapes of the frames.
Also by allowing them to define a set of short-keys for commands/buildings.
Other feature requests are asked all over the forum. I've gathered them in the wiki.
http://taspring.clan-sy.com/wiki/New_GUI (this will be accesable in the wiki main page from now on).
Most of it can be solved by making the users possible to rearrage the build pics (mod bound) and customise the shapes of the frames.
Also by allowing them to define a set of short-keys for commands/buildings.
Other feature requests are asked all over the forum. I've gathered them in the wiki.
Two days ago, I was for the option 2.
Bit I have take my time ...and now, I'm for the option 1.
Because :
It would be better for modder, because they could more easly make mod wich are not in the way of OTA, by choosing to display, or not display something. (For exemple, you could make a building wich display a list of all unit near him, or make a windows wich display all units selected.)
You will able to choose to react differently if a special unit is selected etc..
(Stop me Juninkomiko if I'm wrong.)
For player :
The option 2 allow you to have your skin, but option 1 allow you to have your skin, plus choose how to display it, what to show, and how. (for exemple, one can have the small info windows at a corner, and an another could have it popup under the mouse, like in the newGUI)
Edit added :
For mission (yeah, nobody now) :
It could allow to make special window for your mission, like people who ask you someting, and you could choose "yes" or "no".
Better, for use map setting, you could have windows wich display info, or what you're imagination can.
(And if one time I'm or someone else is motivated to make a mission editor, it could be really cool to have option 1)
BUT if it take more than 2 times the time it take to make option 2 ... I don't know if it worth the cause. It's you, Juninkomiko to know if you have enough motivation to do and finish it.
About CEGUI skin, perhaps IceXuick would me motivated to make something? Have you contacted him to explain?
How, and everybody seem to like to say the "Spring Engine" so, option 1 or more in the way of a "Spring engine" than option 2
Bit I have take my time ...and now, I'm for the option 1.
Because :
It would be better for modder, because they could more easly make mod wich are not in the way of OTA, by choosing to display, or not display something. (For exemple, you could make a building wich display a list of all unit near him, or make a windows wich display all units selected.)
You will able to choose to react differently if a special unit is selected etc..
(Stop me Juninkomiko if I'm wrong.)
For player :
The option 2 allow you to have your skin, but option 1 allow you to have your skin, plus choose how to display it, what to show, and how. (for exemple, one can have the small info windows at a corner, and an another could have it popup under the mouse, like in the newGUI)
Edit added :
For mission (yeah, nobody now) :
It could allow to make special window for your mission, like people who ask you someting, and you could choose "yes" or "no".
Better, for use map setting, you could have windows wich display info, or what you're imagination can.
(And if one time I'm or someone else is motivated to make a mission editor, it could be really cool to have option 1)
BUT if it take more than 2 times the time it take to make option 2 ... I don't know if it worth the cause. It's you, Juninkomiko to know if you have enough motivation to do and finish it.
About CEGUI skin, perhaps IceXuick would me motivated to make something? Have you contacted him to explain?
How, and everybody seem to like to say the "Spring Engine" so, option 1 or more in the way of a "Spring engine" than option 2
-
SwiftSpear
- Classic Community Lead
- Posts: 7287
- Joined: 12 Aug 2005, 09:29
As I've undersdand, it's in the second !SwiftSpear wrote:So in the first case if spring goes looking for a resource bar and it doesn't find one it crashes? So we're locked into a system that requires a resource bar? This isn't my definition of more customizable...
I think Juninkomiko just mixed them
From poll :
From Junin Post :First : UI Lua Mod system
Second : "Traditional system" with layout and looknfeel (skin) defined externally
In the first (non lua) [...]
In the 2nd (lua) [...]
from what i understood
in lua method, you have a standart GUI and you make patches (mods) to it
so if you make a mod "ressource bar" a bar appears
in non lua method .. didn't realy understood how it would work ..
but, with lua :
-- Spring exposes an api for getting data as well as issuing commands
means you can do almost whatever you want with it as long as it is in the API
which imo is nice
-- Doing this requires that an api be made, which will limit the things the UI can do
how hard to do would that be ? i think most of it will be copy/paste ain't it ?
so 2nd option (non lua) seems easier to use as almost no knowledge is required but 1st seems more powerfull
as Zenka said is it possible to do non-lua first then upgrade it to lua ? or is it totaly different ?
in lua method, you have a standart GUI and you make patches (mods) to it
so if you make a mod "ressource bar" a bar appears
in non lua method .. didn't realy understood how it would work ..
but, with lua :
-- Spring exposes an api for getting data as well as issuing commands
means you can do almost whatever you want with it as long as it is in the API
which imo is nice
-- Doing this requires that an api be made, which will limit the things the UI can do
how hard to do would that be ? i think most of it will be copy/paste ain't it ?
so 2nd option (non lua) seems easier to use as almost no knowledge is required but 1st seems more powerfull
as Zenka said is it possible to do non-lua first then upgrade it to lua ? or is it totaly different ?
Just keep in mind youre expecting modders and casual players to learn a completely new programming language to add superfluous features (since all the basic spring functionality will already be there hopefully), and considering most spring mods have OTA-style unit and gameplay behaviour for simple 1+1=2 reasons it follows that most modders wouldnt bother changing anything but the looks of it since all the functionality they need will already be there. Option 1 will only be worth it when spring is much more flexible, regardless of the wishful thinking we see here.
Frankly, lua is not an hard language to learn if you already know a programming language.krogothe wrote:Just keep in mind youre expecting modders and casual players to learn a completely new programming language to add superfluous features (since all the basic spring functionality will already be there hopefully), and considering most spring mods have OTA-style unit and gameplay behaviour for simple 1+1=2 reasons it follows that most modders wouldnt bother changing anything but the looks of it since all the functionality they need will already be there. Option 1 will only be worth it when spring is much more flexible, regardless of the wishful thinking we see here.
I'm sure people will be able, at the beggining to copy existing script, and modify a bit the default behavoir.
( Just look at the testscript.lua , there is just only some cryptic lignes at the beginging, but I'm sur most of the user could be able to add some message at any time, send attack command to a unit, or create some units )
