Nightbird's Loot Distribution Theory

Status
loots and mobs/deposits are two different things. unless you make the assumption that a deposit doesnt exist until its loot is generated. which maybe you are, and there's nothing to say that you are wrong, though i have reservations about that aspect of the theory. Loot value being determined at the time of looting is quite clear, as loot lag proves.

i was really highlighting the fact that a very large assumption is made at the very beginning, leading to a logical flaw.

1. I said so in the first post.

2. Assuming loot is pre-generated is just as big an assumption :)
 
2. Assuming loot is pre-generated is just as big an assumption :)

please tell me, when you say "loot" what do you mean? I take it to mean the oils/wool/items/ore/matter, not the location of a deposit. I do not assume that these or their values are pre-generated and have not said this, indeed i agree with what you have said on that point.

1. I said so in the first post.

but then go on to wield occams razor with this assumption unproven. i say that it may be simpler to have deposits locations/type predetermined just as mobs are.
 
please tell me, when you say "loot" what do you mean? I take it to mean the oils/wool/items/ore/matter. I do not assume that these or their values are pre-generated and have not said this, indeed i agree with what you have said on that point.

When I say loot is not pre-generated, for hunting loot I mean a mob does not have a "loot" or "no loot" tag. From that, you can assume I also don't believe they have the "tt" value of loot attached to them nor items breakdown and corresponding values.

For mining loot I mean the location of deposits is not pre-generated, and without location you can also assume I mean there's no "tt" value attached to that deposit nor ore/enmat type (you can't attach them when location isn't there).
 
see, i dont understand why you should differentiate between hunting loot and mining loot in this way, creating two definitions and good deal of confusion in the process. and might i add, increasing the complexity of the system.
 
Last edited:
see, i dont understand why you should differentiate between hunting loot and mining loot in this way two, creating two definitions and good deal of confusion in the process. and might i add, increasing the complexity of the system.

i think they're the same system a few times now I thot to myself that I'd found a nice 'vein' of globals (recently on buli I globaled 6 times in 200 ped of amo)
 
see, i dont understand why you should differentiate between hunting loot and mining loot in this way two, creating two definitions and good deal of confusion in the process. and might i add, increasing the complexity of the system.

Hunting and mining are different. As for complexity, can you give a simpler definition that encompasses both without needing to add exceptions? This is as simple as it gets in my mind.
 
ok. Loot = oils/wool/items/ore/matter etc. That is as simple as it gets.

mobs and deposits are spawned in predetermined locations. now this is conjecture, but reasonable i hope. deposits are objects that have 0HP, probes/bombs are a certain type of weapon that do a specific damage only effecting matter/ore deposits objects. once one is "dead" its picked up by the finder.

At this point the system passes over to the loot server, and you have your cycles/deposit history/perception/luck factor and whatnot evaluated and the loot determined. But that is a seperate system.

The problem i have with the notion of avatar determined deposits is the evidence that locations and types of deposits are found in certain locations. LA69 has Melchi, Dunkel, Belkar, and Narc. Further, there are areas barren of any deposits. So somthing in the system is determining what matters may be found in a given area. If you take the avatar generated systems at face value, the conclusion is that you should be able to go to any random area and bomb away in time to the time cycles/spirals/moon orbit to gain deposits. Maybe you can do this, but ive not seen or heard of it.

There is one assumption made, that the system is as simple. It may be that the system is deliberately more complex.
 
Since I've been mining for close to 2 years let me give my observations to this discussion.

Mining areas are predetermined by MA, those areas can move a bit, but not by much. Some areas have been reduced, with other areas getting an increase of possible finds. Thats done to give some uncertainty to the mining system, and prevents constant mining in same area. It also keeps you having to find those areas, and to drill empty holes to find them.

Deposits are generated at time of drop, the amount of the find is categorized as far as I can tell. Seems that the they occure every 5 categorys in size. When you get a hit it is totaly controlled by the server, and does not always take in consideration your skill points, but does have a large role. My suspicion is that each avatar has a hook, that determines what it will get over time.

There is a lot of psychological control going on here. I know many claim that depositing has nothing to do with looting, but my logic tells me that it is used. I'm sure that MA understands the Pavlovian response, and there is good reason to utilize it. As far as I can tell, everytime I've made a deposit, I've been rewarded somewhere along the line, even tough my activity has pretty much remained the same. I'm fully aware that others have looted without depositing, but never the less the psychology remains the same. If you dont believe that the Pavlovian response doesnt include you, ask yourself how you respond when the trumpets and the gold swirls occure, or when you see a lot of globals, and those large Ath's when they occure.

Von
 
ok. Loot = oils/wool/items/ore/matter etc. That is as simple as it gets.

mobs and deposits are spawned in predetermined locations. now this is conjecture, but reasonable i hope. deposits are objects that have 0HP, probes/bombs are a certain type of weapon that do a specific damage only effecting matter/ore deposits objects. once one is "dead" its picked up by the finder.

Just that little part right there is EXTREMELY difficult to implement. There is an unbelievable amount of conditions to consider, such a rules on how far the distance is between deposits, how rich an area is (too rich, too poor?) and the amount of calculations and programming is abysmal to consider. It's not the idea that matters to servers, indeed the idea is can be stated in very few words, but the implementation difficulty is incomparable as opposed to my theory, which was formed with ease of implementation in mind.

The problem i have with the notion of avatar determined deposits is the evidence that locations and types of deposits are found in certain locations. LA69 has Melchi, Dunkel, Belkar, and Narc. Further, there are areas barren of any deposits. So somthing in the system is determining what matters may be found in a given area. If you take the avatar generated systems at face value, the conclusion is that you should be able to go to any random area and bomb away in time to the time cycles/spirals/moon orbit to gain deposits. Maybe you can do this, but ive not seen or heard of it.

There is one assumption made, that the system is as simple. It may be that the system is deliberately more complex.

That's no problem at all. I didn't make any mention of how loot tt value and ore/enmat type is generated in my theory after all, as I consider it unimportant. When a deposit in generated, i.e. after it goes through my theory and a location is created, it's a simple matter to check the coordinates of that location for ore/enmat types that can be found in that area (function based on search depth), and the tt value (some other function, easy to guess, impossible to test).
 
Last edited:
Really interesting theory Nightbird. :thumbup:

I think, though, you have drawn the right conclusion to the wrong question?!?

What I mean is, I believe you may have found a good theory to explain 'loot allocation' rather than 'deposit location'. I think this is also what Aridash is saying.

The idea that deposits are spawned on the fly opens up many questions.

As already stated, we know that deposit locations are stored, in the case where a deposit is found but not claimed. My question is why?

Why go to the bother of creating the DB structure, and its associated overhead, if location is not important?
Why not lose the deposit immediately if it isnt claimed?
How is it possible 2 people can detect the same deposit in the same location at the same time?

I think you recognise one of the main arguments against the 'on the fly' theory with this statement -
The Nightbird said:
__I should have mentioned this first but my theory does imply that resources are not already in the ground i.e. spawned, but are generated by the avatar. To penalize overlapping, every drop that does not find anything is blacklisted by the server and dropping too close to a blacklisted spot results in a penality (for example, window of [0,1] becomes [0.75,1]). Blacklisted spots expire after a period of time and there is a limit to the list of blacklisted spots - when full, a new one will bump the oldest one off.
But, I have to ask, why replace the overhead of storing deposit locations, with the overhead of storing 'blacklist' locations?

In fact, if you look at it in a particular way, there is actually no difference between my deposit location and your blacklist location other than a name.

Given this, the following assertion is false IMHO :-
Nightbird said:
I think that because it is extremely server intensive to keep track of 10s millions of deposits in the ground, just as difficult as giving every mob an ID tag and keeping track of a gigantic loot table with all the loot pregenerated.

This is all IMHO though just a theory.

If all loot is computer generated anyways, would you

1. pre-generate it and keep it stored in a gigantic database?

or 2. generate it when it is asked for and skip the database?

Hence Occam's Razor
In any case, it is not necessarily very server intensive to maintain a list of deposit locations. There may a lot of data items to consider, but few are being accessed at one time. Its certainly no more server intensive than the hunting scenario.

Even though I'm sceptical, I have to say its so nice to read a sensible, non number spiral mining theory, for a change. :D
 
Just that little part right there is EXTREMELY difficult to implement.

eh? but that is how mob spawns are implemented. go to the argus beach or argos north of twin and see mobs spawning from the same spot, or tight radius, over and over again. i see no reason why deposits would be any more difficult or different?

...after it goes through my theory and a location is created, it's a simple matter to check the coordinates of that location for ore/enmat types that can be found in that area (function based on search depth), and the tt value (some other function, easy to guess, impossible to test).

since you are commiting a processing load to check the coordinates for type, why not perform a lookup for any spawned deposit in the finders range? in fact you dont even have to perform any additional look up, since the deposit object exists already, you just cant see it. once you "kill" it, it shows to the finder as a dot labeled "Lyst" in its radar range (unknowns are just a gameplay detail).
 
Last edited:
As a professional programmer, I agree with Nightbird.

The loot systems implementation (theory) for mineing, hunting and crafting gets extremly similar (and memory and speed efficient) if you assume that

1. hunting loots are generated when looting.

2. mineing loots are generated when dropping the bomb. type is then (very quickly) calculated by location.

3. crafting loot are generated when clicking (duh)

It also fits with a lot of the observations I have done, and read about on the forum if you assume that:

1. the loot "wave" amplitude and frequency for all of the above depends among many other variables on location and time.


The big trick is to find out a good system for findeing the current loot wave frequency, before you ruin yourself :) (Wich I guess nightbird claim he has)
 
The idea that deposits are spawned on the fly opens up many questions.

As already stated, we know that deposit locations are stored, in the case where a deposit is found but not claimed. My question is why?

Why go to the bother of creating the DB structure, and its associated overhead, if location is not important?
Why not lose the deposit immediately if it isnt claimed?
How is it possible 2 people can detect the same deposit in the same location at the same time?

But, I have to ask, why replace the overhead of storing deposit locations, with the overhead of storing 'blacklist' locations?

Really good questions :) Luckily I think I can answer them (I think :laugh: ).

Locations are stored because a person who found one and died before claiming it can return to that position and would ask why his claim is no longer there.

The DB structure to record deposits found but unclaimed and also store blacklisted spots is a simple list of numbers. On the other hand, a list of all deposits in the ground would be long, but the main problem is how do you control the pattern in the ground? They would have to be many rules and calculations to control density, thus there is far more to it than a list of numbers.

2 people detecting the same deposit at the same time can be explained by one person generating a claim and the next detecting that claim. The detection request should be queued in the system to prevent errors.

eh? but that is how mob spawns are implemented. go to the argus beach or argos north of twin and see mobs spawning from the same spot, or tight radius, over and over again. i see no reason why deposits would be any more difficult or different?

since you are commiting a processing load to check the coordinates for type, why not perform a lookup for any spawned deposit in the finders range? in fact you dont even have to perform a look up, since the deposit object exists already, you just cant see it. once you "kill" it, it shows to the finder as a dot labeled "Lyst" in its radar range (unknowns are just a gameplay detail).

It is different and for more difficult and you can ask other programmers and they will agree with me. I'm afraid I won't take the time to make a lengthy explanation that probably wouldn't be understood in the end.

Again, the problem is not in checking a list of deposits in finder range, but the process of making that list, which is extremely difficult, programming and server work wise.

As a professional programmer, I agree with Nightbird.

The loot systems implementation (theory) for mineing, hunting and crafting gets extremly similar (and memory and speed efficient) if you assume that

1. hunting loots are generated when looting.

2. mineing loots are generated when dropping the bomb. type is then (very quickly) calculated by location.

3. crafting loot are generated when clicking (duh)

It also fits with a lot of the observations I have done, and read about on the forum if you assume that:

1. the loot "wave" amplitude and frequency for all of the above depends among many other variables on location and time.


The big trick is to find out a good system for findeing the current loot wave frequency, before you ruin yourself :) (Wich I guess nightbird claim he has)

I agree with it all :) The hard part is finding the frequency with the limited amount of data you can gather in a short period of time. This is not something you can do by recording data first and then doing math to determine the frequency, you must guess the frequency FIRST then use a METHODICAL system to test whether that frequency HOLDS. The difficulty of this process is beyond any hints I've given, and requires true understanding of statistics and probability, in addition to some good intuition :)
 
Last edited:
Also, to clarify the difference between claims and mobs... The claim need not be there until someone has dropped a bomb to generate it.. to have a big database of pregenerated claims is just stupid. Just keep the ones generated by dropped bombs for a while. preferebly in the same one where you keep the actual claim rod locations, just with a flag that its not "visible" yet...

There is nothing strange that the mob location generation is seperate from the loot generation system.. location generation is simply not needed for mineing and crafting. only for mobs.
 
As a professional programmer, I agree with Nightbird.

The loot systems implementation (theory) for mineing, hunting and crafting gets extremly similar (and memory and speed efficient) if you assume that

1. hunting loots are generated when looting.

2. mineing loots are generated when dropping the bomb. type is then (very quickly) calculated by location.

3. crafting loot are generated when clicking (duh)

It also fits with a lot of the observations I have done, and read about on the forum if you assume that:

1. the loot "wave" amplitude and frequency for all of the above depends among many other variables on location and time.


The big trick is to find out a good system for findeing the current loot wave frequency, before you ruin yourself :) (Wich I guess nightbird claim he has)

Yes, as I said (and others) Nightbird's theory does seem to have some value as a loot generation theory, but not, as stated, a deposit generation theory.

Loot and deposits are different things. :wise:
 
Also.. if mob location and deposit location used the same system, I would only mine corners of land areas :)

This don't work though...

Edit: changed "claim" to "deposit" for consistency...
 
Last edited:
Just keep the ones generated by dropped bombs for a while. preferebly in the same one where you keep the actual claim rod locations, just with a flag that its not "visible" yet...

Yes, exactly, but why only for the ones claimed, why not store all spawned deposit locations, and just activate the 'visible' flag once its claimed. You then do not need a separate process, running all the time, hogging resources, to 'generate' deposits for you.
 
Yes, exactly, but why only for the ones claimed, why not store all spawned deposit locations, and just activate the 'visible' flag once its claimed. You then do not need a separate process, running all the time, hogging resources, to 'generate' deposits for you.


Because it would take magnitudes of more space in the database...

There is a lot less positions to store if you only generate them when dropping bombs. Remember most are claimed and extracted within a minute.

There is no need for any separate process running, don't see what you mean by that... just a function evaluating some big tables with a time value.

Edit: or actually, we probably think very similar.. I (and nightbird) just claim it is spawned when the bomb is dropped..
 
Yes, exactly, but why only for the ones claimed, why not store all spawned deposit locations, and just activate the 'visible' flag once its claimed. You then do not need a separate process, running all the time, hogging resources, to 'generate' deposits for you.

Because the process to create that list of deposit locations is VERY difficult, and it would have to be constantly recreated as deposits are found and more have to be added.
 
A few comments and observations.

I have only been mining for a month or so and just enmatter at that. But I do have a few comments and observations concerning Nightbird's theory.

Before I do that I'd like to recap the main thrust of Nightbird's argument first.

A) Resouces are made available via window that is time based in nature and calculated some kind of mathematical formula.

B) To prevent a player merely staying in the same location making find after find 'penalty' system is in place to prevent.

I think these are the key elements:


So to my observations:

1) I too with my low skills and lack of experience have managed 7 finds in a row and over the course of my mining career have made a similar return to Nightbird. I do much smaller runs than he does and I'd say that for evey 200 PED's spent on probes I'd make 125%.

2) From my experience locations are hot for 'loot' and returns are good whether it be hunting, mining and sweating too. Then the area goes cold after a period and another 'hot' area must be found.

So what does this mean?

Nightbird certainly has a system that seems to work for him, but I do too and mine does not compliment Nightbird's.

My opinion is that most of the evidence offered by Nightbird and the observations offered here do not prove or disprove any models.

For example, most players would do not think it unusual to find that if they mine the same area over and over the return is low. This most would put down to the area not having had time to spawn further finds following your or other's earlier intervention.

As for the time cycle, I have the same economic returns without his model. It would be more convincing if Nightbird hit a higher propostion of the time, certainly once he has found the rate of cycle.

This is not to say that he is wrong, just that I for one do not find it convincing but am pleased that he has found a way to make a profitable return.

Finally, like other's have mentioned the rate of finds does not seem to equate to greater returns, Nightbird himself says that when he has more finds he has a lower return per find.

What I'd like to know is how you maximise the opportunity to get the really big returns, but then wouldn't we all!!!!!! :tongue2:
 
Really good questions :) Luckily I think I can answer them (I think :laugh: ).

Locations are stored because a person who found one and died before claiming it can return to that position and would ask why his claim is no longer there.
hmm..doesnt seeem a good reason to me. Claims often cannot be dug up, doesnt seem to worry MA too much. Why try to give the impression of location, if location is not important?

The DB structure to record deposits found but unclaimed and also store blacklisted spots is a simple list of numbers. On the other hand, a list of all deposits in the ground would be long, but the main problem is how do you control the pattern in the ground? They would have to be many rules and calculations to control density, thus there is far more to it than a list of numbers.
I dont really see a reason to 'control the pattern', nor do I really see any evidence that the pattern is controlled in practice.
RNG for co-ords with server limits as the boundaries, no of deposits generated depends on amount of peds spent in a particular time frame.
Seems simple to me.

2 people detecting the same deposit at the same time can be explained by one person generating a claim and the next detecting that claim. The detection request should be queued in the system to prevent errors.
I accept this one.



It is different and for more difficult and you can ask other programmers and they will agree with me. I'm afraid I won't take the time to make a lengthy explanation and probably won't be understood in the end.

Again, the problem is not in checking a list of deposits in finder range, but the process of making that list, which is extremely difficult, programming and server work wise.
Sorry cant agree with you on this one, there is no real difference between your blacklist and my deposit, all the stored values are the same apart from ore-type.
 
Also.. if mob location and deposit location used the same system, I would only mine corners of land areas :)

This don't work though...

Edit: changed "claim" to "deposit" for consistency...

Try again ;)
 
Yes, as I said (and others) Nightbird's theory does seem to have some value as a loot generation theory, but not, as stated, a deposit generation theory.

Loot and deposits are different things. :wise:

My theory is on how the system creates "loot" and "no loot", and that includes how deposits are generated. It says nothing about the tt value generated however.

For me, loots and deposits are the same :)
 
Because the process to create that list of deposit locations is VERY difficult, and it would have to be constantly recreated as deposits are found and more have to be added.
There are 2 theories on that one ... it may be that deposits are generated en-masse at pre-defined intervals, say every 6 hours.

This was the dominant theory back when I started.
 
Because it would take magnitudes of more space in the database...

There is a lot less positions to store if you only generate them when dropping bombs. Remember most are claimed and extracted within a minute.

Why does predetermined deposits require a magnitude more space? If it is using the same database as the mobs, i cant see any more size increase than 2 or 3 times, unless you propose that there are 10x more deposits found each day than there are mobs.

Yes it is less to store if generated by drop, but it doesnt necessarily involve less server side calculation or DB access. correct me if im wrong, isn't generating small temporay data stores on the fly more of an overhead than accessing an existing large database?
 
I dont really see a reason to 'control the pattern', nor do I really see any evidence that the pattern is controlled in practice.
RNG for co-ords with server limits as the boundaries, no of deposits generated depends on amount of peds spent in a particular time frame.
Seems simple to me.

We can agree to disagree then. I won't try to guess MA's reasons for controlling deposits though I can think of quite a few. This thread is about a deposit generation theory and yours is that it's random generation with the server boundaries as the limits. I'm fine with that.

Sorry cant agree with you on this one, there is no real difference between your blacklist and my deposit, all the stored values are the same apart from ore-type.

I never said storing a list of locations is difficult, only the process of making that list.
 
Why does predetermined deposits require a magnitude more space? If it is using the same database as the mobs, i cant see any more size increase than 2 or 3 times, unless you propose that there are 10x more deposits found each day than there are mobs.

Yes it is less to store if generated by drop, but it doesnt necessarily involve less server side calculation or DB access. correct me if im wrong, isn't generating small temporay data stores on the fly more of an overhead than accessing an existing large database?

Yes, but only if that large database uses simple random generation to create its list of items. The observations that can be made in hunting and mining loots discounts that as a possibility as there are clearly directed patterns at work.

Generating a large database of items with such patterns requires magnitudes of difficulty and workload, while a in the moment data generation method requires almost no resources and can created any pattern desired.
 
Last edited:
This is from another recent mining theory post...

IONO said:
Churning probability matrix

Great post Alpha Greek, I like your idea about a churning probability matrix. After thinking about it for awhile I thought of a test I havent tried yet. I went to a remote location and found a deposit. I didnt claim the deposit but just moved my avatar to be directly south of the deposit and 15 meters away. I marked the position of the deposit (based on its distance from my Avatar) and without claiming it shut off the PE for 2 hours. I then logged on and dropped another probe and found the same deposit, but it had moved almost 1 meter. I marked down the location without claiming the deposit and logged out for 2 hours. When I logged back on I was still able to find the mine but it had moved again. Its like the deposits move along the vein over time. I'm going to drop a probe every hour and plot the path of the deposit. (hopefully nobody will find it while I'm doing my expirament.)

Based on my data and this expirament I think all deposits are in the ground (not generated when you drop the probe) and the deposits move over time along the vein.

Given that Iono was able to re-find the same deposit after a period of time, but with a slight shift in coordinates - wouldn't that indicate that the deposits are stored in some kind of database, with the coordinates gradually shifting over time? Surely claims that have been previously found but not claimed are not just stored indefinitely? And if they are, and the reason is so that an avatar can find them again after perhaps dying before being able to claim, why alter the coordinates over time?
 
This is from another recent mining theory post...



Given that Iono was able to re-find the same deposit after a period of time, but with a slight shift in coordinates - wouldn't that indicate that the deposits are stored in some kind of database, with the coordinates gradually shifting over time? Surely claims that have been previously found but not claimed are not just stored indefinitely? And if they are, and the reason is so that an avatar can find them again after perhaps dying before being able to claim, why alter the coordinates over time?

lol, that's amusing. 1 meter isn't much though and that's certainly no proof that deposits are in the ground and not generated by the avatar.
 
correct me if im wrong, isn't generating small temporay data stores on the fly more of an overhead than accessing an existing large database?

I asked about this. the answer I received went like this:

if all creatures and resources were predetermined and on/in the ground, the required storage of the data-base would be immense. access to a data-base, even a well indexed one, is proportional to its size.

generating small temporary "on-the-fly" stores reduces data-base requirements by an order of magnitude, as none of this information is persistently stored.

it is highly likely that both creature and resourse generation is performed by the same method. the likely one is that upon reacing a certain distance from a spawn point the appropriate creatures or resources are generated from an algorithm. these are then cached with a "time to live" value. if the timer expires and no one is within range, the cache is deleted. a seperate algorithm would be used to re-populate should someone always be present.
 
Status
Back
Top