UFO:Alien Invasion
Development => Coding => Topic started by: Hoehrer on March 23, 2006, 10:05:53 am
-
Since i really want to see research implemented in the game as soon as possible i have basically two questions:
* What does work already (and how/where) ?
* What needs to be done code-wise and content/text-wise to get the basics working?
I suspect all the relevant code is in src/client/cl_research.c (http://svn.sourceforge.net/viewcvs.cgi/ufoai/ufoai/trunk/src/client/cl_research.c) and src/client/cl_research.h (http://svn.sourceforge.net/viewcvs.cgi/ufoai/ufoai/trunk/src/client/cl_research.h), so I might have a look into this in the next few days. But every hint is welcome, 'cause learning everything from the code is rather slow :-/
Werner
-
well,
the weapons and items have a flag "researchNeeded" - if this flag is 1 you are not able to use the item/weapon. These items/weapons should come up in the research menu.
Have a look at game/q_shared.h. you'll a a typedef to objDef_t with all current researchflags included. the weapons.ufo includes the researchneeded flags for all alien weapons.
if any questions left - feel free to ask
-
Ah, thanks.
if any questions left - feel free to ask
Yeah, one question. Do we already have a list or number of hired scientists?
If not i wuold just add a simple int to client.h. But if there is a better place please tell me.
typedef struct base_s
{
//the internal base-id
int id;
char title[MAX_VAR];
int map[BASE_SIZE][BASE_SIZE][MAX_BASE_LEVELS];
qboolean founded;
vec2_t pos;
// to decide which actions are available in the basemenu
byte hasHangar;
byte hasLab;
int NumScientists; <-- add this one??
...
Werner
-
typedef struct building_s
{
// FIXME: This can be a char* name and char* base.... don't it? See bmData in basemanagement.c
char name[MAX_VAR];
char base[MAX_VAR];
char title[MAX_VAR];
char *text, *image, *needs, *depends, *mapPart, *produceType, *pedia;
float energy, workerCosts, produceTime, fixCosts, varCosts;
int production, level, id, timeStart, buildTime, techLevel,
notUpOn, maxWorkers, minWorkers, assignedWorkers;
//if we can build more than one building of the same type:
buildingStatus_t buildingStatus[BASE_SIZE*BASE_SIZE];
int condition[BASE_SIZE*BASE_SIZE];
vec2_t size;
byte visible;
int used;
// event handler functions
char onConstruct[MAX_VAR];
char onAttack[MAX_VAR];
char onDestroy[MAX_VAR];
char onUpgrade[MAX_VAR];
char onRepair[MAX_VAR];
char onClick[MAX_VAR];
//more than one building of the same type allowed?
int moreThanOne;
//how many buildings are there of the same type?
//depends on the value of moreThanOne ^^
int howManyOfThisType;
//position of autobuild
vec2_t pos;
//autobuild when base is set up
byte autobuild;
//autobuild when base is set up
byte firstbase;
//this way we can rename the buildings without loosing the control
byte isLab;
byte isHangar;
struct building_s *dependsBuilding;
struct building_s *prev;
struct building_s *next;
} building_t;
if the isLab flag is set we can use the assignedWorkers (which are scientists in a lab) to get the amount.
-
Ok, so i need to check how many labs there are and sum up the number of "assigned workers" of each to get the total numbers of scientists, am i right?
Werner
-
yes you are right - and fast with your replies ,too :-D
-
Ok, i found the "B_HowManyPeopleInBase" function cl_basemanagement.c
SHould i modify this to accept a second parameter (type of people .. e.g. 0=all, 1=scientists, 2=workers, 3=soldiers) or create a second (mostly redundant) function e.g. B_HowManyScientistsInBase instead?
Werner
-
right now there is no difference between workers, soldiers and so on - the type of people in a base resp. building depends on the building-type. maybe you can add a second parameter - would be best to ask whether a building is a lab, or something other...
-
Ok, i'll make it so it returns the people in the different rooms and all people depending on the second parameter ... it's not on high priority though ;)
Another (more important) thing i'm thinking about is a structure for the techtree/researchtree in ufo format that provides the relationships between the researched items. I'll post a mockup as soon as i get my troubles with the x-server under control (posting under knoppix right now).
What i need to know with the ufo-techtree is how i get this into C-variables. Is there a 'common' parser or do i need something special in C?
Not that i'm lazy, but you might have more experience with this ... If i post the mockup, could you provide me with this pasing things in C?
EDIT the first draft .... comments/critics are welcome. This is meant to be a new ufo-file that links together all the technology that it listed in the other ufo files and some new "pseudo' technology/research items that are only there to provide additional infos and some basic starting points.
//--------------
// research tree
//--------------
// This is just an example of how we _could_ implement a simple researh tree.
//item
// The _unique_ name of the research item in the tree.
//type
// Just says where to look for more information.
// "research" items have all the information in here, everything else in the correct ufo file.
//name
// self-explaining i hope :) Only needed when type=research
//requires
// if you get an alien-item everything that it requires is made available for research (tree top/down)
// e.g. collect a plasrifle -> get the plasma technology but not the plasmpistol.
// The plasrifle itself will not be researchable until the plasmpistol has been researched.
// "initial" - You can research this tech from the beginning.
// "nothing" - You need to collect at least one item (that requires it directly or indirectly) to be able to research this.
// everything else - a research "item"
//provides
// The item name in the correct ufo file. This can be produced once the research item has been finished.
//time
// Time the research needs.
// If time is 0 the item can be produced at the same time the "required" item can be.
// TODO: good values that are in sync with the game-time.
// TODO: A good algorithm for splitting up this time over several scientists.
//-----------------------------------------------------
item tachyon
{
type research
name "Tachyon control"
requires initial
description "tachyon_txt"
time 100
}
item tachyonrifle
{
type weapon
requires tachyon
provides tachyonrifle
time 200
}
item tachyonrifle_ammo
{
type weapon
requires tachyonrifle
provides tachyonrifle_ammo
time 0
}
item tachyonsniper
{
type weapon
requires tachyonrifle
provides tachyonsniper
time 300
}
item tachyonsniper_ammo
{
type weapon
requires tachyonsniper
provides tachyonsniper_ammo
time 0
}
//-----------------------------------------------------
item plasma
{
type research
name "Advanced plasma technology"
requires initial
description "plasma_txt"
time 100
}
item plaspistol
{
type weapon
requires plasma
provides plaspistol
time 300
}
item plaspistol_ammo
{
type weapon
requires plaspistol
provides plaspistol_ammo
time 100
}
item plasrifle
{
type weapon
requires plaspistol
provides plasrifle
time 500
}
item plasrifle_ammo
{
type weapon
requires plasrifle
provides plasrifle_ammo
time 0
}
//-----------------------------------------------------
item irgoggles
{
type weapon
requires initial
provides irgoggles
time 200
}
item nano
{
type research
name "Nano technology"
requires initial
description "nano_txt"
time 200
}
item nano_armor
{
type armor
requires nano
provides medium
time 400
}
item nano_hull //this is just an example of multiple "requirements"
{
type craft
requires nano_armor plasma
provides craft_hull_medium
time 1000
}
Werner
-
have a look at the parser in cl_basemanagement.c
maybe i can help you with that if i find the time - no big deal.
the structure looks reasonable
-
maybe you have to rename item to research or something like that - item is already a known parserentity.
have a look at client/cl_main.c function CL_ParseScriptSecond. here you can add your parser.
-
great job so far - researching works - but i think that showing the finished items in list is not a good idea - we need to keep the list small - othervise there may be more than 28 items. maybe we have to put this into the statistics view.
-
great job so far - researching works - but i think that showing the finished items in list is not a good idea - we need to keep the list small - othervise there may be more than 28 items. maybe we have to put this into the statistics view.
I see your point and this is just a test-implemention after all, but your logic fails anyway, because it is possible that more than 28 items are available for research at one time ... in theory that is ;)
In this case i'm all for a scrollable list .... but that has a low priority right now though.
I'm currently writing on the parser for the ufo files and alot of functions to access the resulting data. Most of it works (at least in theory .. since i haven't tested it yet) but alot of minor things need to be fixed/finished before we can start linking the research to the rest.
Will commit some of the changes soon.
Werner
-
i've implemented the parser for the technologies - use the command "technologylist" to list them in console. anything else i can do?
-
i've implemented the parser for the technologies - use the command "technologylist" to list them in console. anything else i can do?
Whoo, a working skeleton for the techtree, something i can work with .. sweet, thanks a lot :D
That is enough for me to continue my work ... just need to adapt some of my pre-written functions/code.
Werner
-
I've just commited a function named R_GetName to cl_research.c
it's a very basic function (... there are alot more yet uncommited), but i always have problems handling the stringcopy and stringcompare functions because i get errors. I need to resolve this, becasue all the other functions will sue this alot :-/
../client/cl_research.c:417: warning: array subscript has type 'char'
../client/cl_research.c:436: warning: array subscript has type 'char'
../client/cl_research.c: In function 'R_GetName':
../client/cl_research.c:465: warning: passing argument 1 of 'strcmp' from incompatible pointer type
../client/cl_research.c:467: warning: passing argument 1 of 'strcpy' from incompatible pointer type
It compiles, but i'm sure this'll cause some problems. I'm not a c-guru (more of a perl one ;)) , so i'm a bit lost on this... any hints on what am i doing wrong?
Werner
PS: i've added an additional "techlist" command to prevent alot of unneeded tzpos and faster input ;) ... will not be needed after research is done.
-
Looks to me, like u choose the false arguments.
char *bla
Try maybe
void R_GetName( char *id, char *name )
ox
-
Looks to me, like u choose the false arguments.
char *bla
Try maybe
void R_GetName( char *id, char *name )
Ah, that was it ... many thanks to you ox :D
Werner
-
It's me again.
No prob :)
Seems like you are from Germany, maybe check this (http://home.fhtw-berlin.de/~junghans/cref/FUNCTIONS/strcpy.html) bacause of the stringtermination(\0)
ox
-
Seems like you are from Germany,
Bin aus Östereich (Niederösterreich/Wien) , aber _fast_ richtig :)
maybe check this (http://home.fhtw-berlin.de/~junghans/cref/FUNCTIONS/strcpy.html) bacause of the stringtermination(\0)
I know how termination and string-handling in c works in general, but i just dislike the way strings (muahaha string-length-handling and string2number conversions ... that's a good one ;)) and parameter-handling works in c [1] ... other languages (not only perl) are designed to prevent most of the problems you can encounter .... but that's not the topic and doesn't help us (me) in this case ;)
Werner
[1] i know that i wouldn't have this problems if i used more C/C++, but nearly ever language i've seen/used until now has more and easier way to do this.
-
Ok, i finally switched from the data stored in the inventory to the one in the research code/files.
To quote myself (svn log)
* MAJOR: Finally switched from researchNeeded/researchTime to data stored in the research.ufo ("technologies" list)
** drawback: Right now the internal name are used. There are several workarounds possible, but i aim for the full solution.
This it the second big step (after the parser) to a fully working research system :D
Werner
-
i've added saving and loading to research stuff - but i'm not sure what is all needed to save/load the stuff. please have a look at the new code at the end of cl_research.c
btw. incremented savefile version to 3
-
i've added saving and loading to research stuff - but i'm not sure what is all needed to save/load the stuff. please have a look at the new code at the end of cl_research.c
btw. incremented savefile version to 3
Cool. i'll have a look at it when i'm sure my last major commit didn't cause any problems, but it seems to be ok. The only thing i've added is the "time"! value, because this'll change when research progresses.
Werner
-
time value is a float
i changed this to ReadFloat resp. WriteFloat functions. anything else? does it work?
-
time value is a float
i changed this to ReadFloat resp. WriteFloat functions. anything else? does it work?
Ah, thanks.
Not completely. e.g Try researching tachyon-technology and the saving -> exit ufo:ai compeltly (just in case) -> loading.
But i need to figure out if this is a problem with researchtree-marking or save/loading.
Werner
-
I've added RS_MarkResearchable after loading the values. This should fix loading/saving of the tech-tree. But this need some major testing.
An alternative would be to save statusResearchable as well. Is there a preferred way (static values vs. recalculated values)?
Werner
-
are you sure one can use MSG_WriteByte (and read) on an enum like that:
typedef enum researchStatus_s
{
RS_NONE,
RS_RUNNING,
RS_PAUSED,
RS_FINISH
} researchStatus_t;
Just wondering
Werner
-
yes, that should be ok
-
@hoehrer:
assignment of scientists should only work when the research is started already - what do you think? or maybe start the research after assignenment automatically
-
@hoehrer:
assignment of scientists should only work when the research is started already - what do you think? or maybe start the research after assignenment automatically
Yes, the semi-autmatic way was my plan.
As soon as you add a scientist to a research item you not only automatically assign a room, but also start the research. On the other hand removing _all_ scientists will pause the research.
Will add that behaviour when i get some time again.
I also planned to automatically add at least one scientist if the "start" button is pressed, but we'll see how that works out.
The most difficult thing with the research.system still remains the init-, save- and load-behaviour for the research-tree and the employees in the base. Currently if you start a new game and research something you will get messed up data when then starting a new game again.
One question: Are the icons on the bottom to "start/resume" + "pause" the research self-explaining without reading the tooltips?
Werner
-
One question: Are the icons on the bottom to "start/resume" + "pause" the research self-explaining without reading the tooltips?
One answer: yes :-)
The most difficult thing with the research.system still remains the init-, save- and load-behaviour for the research-tree and the employees in the base. Currently if you start a new game and research something you will get messed up data when then starting a new game again.
I can hava a look at this, too. The saving and loading works as expected, but starting a new game will fail...? right?
-
One question: Are the icons on the bottom to "start/resume" + "pause" the research self-explaining without reading the tooltips?
One answer: yes :-)
Good. :)
BTW: How do i change the icon (and maybe tooltips as well) of the start-button from c-code?
There are 4 images in the research-button image, so i figured i will use the second pair to display what's going on and make the icons even clearer in context.
I first planed to do this:
Start/Stop button
* START - starts the research (if not automatically done already)
* STOP - will remove all scientists fromt he research and free the lab
Pause/Unpause button
* PAUSE - pauses the selected research (scientists will remain in lab) -> research just stops
* UNPAUSE - unpauses the selected research -> research continues
Currently i don't know if 'pausing' the research is even needed, because you can't use the scientists elsewhere and you have to remove them anyway. to do so. I'll look into this.
Nevertheless, knowing a way to change the images/tooltips is still a good thing :)
The most difficult thing with the research.system still remains the init-, save- and load-behaviour for the research-tree and the employees in the base. Currently if you start a new game and research something you will get messed up data when then starting a new game again.
I can hava a look at this, too. The saving and loading works as expected, but starting a new game will fail...? right?
Yes, to be more precise: starting a new game or loading another game AFTER you already played a game (and resea4rched something) will fail.
No sweat though. I think i'll solve that by creating a "sceleton" research-tree that on game startup, that is copied (not linked) on new or loaded game and then merged with the correct data. The selecton-tree will remain unchanged.
EDIT: i've commited a fix. Please test if there still are problems with new game/load game after already playing(researching).
Werner
-
Hoehrer. I've been looking at your research.ufo format, and I think I understand your "reverse" dependency thing a bit better now. In fact it's reversed the way it is now, since the system looks forward in the tree for its dependencies, not backwards.
Can you change the system so you can specify actual items in the "required" field, not just types? Also, can you add a field "min_required", an integer that specifies the minimum requirements that must be satisfied before the tech becomes available? Also, I think there should be a control structure, possibly using [] brackets, so you can say:
requires min_required 2 [
plasma_pistol
plasma_rifle
plasma_grenade
]
requires [
Alien_Plasma_Technology
]
This would mean: You must have at least two of the plasma weapons mentioned, and you must also have Alien Plasma Technology.
That way, it will be possible to create more advanced tech trees, and it will be more intuitive (IMO, anyway).
-
Oh, and nesting.
requires min_required 1[
requires[
live_alien_commander
]
requires min_required 2[
live_alien_worker
live_alien_psionic
live_alien_soldier
]
]
So you need either one commander OR two non-commanders.
By the way, I'm not trying to dump your research system here - I just want to make it more versatile.
-
Hmm, i'll need to think about that.
Some points in my mind:
* The reverse lookup (bottom-up) for requirements will not be changed.
It works just fine and is pretty slim. I've written a top-down system for another game and it was not as easy to use.
Just see below for more.
* The main point from out discussion:
"You need to have the item collected and all requirements researched."
This is a matter of some code-additions and a tag like
needs_collected true
in the ufo file.
But i need some time to sort that out. don#t expect this to happen in the next time ... but maybe you get lucky ;)
* You don't need to directly 'require' the live_alien_commander from the battlefield.
The plan is to have a tech-entry for _every_ item in the game.
So you just put a requirement to a researchable
tech alien_live_antarean_commander
type tech
upchaper aliens
requires nothing
provides live_antarean_commander
The "type tech" says that it will not be available as a produceable item.
The word "provides" is a bit irritating here since you can't 'produce' the provided item ;)
You can now use "requires alien_live_antarean_commander" in other techs.
* Require multiple 'collected' items -> That's a feature for thze far future, but keep it in your designs. it needs alot of changes to the current system.
* If you haven't seen this yet: Currently you require multiple technologies like this
requires "plasma nano"
If i forgot an issue just ask.
Werner
-
* The reverse lookup (bottom-up) for requirements will not be changed.
It works just fine and is pretty slim. I've written a top-down system for another game and it was not as easy to use.
It'll work, yeah. It's just not how most people think - that's why I was confused for so long. I totally hadn't expected reverse-lookup.
But i need some time to sort that out. don#t expect this to happen in the next time ... but maybe you get lucky ;)
Okay. As long as it's possible to create a "reverse engineering" style of weapons research I'm happy. Whether we'll use it that way is another matter - but it should not be disallowed, I think.
* You don't need to directly 'require' the live_alien_commander from the battlefield.
The plan is to have a tech-entry for _every_ item in the game.
...
Myeah, I was just planning to apply it to items directly. For example, you can't research "hovernet autopsy" without having Hovernet Wreckage A, Hovernet Wreckage B and Hovernet Wreckage C. You wouldn't be able to research them separate. But, well, I can live with not being able to do that. If you decide to put it in later, that'd be great.
Also, for completeness: We want "timed" requirements for some techs, for example the Geneva Conventions issue. This will be instrumental in some advances in the storyline.
-
Ok, this i'll answer before i go ....
* The reverse lookup (bottom-up) for requirements will not be changed.
It works just fine and is pretty slim. I've written a top-down system for another game and it was not as easy to use.
It'll work, yeah. It's just not how most people think - that's why I was confused for so long. I totally hadn't expected reverse-lookup.
Yes, i know, but once you know it's done like it is' as logical as any other way. Sorry for the inconvenience.
* You don't need to directly 'require' the live_alien_commander from the battlefield.
The plan is to have a tech-entry for _every_ item in the game.
...
Myeah, I was just planning to apply it to items directly. For example, you can't research "hovernet autopsy" without having Hovernet Wreckage A, Hovernet Wreckage B and Hovernet Wreckage C. You wouldn't be able to research them separate. But, well, I can live with not being able to do that. If you decide to put it in later, that'd be great.
You can do that with the current code as well, this is similar to how ammo is handles right now. EDIT: or not.
Please remind me in irc or something so i can write a testcase if possible.
-------------------------------
There is currently a "collected" attribute internally for a tech. it just says 1 or 0 for now, but this can be changed later on to use more that 1 .... it just needs to be coded.
Also, for completeness: We want "timed" requirements for some techs, for example the Geneva Conventions issue. This will be instrumental in some advances in the storyline.
Yes, i'll have to look into the event-system mattn mentioned on irc. This really needs to be implemented, because we could then even "require" news and otehr game events.
Werner
-
But i need some time to sort that out. don#t expect this to happen in the next time ... but maybe you get lucky ;)
Okay. As long as it's possible to create a "reverse engineering" style of weapons research I'm happy. Whether we'll use it that way is another matter - but it should not be disallowed, I think.
Ok, i've recently implemented the "needscollected" in the research tree.
See the research.ufo file for examples (see the plasma and tachyon weapons) and a short description.
To sum it up: if you set this tag to "true" for a tech you can only research this technology/item if you have researched all requirements AND have some (currently 1+) collected items.
Werner
-
Hoehrer, something just occurred to me when I was looking at the research topic descriptions (as a result of this (http://ufo.myexp.de/phpBB2/viewtopic.php?t=80&start=30#878)). We currently have a single description for every research topic, but I think we should have two. One pre-research, telling the player roughly what the research is about, and what the expected results will be, and one post-research, which would be the one we have already. Do you think you could add support for that in the research screen?
-
We currently have a single description for every research topic, but I think we should have two. One pre-research, telling the player roughly what the research is about, and what the expected results will be, and one post-research, which would be the one we have already. Do you think you could add support for that in the research screen?
Hm, should not be that much of a problem. It's a good idea and i'll probably integrate it after the next release.
Werner
-
It's a good idea and i'll probably integrate it after the next release.
Where should the text for those descriptions go ?
-
It's a good idea and i'll probably integrate it after the next release.
Where should the text for those descriptions go ?
I imagined them next to the normal descriptions in the technology_t struct. Something like the following (names might be changed):
char description[MAX_VAR];
char description_prereseach[MAX_VAR];
And the compelte text is handled exactly like the 'description one is now ... in the .po files.
That was the plan. I haven't come around to implement this, but it's a rather easy tweak I think ... except for the text itself.
This way we also reduce the amount of pre-research extra entries in the research.ufo file since we can combine two of 'em. I you know what i mean.
Werner
-
Where should the text for those descriptions go ?
To clarify: Where should contributors submit those texts ?
There are wiki-pages for http://ufo.myexp.de/wiki/index.php/Storyline/Final
and http://ufo.myexp.de/wiki/index.php/Research, but no place to put
suggested texts about research-items...
-
To clarify: Where should contributors submit those texts ?
There are wiki-pages for http://ufo.myexp.de/wiki/index.php/Storyline/Final
and http://ufo.myexp.de/wiki/index.php/Research, but no place to put
suggested texts about research-items...
I suggest to put then in an extra header "==Pre-Research description (proposal)==" (just below the 'official description') into the single research entries here:
http://ufo.myexp.de/wiki/index.php/Research
and here
http://ufo.myexp.de/wiki/index.php/Equipment
An alternative would be to use the talk pages of the entries, so only 'confirmed' information is on the main page.
Werner
-
See TODO page on the wiki, section Creative writing, where it's all described (for a month now, I guess), with a link to an example Pre-research Description.