PC Developer Discussions: Alpha 17

Developer Discussions: Alpha 17

  • Newly Updated

    Votes: 1 100.0%
  • Check out the newest reveals by Madmole

    Votes: 0 0.0%
  • Over 100 new perk books with set collecting and bonuses

    Votes: 0 0.0%

  • Total voters
    1
Status
Not open for further replies.
Now you are just being obstinate. If "25% Loot Abundance" means you have a 75% chance of each container being empty then the odds of getting 200 empty containers in a row is 1 in 9721814310366126963951628. If "25% Loot Abundance" means 25% of normal and normal is say 50% on containers then your odds of any single container being empty is 87.5%. The odds of getting 200 empty containers in a row is a lot better. It is now 1 in 396633502959. Both of these odds are so low that getting 200 empty containers in a row means something is BROKEN. Hell, lets say there is a 90% chance of a container being empty. The odds of opening 200 empty in a row is 1 in 1417418549. 99% gives you 1 in 7. So at 99% you could reasonably say 200 empties could just be bad luck.
Edit: Just a note. It doesn't matter how you get to the % chance of a container being empty. It could be several variables interacting.If you find the chance of a container being completely empty and do the math 200 is way too many containers in a row being empty to just shrug it off to luck.
There are three main variables in play. Loot abundance, random number of items looted and player level.

Loot abundance is 0-100

Items looted can vary between items but let's be generous and say 0-10

player level can vary between 0-200 (if memory serves) but let's be generous and only check 10% of them 0-20

100*10*20 = 20,000

I was being generous the first time. The problem with multiple interacting variables is that they create exponential problems.

I'm not suggesting he actually do this, it would be quicker to write a mod do it automatically. My point was that trying to calculate such a system by hand is futile.

 
There are three main variables in play. Loot abundance, random number of items looted and player level.
Loot abundance is 0-100

Items looted can vary between items but let's be generous and say 0-10

player level can vary between 0-200 (if memory serves) but let's be generous and only check 10% of them 0-20

100*10*20 = 20,000

I was being generous the first time. The problem with multiple interacting variables is that they create exponential problems.

I'm not suggesting he actually do this, it would be quicker to write a mod do it automatically. My point was that trying to calculate such a system by hand is futile.
Why would you multiply those numbers together? What do you think that got you? In other words, what do you intend to do with that 20000 number because it means nothing as far as I can see.

 
Why would you multiply those numbers together? What do you think that got you? In other words, what do you intend to do with that 20000 number because it means nothing as far as I can see.
Statistics not your strong point?

It's the same as determining the odds in any multiple variable system such as dice but with larger numbers.

a * b * c = roughly how many you have to check to get an accurate reading of the system.

You could do less but your margin of error rises until it becomes large enough to render your results meaningless. This is why the original test failed.

 
Along the same lines that others have posted regarding the loot stuff...why is it at 5/5 Lucky Looter, Lucky Goggles and anything from level 20-level 120+ are we still seeing level 1 guns, canned food and other, for what of a better term 'junk' in loot?

 
Statistics not your strong point?
It's the same as determining the odds in any multiple variable system such as dice but with larger numbers.

a * b * c = roughly how many you have to check to get an accurate reading of the system.

You could do less but your margin of error rises until it becomes large enough to render your results meaningless. This is why the original test failed.
Statistics is a strong suit of mine, and I'm sorry but your generalization above does not apply to the problem at hand. Gnomaana's math is correct - unless you assume a ridiculously high (even at "25% abundance") probability of a single container being empty, having a string of 200 in a row be empty is a very strong indicator of things not working correctly.

The numbers you used - 0-100 (percent loot abundance), 0-10 (# of items possibly in a container), and 0-200 (character levels) are not equally relevant and in any case cannot be simply multiplied to come to a "required sample set" for statistical significance. I think maybe you're confusing a couple of different things.

If L is the odds of a container having loot, then (1-L) is the odds of that container being empty. The odds of N containers being empty in a row is (1-L)^N.

If L = 10% = 0.1, then the odds of 200 containers in a row being empty is (1 - 0.1)^200 = 0.9^200 = 0.0000000007055 or 1 chance in 1,417,418,549.

This means that if you opened 200 containers in a row 1.417 billion times, you would expect to have them all be empty exactly once in those 1.417 billion trials*. It doesn't make any sense to claim that 20,000 containers must be opened.

*Independent trials being what they are, it is of course possible that all 200 containers come up empty on each and every one of the 1.417 billion trials.

 
Last edited by a moderator:
<snipped for space>
At this point I'm tempted to just post the damn chunks of code responsible.

I have little doubt your knowledge of statistics is better than mine but I thought this is a multiple consecutive variable system.

You have the odds of a container being spawned open or closed. You also (possibly) have the amount of loot spawned by such things as lucky looter. Finally you have player level.

I'm not sure whether these are applied concurrently or consecutively but given the generally single-threaded nature of code I'd suspect the latter.

I was under the impression that in such a case the number of calculations required for an accurate assessment is exponential.

 
At this point I'm tempted to just post the damn chunks of code responsible.
I have little doubt your knowledge of statistics is better than mine but I thought this is a multiple consecutive variable system.

You have the odds of a container being spawned open or closed. You also (possibly) have the amount of loot spawned by such things as lucky looter. Finally you have player level.

I'm not sure whether these are applied concurrently or consecutively but given the generally single-threaded nature of code I'd suspect the latter.

I was under the impression that in such a case the number of calculations required for an accurate assessment is exponential.
I think you're right about how the probabilities are applied, and I think that's the source of your confusion. You'd be right that A * B * C is how to get to the probability of a container being empty, but once you have that, the number of trials required to infer a bug in the system should be pretty low.

For example, using something similar to your earlier numbers:

A = "Normal" odds of container "having loot" (but see item C) = 50%

B = Loot Abundance modifier = 50%

C = Odds of a non-zero # of items in a container which "has loot" = 91% (this is your 0-10 loot count, but excluding 0)

A * B * C = 0.5 x 0.5 x 0.91 = 0.2275 = ~23% chance that any single container will have a non-zero number of items in it.

The odds of that container being empty, then, is (1 - 0.2275) = 0.7725, or ~77%.

Once you have that 77% number, then you calculate the odds of 200 containers in a row being empty as 0.77 ^ 200. No need to multiply A * B * C again here, just pick a reasonable number of trials.

0.77 ^ 200 = 1.987 e-23, a vanishingly small number. This is the percentage chance of 200 containers in a row being empty, given the above assumptions.

And but so, unless you think A * B * C - or all the combinations of parameters that go into "percent chance a container has at least one item in it" - results in a number less than 0.05, 200 containers is quite enough to test the system.

 
<snipped for space>
There ya go, I can be wrong every now and again. Cheers for the clarification.

I've been spoiled by computers. The difference between 200 tests and 20,000 tests is often a matter of time, not effort. :-)

 
I think you're right about how the probabilities are applied, and I think that's the source of your confusion. You'd be right that A * B * C is how to get to the probability of a container being empty, but once you have that, the number of trials required to infer a bug in the system should be pretty low.
For example, using something similar to your earlier numbers:

A = "Normal" odds of container "having loot" (but see item C) = 50%

B = Loot Abundance modifier = 50%

C = Odds of a non-zero # of items in a container which "has loot" = 91% (this is your 0-10 loot count, but excluding 0)

A * B * C = 0.5 x 0.5 x 0.91 = 0.2275 = ~23% chance that any single container will have a non-zero number of items in it.

The odds of that container being empty, then, is (1 - 0.2275) = 0.7725, or ~77%.

Once you have that 77% number, then you calculate the odds of 200 containers in a row being empty as 0.77 ^ 200. No need to multiply A * B * C again here, just pick a reasonable number of trials.

0.77 ^ 200 = 1.987 e-23, a vanishingly small number. This is the percentage chance of 200 containers in a row being empty, given the above assumptions.

And but so, unless you think A * B * C - or all the combinations of parameters that go into "percent chance a container has at least one item in it" - results in a number less than 0.05, 200 containers is quite enough to test the system.
If memory serves, in A16.4, setting Loot Abundance to 200% didn't seem to increase the number of containers that had loot. It just increased the amount of each item. So nests tended to have double the number of feathers in them. You would find 2 cans of food instead of mostly one can at a time. That sort of thing. If that is still the case then the 25% causing no loot to drop could be as simple as rounding down after multiplying 1 by 25%. So, at that point every container that was only going to have one of something would be empty.

Of course this is a total guess. I've never looked at their code and I didn't really test that result in A16.

 
I like the way wedges of bridges are made to jump on the bridges, but its too much of a block damage.

I`ve build/restored many bridges in Navez where I use concrete plates as a last upper layer. I put some concrete poles (depending on depth) for.. poles and I can pretty easily go around the bridges with any vehicle and no block damage (so far). Sort of drive like James May, but it really does not damage cars or make you stop and repair wedges.

Good job with the new bridges !

 
What's the rocket science behind dropping the bridge by 1 block, and then adding a plate to catch the new gap,so that the UNREALISTIC and BUGGY AS FRACK wedge isn't necessary?

 
What's the rocket science behind dropping the bridge by 1 block, and then adding a plate to catch the new gap,so that the UNREALISTIC and BUGGY AS FRACK wedge isn't necessary?
Less bumping when ground on both shores is uneven. I just avoid leveling it by putting plates all over the brigdge lenght and part of the shores, devastating my ingame time. Street science, thanks god its not rocket science because we are doomed.

 
What's the rocket science behind dropping the bridge by 1 block, and then adding a plate to catch the new gap,so that the UNREALISTIC and BUGGY AS FRACK wedge isn't necessary?
You mean like the system often used on real bridges to allow for the expansion and contraction of different materials? That's a crazy idea! It'll never work!

If only TFP had a construction engineer on the team :-)

 
If only TFP had a construction engineer on the team :-)
He died by being zombie meal.

Bridges are cool, I used to put some lights on them in Navez, powered by solar power and timer relays. They looked awesome in A16.x and sort of miss that in A17. Where is the solar power gone ? Why, ah ?

 
He died by being zombie meal.
Bridges are cool, I used to put some lights on them in Navez, powered by solar power and timer relays. They looked awesome in A16.x and sort of miss that in A17. Where is the solar power gone ? Why, ah ?
I'm more excited about bodies of water large enough to require a bridge in RWG. One thing I liked about Nave was setting up next to a lake which provided an obstacle to navigation. It meant that there was an unexplored area the other side of the lake which I didn't get to until quite late. It broke up the generally circular pattern of scavenged POI's with a naturally occurring obstacle.

It does also raise the slight possibility that rivers have been added to RWG. I'm not sure about America but we have far more bridges going over rivers than over lakes.

 
They do level designer things. ;)
Can't just drop new POI in a patch because that is only going to cause trouble with existing savegames and then players cry unfathomable tears of sadness. (which are yummy but that's beside the point)
would accept tears of gratitude?

 
Status
Not open for further replies.
Back
Top