NoQ commented

I also wonder where do we have {research, power, production} points of the modules stored. There aren't any signs of them in structure.ini.

crab_ commented

Replying to Warzone2100/old-trac-import#4075 (comment:1):

I also wonder where do we have {research, power, production} points of the modules stored. There aren't any signs of them in structure.ini.

see structures.ini
section [A0ResearchModule1]
researchPoints = 12

Per changed blocking which not transferred by tractive

Per changed blockedby which not transferred by tractive

Per commented

IIRC modules now do a hard-coded improvement to the underlying structure. No time to check now, though, so might be wrong.

NoQ commented

researchPoints = 12
Yeah, right, but for factory module it is still not defined (even though they work).

hard-coded
Do not want! (tm)

NoQ changed _comment0 which not transferred by tractive

crab_ commented

Replying to Warzone2100/old-trac-import#4075 (comment:4):

researchPoints = 12
Yeah, right, but for factory module it is still not defined (even though they work).

i found function in hard-code:

static inline int getBuildingProductionPoints(STRUCTURE *psStruct)
{
	return psStruct->pStructureType->upgrade[psStruct->player].production * (psStruct->capacity + 1);
}

no modules = 100% of factory.productionPoints
1 module = 200% of factory.productionPoints
2 modules = 300% of factory.productionPoints

in 3.1.0 we were able to set factory module production points in structurefunctions.txt :(

Per commented

Yes, this is a regression in mod-ability, which I noted in the forum post in which I announced the change to the new upgrade format. Unfortunately, it is a bit hard to change, and I do not really know what would be a good way to deal with it.

IIRC the researchPointers for the research module is a mistake, it has no effect, and it should be removed to avoid confusion.

Can we adjust some of the parameters that we can change to simulate 3.1 behaviour?

crab_ commented

Replying to Warzone2100/old-trac-import#4075 (comment:7):

the researchPointers for the research module is a mistake, it has no effect, and it should be removed
are you hard-coded research points? is it impossible to set research points for module in master?
[research facility].researchPoints = 14
[research module].researchPoints = 12
did you hard-coded value "12" for research module?

Replying to Warzone2100/old-trac-import#4075 (comment:7):

Can we adjust some of the parameters that we can change to simulate 3.1 behaviour?

yes, i think best place to adjust is rules.js
i can make patch but i think whole "research hint" system should be remade
http://forums.wz2100.net/viewtopic.php?f=6&t=11257
Why names of parameters in research hints is different than parameters in ini files?

Replying to Warzone2100/old-trac-import#4075 (comment:7):

and I do not really know what would be a good way to deal with it.
may be convert research hints to json-format?
so research result becomes an object.

all results of research can be stored in one object in json format
Example
"[{"function_name":"upgradeResearchFacility","function_parameters":{"modifier":30],{}]"
function_name - name of function in rules.js which should be called as research result
function_parameters - array of named function parameters

so i can make patch with conversion research hints to json and i can write set of functions (i can make all except hardcoded stuff with modules)

Another variant - store in research results "select query" for affected stuff
"[{"stat_type":"structure","stat_filter":{"type":"RESEARCH","id":"A0ResearchFacility"},"upgrade":{"researchPoints":30]]"
stat_type - search objects with type "structure"
stat_filter - set of values of fields. Object with these fields value will be affected.
upgrade - set of fields of affected object

crab_ commented

I see in master research points of lab are calculated just *2 if lab has module.
So there is no way to simulate 3.1 variant

Per changed _comment0 which not transferred by tractive

Per commented

That was what I was afraid of. I was really asking more in terms of how modules in general should be treated in the data. They have always been rather hard-coded (more now than before, but always very much so). Should they be real buildings, or just modifications to existing buildings? The existing and previous code pretty much does both, perhaps treating it more as a building upgrade now than before.

I think the very concept of modules is very poorly thought out, not having much purpose, and ideally should be retired. But I have no idea how to do that without causing a lot of messes.

crab_ commented

Replying to Warzone2100/old-trac-import#4075 (comment:10):

I think the very concept of modules is very poorly thought out, not having much purpose, and ideally should be retired.

Concept of upgrades is strongest motivation to play the game over and over.
I think warzone is still alive mostly because of upgrades.
Building modules is visualization of upgrades, therefore we need more modules :)
In Warzone2100 we have lack of visible upgrades, surely.

We need make complete and integrity system of building upgrades (modules). So i think making modules to work simply as 200% of building power is Wrong Way.

Each module can be considered as individual element in list of structures.
Better if we could write one piece of code which does 'concatenation' of structure and module, but i believe all this stuff also can be made in js-code with placing stats of resulting structure back in low-level data structures.
We can consider structure which has list of attached modules, and consider each modules as object 'Module' in 'modules.ini'..
I am afraid i tell not quite understandable..

There is one problem with modules - they are are mandatory. Player who do not built modules eventually lose game. But this problem can be solved by adjusting stats.

Per commented

How about we just make modules replace the original building entirely? I think that would make the code simpler, and give more options at the same time.

crab_ commented

Replying to Warzone2100/old-trac-import#4075 (comment:12):

How about we just make modules replace the original building entirely? I think that would make the code simpler, and give more options at the same time.

I'm agree. But we need keep separate models of modules and base buldings to be able to show blueprints.
I think current upgrade code in rules.js will not work with modules correctl

klasskill commented

Replying to Warzone2100/old-trac-import#4075 (comment:9):

I see in master research points of lab are calculated just *2 if lab has module.
So there is no way to simulate 3.1 variant

I have noticed this has not been replied to in 22 months, does that mean it is going to stay as it is now?

Cyp <cyp@...> changed status from new to closed

Cyp <cyp@...> changed owner from `` to Cyp <cyp@wz2100.net>

Cyp <cyp@...> changed resolution from `` to fixed

Cyp <cyp@...> committed [01]

In Warzone2100/warzone2100@01c2ea9:

#CommitTicketReference repository="" revision="01c2ea98c7b03adc9ab8412fb3d6f3b58df675c3"
stats: Split research/power/production upgrades into a base part and a module part.

It might make more sense to use the stats for the module itself, but structures don't have any actual modules in them, they only
have an untyped module count.

Fixes #4075.

Cyp commented

Replying to Warzone2100/old-trac-import#4075 (comment:14):

Replying to Warzone2100/old-trac-import#4075 (comment:9):

…

I have noticed this has not been replied to in 22 months, does that mean it is going to stay as it is now?

No, eventually things get fixed.