Really interesting theory Nightbird.
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.