Whats the point ......

[TheMasterGee]

Edit: Just curious, is there a log generated by the craft npc?

That'd be a decent idea for many things.

Cos although logic may dictate that the 'randomness' should be correct, and Sam is right with the possible outcomes based on a small section of tests (i.e. 1 player or something) - it would be good to make sure that over 10000s of crafts, the randomness is tending to be correct. (it'll never be 100% of 97/100)

 

[mStation]

tbh random numbers on computers have never really worked properly..

for example if you made a simple c++ program like this:

#include <stdio.h>
#include <stdlib.h>

int main() {
int i = rand();
printf("%d\n\n", i);
system("pause");
}

even if you start the .exe 200 times you will always get the same random number generated..

this issue is present in a lot of other languages infact usually advanced random functions get specific time information or ask for a special variable key to generate a spoiled random number which is really different everytime to start the application.

going back to linear or gaussian.. yes it should be linear but when you stack up all the results and check what solution you got you will find a graph which plots values similar to the gaussian curve.. just that i was trying to say :/

 

[Liandrin2]

I'm kinda mystified, not in a disrespectful way, but although I quit machine language programming 25/8 before the 486 came about, I always derived random numbers in my coding as a factor of the program execute address (non absolute), the bios time/clock and the range of number you wanted randomising.

That's not cpu based.

Maybe compilers do it differently. Not heard of gaussian or linear tbh, which probably means it's taught in college.

I looked it up, most languages use http://en.wikipedia.org/wiki/Linear_congruential_generator. I think thats what my brain was trying to dig up, your right I remember doing it in uni.

 

[TheMasterGee]

I got you. It's pretty much why I always liked the program counter and clock approach. If rand() definitely gives the same result each time, I'm thinking back in my memory that C has something in addition to it called 'randx()' or summit, that doesn't give the same result each time run (or vice versa - been a while)

 

[mStation]

I got you. It's pretty much why I always liked the program counter and clock approach. If rand() definitely gives the same result each time, I'm thinking back in my memory that C has something in addition to it called 'randx()' or summit, that doesn't give the same result each time run (or vice versa - been a while)

yep.. rand() always give the same number.. if you want it different you simply have to use srand based on something like a seed or time.. for example

#include <stdio.h>
#include <stdlib.h>
#include <time.h>

int main ()
{
srand (time(NULL));
printf ("%d\n", rand() );
}

 

[Liandrin2]

yep.. rand() always give the same number.. if you want it different you simply have to use srand based on something like a seed or time.. for example

#include <stdio.h>
#include <stdlib.h>
#include <time.h>

int main ()
{
srand (time(NULL));
printf ("%d\n", rand() );
}

You can get a lot of true random generators now as well but they're far more work on the cpu.

I've always thought most modern compilers were uniformly distributed though, I'll try and find something to read up on this gaussian idea.

 

[Dun]

97% isn't 100%, so there is a chance it might fail. There is always a chance it won't work, unless it's 100%.

 

[Foopah]

Yeah 97% is not 100% but to see something like 40 fails out of 100 would lead me to believe something is broken within the math. Math is never wrong, it is the human factor that makes mistakes.

Yes of course you could have a 97% chance of success and of course this "could" in theory fail 40-50 times out of 100 tries, but does someone want to work out the probability of that actually occurring? Cos I sure as hell don't... All am pointing out is that 97% would be closer to say 92-95 out of 100 gems rather than 60-70 out of 100... See what I'm getting at. Even tho the success rate is taken per gem and not over a larger number it should still balance out like I am saying... It's like you are telling us 97% when really what you mean is 67%.

 

[TheMasterGee]

yep.. rand() always give the same number.. if you want it different you simply have to use srand based on something like a seed or time.

I understand.

Think Tai hit it on the head with a log based on results of vendors. Over a huge spread, the actual results can be tested.

 

[mStation]

tbh i can't think of a way to test this effectively..

i believe the best solution remains to check the exact code and try to debug it to understand what it is suppose to do.

surely, besides all what has been said, a 97% chance can't in NO WAY result in 40 fails of 100.. chance of having this kind of result is low to 1.

i'm sure that Samuel will look at this when he has completed the tasks he has placed above this.

log file is a good idea but you still need to create some sort of npc which could test 100 gems for you automatically.. else it is a waste of time.

btw i don't really remember if npc's can make ores with a specific purity.. don't think so..

 

[TheMasterGee]

NPCs have not had the purity ability up to now, but these guys have the code - having said that, it may mean taking them from the main item generating routines. Might be a big task.

In terms of the 97% failing 40 times... whilst logically it has a cat in hells chance of happening, it can still happen. I wouldn't buy a lottery ticket if it happened to me, but hey Stats being as they are, failing 40 times for a small group of people, even one person, doesn't mean elsewhere in the game, the stats are giving 200+ successes to other players - who of course won't 'complain'.

The only way I can think to be sure the engine is actually working for %ages is to log them game-wide and over a period of time.

(as a side note, things like adding stats with benes, orbs, etc, previously depended also on whether the item already had a stat added to it also, and some variable regarding the player (like bodyluck). so as opposed to being a flat 97%, it'd be 97%+luck+existing item status. Can't say what it is now cos I've not filtered the code the guys are using)

 

[Turrican]

honestly i dont think there should be anyway to get 97% success rate, i think a max rate of success should be 50-60% this would of solved alot of issues when it comes to gemming being a much cheaper alternative to upgrading items.

iv never been a fan of gemming, due to what can been seen to be happening ingame atm, you can double your stats from gemming / runes alone. but as a lot of people seem to want to keep gemming, there should be a higher risk of breakage when doing it, its a sad fact that alot of people spend more time mining than boss hunting for that stat upgrade, personally id rather spend my time boss hunting for item upgrades than hitting a wall (but until its changed if you want to stay competitive you have very little options)

 

[mStation]

as a matter of fact, people spend thier time in mines and boss hunting at the same time

so many doubles ingame.. we got 120+ users online.. not sure how many of these are miners and at the same time players.. :/

 

[Jacko]

it should always average out at 97% at some point, otherwise the code is broken.
You can make 1000 gems without one failing at 97%, but for example if you'd craft 1.000.000 gems you should have around 970.000 gems crafted.
which is probable to be 980.000 or 960.000
for example if the crafting chance is 97%
the chance to get 60 gems out of 100 crafts is 0.075% which is almost impossible
the chance to get 900.000 of the 1.000.000 crafts =30%
remember it can be lower but eventually when you reach a huge hight of numbers it evens out eventually
and you can say yeah it's 97% each gem but that isn't different then getting 97 gems out of hundred
it's an chance that eventually should come out althought it can take time to reach it
remember the chance to craft 100/100 gems at 97% is around 4.75%
it's all a probability ofcourse it ain't 30% chance to get flat 900.000 out of 1.000.000 but the chance is lower then 30% that you will get<900.000
the less you get the lower the chance becomes but the hard to understand part is if you'd calculat it back up you'd see a moment that you'd peak at chance at 970.000 which should be 100% but it isn't cause there is a chance that it won't follow 97% cause it's calculated each gem which is hard to understand cause it doesn't make sense but it's the same as crafting something at 30% you can get 3 crafts ut of 100 but also 90 crafts at the same chance which chance it is isn't known but if you'd go futher forever it should at a certain moment even out around the 30% chance.
people believe that it's like some kind of rng that for example if you fail the first that the second has more chance of working the sad story is it does not change the more you fail.
it's not like if you fail at 30% that the next is 60% and the one after that becomes 90%
it's a real life chance 90% that after 3 fails your fourth will work.
but not in the game the game just repeats the chance all over it's like rolling in a game theres a 97% chance the you are gonna roll 1-97 and a 3% chance that you are gonna roll 98-100 but that does not mean that after 97 rolls of 1-97 you have to get 3 rolls of 98-100
or even inbetween it it's just a chance
feel free to correct me if i calculated something wrong and explain why

 

[Shady]

the code is deffo bugged , i seem to make as many gems @ 40% then i do @ 80%.

 

[FUTURA]

Well I've gone through my calculations and I have found the following:

- **** maths

 

[Skyline]

i did a quick test

5 Brave Gems tried with 98% chance = 1 fail 4 work
5 Bravery game with 44% chance = 4 fail 1 work
6 Storm gems with 98% chance = 6 work

As I say, only a quick test but from those results it seems fine? Will let Sam check code and test himself and see what he thinks.