current source state? (Akari?)

  • Thread starter Thread starter Cyberman
  • Start date Start date
Status
Not open for further replies.
Thanks G for explaining the projects current build system if I have questions they'll end up in this thread I suppose.

Is there a data flow diagram of information exchanges and changes within Q-gears?
I'll have to look sometime tomorrow to see what is in the repository etc.

Scarily these days I spend very little time implementing and instead architect system function, and data instead.

Cyb
 
Is there a data flow diagram of information exchanges and changes within Q-gears?
I'll have to look sometime tomorrow to see what is in the repository etc.
Take a quick read through the gears pdf. It's older but it gives you a good idea of how the modules interact. As for reading Akari's code, it's fantastically well built and definately something to be proud of. It's well thought out and super easy to read.
 
Is there a data flow diagram of information exchanges and changes within Q-gears?
I'll have to look sometime tomorrow to see what is in the repository etc.
Take a quick read through the gears pdf. It's older but it gives you a good idea of how the modules interact. As for reading Akari's code, it's fantastically well built and definately something to be proud of. It's well thought out and super easy to read.
Yes I know the diagram from the early days of the project, the problem is I am certain things have changed since then, and that is more or less is what I was looking for.
Akari's code fortunately is an easier read (than mine) I can doxygen it later to get a better idea. I was just curious if the data flow and transformations were diagrammed or not. (is the doxygen project file included with the file set or do I have to DIY it?)

Cyb
 
There is neither data flow diagram nor Doxyfile in the project. I doubt, that creating Doxygen documentation will help, as there isn't any comments in doxygen format.
 
Hey I've got it all compiled fine and it runs lets me get to console etc. No response from /field /battle etc commands don't appear to do anything, the screen just stays black. Console input does work as /quit operates as expected. Maybe an opengl issue (dell 1420 with intel integrated). On the debug compile all goes smoothly. I'm having some issues with the release compile, but I'm sure I can be figuring it out.
 
There is neither data flow diagram nor Doxyfile in the project. I doubt, that creating Doxygen documentation will help, as there isn't any comments in doxygen format.
I doubt it would help if I added any doxygen comments, either since I am not the original author.  I've seen lots of arguments between self documenting code and adding good comments.  I've spent a year using doxygen thus far. So I'm somewhat familiar with it.  Someone inexperienced using it might have lots of questions.  I know I am just beginning to use some of it's features.

Oh well I guess it's dig through the code instead.

Cyb
 
Ok so I've been playing around with what's around so far and it's pretty freaking awesome. I managed to figure out how the commands work and stuff. I still can't figure out if i'm doing something wrong with the battles yet though, but i'll keep poking around, that's for sure. Very very cool work guys.
 
So right now i'm trying to understand how the lua script files for the menus work. Here's what I've got so far.

Binder.cpp binds the ModuleManager functions RunField,RunMenu,RunBattle to lua. In lua to call these you would use module:run_field(116) for example. Communication runs through the boost thread g_ModuleManager.

That part seems nice and clear.

Now I'm trying to look at what happens when RunMenu gets called.

ModuleManager makes a new MenuModule and passes in the menu_id. It then goes and spits out "MenuModule created."
Some how the OnStart function gets run (i'm thinking that's an ogre thing?) and then it goes through and creates a new MenuScriptManager
That MenuScriptManager is used to MenuScriptManager.LoadFile("data/menu/simple.lua")
The Load then opens and runs the script.

The Script then runs and becuause after the script is loaded the state is set to MODULE_RUN nothing shows up. If you make it so that after the script loads the state is changed to MODULE_FINISH you can make a module:run_field(116) call and it then shows and works.

I think i just needed to type that out, and I don't know if i have an actual question, but pointers in any which direction would be helpful i think.

*edit yet again*

So it seems like binder.cpp is missing a bind for setting the state of module so you can actually get out of the script. I haven't for the life of me been able to get the script to exit and continue on execution of the game. Maybe I just don't understand the logic in the construction of how it works or how to actually get it to exit, definately toss some advice myway if you've got it.

*edit-- man this is like a stream of consciousness*

I just found the scripts for the functions and maps and i'm going to go through those and hopefully they'll solve my questions.

md1_1.xml has an error.  For encounters it should be 28.125 no 28,125.
 
Last edited:
So right now i'm trying to understand how the lua script files for the menus work. Here's what I've got so far.

Binder.cpp binds the ModuleManager functions RunField,RunMenu,RunBattle to lua. In lua to call these you would use module:run_field(116) for example. Communication runs through the boost thread g_ModuleManager.

That part seems nice and clear.

Now I'm trying to look at what happens when RunMenu gets called.

ModuleManager makes a new MenuModule and passes in the menu_id. It then goes and spits out "MenuModule created."
Some how the OnStart function gets run (i'm thinking that's an ogre thing?) and then it goes through and creates a new MenuScriptManager
That MenuScriptManager is used to MenuScriptManager.LoadFile("data/menu/simple.lua")
The Load then opens and runs the script.

The Script then runs and becuause after the script is loaded the state is set to MODULE_RUN nothing shows up. If you make it so that after the script loads the state is changed to MODULE_FINISH you can make a module:run_field(116) call and it then shows and works.

I think i just needed to type that out, and I don't know if i have an actual question, but pointers in any which direction would be helpful i think.

*edit yet again*

So it seems like binder.cpp is missing a bind for setting the state of module so you can actually get out of the script. I haven't for the life of me been able to get the script to exit and continue on execution of the game. Maybe I just don't understand the logic in the construction of how it works or how to actually get it to exit, definately toss some advice myway if you've got it.

*edit-- man this is like a stream of consciousness*

I just found the scripts for the functions and maps and i'm going to go through those and hopefully they'll solve my questions.

md1_1.xml has an error.  For encounters it should be 28.125 no 28,125.
There is no menu yet. Just some drafts. Better play with fields. There are really a lot of things that can be done.
 
Updated to Ibex. Compile works fine, run fails.

qgears_debug: ../common/dri_bufmgr_fake.c:1054: dri_fake_reloc_and_validate_buffer: Assertion `bo_fake->map_count ==0' failed.

I am damn confused. I can't find that file, and searching the project for the dri_fake_reloc doesn't pop up anything. Any advice?
 
Updated too, so far no problems, this can be related to your video card drivers.
 
Interesting note. I rolled back a few of my code changes. I had it set to auto-run "field 116" after I removed that it worked fine for "field 65" and "field 110" I'll keep playing around with it and see what happens.

Oh and i popped out a quick patch for the  md1_1.xml file. It just changes a , to a . where it should be.
http://www.tcnj.edu/~liskove2/md1_1.patch
 
Last edited:
it's a video card problem. i had some weird issues with my ati card recently when trying out ta3d game, and they were caused by issues with mesa/video driver.
 
Well I'll keep working on things and see if I can fix anything.  I don't really understand how it could let me run other things but just not the first two opening maps...

I've got a new computer in the works for December. If worse comes to worse I'll just get back on the horse then. I would like to get cracking though.
 
Well I'll keep working on things and see if I can fix anything.  I don't really understand how it could let me run other things but just not the first two opening maps...

I've got a new computer in the works for December. If worse comes to worse I'll just get back on the horse then. I would like to get cracking though.
You need walkmesh, models script and description file to run other field. Walkmesh and Models could be obtained through exporter. Script and desctiprion something that you need to write yourself (at least script).
If you want try to make next field - I could send you walkmesh and models.
 
I don't quite need those files yet I think. I was just detailing the what/when of the crashing.

Before upgrade when i would run /field 116  and it would run through the first 2 with no issues. Now that one in particular fails.

I still only about half way through figuring out the field model. Monday i should have a couple hours to dedicate to it.
 
00014xw9
 
Wow thats just awsome Akari

from the looks of things you can now put bad guys in can you put cloud and co in and can they attack
 
It appears you have the battle scenes and battle models working. This is good news.

Are you using information from the battle encounter file to populate the battle scene?

Cyb
 
It appears you have the battle scenes and battle models working. This is good news.

Are you using information from the battle encounter file to populate the battle scene?

Cyb
It use battle.xml which has converted scene.bin info about battle formation. This is just test battle where I put MP to this location. There are a lot of unknown info so I can't reproduce everything for now. I'm trying to create battle cycle now and make unit execute script each turn (without any animations, only logic).
 
Status
Not open for further replies.
Back
Top