Tech Tree Java App - Updated 12/9/10

Research and Development in the SotS universe.
BlueEagle
Posts: 36
Joined: Wed Dec 08, 2010 9:35 am

Re: Tech Tree Java App - Updated 4/25/10

Post by BlueEagle » Wed Dec 08, 2010 9:14 pm

Thanks for answering on such short notice :)

At first, I tried simple things like calculating probabilities on calculator and editing in Paint :roll:

Eventually, I used Matlab for the calculations (insert variables and execute calculation) in two basic algorithms (path multiplying and path reunion of 4/3/2 branches - just inserting 0s for inexistant branches).
I also found Paint.NET to write those probabilities down very nicely.
As you might see from the edited image, I rounded probabilities for every calculation to the first decimal (1 per thousand).

This kind of manual Matlab-aided calculation is very simple, if tedious. You just advance along the tech paths with the multiplier and use the other, reunion algorithm, when tech paths merge. Here are my formulas (I'm sure you used the same probability maths):

a1=88.8; b1=75; a2=83.4; b2=60; ...
x(1)=a1*b1/100;
x(2)=a2*b2/100;
...

The path reunion should be for 4 paths, I noticed there are the mark 4 shields and the AI, maybe others. Here is for three:
a1=55.1; b1=75; c1=0;...
a = ((100-a1)*b1/100 + a1 );
a = ((100-a)*c1/100 + a );
x(1)=a;...

Eventually, vector x contains your result (6 values in the proper order) provided you entered the inputs correctly. Much easier than doing all of it on any calculator, much slower than having an app doing everything automatically :D

You just insert your numbers for a1(Human), a2(Hiver), etc.
And then I "painted" those numbers, one step at a time. Needless to say, the tree is far from completed :lol:

User avatar
Arkalius
Posts: 441
Joined: Tue Jun 20, 2006 6:06 am

Re: Tech Tree Java App - Updated 4/25/10

Post by Arkalius » Wed Dec 08, 2010 9:51 pm

Thanks for answering on such short notice


I set it up so I get notified by e-mail if this thread gets posted to... :)


Anyway, I'm not sure about your method. At first glance it actually looks wrong to me but that's because it's rather different than my approach so I'm not sure...

In my application, the true probability is a combination of the chance that you will have all of the required techs, and then the chance that you will have at least one of the leading branch techs.

For the requirement techs, this is pretty simple... you simply multiply together the probabilities of having each of those techs. However... if there are more than one, you must assume you already have all the others when doing the calculation for the probability for each one. This is one of the tricky parts.

Then, you have to calculate the chance of having at least one leading tech. This is done by taking the inverse of the probability of having none of them. So, you have to multiply the probability of having the tech by the probability assigned to the branch leading to the current one, and then take the inverse of that, and then multiply all these inverses together, then take the inverse of this product.

Finally, you multiply these two probabilities (from requirements and from leading techs) together to get the final probability.

The code that does this in my app can run recursively, since the probablity of each tech relies on the probability of ones it requires and relies on... As I do these calculations, I have to maintain a calling stack to make sure I don't end up recursively looping as can happen with a few techs which can lead to each other. Another thing is keeping track of the techs one is assuming exist in the current calculations. For example, when determining the probability of a parent tech, I have to first assume all of the main tech's requirements actually exist while calculating it. If I don't, then I could end up incorporating the probability that the required techs exist more than once which would produce wrong results.

To be sure, doing these probability calculations was probably one of the most intellectually rewarding programming endeavors I've undertaken in my career. I'm pretty good with probabilities and I feel very confident that I've worked out the correct means of doing these calculations... I suppose I could have messed up somewhere, but to me it seems right.

I don't know how much of a programmer you might be. I'd be willing to offer up the source code for you to look at. I'll warn you, it can be hard to follow if you are not well-versed in Java. I think I've commented it fairly well but how much that helps depends on how much you know about Java and programming.
-Arkalius

Check out my SotS2 tech tree java app!
For the SotS prime player, grab the original tech tree java app.

BlueEagle
Posts: 36
Joined: Wed Dec 08, 2010 9:35 am

Re: Tech Tree Java App - Updated 4/25/10

Post by BlueEagle » Thu Dec 09, 2010 7:38 am

Arkalius wrote:
To be sure, doing these probability calculations was probably one of the most intellectually rewarding programming endeavors I've undertaken in my career.

I think I know what you mean :). I've had some of these moments.

Anyway, I'm not sure about your method. At first glance it actually looks wrong to me but that's because it's rather different than my approach so I'm not sure...

Considering we both got the same numbers for most of it, I'm quite sure both our methods of calculation are correct. The difference is mine are pure calculations, while doing them the smart way (with an app) can go beyond human error but with the risk of the unseen program glitch. In any case, your app obviously succeeds, just that it has to be further perfected in order to feel 100% reliable :D

After staring at the tree for a while trying to figure it out, I came up with the obvious method, which involves merely two types of operation : "multiplication" and "reunion". Multiplication involves going up the straight tech lines and multiply probabilities.
Reunion happens when two paths merge into one tech. That almost always gets me to track the other path back to the bottom of the tree and provide its cummulated probabilities. Once I have all the lines leading to a certain tech, I add them up like this:

1. Imagine you have a1=40%, b1=20%, c1= 75%, d1=50%
2. First of all, let's say you consider a1. You have 60% chance of it "not happening". Then you consider b1. Within the 60%, there is a 20% out of 60 that "it will happen". You add this up with the first and get 52 %. Then you go to c1 and d1 doing the same thing, and finally you end up with 94%.

We both did the same math, otherwise we would not get the same results for say, Heavy antimatter cannon.

For example, when determining the probability of a parent tech, I have to first assume all of the main tech's requirements actually exist while calculating it. If I don't, then I could end up incorporating the probability that the required techs exist more than once which would produce wrong results.

:D That sounds like what happened with AI slaves for Zuul.

I'm pretty good with probabilities and I feel very confident that I've worked out the correct means of doing these calculations... I suppose I could have messed up somewhere, but to me it seems right.

I don't think you messed up, just that you overlooked something minor that ends up affecting some of the probabilities. It happens to me all the time when I build an algorithm. It doesn't mean something is messed up, the basic idea is almost always correct if it works over 80% !

I don't know how much of a programmer you might be. I'd be willing to offer up the source code for you to look at. I'll warn you, it can be hard to follow if you are not well-versed in Java. I think I've commented it fairly well but how much that helps depends on how much you know about Java and programming.

I was thinking of learning Java for the last months. I'm still a full-time student doing various assignments. Can you believe I've never done an actual full and independent program in either C or Java? I have the basic concepts and that is pretty much it.


The code that does this in my app can run recursively, since the probablity of each tech relies on the probability of ones it requires and relies on... As I do these calculations, I have to maintain a calling stack to make sure I don't end up recursively looping as can happen with a few techs which can lead to each other. Another thing is keeping track of the techs one is assuming exist in the current calculations.


What if you tried to build things from the bottom up? You have objects (nodes and links) building from the bottom of the tree, with multiple "scans" (as many as it takes) checking to see if all links leading to a node are completed, then building the above link and so on ? (I suppose I'd have to do that :D, from the ground up). No more overflows or exponentially complicated recursiveness !


Okay, let's take a look at the couple of things I mentioned in previous posts.

1. With your application, AI for Zuul is 59% and AI Virus is 76%. Obviously that cannot be the case. The AI branch is not connected to anything else, therefor AI Virus must be less (or equal to, provided 100% links) than AI.

2.Let's take a look at the Meson projector.

We both got roughly the same probabilities for Antimatter projector:
27 (27.1), 12 (12.4), 23 (21.2), 93 (93.2), 4 (4), 67 (66.7)
Mine are in (). There is a slight difference for Tarkas, I assume that was a build up of cuantization error on my part, as I started building this on less precise grounds. Or, the cuantization error might be on your app (I don't know when you rounded those numbers up, just for display or after each step).

It is already amazing that for such a complicated tree as that leading to Antimatter projector, we got roughly the same probabilities ! I don't think either of our methods got the basic thing wrong.

Now lets's look at the single other tech leading to Meson P, the Meson beam.
34 (33.6), 21, 14, 65 ( 64.8 ), 1 (1.2), 57 (56.7)
This time we have a perfect match, seeing as how you rounded them up ! I cannot tell if it is a match with floating point variables, my guess is I didn't have to round anything at .1, at that point.

Now let's find out how I calculated MP, and maybe discover why we got different results. I'll just check the calculation for humans:
- leading to MP from AP, the 27.1 of humans "encounters" 25% and becomes 6.775 (I rounded it to 6.8 at that point)
- leading to MP from MB, the 33.6% enounters 55% and becomes 18.48% (I rounded to 18.5)
- adding 6.775 with 18.48, as probabilities, I now get 24.003%
(100-6.775)*18.48/100 +6.775 = 24.003

Using your app, I notice that you get the same 25% and 55% links for humans, therefore we really were calculating on the same tree.
You got 17% instead of 24.

Finally, what happens if you actually round the probabilities at 1% level with each calculation.. (I'll use your numbers : 27 and 34)
27 * 0.25 = 27/4 = 6.75 ~7
34 * 0.55 = 18.7 ~ 19
(100-7)*19/100 +7 = 24.67 ~ 25
As you can see, rounding them leads to 25 instead of 24, but it still doesn't account for 17.


In fact, I'm sure some of my own calculations drifted more or less because of quantization, so I would assume yours are much better as long as the app doesn't fall into faulty logic.


Here is something wierd: one more glitch: leading into Shield projector from Fusion projector, you have 48% for human FP, while I have 47.5 for the same. What happens next in getting Shield projector is :
60% of 47.5 gives 28.5 for me
60% of 48 gives 27 for you, when it should give 28.8 ~29
This is even stranger seeing as how we have the same premise and conclusion for Liir on the same link:
90 (89.9) FP -> 72 (71.9) SP
Note that on that link we get different results for Human, Zuul, Tarka and Hiver but the same for Liir and Morrigi. For SP, you get Zuul probability at 2 % when it should be 4 % !


Don't worry, the app works great but needs some tuning for reliability :)
In any case, the point of this little project is giving us the idea of what each race is good at, and helping us along the game progress, to evaluate our changing chances for various techs. Also, a graphical representation would be great, both easier to view and mentally evaluate, also easier to appreciate (visualise) your chances and best path of getting to a certain tech, especially when you fail to get there by one of the branches.

User avatar
Arkalius
Posts: 441
Joined: Tue Jun 20, 2006 6:06 am

Re: Tech Tree Java App - Updated 4/25/10

Post by Arkalius » Thu Dec 09, 2010 6:48 pm

What if you tried to build things from the bottom up?


Well my method ultimately does that in a way... I starts at leaf nodes (techs that lead nowhere). Since the probability of a tech depends on the techs that lead to it, the recursive calls keep going down all the way to the root of the tree and then the calculations unravel all the way back up the stack.

With your application, AI for Zuul is 59% and AI Virus is 76%. Obviously that cannot be the case


Indeed, you are right, that is a problem. The appropriate way to calculate the chance of virus in this case would be to calculate the chances of not getting any of the 4 links that go to it assuming you have AI, and then multiply the inverse of that to the chance of getting AI... since the other 3 techs are all 100% from AI.

I'm having a diffuclt time trying to determine what it is about this particular situation that causes the problem. I think it has to do with multiple parent techs having themselves a common parent. I'm going to have to spend some time trying to figure out how to work around this programmatically.

The issues you identified with projectors may have to do with group requirements. Are you factoring those in? Some techs require a "group" which I assume means one of any of a set of techs (that's how I calculate it in my code anyway). I'm not sure that's the issue... I'm not at home so I can't examine it more closely.

But for sure, the AI slaves thing is a glitch that I'll have to work out.
-Arkalius

Check out my SotS2 tech tree java app!
For the SotS prime player, grab the original tech tree java app.

User avatar
ProjectLevyDelta
Posts: 3945
Joined: Fri Nov 12, 2010 4:42 am

Re: Tech Tree Java App - Updated 4/25/10

Post by ProjectLevyDelta » Thu Dec 09, 2010 7:42 pm

Thank very much for this it is a life saver when trying to figure out the tech tree and what you actually have to get to get something else. As well as giving me percentages great job man! :thumbsup:

Also it seem Meson beams you cant get through energy weapon tree... but HCL is in energy weapon tree? It seems Meson beats you get from partical beam tree, but the Meson Beam projector is in the plasma tree? does this mean you can get one, but not the other then??

I always though you would need Meson Beams before you could get a Projector variant of it :wink:

I am curious however about the Liir shield tech. Maybe Mecron or someone else would have a better explanation or answer. Anyway if you are NAP or rather in an Alliance with a liir using Shield Focusing do your ships also get the benefit of the shield?? Or does it still only go to liir cruisers and ignore your own ships despite normally you might want to benefit your allies not let them become sitting ducks to weapon fire :roll: !ouch

Then again Tarka have pretty decent chances at getting cloak lvl 2 so I don't mind if my buddies shield focusing doesn't help me out. 8)

Once again great job :D
I really do wish I could script like people here.. all I can do is graphic design
:shock: quantum shaft links to cloaking! :shock: I did not know this :bangdesk:
Image

User avatar
Nspace
Kerbicron Cleric
Kerbicron Cleric
Posts: 4665
Joined: Thu Dec 29, 2005 7:26 pm

Re: Tech Tree Java App - Updated 4/25/10

Post by Nspace » Thu Dec 09, 2010 11:57 pm

[Edit] 1973 - The Dark Side of the Moon :thumbsup: IMO, the greatest album of all time[/Edit]

Alright BlueEagle and Arkalius, I have a question for one or both of you. My numbers for the total probability of Zuul getting AI don't seem to match up with what you have, so I'm going to show my work and try to find out if I'm doing something wrong.

OK, so there are 5 paths for the Zuul to take to AI:

1) Root to Cyber to Expert to AI
# (1.0 * 0.4 * 0.3) = .12 or 12 %

2) Root to Cyber to AdvRob to DRN_cmbt to DRN_Squad to WingMan to AI
# (1.0 * 1.0 * 1.0 * 1.0 * 1.0 * 0.3) = .3 or 30%

3) Root to FTLCom to BtlCmp to DataSyn to CmbtAlg To AI
# (1.0 * 1.0 * 1.0 * 0.9 * 0.2) = .18 or 18%

4) Root to FTLCom to BtlCmp to DataSyn to CmbtAlg to HoloTac To AI
# (1.0 * 1.0 * 1.0 * 0.9 * 0.9 * 0.2) = .162 or 16%

5) Root to FTLCom to BtlCmp to DataSyn to ArmCom to HoloTac To AI
# (1.0 * 1.0 * 1.0 * 1.0 * 0.9 * 0.2) = .18 or 18%

So when I add all those paths up I get the following (using the formula ZedF posted in his 2nd post in this thread):

(1-((1-0.12) * (1-0.3) * (1-0.18) * (1-0.162) * (1-0.18))) = 0.652902 or 65.2902%

So how are you getting 59% for Zuul getting AI?
"Quando omni flunkus, mortati" - "When all else fails, play dead"
SotS 1 wiki: http://wiki.swordofthestars.com/sots1/Main_Page
SotS 2 wiki: http://wiki.swordofthestars.com/sots2/SotS2_Codex

User avatar
Arkalius
Posts: 441
Joined: Tue Jun 20, 2006 6:06 am

Re: Tech Tree Java App - Updated 4/25/10

Post by Arkalius » Fri Dec 10, 2010 12:58 am

I think the problem with your method, and it's a problem I'm facing in a different way, is that those probabilities you've calculated are not independent (because they have common elements through them) and the value you end up with is therefore incorrect. When I get home tonight I am going to spend some time rethinking the way this needs to be approached.
-Arkalius

Check out my SotS2 tech tree java app!
For the SotS prime player, grab the original tech tree java app.

ZedF
Board Ninja
Board Ninja
Posts: 12540
Joined: Sun Aug 27, 2006 7:13 pm

Re: Tech Tree Java App - Updated 4/25/10

Post by ZedF » Fri Dec 10, 2010 1:04 am

I agree that (part of?) the problem is that you are treating the two paths through holographic tactics as independent when they are not. You should calculate the chance to get to holographic tactics via either path, and then multiply that by the chance to get from holographic tactics to AI.
Zed's TARs (sample):
Fractious Allies -- Hiver vs. Hiver, with allies
Who Let The Bugs Out -- Hiver vs. Tarka and Zuul
Tarka Ascendant -- Tarka vs. Hiver and Zuul

Strategy & Tactics Forum Archive -- More posts on strategy, tactics, and TARs

User avatar
Nspace
Kerbicron Cleric
Kerbicron Cleric
Posts: 4665
Joined: Thu Dec 29, 2005 7:26 pm

Re: Tech Tree Java App - Updated 4/25/10

Post by Nspace » Fri Dec 10, 2010 4:43 am

Ahhh... OK, I got it now. The first three paths are correct, there is only one possible path through the first two and since there is only one possible path from DatSyn to CmbtAlg (set at 90%) then path 3 is also unchanged. It's the jump to HoloTac that was miscalculated. The total chance to get HoloTac is:

4) DataSyn to CmbtAlg to HoloTac
# (0.9 * 0.9) = .81

5) DataSyn to ArmCom to HoloTac
# (1.0 * 0.9) = .9

Total chance of HoloTac
(1-((1-0.9)*(1-0.81))) = .981 or 98.1%

Then since there is only one path from HoloTac to AI, path 4 and 5 are actually combined and then multiplied by the chance of HoloTac to AI (.2 or 20%) giving a total of .1962 (19.62%).

So the total chance is:

(1 - ((1 - .12) * (1 - .3) * (1 - .18) * (1 - .1962))) = .593985 or 59.3985%

Thanks for the help. :) It looks like the total chance of each tech along the way must be calculated before you can move on to the next "level" of techs further up the tree.
"Quando omni flunkus, mortati" - "When all else fails, play dead"
SotS 1 wiki: http://wiki.swordofthestars.com/sots1/Main_Page
SotS 2 wiki: http://wiki.swordofthestars.com/sots2/SotS2_Codex

User avatar
Arkalius
Posts: 441
Joined: Tue Jun 20, 2006 6:06 am

Re: Tech Tree Java App - Updated 4/25/10

Post by Arkalius » Fri Dec 10, 2010 7:36 am

Well I've fixed the problem with AI Virus. I'm actually pretty happy with the solution... basically for each tech when calculating probabilities, I make a list of all of the paths that lead to the tech, then take the intersection of all of those paths. If there's a tech in common, I treat it like a requirement and calculate from that perspective and it seems to fix this particular problem. I'm not sure if there are any other examples of this kind of tech bottleneck in the game to test against.

I still feel like there is another scenario that's hard to describe that might cause a similar error... I'll continue investigating this at some point.

The discrepancies you mentioned with meson projector and the shield projectors seem to me to most likely be a failure to account for group requirements as I mentioned before, unless you tell me you've factored those in. The meson projectors one is particularly wierd because it both requires and is a member of the projectors group. Basically, I have to pretend meson projectors isn't in the group when calculating the odds of having the group present in this particular instance.

I've updated the application online and you can download the new version here or from the link in the first post.
-Arkalius

Check out my SotS2 tech tree java app!
For the SotS prime player, grab the original tech tree java app.

BlueEagle
Posts: 36
Joined: Wed Dec 08, 2010 9:35 am

Re: Tech Tree Java App - Updated 12/9/10

Post by BlueEagle » Fri Dec 10, 2010 3:24 pm

Wow ! I just realised that meson projector needs projectors when coming from Meson beam :D I'll fix that and tell you if my new probability matches with yours. Hehe, now my calculation suddenly spikes up, as there is no clear way to determine it (I have to split each projector).


EDIT:
I am going to make a simple but incomplete adjustment involving Plasma, Fusion and Antimatter Projector. A complete evaluation would take the presence of fusion cannon into consideration (it is a common but not exclusive point on the road to both AP and FP, and is random for each race).

Before I calculate this, I have to say there is a far easier way to arrange this probability tree :D
Use the in-game generator to make 10,000 trees for each race, and chart the probabilities. 10,000 should give below 1% error, problem solved ! (and little math needed :)) Can that be done ?

EDIT2:
And if I want a completely correct calculation, I should probably even adjust the projector condition of having Antimatter projector in the final calculation of not having a direct link to Meson projector !! Also, Meson beam is a must if you come from Antimatter Projector...
Well at least I know that my calculation has to be redone.

BlueEagle
Posts: 36
Joined: Wed Dec 08, 2010 9:35 am

Re: Tech Tree Java App - Updated 12/9/10

Post by BlueEagle » Sat Dec 11, 2010 7:33 am

I'll ask this again.. can you use the in-game tree generator or a clone of that to make a large number of trees and obtain the probabilities from statistics ?

As it is, I calculated Meson projector for humans on a very simple basis and got your 17 (I think it was 16.53), but it's not a complete calculation. You would have to factor in a reduced probability for fusion cannon for not having Fusion projector and then for Antimatter projector for not having the direct link from Antimatter Projector to Meson Projector. Then you would have to make a similar reduction for Meson beam for not having a direct link from it. Only then do you get the "real" probability, which will be less than 16.5 - making even your 17 wrong :roll:. This is all so terribly complicated ! Much easier to make a plain statistic.

If you decide to do that, then I think it would be a great idea to also include probabilities for coming from different paths, for techs that are "leaf"s to more than one tree. And a graphical representation generator :D

EDIT: also specify "conditioned" (on the said graphic) for techs that are conditioned beyond their immediate links, to make it clear that their probabilities involve more than their direct links. You do specify "requires" with the current app (something I missed :) ).

ZedF
Board Ninja
Board Ninja
Posts: 12540
Joined: Sun Aug 27, 2006 7:13 pm

Re: Tech Tree Java App - Updated 12/9/10

Post by ZedF » Sat Dec 11, 2010 11:02 am

You'd have to ask in the mod forum, but I doubt it's practical. You'd probably have to do it manually.
Zed's TARs (sample):
Fractious Allies -- Hiver vs. Hiver, with allies
Who Let The Bugs Out -- Hiver vs. Tarka and Zuul
Tarka Ascendant -- Tarka vs. Hiver and Zuul

Strategy & Tactics Forum Archive -- More posts on strategy, tactics, and TARs

User avatar
Arkalius
Posts: 441
Joined: Tue Jun 20, 2006 6:06 am

Re: Tech Tree Java App - Updated 12/9/10

Post by Arkalius » Sun Dec 12, 2010 1:17 am

BlueEagle wrote:I'll ask this again.. can you use the in-game tree generator or a clone of that to make a large number of trees and obtain the probabilities from statistics ?


You ask this question as if you think such a thing would be easy... The simple answer is no. The long answer would start with "it would be very difficult".

As it is, I calculated Meson projector for humans on a very simple basis and got your 17 (I think it was 16.53), but it's not a complete calculation. You would have to factor in a reduced probability for fusion cannon for not having Fusion projector and then for Antimatter projector for not having the direct link from Antimatter Projector to Meson Projector. Then you would have to make a similar reduction for Meson beam for not having a direct link from it. Only then do you get the "real" probability, which will be less than 16.5 - making even your 17 wrong :roll:. This is all so terribly complicated ! Much easier to make a plain statistic.


Hey, I enjoy discussing this topic, but your presumption that I must be doing it wrong is a little arrogant. Now, I recognize that my current algorithm actually has a problem in it. It can end up treating dependend probabilities as if they are independent. I partially fixed that in the recent update, which solved the AI Virus issue. I'm still working on figuring out how to fix it entirely. Understanding how to calculate the probability manually in a specific instance and building an algorithm that can do it arbitrarily are two very different challenges.

If you decide to do that, then I think it would be a great idea to also include probabilities for coming from different paths, for techs that are "leaf"s to more than one tree. And a graphical representation generator :D


Yeah, and while I'm at it, I'll add a module that should solve the US's budget problems and calculate how to create a cure for AIDS. In all seriousness, you throw that last suggestion around as if it's a simple thing. Generating a graphic is something that is beyond my expertise and which would take an exhorbitant amount of time to boot. It also seems like a waste of time, considering how there are perfectly good manually-created graphics already available.

EDIT: also specify "conditioned" (on the said graphic) for techs that are conditioned beyond their immediate links, to make it clear that their probabilities involve more than their direct links. You do specify "requires" with the current app (something I missed :) ).


When I was creating the original tech tree graphic, I was trying to figure out a way to represent requirements. But, I don't think there really is a good way to do that without cluttering up the image too much. If you think you know a good way to do this, I recommend suggesting it in the tech tree graphic thread.
-Arkalius

Check out my SotS2 tech tree java app!
For the SotS prime player, grab the original tech tree java app.

BlueEagle
Posts: 36
Joined: Wed Dec 08, 2010 9:35 am

Re: Tech Tree Java App - Updated 12/9/10

Post by BlueEagle » Sun Dec 12, 2010 7:14 am

Arkalius wrote:
BlueEagle wrote:I'll ask this again.. can you use the in-game tree generator or a clone of that to make a large number of trees and obtain the probabilities from statistics ?


You ask this question as if you think such a thing would be easy... The simple answer is no. The long answer would start with "it would be very difficult".


OK, I just wish I knew how to acces the data from the game files the way you did. As it is, I don't know how it could be done, so no idea that it would be harder.


As it is, I calculated Meson projector for humans on a very simple basis and got your 17 (I think it was 16.53), but it's not a complete calculation. You would have to factor in a reduced probability for fusion cannon for not having Fusion projector and then for Antimatter projector for not having the direct link from Antimatter Projector to Meson Projector. Then you would have to make a similar reduction for Meson beam for not having a direct link from it. Only then do you get the "real" probability, which will be less than 16.5 - making even your 17 wrong :roll:. This is all so terribly complicated ! Much easier to make a plain statistic.


Understanding how to calculate the probability manually in a specific instance and building an algorithm that can do it arbitrarily are two very different challenges.


Yes, I realise that much. Just saying that when calculating the probability of having projectors when coming from Meson beam and of having Meson beam without a direct link is more complex - it reduces probabilities along the way, doesn't factor the plain original probabilities for those techs.

Imagine there was a 100% leading from fusion cannon to fusion projector and you didn't get fusion projector. That would cut the cannon line leading to Antimatter projector, clearly reducing its probability. What might be less obvious is that, as it is, it still reduces that probability, to a lesser degree (and I would have to improvise a formula for that, don't know for sure what it is).

I'm thining of creating a proportional relation that increases or decreases the likelyhood of a tech not being there based on the probability of another tech coming out of it, that you don't get.
For example, if Fusion cannon is overall 80% and Fusion Projector came from it at 50% (it's actually 45), not getting Fusion Projector would halve the chance you get Fusion Cannon, reducing its likelyhood to 40% (this is based on the idea that at 100%, it cuts the likelyhood alltogether).

Of course, this is all a ton of calculations and reevaluations on trees for just one tech (better having inside an app than manually building those probabilities).

If you decide to do that, then I think it would be a great idea to also include probabilities for coming from different paths, for techs that are "leaf"s to more than one tree. And a graphical representation generator :D


Yeah, and while I'm at it, I'll add a module that should solve the US's budget problems and calculate how to create a cure for AIDS. In all seriousness, you throw that last suggestion around as if it's a simple thing. Generating a graphic is something that is beyond my expertise and which would take an exhorbitant amount of time to boot. It also seems like a waste of time, considering how there are perfectly good manually-created graphics already available.


OK, I get it, the graphic can be manually edited for less effort once you have the datat for it (mostly only have to edit it once). I haven't even gotten to writing an app, so I'm not going to wonder about people having different skills.

EDIT: also specify "conditioned" (on the said graphic) for techs that are conditioned beyond their immediate links, to make it clear that their probabilities involve more than their direct links. You do specify "requires" with the current app (something I missed :) ).


When I was creating the original tech tree graphic, I was trying to figure out a way to represent requirements. But, I don't think there really is a good way to do that without cluttering up the image too much. If you think you know a good way to do this, I recommend suggesting it in the tech tree graphic thread.


Yea, I could see my own attempt at adding to that graphic cluttering it. I figured adding a symbol next to conditioned techs would make a difference, with each symbol explained to the side of the graphic.

Post Reply

Return to “The Tech”

Who is online

Users browsing this forum: No registered users and 3 guests