Time and production speed

[Omega]

So, we know the formula for finding how many world frames is used to calculate the time it takes to perform a skill ^[1], but it doesn't apply to production, morph, or upgrade skills, which have both a speed value on the skill and a time value on the unit/upgrade. So what formula do they use?

Perhaps we should have a nice topic here to share formulas for different calculations? Feel free to post any you may know.

[Omega]

Bump.

Also, what about particle speed? If the speed is 25, just what does that mean?

[Zoythrus]

Perhaps we should have a nice topic here to share formulas for different calculations? Feel free to post any you may know.

no, we need a tool that calculates all the different equations that Glest uses....

[Omega]

Perhaps we should have a nice topic here to share formulas for different calculations? Feel free to post any you may know.

no, we need a tool that calculates all the different equations that Glest uses....

I could easily make a cross platform web based tool if I knew the formulas...

For example, the same day that silnarm explained the attack speed formula, I made this: http://glestguide.co.cc/sandbox/damage.html

[Zoythrus]

i would suggest that the tool shouldnt be some web-based tool, but some stand-alone program that has all of the equation formats stored in it

[Omega]

i would suggest that the tool shouldnt be some web-based tool, but some stand-alone program that has all of the equation formats stored in it

Why? A web tool would be more versatile. Written in javascript, you could download it, no need to compile, open source, works on virtually every operating system, easier to do than a program (and with the potent to be prettier). Plus, javascript is pretty darn fast and easy to use. Being online, it could also be used on any computer, even a limited school or work computer which might not allow the running of foreign executables.

Pros: Everything
Cons: Nothing (besides the faulty logic of this pros and cons section)


EDIT:
I think I managed to find the production speed looking through the code:

Code: [Select]

time * floor((1 / (speed / 4000)) + 1) / 40This is in seconds, for world frames, just remove the division by 40 at the end.

Code: [Select]

time * floor((1 / (speed / 4000)) + 1)
Initially tests seem to prove it's correct. This here is the code fragment it is adopted from:

Code: (prototypes/cmd_types_general.cpp) [Select]

int framesPerCycle = int(floorf((1.f / (float(unit->getSpeed(m_produceSkillType)) / 4000.f)) + 1.f));
int timeToBuild = pt->getProductionTime() * framesPerCycle / 40;
Also, devs, if I am correct in assuming that the division by 40 is meant to be the world frames (defaults to 40) shouldn't it be float(WORLD_FPS) or whatever instead, just in case someone changes the setting in their INI? Obviously, there's no reason for anyone to do such a thing, but...

EDIT2:
This one seems to be the formula for damage:

Code: [Select]

((attack strength + random) / (distance + 1) - armor) * damage multiplier
Distance seems to be for splash attacks only, so not sure how it is calculated, though presumably the tiles away.

Code: (world/world.cpp) [Select]

((fDamage + random.randRange(-var, var)) / (distance + 1) - armor) * damageMultiplier

[hailstone]

Javascript should be good for doing the task. Make sure the types match though. C++ is using int so use number.toFixed() to make sure no decimal values are in the result. Also when you do it I think you should show what the equation is not just the inputs (in case you weren't going to).

Also, devs, if I am correct in assuming that the division by 40 is meant to be the world frames (defaults to 40) shouldn't it be float(WORLD_FPS) or whatever instead, just in case someone changes the setting in their INI? Obviously, there's no reason for anyone to do such a thing, but...

Yes if that is what it is. Ideally there shouldn't be any duplicated data or magic numbers. Silnarm might know better than I do.

Code: [Select]

time * floor((1 / (speed / 4000)) + 1) / 40speed is between 1 and MAX_INT. It also depends on the SkillType.

Here are the ones that differ from speed. These come from their respective getSpeed().

Code: (skill_type.cpp) [Select]

MoveSkillType: speed * unit->getMoveSpeedMult() + unit->getMoveSpeed();
AttackSkillType: speed * unit->getAttackSpeedMult() + unit->getAttackSpeed();
BuildSkillType: speed * unit->getRepairSpeedMult() + unit->getRepairSpeed();
HarvestSkillType: speed * unit->getHarvestSpeedMult() + unit->getHarvestSpeed();
RepairSkillType: speed * unit->getRepairSpeedMult() + unit->getRepairSpeed();
ProduceSkillType: speed * unit->getProdSpeedMult() + unit->getProdSpeed();
UpgradeSkillType: speed * unit->getProdSpeedMult() + unit->getProdSpeed();
MorphSkillType: speed * unit->getProdSpeedMult() + unit->getProdSpeed();

unit->getMoveSpeed(); type calls are affected by additional multipliers while unit->getMoveSpeedMult() seems to be the base multiplier speed (?).

Code: [Select]

void UnitStats::addStatic(const EnhancementType &e, fixed strength) {
...
moveSpeed += (e.getMoveSpeed() * strength).intp();
...
}

void UnitStats::applyMultipliers(const EnhancementType &e) {
...
moveSpeed = (moveSpeed * e.getMoveSpeedMult()).intp();
...
}


[Omega]

Javascript should be good for doing the task. Make sure the types match though. C++ is using int so use number.toFixed() to make sure no decimal values are in the result. Also when you do it I think you should show what the equation is not just the inputs (in case you weren't going to).

Indeed.

Here are the ones that differ from speed. These come from their respective getSpeed().

Code: (skill_type.cpp) [Select]

MoveSkillType: speed * unit->getMoveSpeedMult() + unit->getMoveSpeed();
AttackSkillType: speed * unit->getAttackSpeedMult() + unit->getAttackSpeed();
BuildSkillType: speed * unit->getRepairSpeedMult() + unit->getRepairSpeed();
HarvestSkillType: speed * unit->getHarvestSpeedMult() + unit->getHarvestSpeed();
RepairSkillType: speed * unit->getRepairSpeedMult() + unit->getRepairSpeed();
ProduceSkillType: speed * unit->getProdSpeedMult() + unit->getProdSpeed();
UpgradeSkillType: speed * unit->getProdSpeedMult() + unit->getProdSpeed();
MorphSkillType: speed * unit->getProdSpeedMult() + unit->getProdSpeed();


I'm not completely sure I understand this... Speed is multiplied by the multiplier then added to... Speed? Or is there a difference between "speed" and "unit->getProdSpeed()"?

I've taken the assumption that the speed is the skill cycles to do something, but how does it apply to move? Is it how many skill cycles are needed to move one tile (or how Lua splits each tile into 2x2 cells). And would harvest get one "hit" per skill cycle (and resources would be given depending on the "units-per-hit" value in the XML)?

I'm making a lot of assumptions, since reading the source is hard (it's a delicate webbing, or in other words, stuff is everywhere), so I could be entirely wrong in these guesses. Hopefully someone knows a more absolute answer.

[silnarm]

The code you found for production time is actually the code to "calculate" the text for the tool-tip. That's the best you're gonna get though, if you want a one liner. The actual relevant calculations are the number frames per skill cycle, which is modified by a 'total enhancement' that is cached within the Unit class via inheriting from EnhancementType.

 In the snippet hailstone posted The 'speed' is the 'incoming' skill-speed (from xml) and unit->getXxxxSpeedMult() and unit->getXxxxSpeed() are the cached total multipliers and static modifiers of all current upgrades, level, effects, etc on the unit.

And yes, the 40 you found should indeed be WORLD_FPS, thanks for pointing that out (the ini option doesn't do anything these days though, its always 40, I meant to change it back for the debug edition, but don't think I ever got around to it...)

Some of this was touched on here, will try to dig up what I had for that sometime.

[Omega]

Thanks! I thought there was such a topic, but couldn't find it. I'll slowly migrate the last few formulas to the wiki, mostly on XML/Skills.

Haven't seen the wiki yet? You should. I revamped ALL of the XML pages. The new format is part of my radical new guide to the XMLs, which shows all three engine's code on the same page. I don't expect everyone to agree with it, but it will make it easier for modders to find what they are looking for and learn to mod while seeing all the potent the XMLs have. Every type of XML has an outline now, in this one standardized format. No longer are there long comments that require the user to scroll to read, which may be as obscure as the XML tag itself, but instead we have a header for each one (though a special template is used to prevent the table of contents from showing all these headers, which number as high as over 100 on the XML/Skills and XML/Commands pages). Pretty much every XML element on either engines that I know of is documented, though I recently discovered many GAE only stuff in Shibboleth I didn't know existed, and that will be added over time, and there could be equally undocumented MG stuff.

Expect to see a modeling tutorial soon, as well as revamped guides on Modifying Glest. Reasoning to use the Wiki is to have one centralized source, as well, I know enough about LaTeX to create the math formulas, such as you see on the Skills page (use the <math> tag).

So, I strongly advise to take a look at the pages linked from XMLs, as they will soon be replacing the GAE and MG pages, which no longer have any extra information (I combed all of them with a fine tooth comb) besides what you added yesterday (I'll merge it later today, in about four or five hours). Maybe we should rename the enchantments page to something like a simpler "GAE/Enchantments" simply because the XML part will be depreciated in favor of a unified method (be sure to take a look before commenting). The upgrade XML page can be merged with GAE/Upgrades as well as XML/Upgrade. Cloak/XML will be merged with XML/Skills, XML/Commands, and GAE/Stealth. If we can't agree, this could all be reversed easily enough, but for the most part, it would make the layout of information more consistent and is geared at making things the easiest for the modder, using a plotted web of pages to eventually teach the user how to make a mod, and presenting both GAE and MG as options. Naturally, that's not complete yet, but it'll get there, so let's bear in mind the big picture.

Also, have you seen my documentation topic?