Research code in tules.js in Master

[crab_]

Hello i found some issues with current research code in rules.js
eventResearched(research, structure, player)

1) Wrong code for research upgrades (see #4075)
2) Wrong logic for ROF upgrades. lancer ROF is not upgraded
3) Why names of parameters is different in stats and in Upgrades Data Structure?
damage - Damage
firePause - FirePause
armorHeat - Thermal
powerOutput - Power

[crab_]

I have found 1 more bug in research code in Master
Wrong research code for production upgrades

3.1.0 formula: factory_production + factory_module_production * number_modules + factory_production*production_upgrade_modifier/100
fully upgraded factory = 10 + 10*2 + 10*240/100 = 54

master formula: (factory_production * (number_modules + 1)) *production_upgrade_modifier/100
fully upgraded factory = (10 * 3) * 220 / 100 = 66

Production is faster in master version, but this is noticeable only on late stages of game.

Note sure 100% in my formulas..
in 3.1.0 production upgrades are 60,120,180,240 but in master upgrades are 30,60,90,120

[crab_]

Hello.
Just found new issue: Transports armor do not get upgrades in Master version.
This happens because transports have body type "Transport".
This issue can be fixed easily but...research code is bad.. do not like to fix bugs in bad code

[R-Vehicle-Metals01]
results = "Droids:Armour:30", "Droids:HitPoints:30"

[R-Vehicle-Metals01]
results = "Droids:Armour:30", "Droids:HitPoints:30", "Transports:HitPoints:30" , "Transports:Armour:30"


I think Transports are get upgraded in current 3.1 but did not checked it.

[Per]

Do you want to make patch(es) for these issues?

[crab_]

Do you want to make patch(es) for these issues?

See. We can fix these issues. Some of these issues can be fixed easy.
But i think better is remake current research code.

I want remake research code, but i cannot provide working patch at once.
I do not like current research hints. I spent much time to make current research code work in my wz Guide.
.
What i want in new research code
1. Generalize names of properties of components.
I mean: names of properties in research hints should be the same as in .ini
2. Change format of research hints to something more flexible (like json)
3. Change eventResearched. Current code is not clear enough for me.
4. Unhardcode some logic. Currently structure upgrades are hardcoded by some way.
5. (not sure) Make possibility of changing more component's properties via research.
e.g. change range of fire, separate change of periodical damage and direct damage.
separate change firePause and salvoReload etc. change ammo.
This last point requires remaking current Upgrade structures in low-level c-code.
I'm bad coder so i'm afraid of changing low-level code
...
So what;s why i show you bugs here. If you agree with my statements above then someone can start coding. I'm afraid you have your own vision as usual

[NoQ]

Right now we can even change weapon range from js >_<

[crab_]

Right now we can even change weapon range from js >_<

hmm.. do range changed directly in 'asWeaponStats'.. directly in weapon stats or do we have structure like Upgrades[player].weapons[weap_id]
if you change range from js do you change it for all player or you can select player?

[NoQ]

Play with jsdebug cheat to see how it works and explore the global objects.
Naturally, yeah, the "player" index in

Code: Select all

Upgrades[player].Weapon["Heavy Machinegun"].MaxRange

stands for the player it applies to.

[crab_]

Play with jsdebug cheat to see how it works.
Naturally, yeah, the "player" index in

Code: Select all

Upgrades[player].Weapon["Heavy Machinegun"].MaxRange

stands for the player it applies to.

really? this mean i can upgrade research code without changing low-level code.
Well. i'll check

[crab_]

NoQ - it worked for me.
I changed maxRange for heavy machinegun from jsdebug Upgrades[0].Weapon["Heavy Machinegun"].MaxRange = 100
Well. i can remake research hints and eventResearched.
....hmm i see QT script do not supports JSON
i want be able to store more complex objects as research results in research.ini
-filters for stats, to be able upgrade given component_id or set of components
-store set of changed parameters

may be research hints should refer to some functions in rules.js where we can implement custom logic of research results..but it can look as downgrade..

[update]
I was wrong. I see json is supported in scripts.
tried JSON.parse('{"a":1,"b":2}').a and 1 was shown in wz

[update2]
i do not need json.parse
i can use eval

[update3]
Does .ini support multi-line values?

[update4]
I can suggest convert research hints to calls to certain js-functions

Code: Select all

[R-Cyborg-Armor-Heat07]
results = "Cyborgs:Thermal:45" will be converted to

[R-Cyborg-Armor-Heat07]
results = UpgradeCyborg,armorHeat,145

function UpgradeCyborg(player, field,modifier)
{
	for (var i in Upgrades[player].Body) // loop over all bodies
	{
		if (Stats.Body[i].BodyClass === "Cyborgs" )
		{
			Upgrades[player].Body[i][field] += Math.ceil(Stats.Body[i][field] * modifier / 100);
		}
	}
}

function eventResearched(research, structure, player)
{
	for (var i = 0; i < research.results.length; i++)
	{
		var res_array = research.results[i].split(',');
		var funcName = res_array[0];
                (func_list[funcName]).apply(player, res_array );
	}

}

[Per]

I do not think .ini supports multi-line. (In retrospect, going for .ini might have been a mistake. Maybe we should have used JSON for everything. But probably too late to change now. What we have works as well.)

Not entirely sure what is suggested in [update4] above.

[crab_]

Not entirely sure what is suggested in [update4] above.

Currently we have "hint" - formatted string which says what to upgrade. I mean Research.results is field which contains research hint.
I suggest change hints and make them able to point to some js-function.
All logic of upgrade will be stored in function referenced by hint.
Research hint will be transformed into string <function name>,<param1>,<param2>...,<paramN>
This is like we had in older versions (functions.txt)
But this time functions will be unhardcoded in js.

still do not clear?

[Per]

Quite clear. I suppose the only thing that needs to be changed in the c++ code, is to handle the hint as a list of strings, rather than a simple string. Then the .js code can handle the rest?

[crab_]

Quite clear. I suppose the only thing that needs to be changed in the c++ code, is to handle the hint as a list of strings, rather than a simple string. Then the .js code can handle the rest?

I think js-code can simply split string.
js-code can handle all.

results = UpgradeCyborg,armorHeat,145
UpgradeCyborg - name of function
armorHeat,145 - list os parameters
i will see how it can work..
may be i will add research.js and place all research functions there

[update]
Currently each research hint have some modifier:
armor 30%
armor 30%
armor 30%

...thinking may be better remake it as shown below:
armor 30%
armor 90%
armor 130%

dunno why, but when i worked on research code in my guide it was not good to see only partial values, better when i can see sum of upgrades in each upgrade...

[crab_]

@per

Lets see in body.ini we have fields armourKinetic, armourHeat
But in JS in Stats object we have Body.Armour and Body.Thermal
Why "themalArmor" was named simply "Thermal"?

Can i ask you to change these names of fields to make them the same as we have in ini?
Why we have 2 sets of names of fields for each object?
It is just confusing