Race Tech Trees (Resources)

I’ve collected all relevant data for the Vaygr and Hiigaran tech trees and put it into a visual format that’s easier to process.

Intended originally for theorycrafting and comparing with other races, I decided to share it as it may be useful for other veterans and new players also. Let me know what you guys think.

Help yourselves. :blush:

Updated 11/04/2015: New Hiigaran Tech Tree, Revised Vaygr appearance for clarity. Changed thread name to keep all 4 tech trees in one thread.

Taidan + Kushan coming soon!


7 Likes

Yeah, this is super useful.

Really wish they had used a formula that is the listed speed with a single module and that the ingame UI showed the time. :confused:
It’s odd to use a number in definitions that never actually appears as-in in game.

You and me both. Being someone that really hates hidden stats, I had to know what gains the research I was doing was actually giving me, hence the added numerical values.

Yeah. The formula probably should have been
time = time / max(#*0.75, 1)^0.5
not
time = time / (#+1)^0.5

Currently real time with one is 29.3%(+29.3%) faster, the second 42.3%(+13%) and the third 50% faster(+7.7%)
That other formula would make the first module the listed (and really 30% lower) time, second 81.6%(+18.4%), and third 66.6(+15%). Could actually make a third module on Hiig an actual potential build, but probably not. At least it’d make it more of a thought instead of +7.7% being obviously not worth it.

Even if they didn’t want a second module to give so much, there’s better ways to achieve that and keep the time listed correct for 1 module.

Then they could have listed nice round numbers in the tooltip for 1 module times, that lower with more modules. Instead you get these odd numbers for a single module and they aren’t even listed in game.

It seems like HW2 is full of lessons of what not to do. :frowning: Even if, yes, the end result of its gameplay winds up to be fairly nice in many areas, don’t get me wrong. The under-the-hood things are really odd.

Great stuff. Can I ask what you used to make this chart with?

Sure, I used Lucidchart (there’s a free usage option) and then imported to GIMP to give it a bit of ‘flash’. :smile:

Indeed. Whilst I was testing the capital ship armor upgrades on destroyers I noticed they’d made Level 1 Armor give +29.99988…% extra armor (110,499 total) and Level 2 Armor to give +30.00117…% extra armor. Why they couldn’t have just given each level a 30% increase (which achieves exactly the same thing) is beyond me. :confused:

That’s almost surely just due to floating point precision, but there are ways to stop that from happening.

This is sweet. Good stuff!

Isn’t that because the HP is rounded to the nearest whole digit?

No. It’s hard to explain. You can google “floating point precision” and read something more in depth.

Basically it’s because floating points are only precise to 6-9 digits.
Like 0.1+0.2 as a flat is going to give you 0.30000000000000004
But this doesn’t always happen. 0.5+0.2 is 0.7 just fine.

This is also why my dump of weapon and ship values has some weird numbers like 32.000002 and such when really it’s 32. I could have made it come out nice and round and had done the math more properly, but I just didn’t bother.
https://github.com/MikeMcl/bignumber.js/ This is a node.js module that I SHOULD have used if I was bothered. Really I think doing it in C/C++ is similar. In JS, every number is a float and you run into the floating point precision all the time.

It doesn’t really cost more resources to do. That sort of math is cheap. It’s just a bit of a pain as a programmer.

I… have knowledge of how floating points work, Lua uses double precision floating points exclusively. I just didn’t think it was the case here, unless the back-end is using single precision floating points to store Health and then returning those values back to Lua.

Right. I’m sure it does just that.
The game runs in C++. (Or rather it’s written in C++, then compiled. It’s sort of a misnomer to say it runs in C++ when it’s not a VM) Those values in ship files are parsed from Lua into the running game, I believe.

Then again, based on what BitVenom has said, it sounds like the Lau runs along side. But I believe it’s just that case with the “AddCustomCode” stuff and not .ship and .weapon files. I’d imagine .ship and .weapon are simply parsed at runtime, or it’s something that executes in Lua only to set values used in the game. Those are values the engine code uses, after all. The core game doesn’t run in Lua.

When you call some of the functions in the API, it’s also my understanding that what is returned comes from the C++ running game and is just exposed to the Lua.

Lua is a VM, and when you have VMs written in C/C++ well then it tends to make it easy to extend some other programs with those. But you only extend what’s exposed to it and the program itself has to call on what the VM runs somehow, so there’s a back and forth.

Lua always runs in C :stuck_out_tongue:
I understand what you are getting at with the ship files however.

Lua variables are always returned in their native double format, but what ever relic do from there is a mystery however. So you could be right, I just don’t have any way to prove or disprove otherwise.
We could of course crunch the math behind it, if one feels like expending time on it.

P3G5SU5 should be satisfied with your answer…

Right, it does. It’s a VM.
But the thing is, like every time you attach a VM to another program, it only has access to what the main program has exposed to it. What is called in the Lua gets called based on the main program calling it.
And when the main program takes values from the VM, there are no assurances in the VM as to what happens next to it.

So the main program can easily be getting doubles from Lua and converting them to something else. Lua is dynamically typed, after all, which makes these things happening even more likely.

When these things are done, it’s commonly for some simple moddability where the VM acts as a hyper controllable(as in, restrictable) sandbox.

That said, just because a number is a single precision float doesn’t mean you can’t get accurately mathed numbers, like I mentioned. It’s just not as simple as x+y or x*y.

Lua is dynamically typed, but internally every number is a double no matter what, it does not lose precision (beyond what doubles are capable of), and it cannot even do integer math. It’s possible to compile the entire VM to integers if you have no floating-point however.

“I noticed they’d made Level 1 Armor give +29.99988…% extra armor (110,499 total)”
Are you not sure that 30% would be 110,499.4 ?

85000*1.3 = 110500

And when I said that, I meant that the game has to type those numbers after it gets them from the VM. They aren’t going to stay doubles, generally.

Then I humbly accept :smiley:
I didn’t know what all the variables were.

Well you wouldn’t normally want to cast every double to a different precision, especially if you’re using Lua in realtime.

Yes but, I don’t think .ship, .weapon, .research, etc are used in real time. They’re run once on map load to make content from game code.

Only the addCustomCode and maybe some others that point to a separate Lua script I think get called based on some event or tick.
And when those are run, they’re just calling native exposed functions and supplying arguments. To my understanding, at least.