stuff to unhardcode

[Reg312]

Hello

Please unhardcode damage/speed formulas

some stuff to unhardcode...

1) minimum 30% of damage dealt

Code: Select all

	// You always do at least a third of the experience modified damage
	actualDamage = MAX(actualDamage - armour, actualDamage / 3);

2) speed bonus for "light" designs

that shitty piece of code breaks speed in game

Code: Select all

	
     if ( (asBodyStats + psTemplate->asParts[COMP_BODY])->powerOutput > weight )
	{
		speed = speed * 3 / 2;
	}

that code means: if engine power of body more that weight of whole tank then get 50% additional engine power
(but engine upgrades does not taken into account in this formula)


3) 300% damage to landed vtols

Code: Select all

	
        if (isVtolDroid(psDroid) && psDroid->sMove.Status == MOVEINACTIVE)
	{
		damage *= 3;
	}

4) constant damage of visible burning effect

Code: Select all

#define BURN_TIME	10000	///< How long an object burns for after leaving a fire.
#define BURN_DAMAGE	15	///< How much damaga a second an object takes when it is burning

.

[aubergine]

How often are those functions called? I imagine they could be moved to rules.js, allowing custom game rules to define how damage/speed are applied?

Pondering: If there's a traffic jam of 50 droids, and a VTOL drops a plasmite bomb on them, how many calls to the functions will be made? How fast will the functions be, assuming the spidermonkey-based JS optimiser has done a good job? I'm fairly confident it can be moved to JS without causing performance impact...

[Reg312]

@aubergine
i've tried to move some functions to JS in my experiments
i think damage formula called many times in second
each projectile produces more than 1 damage effects
burn damage called 10 times per second
speed formula and HP formula might be called more more rarely...

[aubergine]

Why is burn damage called so often? Surely it should only get called once per game second and just do 10x more damage to compensate?

I can understand why projectile damage could be called many times at once, but it's a one-off per projectile hit. I don't know how many projectile hits there are likely to be happening concurrently, or how many resultant damage checks those hits will result in, so somewhat difficult to estimate the performance impact of moving the functions to JS...

EDIT: By ensuring strict adherence to using const primitive values, the JS compiler/optimiser will remove unnecessary typecasting overheads from the computations. The function would therefore have comparable performance to the C++ equivalent, albeit with a little extra overhead due to the JS<-->C++ transit.

[Reg312]

one more thing:

max price of research 450$
please unhardcode!!!

[aubergine]

OMG! That one doesn't just need unhardcoding, it needs eradicating! There should be no upper limit on research price, surely? Or maybe its something to do with the GUI code not being able to handle progress bars more than $450?

[Reg312]

OMG! That one doesn't just need unhardcoding, it needs eradicating! There should be no upper limit on research price, surely? Or maybe its something to do with the GUI code not being able to handle progress bars more than $450?

Code: Select all

#define RESEARCH_FACTOR		32
#define RESEARCH_MAX_POWER  450

Code: Select all

		//set the research power
		research.researchPower = research.researchPoints / RESEARCH_FACTOR;
		if (research.researchPower > RESEARCH_MAX_POWER)
		{
			research.researchPower = RESEARCH_MAX_POWER;
		}

i thought all knew about this

[Per]

Yeah, that crap. Not sure why it exists, but I think a lot of people will be rather surprised at the impact it would have, if removed. This is for skirmish:

Cyborg Superdense Thermal Armor Mk2 : 500 -> 450
Cyborg Superdense Thermal Armor Mk3 : 562 -> 450
Vehicle Superdense Thermal Armor : 531 -> 450
Vehicle Superdense Thermal Armor Mk2 : 593 -> 450
Vehicle Superdense Thermal Armor Mk3 : 656 -> 450
Medium Body - Retribution : 900 -> 450
Heavy Body - Vengeance : 1350 -> 450
Pulse Laser : 900 -> 450
Rail Gun : 900 -> 450
Gauss Cannon : 1350 -> 450
Cyborg Superdense Composite Alloys Mk3 : 487 -> 450
Superdense Composite Alloys Mk2 : 487 -> 450
Superdense Composite Alloys Mk3 : 550 -> 450
Vindicator SAM Site : 900 -> 450
Archangel Missile Battery : 900 -> 450
Plascrete Mk3 : 500 -> 450
Advanced Base Structure Materials Mk3 : 500 -> 450
Gas Turbine Engine Mk2 : 468 -> 450
Gas Turbine Engine Mk3 : 531 -> 450
Hi-Energy Laser Emitter Mk2 : 900 -> 450
Hi-Energy Laser Emitter Mk3 : 1350 -> 450
Thermopole Energizer Mk2 : 900 -> 450
Thermopole Energizer Mk3 : 1350 -> 450
Search & Destroy Missiles : 900 -> 450
Advanced Missile Warhead Mk2 : 900 -> 450
Advanced Missile Warhead Mk3 : 1350 -> 450
Advanced Missile Allocation System Mk2 : 900 -> 450
Advanced Missile Allocation System Mk3 : 1350 -> 450
Hardened Rail Dart Mk2 : 900 -> 450
Hardened Rail Dart Mk3 : 1350 -> 450
Rail Gun ROF Mk2 : 900 -> 450
Rail Gun ROF Mk3 : 1350 -> 450
Mass Driver Fortress : 1562 -> 450
High Intensity Thermal Armor Mk3 : 468 -> 450
Vindicator SAM : 900 -> 450
Archangel Missile : 900 -> 450
Heavy Laser : 1125 -> 450
Heavy Laser Emplacement : 637 -> 450
Wide Spectrum Sensor Tower : 512 -> 450
Satellite Uplink Center : 900 -> 450
Laser Satellite Command Post : 1768 -> 450
EMP Cannon Tower : 900 -> 450
Missile Fortress : 1562 -> 450
Plasteel : 562 -> 450
Plasteel Mk2 : 687 -> 450
Plasteel Mk3 : 750 -> 450
Heavy Body - Wyvern : 1562 -> 450
Multi Turret Body - Dragon : 1718 -> 450
Superhot Plasmite gel Mk2 : 475 -> 450
Superhot Plasmite gel Mk3 : 537 -> 450
Advanced Manufacturing : 475 -> 450
Self-Replicating Manufacturing : 600 -> 450
EMP Mortar : 625 -> 450
Stormbringer AA Laser : 900 -> 450
EMP Mortar Pit : 900 -> 450
Vindicator Hardpoint : 937 -> 450
Whirlwind Hardpoint : 937 -> 450
EMP Cannon : 900 -> 450
AA Flak Cannon Hardpoint : 937 -> 450
Avenger Hardpoint : 937 -> 450
Twin Assault Gun : 468 -> 450
Twin Assault Gun Hardpoint : 468 -> 450
Plasmite Bomb : 625 -> 450
EMP Missile Launcher : 781 -> 450
Depleted Uranium MG Bullets : 475 -> 450

[aubergine]

Surely the better approach would be to change the cost of techs in the stats and not have some global ceiling forced upon them?

[Reg312]

Yeah, that crap. Not sure why it exists, but I think a lot of people will be rather surprised at the impact it would have, if removed. This is for skirmish:

you listed research of very late level of the game, most of these tech used rarely
and even when it used it happens on high-oil maps

many things can be done silently

[felipe]

Per:
after some rl probs I started working on the ini conversion again.
For now, this txt are converted.
sensors.ini
ecm.ini
repair.ini
construction.ini

I pushed my changes in my repo, here you can see the diffs: https://github.com/epilef/warzone2100/c ... ster...new

I need to ask you some questions about propulsiontype.txt.

I'll be on irc when possible.

[aubergine]

Wow, nice work felipe! Are there any docs on what the properties mean? I can guess some of them, but not all. I'd like to document the .ini files, stating what each one is for, where it lives and what its properties mean.

[felipe]

aubergine:
Thx
Wait until the code has been comitted, because some things can change..
Anyway, you can use http://developer.wz2100.net/wiki/TxtEditing as reference (like I do).
The diff you see in my previous post, for example, didn't change/add anything to the standard values.
I think you can guess everything easily, if in doubt ask me.

In brain.ini (that's already committed to master by per) has been added to the standard commander parameters:
maxDroids default 6 ( maximum number of droids associable to commander)
maxDroidsMult default 2 (multiplier for the commander level)

the formula is: numDroids = maxDroids + maxDroidsMult * level
where level = 0..8

If you take care of the documentation I'll advise you when changes are introduced.

[Per]

@felipe: Your changes look good to me. Please make a ticket when you think it is ready to merge. Make sure you have removed all commented out code first, though...

[aubergine]

@felipe: I notice that each ini file basically has a defaults section at the start (ZNULL<whatever>) -- what work would be involved in renaming those default sections so they all have a consistent name [DEFAULTS]? The ini file already tells us what sort of stats it contains, so having different names for the defaults seems a bit odd (relic of the past I guess).