(01-12-2017, 08:02 AM)Green_Dragon Wrote:

(01-12-2017, 06:45 AM)Kratos Wrote: This was lingering in my mind for a while now, thought I should share it with you guys. Often times people complain about not looting enough, unrewarding loot system and game getting boring without loots, which they are right to complain in many cases. I figured the famine in loots can be removed, or at very least, reduced by a loot crate system. Basically every time you complete a run you are guaranteed to get a loot box, depending on the type of the run you have completed you get a different box, in which you can loot low and high tier crafting mats, legendaries(idk if it will break the game, it probably will, so it's better if they didn't give any orange/red items).
I don't know what can be done against wave 12 joiners in this system, maybe you get a crate if you join from wave 1? how about innocent wave 3-6-9 joiners? Discuss.

Good idea. Excluding crap mats which are about fine. Red mats however could come this way that
you describe as it's obviously not possible to make their drops fair and let all players loot equally.
Lumps now on their way to 70k, Sulphur at 100k, Damascus and Eagle Feather same. Bear Fur heavily
depending on the ongoing crafting processes between 25k and 50k while you need 40 of that to
craft Heavy Bear. So your suggestion absolutely makes sense.

Edit: Of course there should be a relation between number of players on the server and the amount
of loot in the basket to limit solo farming but not exclude it.

(05-12-2017, 01:06 AM)Galen_Thalheimer Wrote: It is possible to make drops fairer (not sure if the Warband scripting actually allows for it though).

There are some problems with random looting:
1) it can feel biased even if it's not (human nature)
2) when you go a round and a few people got several drops but others got nothing, it doesn't feel great
3) RNG on computers aren't actually that random, even on linux -- the whole /dev/random issue with loss of entropy
4) RNG on shared/cloud/virtual servers are even worse because of the shared nature and heavier loads.

#3 and #4 can make it so the random isn't actually random at all.

The way to fix it would be to make it less actually random. Keep a list of drop-receiving players in a server (you could keep a list of everyone and use flags to determine if they are drop eligible or not). On a new drop, look for the next eligible player and give it to them. When you get to the end of the list, start back at the front (or make it a ring). The individual loot item would still be random, but the distribution would be even (among alive players). You might always end up getting twisted string instead of hardened metal, but at least you get something, instead of 3 players getting multiple drops and 7 not getting any (or whatever).

(05-12-2017, 03:05 AM)TerrorBite Wrote: I want to point out that you suggest that the system should stray from true randomness, right after saying it's currently not true random anyway. 
Anyway the good thing about randomness based drops is the lack of anticipation, imo it's important to keep anticipation low.

(05-12-2017, 04:53 AM)TerrorBite Wrote: Sir, I do not speak your hyptijibberyjoo . What is the situation that conflicts with what I said?
Is it not right that you're trying to say a regular drop pattern is better than a random one, but also what is currently set is not random?

hmm I'm not getting anywhere productive, just analysing the way you said it, best not to respond and move on

(05-12-2017, 06:35 AM)Galen_Thalheimer Wrote:

(05-12-2017, 04:53 AM)TerrorBite Wrote: Sir, I do not speak your hyptijibberyjoo . What is the situation that conflicts with what I said?
Is it not right that you're trying to say a regular drop pattern is better than a random one, but also what is currently set is not random?

hmm I'm not getting anywhere productive, just analysing the way you said it, best not to respond and move on

The drop pattern itself can still be random, as in the drop rate of the materials. Who gets the drop should be round-robin (as in, one player won't get a second drop until everyone else alive has gotten one). A particular player could still get all the crappy mats while someone else happens to get the better ones, but at least everyone would get SOMETHING.

The software is probably using a "pure" random method now, but in a limited computer system (like the servers probably run in), that situation is difficult to keep true random.

(05-12-2017, 04:34 AM)Galen_Thalheimer Wrote:

(05-12-2017, 03:05 AM)TerrorBite Wrote: I want to point out that you suggest that the system should stray from true randomness, right after saying it's currently not true random anyway. 
Anyway the good thing about randomness based drops is the lack of anticipation, imo it's important to keep anticipation low.

With that statement, it's clear you don't understand the situation.

Computer random number generators are usually only pseudorandom. If you feed the same seed into them, you get the same sequence every single time. The only way to eliminate that is to use different seed values (which hopefully the devs are already doing) or to have the underlying software pull from a random pool of data. NI runs on Linux servers, I believe, so this is usually done via a pool in /dev/random. However, if the amount of random data in that pool runs out, the random data call will still give you a value, but it's now longer random. They have found in the last few years that this pool was depleting far more than thought on normal systems, and it's even worse in shared server situations (because more processes are running pulling from the pool) and then even worse in VM'ed OSes (which is how most servers run these days; because the actual things that generate the raw data aren't part of a VM so entropy of the pool is much lower already). And I'd be willing to bet that Warband makes heavy use of the random number system in general, due to the way aiming works plus all the bot AI, all of which can deplete the pool.

What is supposed to happen is that if you look at the distribution of random numbers coming out, NI would limit that pool to the number of players, so there are say 16 bins. Over time, those bins should be filled equality with number of times they were picked. However, the generator in NI could be starting with either the same seed (probably not), with a diminished pool of entropy (probably, but I don't know the server code or the OS/language versions or the server setup), or with restarting the generator each round. This means that the distribution won't necessarily trend towards even, especially in the short term.

While it can be that some players just don't get much, no player should be going rounds and rounds of playing and not get anything while others are getting a lot. I know I've played for hours at a time with full servers and not gotten any drops, while other players on the same server have gotten many. I know I'm not alone in that experience.

My solution is to keep the randomness in the type of drop given, but remove the randomness in the distribution. NI is a team game, so all alive players should be sharing in the drops gained, not relaying on the server pseudorandom number generator to give that distribution.

(05-12-2017, 04:05 PM)Malong Wrote: With that statement, it's clear you didn't put much thought in the non-ideal cases. Round robin implementations of distributed handlers usually have holes (e.g. sending/queueing jobs to worker machines). First, the results will heavily depend on the scope of the distributed handler. Even if the scope is the simplest scenario of a single game where nobody dies/leaves and rejoins/crashes/whatever, the best case is the number of items (I) dropping modulo number of players (P) is 0 (M), then everyone gets the same amount. In the case where the modulo is not zero, then P - M players get 1 fewer item than M players.

The simplest scenario in which the result isn't ideal is if a player is dead when the distributed handler points to them, then they get skipped in the revolution. Maybe you meant that you use that player's index as a pivot position where while they get no drops, everyone else positions in the queue in front of them, so the dead player is next when alive. But in this case, if a full revolution is made by the distributed handler then the skipped players will get more than one fewer item.

This also leaves multiple huge ways to exploit the system. If the distributed handler does not reset on player crash/suicide, then just join on the early 3n + 1 waves, spawn and suicide before you get any loot. At this point, everyone else is getting items,  and then spawn and play wave 10 or 13 and onward to guarantee multiple consecutive items from the distributor when the drops are better.

P.S. Then The Night King took out a spear and threw it at Viserion, killing it.

(05-12-2017, 11:54 PM)TerrorBite Wrote: Please, english only

(05-12-2017, 04:05 PM)Malong Wrote:

(05-12-2017, 04:34 AM)Galen_Thalheimer Wrote:

(05-12-2017, 03:05 AM)TerrorBite Wrote: I want to point out that you suggest that the system should stray from true randomness, right after saying it's currently not true random anyway. 
Anyway the good thing about randomness based drops is the lack of anticipation, imo it's important to keep anticipation low.

With that statement, it's clear you don't understand the situation.

Computer random number generators are usually only pseudorandom. If you feed the same seed into them, you get the same sequence every single time. The only way to eliminate that is to use different seed values (which hopefully the devs are already doing) or to have the underlying software pull from a random pool of data. NI runs on Linux servers, I believe, so this is usually done via a pool in /dev/random. However, if the amount of random data in that pool runs out, the random data call will still give you a value, but it's now longer random. They have found in the last few years that this pool was depleting far more than thought on normal systems, and it's even worse in shared server situations (because more processes are running pulling from the pool) and then even worse in VM'ed OSes (which is how most servers run these days; because the actual things that generate the raw data aren't part of a VM so entropy of the pool is much lower already). And I'd be willing to bet that Warband makes heavy use of the random number system in general, due to the way aiming works plus all the bot AI, all of which can deplete the pool.

What is supposed to happen is that if you look at the distribution of random numbers coming out, NI would limit that pool to the number of players, so there are say 16 bins. Over time, those bins should be filled equality with number of times they were picked. However, the generator in NI could be starting with either the same seed (probably not), with a diminished pool of entropy (probably, but I don't know the server code or the OS/language versions or the server setup), or with restarting the generator each round. This means that the distribution won't necessarily trend towards even, especially in the short term.

While it can be that some players just don't get much, no player should be going rounds and rounds of playing and not get anything while others are getting a lot. I know I've played for hours at a time with full servers and not gotten any drops, while other players on the same server have gotten many. I know I'm not alone in that experience.

My solution is to keep the randomness in the type of drop given, but remove the randomness in the distribution. NI is a team game, so all alive players should be sharing in the drops gained, not relaying on the server pseudorandom number generator to give that distribution.

With that statement, it's clear you didn't put much thought in the non-ideal cases. Round robin implementations of distributed handlers usually have holes (e.g. sending/queueing jobs to worker machines). First, the results will heavily depend on the scope of the distributed handler. Even if the scope is the simplest scenario of a single game where nobody dies/leaves and rejoins/crashes/whatever, the best case is the number of items (I) dropping modulo number of players (P) is 0 (M), then everyone gets the same amount. In the case where the modulo is not zero, then P - M players get 1 fewer item than M players.

The simplest scenario in which the result isn't ideal is if a player is dead when the distributed handler points to them, then they get skipped in the revolution. Maybe you meant that you use that player's index as a pivot position where while they get no drops, everyone else positions in the queue in front of them, so the dead player is next when alive. But in this case, if a full revolution is made by the distributed handler then the skipped players will get more than one fewer item.

This also leaves multiple huge ways to exploit the system. If the distributed handler does not reset on player crash/suicide, then just join on the early 3n + 1 waves, spawn and suicide before you get any loot. At this point, everyone else is getting items,  and then spawn and play wave 10 or 13 and onward to guarantee multiple consecutive items from the distributor when the drops are better.

P.S. Then The Night King took out a spear and threw it at Viserion, killing it.