1. #76
    I am BlackMaze SilentEye's Avatar
    Join Date
    July 2003
    Location
    NeoCast HQ
    Posts
    1,732

    Default

    Quote Originally Posted by Alduin View Post
    except maybe me.
    We love you Alduin

  2. #77
    Dream Cast Cursed Shadow's Avatar
    Join Date
    November 2005
    Location
    London, United Kingdom
    Posts
    223

    Default

    Quote Originally Posted by Alduin View Post
    To get a few things straight here: up 'till recently the code looked fine. There is no inherent problem in the random number generation itself and I have to admit, I did not consider the possibility of there being a reseeding somewhere in the code, therefore I did not search for it. So all in all everything looked alright and with the statistics at the beginning of Titan were non conclusive.
    However, while fixing several beam weapon related issues I noticed that there is some reseeding going on which should not be the case, because it introduces correlations. Changing the reseeding to reseed differently will not solve the problem, it will only change the correlations to be differently. The reseeding has to be removed. Different measures of networking synchronization have to be taken. Which are now being implemented step by step, but that takes time, changing the random number generation needs a lot of testing and can easily break everything, but it is in progress.
    Some of the changes which will be introduced with R#184, reduce the number of reseeds and will therefore change the correlations and therefore should affect the distribution heavily.

    Nevertheless, neither the 'forum fanbois' nor anyone from the dev/volunteer team is to blame for the informations supplied throught the last months, except maybe me.
    Alduin, I don't think anyone should be playing the blame game, and I don't think you can take the wrap for this. This erroneous correlation has been around for a long, long time. Some people would argue that some rares being harder to get is better for the economy, and we're going to ruin their precious stash. (Especially if those rares are naturally popular/sought after)

    What I will say, and have said, is that you sir, are a Gentleman and a Scholar.
    Thanks for the effort you're putting in here.

    Once you know more about how widespread this issue is, some people are wondering whether the same RNG reseeding causes a correlation for Slots and Stats too (it would be nice if this could be confirmed ), then I can really start to write test cases to run through. You're gonna need all the hands you can get to test this.

  3. #78

    Default

    Quote Originally Posted by Alduin View Post
    neither the 'forum fanbois' nor anyone from the dev/volunteer team is to blame for the informations supplied throught the last months
    /me wipes brow
    Trivaldi
    Neocron Support Team
    N E O C R O N - G A M E . C O M

    »I'm in a glass case of emotion!«

    DOWNLOAD NEOCRON • PLAY NEOCRON • FACEBOOK • TWITTER • IRC • GET SUPPORT • FORUM RULES • RULES OF CONDUCT

  4. #79
    Registered User Agent L's Avatar
    Join Date
    September 2002
    Location
    Plaza 1 Medicare
    Posts
    917

    Default

    No code works on it's own and is independent (eg from not exactly top-notch implementation of C's rand()). No human is omniknowing, therefore all assertions about "no mechanisms or code or algorithms which cause the game to generate certain parts over others" must be taken with "*as far as we're aware of" disclaimer.

    First of all, unnecessary reseeding of generator is a mistake far too common to be even mad about.
    Second, uniformity of distribution of random generator is very difficult to get and when you achieve it, it's even easier to break (eg by popular modulo).
    Third, funniest part is that in a game we don't even need random - a global, wrap-around counter going from 0 to numparts with ++ every drop would do 99% as good. So the reseeding takes the exact part we needed most and leaves the one we don't, isn't that just how life works? : )

    I have a question to Alduin: I understand the need of network-synchronised PRNGs for shooting (when 2 clients have to predict a roll made by server), but with smth like loot generation, shouldn't there be one, central authority? After all, even with 1500 players hunting, it wont be a heavy load. Or leave independent PRNGs for some groups (one per zone, lets say) - because I fear that synchronizing PRNGs could lead to one roll being used twice (by two simultaneous events), then they'll synchronize (and maybe even skip over next iteration). Which is another bias.

    Oh, and another question (if that's not a secret): In the new system of stacking rares, are they determined during drop or during research?

  5. #80
    Registered User
    Join Date
    December 2004
    Location
    Stuttgart, Germany
    Posts
    578

    Default

    Quote Originally Posted by Agent L View Post
    Third, funniest part is that in a game we don't even need random - a global, wrap-around counter going from 0 to numparts with ++ every drop would do 99% as good.
    That would really be a simple solution to a complex problem. But if I am not mistaken players could then easily predict the ressing / looting of rare parts after a short while. That would make it also quite boring, I guess.

  6. #81
    Registered User Agent L's Avatar
    Join Date
    September 2002
    Location
    Plaza 1 Medicare
    Posts
    917

    Default

    Quote Originally Posted by Ivan Eres View Post
    But if I am not mistaken players could then easily predict the ressing / looting of rare parts after a short while.
    First, I proposed it as a short term, quick-and-dirty patch, not a real solution.
    Secondly, noone figured how current loot is generated during 10 years of it - so I think there are too many hidden variables (like exact server time) and hidden algorithms (like influence of mob type or lvl) to get it figured out before the real solution will make it to the retail.

  7. #82
    Roger Ramjet Fanboy Number 1 RogerRamjet's Avatar
    Join Date
    April 2004
    Location
    Middlesbrough, England
    Posts
    3,303

    Default

    Quote Originally Posted by Agent L View Post
    First, I proposed it as a short term, quick-and-dirty patch, not a real solution.
    Secondly, noone figured how current loot is generated during 10 years of it - so I think there are too many hidden variables (like exact server time) and hidden algorithms (like influence of mob type or lvl) to get it figured out before the real solution will make it to the retail.
    There has been times when rare drops were far higher than they are now (the glory days of 2 or 3 techs from every WB?), so maybe the reseeding wasn't an issue then as it easily ticked round to the rarer tech parts. With the lower drop you will need a lot more runners killing a lot more mobs to achieve that?

  8. #83
    Registered User Agent L's Avatar
    Join Date
    September 2002
    Location
    Plaza 1 Medicare
    Posts
    917

    Default

    Quote Originally Posted by RogerRamjet View Post
    There has been times when rare drops were far higher than they are now (the glory days of 2 or 3 techs from every WB?), so maybe the reseeding wasn't an issue then as it easily ticked round to the rarer tech parts. With the lower drop you will need a lot more runners killing a lot more mobs to achieve that?
    Here's the problem: it never ticks to the next part, because it never tics at all. It's just a function of what and when.
    But you do have a point, less parts (and smaller pop!) magnifies the problem.

  9. #84

    Default

    Quote Originally Posted by Agent L View Post
    I have a question to Alduin: I understand the need of network-synchronised PRNGs for shooting (when 2 clients have to predict a roll made by server), but with smth like loot generation, shouldn't there be one, central authority? After all, even with 1500 players hunting, it wont be a heavy load. Or leave independent PRNGs for some groups (one per zone, lets say) - because I fear that synchronizing PRNGs could lead to one roll being used twice (by two simultaneous events), then they'll synchronize (and maybe even skip over next iteration). Which is another bias.

    Oh, and another question (if that's not a secret): In the new system of stacking rares, are they determined during drop or during research?
    You are right, there should be one central authority. However that is where the problem starts: multithreading and multiple process instances. Making everything thread safe is possible in theory, but you still have to make sure to avoid deadlocks, so you need to think about every possible chain of calls which might happen. You cannot simply ignore rare events because they will occur especially under heavy server load and not be debugable usually. Having multiple process instances running will make the problem of random number generation even far worse: they cannot all access the same random number generator, because they do not access the same memory. So you cannot put the central authority into a simple thread-safe class.

    And concerning your other question? Would that make any difference? The problem will be the same, no matter where you determine it (assuming that you are not alone on the server). But we moved it to researching.
    Alduin
    Development
    Neocron Support Team
    N E O C R O N - G A M E . C O M

    »After the patch is before the patch!«

    DOWNLOAD NEOCRON • PLAY NEOCRON • FACEBOOK • TWITTER • IRC • GET SUPPORT • FORUM RULES • RULES OF CONDUCT

  10. #85
    Registered User Agent L's Avatar
    Join Date
    September 2002
    Location
    Plaza 1 Medicare
    Posts
    917

    Default

    Well, my rationale is that such central drop PRNG authority is not dependable from anything (except one seeding or restoring at server start), therefore locking, querying and releasing it would be a quick and non-haltable operation. So it can't be a source of deadlock. Ofc that's my oversimplistic view of things, if "server" is distributed on several machines then communication can introduce dangerous dependency and deadlock. That's why I thought about independent prngs - I mean when server processes can access such object via simple mutex (or critical section), it's all very fast and not a possible source of deadlocks. (unless the deadlock was already there in another code and just waiting for the threads to synchronize)

    The other thing I was just curious. I always suspected the stack holds properties of just one object and count of it's exact replicas (coz that's exactly what I did), so I thought it was the reason techs stacked as they did so far and that you've moved roll to res time.
    But it introduces difference IMHO: you now have to randomize each part not once, but twice: once to determine L,T or E and second when they are actually identified. I don't know how exactly, but I'm sure it's another dangerous point with potential of introducing bias : )
    Plus, when considering central authority, it means that such authority can be not accessed for any "missed" drops (that is, drops not including techs, eg. because of wrong mob type or too high player rank).

  11. #86
    fόr einen freien Geist Deus Ex Machina's Avatar
    Join Date
    February 2005
    Location
    Tech Haven
    Posts
    573

    Default

    If it is in here somewhere, maybe I overlooked it - could someone please explain to me what "reseeding" in programming terms means?
    I may not agree
    with what you have to say,
    but I'll defend to the death
    your right to say it!
    - Voltaire

  12. #87
    CmyKK F4nb01 <3 aKe`cj's Avatar
    Join Date
    January 2004
    Location
    /var/www
    Posts
    2,844

    Default

    Quote Originally Posted by Deus Ex Machina View Post
    If it is in here somewhere, maybe I overlooked it - could someone please explain to me what "reseeding" in programming terms means?
    Reseeding is the supplementing of the randomisation algorithm with a new "basis".
    If you generate a bunch of results based on a single seed, they are expected to be distributed uniformly (good).
    Reseeding on every poll is counterproductive, because the chance to have indentical seed modifiers (these are usually much less random) is fairly high and that will result in a fairly high chance to have identical random numbers being generated, skewing uniform distribution.
    PHP Code:
    "Computer voice: Fatal system error in unit 13, gamma sector, cryo recreation phase has been interrupted.";

    //answers
    set 4        "Ok, see you later";
    set 5        "You're boring me, piss off"

  13. #88
    Registered User Agent L's Avatar
    Join Date
    September 2002
    Location
    Plaza 1 Medicare
    Posts
    917

    Default

    Quote Originally Posted by Deus Ex Machina View Post
    If it is in here somewhere, maybe I overlooked it - could someone please explain to me what "reseeding" in programming terms means?
    It's about PseudoRandom Number Generators.

    PRNG is exactly what it names implies: a pseudo. It creates bunch of numbers which appear random to a human and usually are useful for statistical purposes - but are not truly random (that is independent and unpredictable).

    The generator keeps some kind of state. Each time you request new number, the PRNG advances this state somehow, and calculates the output based on the new state. As it's easy to imagine now, two independent PRNGs started from same state, will proceed in exactly same way - creating identical streams of number. So far our PRNGs are not unpredictable at all - every new PRNG would start from 0, thus yielding same sequence. That's not good enough.

    Here comes the seeding part: When you create new PRNG (eg. when program is starting) you take some value and put it into the state of your PRNG. This is called seeding. Usually PRNGs are seeded with current time - when it's down to milliseconds it's variable enough and from here the PRNG algorithm will take it. Important thing is to do it ONCE.



    Lets imagine simplest PRNG (that's not even looking random at all): Increase the state by 1, then return last 2 digits. (Lets assume there are only 100 tech parts). So this not-so random generator just creates numbers from 1 to 99, then back to 0.
    It's very easy to imagine how it should work: every time someone kills a Warbot, one part is generated. Every kill it's "next" part in the line. So if you are the only person on the server, after 100 kills you have one of every part and 101st kill yields part #1 again, and so on. When there are many ppl hunting, every kill increases the state, so you can never tell what part will come next.
    If the PRNG would be seeded once per server restart, it would start from part, so no one can predict smth like "first kill after reboot means Vein Ripper Core".

    But now imagine that the PRNG is seeded every time the roll is made. You take current time, and seed the PRNG with it, then you request next pseudorandom number. What do you get? Is it the nice sequence you wanted the PRNG to create? No. You just get out what you just put in as seed plus 1.

    To make things bigger than life, imagine the server time is rounded to full hours then fed to the PRNG as the seed, then the number requested:
    - everyone hunting in the first hour after reboot get part #1
    - everyone hunting in the second hour after reboot get part #2
    ...
    - everyone hunting in the 24th hour after reboot get part #25
    - server is rebooted and we're back to first hour.
    Noone ever gets parts #26 and higher (neither part#0).

    OFC the server time was not rounded to full hours, other factors were getting in the way (like mob rank), and the PRNG wasn't as simple as +1.


    PS: if someone's curious about how a "real" PRNG works:
    state = (state * 1103515245) + 12345;
    return (state % 2147483647);

    Where % is the modulo operation (reminder of division )

  14. #89
    aka Ash Lipvig DER_julu's Avatar
    Join Date
    June 2005
    Location
    where you won't expect it...
    Posts
    604

    Default

    thanks a bunch for pointing this out, folks, and kudos to the dev-team for communication and the awesome work so far. and while i think that fix is a great thing, i think it takes a bit of the myth and enigma away from the big enigmatic mess that is nc (and yes, i somehow liked it that way - having so many weird and wild guesses at where which part dropped and how slots came to certain weapons was fun, imho ); just my 2 cents...

  15. #90
    Registered User Agent L's Avatar
    Join Date
    September 2002
    Location
    Plaza 1 Medicare
    Posts
    917

    Default

    Legends and lore about which mobs are "better" for different things plus inventing charms to please Gods Of Drop : )

    It slipped when many ppl played, but with pop so low it could not be blamed on bad mojo anymore : /

Page 6 of 7 FirstFirst ... 234567 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •