Converting from INI to JSON

[crab_]

Well. Now i have issue with eventResearched.

Old code does not work with new format of research results.
So we need discuss how research code should work.

I'm still believe better is use functions than store all logic in json-objects.

Per's variant

Code: Select all

"results": [
	{
		"Damage": 25,
		"weaponSubClass": "MACHINE GUN"
	}
],

variant 2
Stored array of results, to be able to store multiple results.
Stored name of function.
Parameters of function stored as fields "weaponSubClass", "modifier"

Code: Select all

"results": [
	{
		[
			"function": "UpgradeWeaponDamage",
			"weaponSubClass": "MACHINE GUN"
			"modifier": 25,
		],
	}
],

variant 3
Stored array of results, to be able to store multiplie results.
Stored name of function.
Stored each field which we want to change

Code: Select all

"results": [
	{
		[
			"function": "UpgradeWeapon",
			"weaponSubClass": "MACHINE GUN",
			upgrade_fields:
			{
				damage: 25,
				radisuDamage: 25,
				periodicallDamage: 25,
			},
		],
	}
],

variant 4
Stored array of results, to be able to store multiplie results.
Stored name of upgraded component type.
Stored each field which we want to change.
Stored list of filters.

Code: Select all

"results": [
	{
		[
			component_type: "Weapons",
			filters:
			{
				"weaponSubClass": "MACHINE GUN",
				designable: 1,
			},
			
			upgrade_fields
			{
				damage: 25,
				radisuDamage: 25,
				periodicallDamage: 25,
			},
		],
	}
],

Another form of filters

Code: Select all

			filters:
			{
				weaponSubClass: "== 'MACHINE GUN'",
				designable: "== 1",
			},

],

**we need to store somehow - what weapons (bodies, propulsion) we want upgrade

I prever variant 2

I'm afraid my ideas is not clear. Please ask if something not clear in my examples above.

Again.
We need a flexible and accurate form of results of research.
I suggest to use research frunctions (js). Because it makes less problems but in this case you need to open research.js to be able to read details of "what was upgraded actually"

[Per]

The results is the hardest of them all, and I spent a bit of time fiddling with it before I had something I was somewhat happy with. What made me somewhat happy was its conciseness, which I think is very important for newcomers to understand and not be frightened by it. It is also interpretable data, not function calls, even though the parser is implemented in javascript, which I think is sort of a good thing. I have not yet attempted to write the parser, nor extend the data in any meaningful way, so I may be completely wrong on all counts, however.

Here is a new version of body.json, with bodypropulsionimd.ini merged into it, attached. I like this a lot better than the horrific bodypropulsionimd.ini ...

[Per]

Looking at propulsiontype.ini, I think we should completely change how we specify the speed modifiers. Having a power ratio multiplier for each propulsion category, then a bunch of hard-coded extra modifiers based on body type and size, is a sign the whole speed calculation is bollocks. A start would be to move the power ratio multiplier into propulsions, but if the power ratio multiplier really did what it advertises, then there should be no reason for the hard-coded changes... so something is really bad here, and I'm not sure how much I want to change it now...

It is interesting that the Pumpkins were at odds about it as well. The loading code is prefaced with this:

Code: Select all

               //don't care about this anymore! AB FRIDAY 13/11/98
                //want it back again! AB 27/11/98

[Per]

I'm considering splitting speed in propulsion.json into a dictionary, like this:

Code: Select all

        "speed" : {
           "LIGHT" : 175,
           "MEDIUM" : 175,
           "HEAVY" : 175,
       	   "SUPER HEAVY" : 175
        }
        "speedMultiplier" : {
            "AIR" : 150,
            "GROUND" : 100
        }

This will allow us to specify speed precisely for each propulsion, for each body size and air/ground, instead of hard-coding anything, I think. Also, if a body size or air/ground variant is not mentioned, it can serve as a ban against making use of this propulsion for this body size, adding more customization.

[crab_]

The results is the hardest of them all, and I spent a bit of time fiddling with it before I had something I was somewhat happy with. What made me somewhat happy was its conciseness, which I think is very important for newcomers to understand and not be frightened by it. It is also interpretable data, not function calls, even though the parser is implemented in javascript, which I think is sort of a good thing. I have not yet attempted to write the parser, nor extend the data in any meaningful way, so I may be completely wrong on all counts, however.

Well. I suggested functions calls because it looks good for me (and it looked good for old devs )
Please can you write parser (make good looking research code working with your json-structures of research results). I think it is high priority task...

Looking at propulsiontype.ini, I think we should completely change how we specify the speed modifiers. Having a power ratio multiplier for each propulsion category, then a bunch of hard-coded extra modifiers based on body type and size, is a sign the whole speed calculation is bollocks. A start would be to move the power ratio multiplier into propulsions, but if the power ratio multiplier really did what it advertises, then there should be no reason for the hard-coded changes... so something is really bad here, and I'm not sure how much I want to change it now...

Do we need to change this part right now?

First - let's remove 50% speed modifier for "light" tanks (weight <= engine_power_without_upgrades)
Next - unhardcode VTOL speed modifiers for different body types.
3 - terrain types should be written understandable in TerrainTable.ini
4 - move speed modifier from propulsionType.ini to propulsion.json

I'm considering splitting speed in propulsion.json into a dictionary, like this:

Code: Select all

        "speed" : {
           "LIGHT" : 175,
           "MEDIUM" : 175,
           "HEAVY" : 175,
       	   "SUPER HEAVY" : 175
        }
        "speedMultiplier" : {
            "AIR" : 150,
            "GROUND" : 100
        }

What means that numbers 175? 150 ?
Do you meant maxSpeed?
Currently we have speed modifiers in %.

Code: Select all

        "speed" : {
           "LIGHT" : 1,
           "MEDIUM" : 1,
           "HEAVY" : 0.75,
       	   "SUPER HEAVY" : 0.75
        }
        "speedMultiplier" : {
            "AIR" : 1.5,
            "GROUND" : 1,
        }

MaxSpeed and Speed Modifiers is two different things.
Speed Modifiers are related to engine_power/weight.
Max Speed is just maximum speed (we can increase max speed but it will not increase actual speed)

What with TerrainTable?

Code: Select all

        "speed" : {
           "LIGHT" : 1,
           "MEDIUM" : 1,
           "HEAVY" : 0.75,
       	   "SUPER HEAVY" : 0.75
        }
        "max_speed" : {
           "LIGHT" : 175,
           "MEDIUM" : 175,
           "HEAVY" : 175,
       	   "SUPER HEAVY" : 175
        }
        "speedMultiplier" : {
            "AIR" : 1.5,
            "GROUND" : 1,
        }
        "speedMultiplier" : {
            "TER_SAND" : 1,
            "TER_SANDYBRUSH" : 1,
            "TER_BAKEDEARTH" : 1,
            "TER_GREENMUD" : 1,
            "TER_REDBRUSH" : 1,
            "TER_PINKROCK" : 1,
            "TER_ROAD" : 1.5,
            "TER_WATER" : 0,
            "TER_CLIFFFACE" : 1,
            "TER_RUBBLE" : 1,
            "TER_SHEETICE" : 1,
            "TER_SLUSH" : 0.9,
        }

[crab_]

Hi per. I found one reason why we should not use research functions.
The reason is filtering research or groupping research.
When result of research is random function we cannot analyse what effect has this research. So we need apply research and see what was changed...

I have tried to draw Research Tree. I had needed to have a Research Groups.
If you read list of groups below i hope you can understand an idea and understand why we should have ability to analyse effects of research.
I formed following groups of research:

Code: Select all

- Production upgrades + Construction Upgrades
- Power Upgrades
- Repair Turrets + Repair Upgrades + Repair Buildings
- VTOL Rearming Structures + VTOL Rearming upgrades
- Research upgrades
- Base Structures Line
    --Sub_line - Armor of base structures
- Bodies
    -- Tank Armor/Thermal Armor upgrades
    -- Engine Upgrades
    -- Cyborg Armor/Thermal Armor upgrades
- Propulsion
- Hardcrete upgrades
- Sensors/Sensor towers
- Weapon lines
    --Weapon Damage/Rof upgrades
    --Defenses linked from weapon lines
 - Other upgrades

I have managed to draw research tree using listed groups, but result was too slow in SVG graphics and now i have to remake it.

You can see sample of research tree below, but this sample is wrong in some acpects. It is just sample.

[Per]

So does this mean that the JSON structure I suggested is ok? Or does it still need improving?

[crab_]

So does this mean that the JSON structure I suggested is ok? Or does it still need improving?

Here is sample of your structure.

"results": [
{
"FirePause": -10,
"weaponSubClass": "A-A GUN"
}

1) Names of fields are not correct. Names of fields should be equal to fields names in .json.
2) How we can determine is "weaponSubClass" is upgrade effect or it is filter for weapon?
May be example above means upgrade set 'weaponSubClass' for all weapons to "A-A GUN"?
I think we should be able to upgrade one component or set of components or all components.
3) How we can determite - do we should upgrade weapons or may be we should upgrade bodies?
4) We should be able to have set of results

I want suggest my own structure, or you can correct your structure.
Lets see. Below is ugly sample to show my suggestions

Code: Select all

results:[
{
  object: Body,
  filters [
  {
    droidType: "droids",
  },
  {
    droidType: "transports",
  },
  ]
  modifiers:
  {
    armorKinetic: 30,
    hitpoints: 30,
 }
},
{
  object: Weapons,
  filters [
  {
    "weaponSubClass": "A-A GUN"
  }, ]
  modifiers:
  {
    "FirePause": -10,
 }

}]

Note: my example above also contains correction for bug of current research code - unable to upgrade both droids and transports

[Per]

How about

Code: Select all

"body":
{
  "droidType": [ "droids", "transports" ],
  "modifiers":
  {
    "thermal": 30,
    "hitpoints": 30,
 },
"weapon":{
  "weaponSubClass" : [ "A-A GUN" ],
  "modifiers":
  {
    "FirePause": -10,
 }

}

The "results" keyword is gone, replaced by keywords for each component type (could be named "bodyResults"...). Anything not "modifiers" is a filter, and each filter is a list of items that match inclusively. For modifiers, each line applies to the named component.

[crab_]

@per looks good for me.
We have to evaluate this form of results for current researches.. to see how it will be applied..

I think may be we can merge resultComponentand resultStructures into results?

[crab_]

@per in your structure of results - does it possible to have 2 results for weapons?

[Per]

@per in your structure of results - does it possible to have 2 results for weapons?

For the same filter, yes. Two different results for two different filters, no. I don't think that makes much sense, and should be discouraged. (If some mod really wants to have a few exceptional reseach results, they can be implemented wholly inside scripts.)

[crab_]

@per in your structure of results - does it possible to have 2 results for weapons?

For the same filter, yes. Two different results for two different filters, no. I don't think that makes much sense, and should be discouraged. (If some mod really wants to have a few exceptional reseach results, they can be implemented wholly inside scripts.)

But may be we can add just few more brackets?
Make "weapon", "body" - arrays ?
Just little brackets

Code: Select all

"body":
[{
  "droidType": [ "droids", "transports" ],
  "modifiers":
  {
    "thermal": 30,
    "hitpoints": 30,
 }],
"weapon":[{
  "weaponSubClass" : [ "A-A GUN" ],
  "modifiers":
  {
    "FirePause": -
10,
 }]
}

One more question
"weapon" is not equal to "Upgrades.Weapon". I mean - names of objects should be the same everywhere
weapon.json
Stats.weapon
Upgrades[player].weapon
....results: { weapon: [{...

or

Weapon.json
Stats.Weapon
....results: { Weapon: [{...
Upgrades[player].Weapon

Fields of objects also should have the same names everywhere

weapon.hitpoints
Upgrades[player].weapon.hitpoints
Stats.weapon.hitpoints


One more question 2
Do you plan to convert research results to new form by script?
Otherwise I can do it in text editor.

[Duha]

I'm seriously considering changing all the .ini format stuff to JSON format instead.

I have done some tolls for csv to ini conversation, but is is not to hard to convert ini to json.

My code use profile files and looks more complicated. But I think I can make this work faster.

May be I will do it in my way while you add c++ support?

It is not bugs but it is not comfort for me:
You use tab indentations, all my editors use space indentation (convert my tab press to 4 spaces).
I can't run script because my system is not accept sh.

[Per]

Making the converter itself isn't the big work, figuring out how the resulting JSON should look like, is. If you are bothered by tabs, just replace them with spaces with astyle or similar tool. Then you can convert it back to tabs if you want to send something for committing. Or use an editor that does not care.