Research code in tules.js in Master

[Per]

I agree they should be consistent, and they are not now. However, I like armour and thermal better than armour and heat, or armour and armourheat.

[NoQ]

Why don't we have some "rename everything" patch to make all names in all stats and all code as consistent as possible? Eg. MG3Mk1 => HeavyMachinegun etc. I'd join something like that even if I had to fix AI stat arrays in the process (:

[crab_]

I agree they should be consistent, and they are not now. However, I like armour and thermal better than armour and heat, or armour and armourheat.

I do not like "Thermal" for many reasons
i like armor fields like this:
armorKinetic
armorHeat
armorElectronic
armorXXXX

Eg. MG3Mk1 => HeavyMachinegun etc. I'd join something like that even if I had to fix AI stat arrays in the process (:

MG3Mk1 - more useful for sorting (if you sort all weapons then you will get all machineguns in a row). Better variant - MachinegunHeavy.
HeavyMachinegun - is name of weapon. It can be changed one time.
I'd suggested to generalize all IDs of all components in some 'common' way

[Per]

We could use "resistance.thermal" and "resistance.kinetic" to be more in line with what other games use, perhaps.

As for IDs... do we really need them? We could refer to entities by their untranslated real names instead.

[crab_]

We could use "resistance.thermal" and "resistance.kinetic" to be more in line with what other games use, perhaps.

I think we should have in JS same structure of objects as we have in ini.
We can convert .ini to json and then we will be able to use complex properties like body.resistance.thermal
Note: we have resistances already.

per_see_we_have_resistances.png

Resistance = Propulsion damage modifiers

As for IDs... do we really need them? We could refer to entities by their untranslated real names instead.

In some case we may need to use the same name for different components.
I think usage of IDs is common practice and we should keep IDs


Stats load procedures could be placed in .js and then we will be able to use any structure of objects

[crab_]

Hey. I've made sample patch. Please review it.
Sample means this patch changes only few selected research.

0001-Replace-research-hints-with-modern-crab-s-code.patch

In my patch i have changed some of research to new system.
(see [R-Vehicle-Metals01])
Old research code was not removed.

Code: Select all

[R-Vehicle-Metals01]
[results = UpgradeTankBody,armourKinetic:30,hitpoints:30

function eventResearched(research, structure, player)
{
	if(research.results.length>0)
	{
		var func_name = research.results[0];
		if(this[func_name] != undefined)
		{
			var tmp = {};
			tmp.player = player;
			this[func_name].apply(tmp, research.results.slice(1))
			return;
		}
	}
...............................

function UpgradeTankBody()
{
	var player = this.player;
	var pair_list = Array.prototype.slice.call(arguments);
	var upgrFields = TranslateUpgradeFields(pair_list);
	for (var i in Upgrades[player].Body)
	{
		if (Stats.Body[i].BodyClass != "Cyborgs") //Grrr we have field "class" in body.ini
		{
			for(var f in upgrFields)
			{
				UpgradeField(Stats.Body[i], Upgrades[player].Body[i], upgrFields[f].fieldName, upgrFields[f].fieldModifier);
			}
		}
	}
}

[NoQ]

Code: Select all

include("multiplay/skirmish/research.js");

Get out of my head!!!11

As for IDs... do we really need them? We could refer to entities by their untranslated real names instead.

Yeah, with ini format, spaces are fine too. Dropping "name = " is quite a plan (:
As for sorting, we can sort by weapon type, or just by line number in the file.

[crab_]

Please say is my patch good? I want continue work but i cant because i dont know is it good work or bad work?

[Per]

(Slow to respond to this since I've been on x-mas vacation...)

I think the patch above is the right way to go, with some minor modifications. My approach of putting everything into a giant function was not a very pretty way to do it. I'd like to make each item in the string list a separate function call, though. So "upgradeDroidBody:30:30" would be the call upgradeDroidBody(30, 30). That way you can more easily make research results that have multiple effects (if you want to). It also seems cleaner, somehow. I don't like the translator function. If there is inconsistency, this is the wrong way to fix it.

PS In our javascript code we've used function names that start with a lower case letter. Please follow this notation for consistency

[crab_]

I don't like the translator function.

oh, i dont like this functions too. i forgot to warn you
I planned use translator function until you fix names of properties.
I meant: i hoped you will be agree to fix names of properties and i planned remove translator function when you do

My approach of putting everything into a giant function was not a very pretty way to do it. I'd like to make each item in the string list a separate function call, though

Do you mean?
old: UpgradeTankBody,armourKinetic:30,hitpoints:30
new: UpgradeTankBody:armourKinetic:30, UpgradeTankBody:hitpoints:30

For example for damage upgrades:
UpgradeWeapon,MACHINE GUN,damage:30,radiusDamage:30,periodicalDamage:30
UpgradeWeapon:MACHINE GUN:damage:30,UpgradeWeapon:MACHINE GUN:radiusDamage:30,UpgradeWeapon:MACHINE GUN:periodicalDamage:30
hmm... i more like my variant (strikeout line) just because my line is more readable
but yes my variant does not allow to use multiplie functions...

See my variant with ability to use multiplie effects
UpgradeWeapon;MACHINE GUN;damage:30;radiusDamage:30;periodicalDamage:30,UpgradeTankBody;armourKinetic:30;hitpoints:30
UpgradeWeapon:MACHINE GUN:damage:30,UpgradeWeapon:MACHINE GUN:radiusDamage:30,UpgradeWeapon:MACHINE GUN:periodicalDamage:30,UpgradeTankBody:armourKinetic:30, UpgradeTankBody:hitpoints:30

So "upgradeDroidBody:30:30" would be the call upgradeDroidBody(30, 30).

I want to keep names of changed fields in .ini to make it more readable (which also means less bugs)
So it should be as following "upgradeDroidBody:fieldName:30"

Do you insist me not to use giant functions?

[Per]

This is the kind of thing that screams out for proper JSON notation

I'm not entirely sure what is the best way to annotate this stuff. Let me think about it for a moment.

I think using names rather than just numbers (as in my ad hoc example) makes sense.

We can change the names for things (thermal vs armourHeat etc) in a separate step/patch. So please leave that out for now...

[crab_]

Lets see. Each upgrade have followings parts

• Filter part - in filter we set what items will be affected
  example1: research upgrade should work only for "Research Facility" - 'A0ResearchFacility' in structures list
  example2: engine upgrade should affect all bodies, excluding cyborg bodies
• Field name part - name of field which value should be changed
  example: armourHeat
• Modifier part

I think it can be too complex to use JSON for coding filter part of research.
So best solution - use custom JS-function for each research
Do not try to generalize research effects into some formatted string. Do not do that.

In my point of view - each research effect is custom function which can do anything.

We can change the names for things (thermal vs armourHeat etc) in a separate step/patch. So please leave that out for now..

I planned use new research code in my WZ Guide (and i can do good tests for new research code in my Guide). Since my Guide does not know about new hardcoded names of fields i need some 'field translator'.
Plus i planned to change research.ini manually, by hands, i wont use regExp and/or find&replace for turning research.ini into new version.
I mean: i change research.ini by hands so i want do it only 1 time... This means i need to know what to use as names of properties of components.

[Per]

So best solution - use custom JS-function for each research

How would you handle that in the guide?

Where would you put the functions?

Wouldn't that be a lot of duplicated code?

I wonder if perhaps my ad hoc example might be worth considering seriously. If you have a string "upgradeDroidArmour(30), upgradeCyborgArmour(30)" which are functions to upgrade all droid and cyborgs armours by 30%, then that will be a lot more neat than making one function for each research. I wonder if we could just run eval() on that string, even...

[crab_]

How would you handle that in the guide?

Where would you put the functions?

In my Guide i use research code to calculate upgrades.
In my Guide i use eventResearched(..) from rules.js
I have Upgrade structures in my Guide like in Wz.
But in my Guide i know only fields from .ini files.

When i load .ini - fields from .ini become fields of my objects.
For example, in my Guide "armourHeat" from .ini becomes Upgrades[player].Bodies.armourHeat.
In my Guide I do not have new hardcoded names of fields which we have in Wz

Since i use eventResearched(..) in my Guide i can use any code from rules.js if this code operates with properties names from .ini files.
So what's why i added "translator" function. I did it only to show the problem, nothing more

Do i explaining clear? (I'm asking because my english very bad and you can misunderstood me in some details)

Wouldn't that be a lot of duplicated code?

I think we can avoid duplicated code.
Similar functions can use some common functions.
Well, some code can be duplicated, not sure. But it makes easier adding custom logic in research code.

Multiple research effects can be implemented as function
function upgradeXXX(...)
{
upgradeAAA(...)
upgradeBBB(...)
upgradeCCC(...)
}

If you have a string "upgradeDroidArmour(30), upgradeCyborgArmour(30)" which are functions to upgrade all droid and cyborgs armours by 30%, then that will be a lot more neat than making one function for each research.

lets see:
For body:
results: upgradeTankArmour(30),upgradeTankHitPoints(30)

i'm afraid in this solution we are not able to use more 1 parameter per function.

Lets see for damage
results: upgradeTankDamage("MACHINE GUN",30),upgradeTankRadiusDamage("MACHINE GUN",30),upgradeTankPeriodicallDamage("MACHINE GUN",30)
We need 2 parameters in our functions, but comma serves for splitting string to list of functions.
Not sure, but seems "eval" wont do work because we cannot use commas inside eval. I do not know how exactly works Qt.toStringList()

per: can you show your example for damage research?

I wonder if we could just run eval() on that string, even...

Internet says eval is evil. So i'd tried to avoid eval.
Dont know

[update]
I'd like to have possibility to store custom logic in result of research. I mean we can have many various effects in 1 research.
So i do not think we should to use only 1 function per 1 effect (if i understood your suggestion)

...So i think... enough thinking js-code can be remade many times