For the 20 hour achievement - does starting AM matter more than skills since you'll be failing most of the challenges for most of the voyage?
Interesting question.
It depends. Certainly if you are going for 20h, traits will matter more than they would otherwise, but there's probably a limit where you don't want to slot worthless crew just for the trait.
If you slot worthless crew everywhere, you will lose like 4-6 hours compared to slotting "good" (FE/FF super rare) crew. That's a lot.
In comparison, you get 25 AM per trait match, which is equal to about 1 minute per extend. Assuming you have a 2500 AM ship, you will need to extend at most 9 times. So that's about minutes (actually it's a bit more than 10). There are 12 slots, so 12*10 = 120 minutes, or 2 hours. 2 hours is a lot less than 4-6 hours.
In practice, you don't have to choose between "very good" and "absolutely terrible", though, so it depends on how much skill exactly you'd be giving up.
So, it's probably a good idea to give up proportion of skill - like maybe 1/3, for a trait in this case, but that's about it.
Maybe I'll add a calculation to the estimator for how much dilithium it would cost to get to 20 hours.
Note that the dil cost will vary a lot (by like 250) depending on when exactly you have to refill. If you refill at 18.1 hours, it will be much cheaper than if you have to refill at 19.9 hours.
So with that in mind, it's actually more important to calculate it so you refill closer to 18 hours.
Thank you very much! I appreciate the update and will be using it to scheme my 20-hour voyage.
Edit: Reread the first post and saw that I could have answered my questions there, so I appreciate you taking the time to hold my hand through it and add the estimator. I've shared with my fleet and advised to add a 250 dil safety cushion.
Found a small bug with the -5% and -10% estimates when using the Current AM and mins elapsed feature.
For example if you put in a minutes elapsed of 8 hours and a current antimatter of 200, it'll show you a -5% estimate of less than the current amount of time. The expected behavior should probably be calculating -5% of the estimated remaining time and adding that the the current time, rather than calculating -5% of the estimated total time.
It's a very minor non issue though, and I'm loving the ability to be able to enter in a current time.
Found a small bug with the -5% and -10% estimates when using the Current AM and mins elapsed feature.
For example if you put in a minutes elapsed of 8 hours and a current antimatter of 200, it'll show you a -5% estimate of less than the current amount of time. The expected behavior should probably be calculating -5% of the estimated remaining time and adding that the the current time, rather than calculating -5% of the estimated total time.
It's a very minor non issue though, and I'm loving the ability to be able to enter in a current time.
"It's not a bug, it's a feature!"
Thanks for pointing it out, but, yeah, I actually was aware of it. I just couldn't think of an easy way to have the range relevantly and accurately adjust. Simply scaling it would be wrong because there could actually be much greater variation near than over the course of the whole voyage due to where the random pass/fail ranges happen to be.
Maybe I'll work out improvements to that some day.
Found a small bug with the -5% and -10% estimates when using the Current AM and mins elapsed feature.
For example if you put in a minutes elapsed of 8 hours and a current antimatter of 200, it'll show you a -5% estimate of less than the current amount of time. The expected behavior should probably be calculating -5% of the estimated remaining time and adding that the the current time, rather than calculating -5% of the estimated total time.
It's a very minor non issue though, and I'm loving the ability to be able to enter in a current time.
Similarly, the refill times decrease as you enter more elapsed time and decrease your current AM. May need to have separate boxes for starting and current AM to keep those working.
Found a small bug with the -5% and -10% estimates when using the Current AM and mins elapsed feature.
For example if you put in a minutes elapsed of 8 hours and a current antimatter of 200, it'll show you a -5% estimate of less than the current amount of time. The expected behavior should probably be calculating -5% of the estimated remaining time and adding that the the current time, rather than calculating -5% of the estimated total time.
It's a very minor non issue though, and I'm loving the ability to be able to enter in a current time.
Similarly, the refill times decrease as you enter more elapsed time and decrease your current AM. May need to have separate boxes for starting and current AM to keep those working.
That's a very good point. I'll try to get that fixed.
Found a small bug with the -5% and -10% estimates when using the Current AM and mins elapsed feature.
For example if you put in a minutes elapsed of 8 hours and a current antimatter of 200, it'll show you a -5% estimate of less than the current amount of time. The expected behavior should probably be calculating -5% of the estimated remaining time and adding that the the current time, rather than calculating -5% of the estimated total time.
It's a very minor non issue though, and I'm loving the ability to be able to enter in a current time.
Similarly, the refill times decrease as you enter more elapsed time and decrease your current AM. May need to have separate boxes for starting and current AM to keep those working.
That's a very good point. I'll try to get that fixed.
i was hoping to incorporate your estimator into a spreadsheet for my own use. i notice you have a sample spreadsheet file available, but it doesn't produce the same answer as the web script. do you have an updated spreadsheet which more closely mimics the javascript accuracy?
The main benefit is that the estimator will now show a more meaningful range of outcomes than before, based on actual RNG over 100s of simulations.
The number of simulations can be adjusted. It's set to 500 (per refill) by default to be friendly to lower end hardware.
Unfortunately due to the relatively poor performance of JavaScript, the tradeoff is that the results will fluctuate somewhat. However, I believe this should be more useful overall.
Made some other changes to UX - you'll need to click a button or press enter now to start the estimate (which will then auto-update). This is because the Monte Carlo is non-trivial, as is the graph drawing. I hesitated to make this change, but I think it's for the best if we are to keep the Monte Carlo approach. This way it's also harder to forget to update your starting AM. (there are some hidden default values used to do an initial calculation just to populate the output so it doesn't look empty on load)
I replaced the "worst" result with information about the chance you have of seeing the last dilemma - I think this is practically what many/most people optimize for, and now we can measure it "directly".
I really like your tool and use it often. For some reason when I put 10 hours in for the time elapsed it gives me a prediction for the dilemma at 10 hours instead of 12 hours. SInce that's already occured, it's not helpful information. It does display the other two predictions correctly. It's still very useful despite this happening, but I thought I would let you know about it.
I really like your tool and use it often. For some reason when I put 10 hours in for the time elapsed it gives me a prediction for the dilemma at 10 hours instead of 12 hours. SInce that's already occured, it's not helpful information. It does display the other two predictions correctly. It's still very useful despite this happening, but I thought I would let you know about it.
Thanks!
The way the dilemma chance prediction works is it shows the chance for the farthest dilemma seen in any of the simulation runs that has at least a 1% chance. If it's showing the previous dilemma, that means the chance of seeing the next one is less than 1%.
I did it this way because of the nature of the probability distribution in many cases allowing rare, but large outliers. And since the display is rounded down to the nearest integer percentage point, you'd otherwise be seeing 0% a lot, which is not useful either.
I guess I could make it a special case to show 0% for the next one instead in this situation. Maybe that will reduce confusion, but the meaning is the same.
If you think your chance of the next dilemma should be more than 1%, please let me know your inputs and I'll look into that possibly being a bug.
I really like your tool and use it often. For some reason when I put 10 hours in for the time elapsed it gives me a prediction for the dilemma at 10 hours instead of 12 hours. SInce that's already occured, it's not helpful information. It does display the other two predictions correctly. It's still very useful despite this happening, but I thought I would let you know about it.
Thanks!
The way the dilemma chance prediction works is it shows the chance for the farthest dilemma seen in any of the simulation runs that has at least a 1% chance. If it's showing the previous dilemma, that means the chance of seeing the next one is less than 1%.
I did it this way because of the nature of the probability distribution in many cases allowing rare, but large outliers. And since the display is rounded down to the nearest integer percentage point, you'd otherwise be seeing 0% a lot, which is not useful either.
I guess I could make it a special case to show 0% for the next one instead in this situation. Maybe that will reduce confusion, but the meaning is the same.
If you think your chance of the next dilemma should be more than 1%, please let me know your inputs and I'll look into that possibly being a bug.
No worries. That makes total sense now that I've read your explanation. I'm pretty sure that it's working properly then. I'm not sure you need to change it, but you could put a sentence or two explaining how it works on the page. Then nobody else would be confused in the future.
Your tool is great though. I pretty much make it to at least 7 hrs and 30 minutes on the original run of every voyage, but figuring out how far a refill is going to get me is very helpful in knowing when to recall and/or extend additional times. Your predictions are accurate enough to set a timer and recall the voyage with less than 100 am when it goes off. That is really useful information and has saved me money.
I have a question and I can't seem to find it addressed anywhere in this thread. How do I go about determining my Proficiency %? There's a notation to tweak it if using Gauntlet crew, and I don't understand what I'm supposed to do there.
Required Z values for 95% CI is 1.95996 and 50% CI is 0.67449.
I think giving those intervals are a better indication of what to expect from a voyage than averages and odds of getting past a particular dilemma.
Thanks for the suggestion.
Back before I used a Monte Carlo simulation to produce the results, I considered somehow figuring out the distribution and doing something like this (the question remains.. how, exactly?)
The current version produces an actual distribution from thousands of trial (or however many you set).
Even with a very, very large number of trials, the distribution is not quite a normal distribution (although it is close). That's one issue with using statistical confidence intervals/standard deviations.
Mostly, though, I don't see value this would add. Maybe you can clarify the use case?
The way I see it, you basically want to either optimize for longest average time or you want to optimize your dilemma count. Either way, you want to know when to check the voyage.
The current output I have is intended to cover those specific use cases. The 90% and 99% cover two what I think would be the most interesting data points as far as calculated risk is concerned in terms of how long to wait before checking the voyage.
In a sense, if I were to show the 10%/1% estimate, that would complete the other half of the "interval". But I just don't see the point. If we are to assume a normal distribution, unless you are very close to the end, you can generally trivially calculate "lucky case" scenarios by adding the difference between the median (50%) estimate and the 90% or whichever.
Also, the new chart shows the actual distribution.
Now, I do intend to enhance the chart a little further so that the tooltip/annotation on it will show the cumulative percent chance to reach that voyage length. That would cover any other % that someone might want to know besides 50, 90, and 99.
As far as dilemmas, there's really only one within range for any given voyage, realistically. I guess if you have a roster entirely made up of 5/5 gauntlet crew, then you might have a more than 1% chance of the next dilemma while also having a less than 99% chance of the previous one. But that's just very unlikely, and the rest of the output would reveal that.
I have a question and I can't seem to find it addressed anywhere in this thread. How do I go about determining my Proficiency %? There's a notation to tweak it if using Gauntlet crew, and I don't understand what I'm supposed to do there.
I initially wasn't sure whether I should even include that field at all.
The basic answer is don't worry about it. It doesn't make much difference.
Hazard checks are like mission node rolls. They roll your proficiency in that skill and add the base/core value.
Prof% is a percentage relative to your average roll. So if you had 800 + (100-300), your prof% would be 20%. Technically because primary and secondary skill checks are checked more often, ideally your weighted average would go there. So if you were to actually calculate it, you'd calculate it per skill and multiply each skill's value by the chance of that skill being chosen (0.35, 0.25, 0.1) and add them together.
Nobody would actually do that, though.
But what you can do is play with the value. e.g. you can try 10 or 30% and that would may give you a wider range of possible outcomes. If you want to be more risk averse without calculating/guesstimating it, you can assume that your prof% is higher than it really is.
I have a question and I can't seem to find it addressed anywhere in this thread. How do I go about determining my Proficiency %? There's a notation to tweak it if using Gauntlet crew, and I don't understand what I'm supposed to do there.
I initially wasn't sure whether I should even include that field at all.
The basic answer is don't worry about it. It doesn't make much difference.
Hazard checks are like mission node rolls. They roll your proficiency in that skill and add the base/core value.
Prof% is a percentage relative to your average roll. So if you had 800 + (100-300), your prof% would be 20%. Technically because primary and secondary skill checks are checked more often, ideally your weighted average would go there. So if you were to actually calculate it, you'd calculate it per skill and multiply each skill's value by the chance of that skill being chosen (0.35, 0.25, 0.1) and add them together.
Nobody would actually do that, though.
But what you can do is play with the value. e.g. you can try 10 or 30% and that would may give you a wider range of possible outcomes. If you want to be more risk averse without calculating/guesstimating it, you can assume that your prof% is higher than it really is.
The bolded part is the only thing I understood, but that's good enough for me and Bobby McGee. Thanks!
Required Z values for 95% CI is 1.95996 and 50% CI is 0.67449.
I think giving those intervals are a better indication of what to expect from a voyage than averages and odds of getting past a particular dilemma.
Thanks for the suggestion.
Back before I used a Monte Carlo simulation to produce the results, I considered somehow figuring out the distribution and doing something like this (the question remains.. how, exactly?)
The current version produces an actual distribution from thousands of trial (or however many you set).
Even with a very, very large number of trials, the distribution is not quite a normal distribution (although it is close). That's one issue with using statistical confidence intervals/standard deviations.
Mostly, though, I don't see value this would add. Maybe you can clarify the use case?
The way I see it, you basically want to either optimize for longest average time or you want to optimize your dilemma count. Either way, you want to know when to check the voyage.
The current output I have is intended to cover those specific use cases. The 90% and 99% cover two what I think would be the most interesting data points as far as calculated risk is concerned in terms of how long to wait before checking the voyage.
In a sense, if I were to show the 10%/1% estimate, that would complete the other half of the "interval". But I just don't see the point. If we are to assume a normal distribution, unless you are very close to the end, you can generally trivially calculate "lucky case" scenarios by adding the difference between the median (50%) estimate and the 90% or whichever.
Also, the new chart shows the actual distribution.
Now, I do intend to enhance the chart a little further so that the tooltip/annotation on it will show the cumulative percent chance to reach that voyage length. That would cover any other % that someone might want to know besides 50, 90, and 99.
As far as dilemmas, there's really only one within range for any given voyage, realistically. I guess if you have a roster entirely made up of 5/5 gauntlet crew, then you might have a more than 1% chance of the next dilemma while also having a less than 99% chance of the previous one. But that's just very unlikely, and the rest of the output would reveal that.
The intent of the distribution would be to gauge expectations of how it would actually perform. i.e., giving an answer to the "Hey, I came up half an hour short of your expectation, what gives?" questions.
If the normal distributions aren't going to work, maybe a simpler Box-and-whisker info might be nice?
i.e.:
75% of simulations were X or longer
50% of simulations were X or longer
25% of simulations were X or longer
I don't think there's much value in the Min/Max range, but I suppose it couldn't hurt if you were going to add those already.
Required Z values for 95% CI is 1.95996 and 50% CI is 0.67449.
I think giving those intervals are a better indication of what to expect from a voyage than averages and odds of getting past a particular dilemma.
Thanks for the suggestion.
Back before I used a Monte Carlo simulation to produce the results, I considered somehow figuring out the distribution and doing something like this (the question remains.. how, exactly?)
The current version produces an actual distribution from thousands of trial (or however many you set).
Even with a very, very large number of trials, the distribution is not quite a normal distribution (although it is close). That's one issue with using statistical confidence intervals/standard deviations.
Mostly, though, I don't see value this would add. Maybe you can clarify the use case?
The way I see it, you basically want to either optimize for longest average time or you want to optimize your dilemma count. Either way, you want to know when to check the voyage.
The current output I have is intended to cover those specific use cases. The 90% and 99% cover two what I think would be the most interesting data points as far as calculated risk is concerned in terms of how long to wait before checking the voyage.
In a sense, if I were to show the 10%/1% estimate, that would complete the other half of the "interval". But I just don't see the point. If we are to assume a normal distribution, unless you are very close to the end, you can generally trivially calculate "lucky case" scenarios by adding the difference between the median (50%) estimate and the 90% or whichever.
Also, the new chart shows the actual distribution.
Now, I do intend to enhance the chart a little further so that the tooltip/annotation on it will show the cumulative percent chance to reach that voyage length. That would cover any other % that someone might want to know besides 50, 90, and 99.
As far as dilemmas, there's really only one within range for any given voyage, realistically. I guess if you have a roster entirely made up of 5/5 gauntlet crew, then you might have a more than 1% chance of the next dilemma while also having a less than 99% chance of the previous one. But that's just very unlikely, and the rest of the output would reveal that.
The intent of the distribution would be to gauge expectations of how it would actually perform. i.e., giving an answer to the "Hey, I came up half an hour short of your expectation, what gives?" questions.
If the normal distributions aren't going to work, maybe a simpler Box-and-whisker info might be nice?
i.e.:
75% of simulations were X or longer
50% of simulations were X or longer
25% of simulations were X or longer
I don't think there's much value in the Min/Max range, but I suppose it couldn't hurt if you were going to add those already.
Sorry, I still don't see why the current version doesn't already do this well enough.
A box-and-whisker plot carries less information than the current line graph because it only presents 5 figures rather than the full distribution.
Required Z values for 95% CI is 1.95996 and 50% CI is 0.67449.
I think giving those intervals are a better indication of what to expect from a voyage than averages and odds of getting past a particular dilemma.
Thanks for the suggestion.
Back before I used a Monte Carlo simulation to produce the results, I considered somehow figuring out the distribution and doing something like this (the question remains.. how, exactly?)
The current version produces an actual distribution from thousands of trial (or however many you set).
Even with a very, very large number of trials, the distribution is not quite a normal distribution (although it is close). That's one issue with using statistical confidence intervals/standard deviations.
Mostly, though, I don't see value this would add. Maybe you can clarify the use case?
The way I see it, you basically want to either optimize for longest average time or you want to optimize your dilemma count. Either way, you want to know when to check the voyage.
The current output I have is intended to cover those specific use cases. The 90% and 99% cover two what I think would be the most interesting data points as far as calculated risk is concerned in terms of how long to wait before checking the voyage.
In a sense, if I were to show the 10%/1% estimate, that would complete the other half of the "interval". But I just don't see the point. If we are to assume a normal distribution, unless you are very close to the end, you can generally trivially calculate "lucky case" scenarios by adding the difference between the median (50%) estimate and the 90% or whichever.
Also, the new chart shows the actual distribution.
Now, I do intend to enhance the chart a little further so that the tooltip/annotation on it will show the cumulative percent chance to reach that voyage length. That would cover any other % that someone might want to know besides 50, 90, and 99.
As far as dilemmas, there's really only one within range for any given voyage, realistically. I guess if you have a roster entirely made up of 5/5 gauntlet crew, then you might have a more than 1% chance of the next dilemma while also having a less than 99% chance of the previous one. But that's just very unlikely, and the rest of the output would reveal that.
The intent of the distribution would be to gauge expectations of how it would actually perform. i.e., giving an answer to the "Hey, I came up half an hour short of your expectation, what gives?" questions.
If the normal distributions aren't going to work, maybe a simpler Box-and-whisker info might be nice?
i.e.:
75% of simulations were X or longer
50% of simulations were X or longer
25% of simulations were X or longer
I don't think there's much value in the Min/Max range, but I suppose it couldn't hurt if you were going to add those already.
Sorry, I still don't see why the current version doesn't already do this well enough.
A box-and-whisker plot carries less information than the current line graph because it only presents 5 figures rather than the full distribution.
Maybe having the percentage in the bars on the distribution rather than the number of trials?
The problem with distributions like that is it's almost too much information to get an adequate feel for exactly how it's structured. In order for me to figure out where my "middle 50%" might land, I would need to check the quantities on each bar, back and forth from the middle until I added up to n/2.
Comments
Interesting question.
It depends. Certainly if you are going for 20h, traits will matter more than they would otherwise, but there's probably a limit where you don't want to slot worthless crew just for the trait.
If you slot worthless crew everywhere, you will lose like 4-6 hours compared to slotting "good" (FE/FF super rare) crew. That's a lot.
In comparison, you get 25 AM per trait match, which is equal to about 1 minute per extend. Assuming you have a 2500 AM ship, you will need to extend at most 9 times. So that's about minutes (actually it's a bit more than 10). There are 12 slots, so 12*10 = 120 minutes, or 2 hours. 2 hours is a lot less than 4-6 hours.
In practice, you don't have to choose between "very good" and "absolutely terrible", though, so it depends on how much skill exactly you'd be giving up.
So, it's probably a good idea to give up proportion of skill - like maybe 1/3, for a trait in this case, but that's about it.
Maybe I'll add a calculation to the estimator for how much dilithium it would cost to get to 20 hours.
Voyage Estimator Tool thread
Voyage Estimator Tool thread
So with that in mind, it's actually more important to calculate it so you refill closer to 18 hours.
Voyage Estimator Tool thread
Edit: Reread the first post and saw that I could have answered my questions there, so I appreciate you taking the time to hold my hand through it and add the estimator. I've shared with my fleet and advised to add a 250 dil safety cushion.
For example if you put in a minutes elapsed of 8 hours and a current antimatter of 200, it'll show you a -5% estimate of less than the current amount of time. The expected behavior should probably be calculating -5% of the estimated remaining time and adding that the the current time, rather than calculating -5% of the estimated total time.
It's a very minor non issue though, and I'm loving the ability to be able to enter in a current time.
"It's not a bug, it's a feature!"
Thanks for pointing it out, but, yeah, I actually was aware of it. I just couldn't think of an easy way to have the range relevantly and accurately adjust. Simply scaling it would be wrong because there could actually be much greater variation near than over the course of the whole voyage due to where the random pass/fail ranges happen to be.
Maybe I'll work out improvements to that some day.
Voyage Estimator Tool thread
Similarly, the refill times decrease as you enter more elapsed time and decrease your current AM. May need to have separate boxes for starting and current AM to keep those working.
That's a very good point. I'll try to get that fixed.
Voyage Estimator Tool thread
Done. Added a separate field for remaining AM.
Voyage Estimator Tool thread
The js uses iteration in a way that a spreadsheet formula cannot.
Voyage Estimator Tool thread
The main benefit is that the estimator will now show a more meaningful range of outcomes than before, based on actual RNG over 100s of simulations.
The number of simulations can be adjusted. It's set to 500 (per refill) by default to be friendly to lower end hardware.
Unfortunately due to the relatively poor performance of JavaScript, the tradeoff is that the results will fluctuate somewhat. However, I believe this should be more useful overall.
Voyage Estimator Tool thread
Voyage Estimator Tool thread
I replaced the "worst" result with information about the chance you have of seeing the last dilemma - I think this is practically what many/most people optimize for, and now we can measure it "directly".
Voyage Estimator Tool thread
Voyage Estimator Tool thread
Voyage Estimator Tool thread
Thanks!
The way the dilemma chance prediction works is it shows the chance for the farthest dilemma seen in any of the simulation runs that has at least a 1% chance. If it's showing the previous dilemma, that means the chance of seeing the next one is less than 1%.
I did it this way because of the nature of the probability distribution in many cases allowing rare, but large outliers. And since the display is rounded down to the nearest integer percentage point, you'd otherwise be seeing 0% a lot, which is not useful either.
I guess I could make it a special case to show 0% for the next one instead in this situation. Maybe that will reduce confusion, but the meaning is the same.
If you think your chance of the next dilemma should be more than 1%, please let me know your inputs and I'll look into that possibly being a bug.
Voyage Estimator Tool thread
No worries. That makes total sense now that I've read your explanation. I'm pretty sure that it's working properly then. I'm not sure you need to change it, but you could put a sentence or two explaining how it works on the page. Then nobody else would be confused in the future.
Your tool is great though. I pretty much make it to at least 7 hrs and 30 minutes on the original run of every voyage, but figuring out how far a refill is going to get me is very helpful in knowing when to recall and/or extend additional times. Your predictions are accurate enough to set a timer and recall the voyage with less than 100 am when it goes off. That is really useful information and has saved me money.
Not sure what your statistical background is, but here's some information on how to calculate them:
http://www.dummies.com/education/math/statistics/how-to-calculate-a-confidence-interval-for-a-population-mean-when-you-know-its-standard-deviation/
Required Z values for 95% CI is 1.95996 and 50% CI is 0.67449.
I think giving those intervals are a better indication of what to expect from a voyage than averages and odds of getting past a particular dilemma.
Thanks for the suggestion.
Back before I used a Monte Carlo simulation to produce the results, I considered somehow figuring out the distribution and doing something like this (the question remains.. how, exactly?)
The current version produces an actual distribution from thousands of trial (or however many you set).
Even with a very, very large number of trials, the distribution is not quite a normal distribution (although it is close). That's one issue with using statistical confidence intervals/standard deviations.
Mostly, though, I don't see value this would add. Maybe you can clarify the use case?
The way I see it, you basically want to either optimize for longest average time or you want to optimize your dilemma count. Either way, you want to know when to check the voyage.
The current output I have is intended to cover those specific use cases. The 90% and 99% cover two what I think would be the most interesting data points as far as calculated risk is concerned in terms of how long to wait before checking the voyage.
In a sense, if I were to show the 10%/1% estimate, that would complete the other half of the "interval". But I just don't see the point. If we are to assume a normal distribution, unless you are very close to the end, you can generally trivially calculate "lucky case" scenarios by adding the difference between the median (50%) estimate and the 90% or whichever.
Also, the new chart shows the actual distribution.
Now, I do intend to enhance the chart a little further so that the tooltip/annotation on it will show the cumulative percent chance to reach that voyage length. That would cover any other % that someone might want to know besides 50, 90, and 99.
As far as dilemmas, there's really only one within range for any given voyage, realistically. I guess if you have a roster entirely made up of 5/5 gauntlet crew, then you might have a more than 1% chance of the next dilemma while also having a less than 99% chance of the previous one. But that's just very unlikely, and the rest of the output would reveal that.
Voyage Estimator Tool thread
I initially wasn't sure whether I should even include that field at all.
The basic answer is don't worry about it. It doesn't make much difference.
Hazard checks are like mission node rolls. They roll your proficiency in that skill and add the base/core value.
Prof% is a percentage relative to your average roll. So if you had 800 + (100-300), your prof% would be 20%. Technically because primary and secondary skill checks are checked more often, ideally your weighted average would go there. So if you were to actually calculate it, you'd calculate it per skill and multiply each skill's value by the chance of that skill being chosen (0.35, 0.25, 0.1) and add them together.
Nobody would actually do that, though.
But what you can do is play with the value. e.g. you can try 10 or 30% and that would may give you a wider range of possible outcomes. If you want to be more risk averse without calculating/guesstimating it, you can assume that your prof% is higher than it really is.
Voyage Estimator Tool thread
The bolded part is the only thing I understood, but that's good enough for me and Bobby McGee. Thanks!
The intent of the distribution would be to gauge expectations of how it would actually perform. i.e., giving an answer to the "Hey, I came up half an hour short of your expectation, what gives?" questions.
If the normal distributions aren't going to work, maybe a simpler Box-and-whisker info might be nice?
i.e.:
75% of simulations were X or longer
50% of simulations were X or longer
25% of simulations were X or longer
I don't think there's much value in the Min/Max range, but I suppose it couldn't hurt if you were going to add those already.
Sorry, I still don't see why the current version doesn't already do this well enough.
A box-and-whisker plot carries less information than the current line graph because it only presents 5 figures rather than the full distribution.
Voyage Estimator Tool thread
Maybe having the percentage in the bars on the distribution rather than the number of trials?
The problem with distributions like that is it's almost too much information to get an adequate feel for exactly how it's structured. In order for me to figure out where my "middle 50%" might land, I would need to check the quantities on each bar, back and forth from the middle until I added up to n/2.