The "secret" project unveiled
Moderator: Moderators
Ok just to clear it up
We have a slider in our fancy new spring 2.0 with new GUI absed on CEGUI
We want the sldier todo soemthing, this is where the 2 options come in
Slider gets moved....
Either:
The logic telling the engine what todo when the slider is moved is inside the engine.
Or:
The engine calls a lua script telling it the sldier moved and it's upto the lua script todo the job, allowing the suer to define different behaviours..
Example 2
We have any empty GUI we need to populate it do we::
Have a standard GUI defined in the engien and we can change hwo ti looks by skinning it
OR
look in a folder of lua scripts and make the lua scripts populate the GUI, allowing users to define multiple GUI's that look and behave differently, instea dof just havign a different skin.
We have a slider in our fancy new spring 2.0 with new GUI absed on CEGUI
We want the sldier todo soemthing, this is where the 2 options come in
Slider gets moved....
Either:
The logic telling the engine what todo when the slider is moved is inside the engine.
Or:
The engine calls a lua script telling it the sldier moved and it's upto the lua script todo the job, allowing the suer to define different behaviours..
Example 2
We have any empty GUI we need to populate it do we::
Have a standard GUI defined in the engien and we can change hwo ti looks by skinning it
OR
look in a folder of lua scripts and make the lua scripts populate the GUI, allowing users to define multiple GUI's that look and behave differently, instea dof just havign a different skin.
- Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
ya know the irritating thing is... I see a lot of writing but I don't see any physical work being put into the gui yet.
If you want to start a discussion about how the gui should be there are already tons of threads about it.
Is any work ACTUALLY being done on it at this moment. For some reason I'm thinking no, which means we are no closer to getting a new gui than when this thread started.
A little irriting to see just talk and 0 action. Heh, look at american congress on illegal immigration. All talk, no real action = frustrating.
If you want to start a discussion about how the gui should be there are already tons of threads about it.
Is any work ACTUALLY being done on it at this moment. For some reason I'm thinking no, which means we are no closer to getting a new gui than when this thread started.
A little irriting to see just talk and 0 action. Heh, look at american congress on illegal immigration. All talk, no real action = frustrating.
- SwiftSpear
- Classic Community Lead
- Posts: 7287
- Joined: 12 Aug 2005, 09:29
-
- Posts: 436
- Joined: 26 Aug 2004, 08:11
Before I can actually start I'm going to have to redo part of the control system so that I can make it flexible enough to stick in a new gui without hacking it in, like was previously done. It's the reason there is no "new gui" even though 95% of the code was written. Now all of that code gets to be scrapped so CEGUI can be incorporated. When it happens, you'll get screenies, no sooner.
(I'm balancing a full time summer job as well as my last summer with my friends and family EVER. I'm moving 3000 miles away. Work will occur in spurts when I have time, which is lookin something like 15 hours a week)
(I'm balancing a full time summer job as well as my last summer with my friends and family EVER. I'm moving 3000 miles away. Work will occur in spurts when I have time, which is lookin something like 15 hours a week)
Does this mean the Command structure and CommandDescription type system will be replaced?
I'm not sure but something more abstract for that would be useful, aswell as the ability to handle sending messages using it to get stuff and returning it without having to format it as an vector<float> or resorting to void*.
I'm not sure but something more abstract for that would be useful, aswell as the ability to handle sending messages using it to get stuff and returning it without having to format it as an vector<float> or resorting to void*.
-
- Posts: 436
- Joined: 26 Aug 2004, 08:11
The command system is quite flexible IMO, and not many commands are being sent so it does not influence performance.
Changing it would also require a lot of changes in all the unit CommandAI classes.
I think what you're looking for is a message based AI system, but that can be done independently of Command (The Commands would be generated by the thing that handles the AI messages).
Changing it would also require a lot of changes in all the unit CommandAI classes.
I think what you're looking for is a message based AI system, but that can be done independently of Command (The Commands would be generated by the thing that handles the AI messages).
At this rate the sub AI you speak of will be changed anyways, if there are enough bugs in their logic as it is and a lack of changes to support several other things then I'm going to have to rewrite and arrange them in the summer and port as much off into dll's like has been done with groupAI and globalAI.
One other problem is the way data is shunted around, aside from having to typecast to get rid of compiler warnings all over the place, there's no way of communicating with other AI's in multiplayer games if they're on different systems, or of transferring non numberical data
One other problem is the way data is shunted around, aside from having to typecast to get rid of compiler warnings all over the place, there's no way of communicating with other AI's in multiplayer games if they're on different systems, or of transferring non numberical data
I don't think it really matters if we use dlls or not...(the issues with using dlls have more to do with well defined interfaces and project files and any technical limitations). But the ability to add functionality into a scripting system would probably make a more flexible gui api.
One thing I fully understand about what your trying to do is put the api just in dlls like the ai stuff is at the moment or just in a scripting language...or did i miss the point?
Wouldn't it make sense to do both and worry about the dll loading mechanism later (I'm sure I'll have a look at that before we hit 1.0 to simplify the way dlls/so/dylib/bundle's are loaded). Especially since the interface would pretty much be the same if you just export the class's interfaces directly using a subsystem approach.
Lorenz (Krysole) Pretterhofer <krysole@internode.on.net>
One thing I fully understand about what your trying to do is put the api just in dlls like the ai stuff is at the moment or just in a scripting language...or did i miss the point?
Wouldn't it make sense to do both and worry about the dll loading mechanism later (I'm sure I'll have a look at that before we hit 1.0 to simplify the way dlls/so/dylib/bundle's are loaded). Especially since the interface would pretty much be the same if you just export the class's interfaces directly using a subsystem approach.
Lorenz (Krysole) Pretterhofer <krysole@internode.on.net>
-
- Posts: 436
- Joined: 26 Aug 2004, 08:11