Research code

[Mattn]

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?

[Hoehrer]

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

[BTAxis]

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:

Code: [Select]

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).

[BTAxis]

Oh, and nesting.

Code: [Select]

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.

[Hoehrer]

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

Code: [Select]

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

Code: [Select]

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

Code: [Select]

requires "plasma nano"

If i forgot an issue just ask.
Werner

[BTAxis]

* 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.

[Hoehrer]

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

[Hoehrer]

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

[BTAxis]

Hoehrer, something just occurred to me when I was looking at the research topic descriptions (as a result of this). 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?

[Hoehrer]

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

[HaJo]

It's a good idea and i'll probably integrate it after the next release.

Where should the text for those descriptions go ?

[Hoehrer]

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):

Code: [Select]

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

[HaJo]

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...

[Hoehrer]

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

[Bandobras]

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.