Gradual Reduction in MF Effectiveness

[Crystalion]

And no, there is no problem with initialization in D2, that has been looked at by many  ;)

Well, various different things can be plausibly meant by using a phrase like "trouble with initializing".

Speaking using D1 as a convenient reference for example...

OTOH we have things like the shrine bug and the uninitialized variable, unsaved variable, unloaded variable.

OTOH we have things like bnet creating (at one time at least, no idea if they still screw up) games at the same second with the same master seed resulting in the same drops for players by high level mobs, as in the Laz room, resulting in "dupes" that are legit but can be acrimoniously auto-deleted nonetheless.

The second category of "improper initialization" is a more subtle one. It is very very hard, given the likely language and tools used, even with peer (or modder/code-reader) review to be absolutely certain of your statement for the first category. IMO it would be unrealistic to venture your statement for the second category, as the people and automatons examining the code to probe for the non-existance of such anomalies would have to be "godlike" in their abilities relative to me, for example.

Given that the code runs on hardware and an OS that is itself only 99.99%+ (metaphorically speaking) reliable there is also the category of "improper initialization" there to consider, as the D2 code may not be resistant to pass-along of flaws in its environment (indeed the D2 clone farmers and bnet crash dupers suggest that it is not).

Whether there are other categories of problems for which one might reasonably use the term "initialization" in a description of their nature I don't know. The problem here is that some portion of the forum reading public--despite any disclaimers you might have made as to infallibility--will take any statement from you such as the one I quoted for this post as gospel, and in a broader context than you likely intended.

[LiquidDamage]

For three runs in a row I did not find any uniques.

Don't forget to check magics for double durability (failed sets) and rares for three times durability (failed uniques). Magic and rare bows or phase blades, obviously, will not tell you if they should have been sets or uniques.

For those of you who don't know what I am talking about, if a unique item is rolled, but there is no unique of that type, OR the monster dropping it is too low level to drop the unique, a rare with 3 times the durability is dropped instead. If a set item is rolled, and no set item exists, or it is too high level, then a magic item is dropped with twice the durability.

I think a lot of people perpetuating the MF rumors either don't know about this, or have forgotten it. So-called "bad" Andariel runs that drop all blue items SHOULD have been all set items (as there is a bug causing her to always drop at least rares-- her quest drop), but there are a lot of items with no sets or uniques, and some sets and uniques that are too high level for her to drop. It is the same if you are exploiting the bug with Mephisto's quest drops.

A lot of the crappy drops are crappy simply because there are so many items and so few sets and uniques in comparison. With my MF necro, I find loads of should-have-been items, like rare/magic barbarian helms, assassin claws, paladin shields, and all kinds of magic items that should have been set items, but don't exist.

[Ruvanal]

5.) Now your ready to MF and not a second too soon (our hour is almost up).  With ZERO MAGIC FIND, have said friend make a Normal game (he must of already killed Baal) and kill all the minons to save you some time.  Now you jump in to kill Baal and reap the rewards of uniques and sets with your ZERO MAGIC FIND.

6.) Repeat the proccess over and over.  Watch as your drops start slowly getting worse and worse.

7.) Go ahead and make a new character and repeat the proccess to prove it's not an anomoly. I'll be waiting for you.

And as I had said in an earlier post here, "If you have not documented a pattern that can be consistently repeated to occur, then you really have not made a case for your argument in the first place." How about a listing of what items are dropped, their magical quality (and taking note of if they are failed uniques and set as LiquidDamage has described since few ever take that factor into account) and also note any 'junk' items that you may get in detail also. And explain in better detail as to what you are meaning by "drops start slowly getting worse and worse" since not everyone will have the same personal definition of what this would mean in context of a progressive series of drops.

And this is not a joke as this kind of detail is what finally helped showed what was happening with some of the drops in the v1.07 to v1.09 game that became known as the "Bishibosh Bug". It was from a poster at the AB that provided this kind of detailed list concering having problems getting runes from the Countess that ended up providing the final piece of the puzzle as to why there were problems with drops from many of the Super Uniques in the game. The detailed list showed some specific things that Countess should never have dropped, but few would have realized were important to reveal what had been happening (it was the 'junk' items that were the main clue, not the magic/rare stuff).

Personally if I am going to spend my time looking into a 'problem' with the game at this point, it is going to spent on something that I already know is not been covered correctly. In the current case it is that the bulk of various speed calculators that are out have some serious fundemental flaws in how they are figure the frames per attack for many of the characters. At this point the only one that I am pretty sure of being correct is the Dragoons wereform speed calcualtor and then only for the shapeshifted speeds.

[Jarulf]

For those wondering how the game gets the initial seed (unless you use the -seed command) here it is:

SeedLo = abs( (QueryPerformanceCounter + SecondsSince1900 + 0x7c558180 + GetTickCount) * 0x2f490a95 - 0x2e330917)
SeedHi = 0x000000029a

The above is calculated with 32 bit signed calcs.

GetTickCount is the call to the windows kernel and returns the number of milliseconds since boot up of the computer if I am not mistake.

QueryPerformanceCounter is the call to the windows kernel and returns a value that is updated with the frequency given by QueryPerformanceFrequency and is systemdependant, it should be with higher precision than miliseconds I would say.

The Starting map seed (which with the -seed command will be the same as the intial game seed) comes from the initial game seed, as calculated above but instead of the QueryPerformanceCounter, the “next” SeedLo is used as the first parameter in the above formula.

When you load a single player command, the starting map seed will be set to the one saved with the character, which is the starting map seed from the game were the character was last played. So, using the -seed command and then exiting the game and then starting a new game, will give you the specific starting map seed but will have the initial game seed for other things to be random.

The next seed is calculated as follow:

Seed64 = SeedLo * 0x6ac690c5 + SeedHi

SeedLo = the lower 32 bits of Seed64
SeedHi = the upper 32 bits of Seed64

If a random value is also to be calculated, it will be calculated as follow:

Rnd[X] = SeedLo mod X


When the game initializes a new seed stream, for a new unit for example, it will update the current game seed (as shown above), and set that new seed such as:

SeedLo = SeedLo (from game after update)
SeedHi = 0x000000029a


This new stream of seeds will thus not be the same as the ongoing game ones since the SeedHi will be different.

Hope this is of any interest to someone.

[Samka]

Just a quick note : a person testing MF reduction does not need to note down failed uniques/set, since for any one creature the proportion of failed uniques/sets should be constant and therefore able to be discounted.

To clarify - a pattern of unique/set drops over time should not be statistically different to the pattern of unique/set/failedunique/failedset drops.

[BOB2]

5.) Now your ready to MF and not a second too soon (our hour is almost up).  With ZERO MAGIC FIND, have said friend make a Normal game (he must of already killed Baal) and kill all the minons to save you some time.  Now you jump in to kill Baal and reap the rewards of uniques and sets with your ZERO MAGIC FIND.

6.) Repeat the proccess over and over.  Watch as your drops start slowly getting worse and worse.

7.) Go ahead and make a new character and repeat the proccess to prove it's not an anomoly. I'll be waiting for you.

And as I had said in an earlier post here, "If you have not documented a pattern that can be consistently repeated to occur, then you really have not made a case for your argument in the first place." How about a listing of what items are dropped, their magical quality (and taking note of if they are failed uniques and set as LiquidDamage has described since few ever take that factor into account) and also note any 'junk' items that you may get in detail also. And explain in better detail as to what you are meaning by "drops start slowly getting worse and worse" since not everyone will have the same personal definition of what this would mean in context of a progressive series of drops.

Hi,

I did the same testing:
- create a game with a character that has killed Baal
- kill it with an other character that has not yet kill Ball

Miscellaneous:
- MF is 4xx
- This characters has already done numerous runs of this type
- when Baal is spawned, it is killed right away without town return (to avoid "Bishibosh bug")

Currently, it happens that "normal" TC (under TC33) are rolled some times. It is not bad, it is just luck to get a good TC. So it does not matter. However, I did notice that magical only drops seem to appear more when the lowest TCs items drops. This point is probably due to a psychological issue as mentionned earlier in this thread.
But, it appears that almost 50% of the time (on a basis of the last 30 hell baal kills) I get some magical only items.
I did believe that the "first kill drop" should have applied every time. The character has not claimed the quest. It should be rares at the minimum.

How can you explained the fact to get blue stuff instead of yellow ones?

I am a little bit disappointed and wondering what I missed :(

Have a good day,

PS: having gold or potion or scroll does not make me wondering, I understand these drops.

[LiquidDamage]

Just a quick note : a person testing MF reduction does not need to note down failed uniques/set, since for any one creature the proportion of failed uniques/sets should be constant and therefore able to be discounted.

To clarify - a pattern of unique/set drops over time should not be statistically different to the pattern of unique/set/failedunique/failedset drops.

I disagree with this, and here is why:

There are 298 weapon types and 203 armor types, plus rings, amulets, charms, and jewels make for a total of 506 item types in the game. There are approximately 350 item types (if we assume ladder play) that can be unique in the game based upon looking in the mpq files and leaving out different uniques of the same type. There are only 114 item types that can be set.

For the purpose of this argument, let us assume that "good" drops are set or unique. this means that if you run a level 95 monster with an equal chance of dropping each item (no monster like this exists, but lets say it did for simplicity's sake), 31% of all unique drops will be failed, and a whopping 87.5% of all set drops will fail.

Yes, in a really massive run count, ignoring failed items will still allow you to see a drop in "good" drops, but you will have to do a much larger number of runs when ignoring them to get the end results to be as statistically accurate as possible.

Most of those willing to test here have said that they want a testing method that takes them as little time as possible. Therefore, ignoring failed drops would not be something they would want to do.

It should be noted that if runners are going to take failed uniques and sets into account, they should NOT take failed OR successful sets and uniques that have no durability, such as bows, throwing weapons, and phase blades. You cannot count a Blood Raven's Charge as a "good" drop and a magic Matriarchal bow as a bad one when the magic bow could have been generated as either set or magic, for all you know. Doing otherwise skews your results in an unknown manner (especially if you find 10 rare Matriarchal bows off of Andariel, and count them as "bad" when they actually could all be failed Blood Raven's Charges, since she can drop the bow but not the unique).

Ok, for people who want to test this, I suggest the following:

1) do Andariel runs, since she always does her quest drop, or exploit the quest drop bug on one of the other act bosses. They will never drop anything less than rare, meaning that you know any magic item she drops is a failed set. The appropriate thing to do would be to count the number of rares vs the number of sets vs the number of uniques per run, over a long stretch of runs.

2) Do not count items without durability as "good" or "bad" no matter WHAT type they are, as you cannot tell if rares are normal rares or failed uniques. Counting the uniques, sets, and failed sets without knowing if the rares are failed or not will give you inaccurate results.

3) Use a character with teleport to get to her as quickly as possible, and kill nothing else on the way. Grab the items, dump them in town, and have a friend id them and tally the "good" and "bad" drops while you go on to the next game, to put as little time between Andy kills as possible.

4a) If the test is to find out if MF is gradually decreased when a specific monster is killed repeatedly in a small timeframe, do as many runs as you possibly can in a row. If 50 is the most reasonable you can do in one sitting, then do several (10+) sets of 50. Add up the results for each numbered run. This means if you do 10 sets of 50 runs, add up the results for run 1 over the 10 sets, run 2 over the 10 sets, etc, and check to see if the numbers decrease as the run number increases.

4b) If the test is to find out if MF is gradually decreased over a character's lifespan, then get to your goal run level as fast as possible, and then do the runs as quickly as you can for as long as you can possibly tolerate for the life of that character. Rinse and repeat for several (10+) characters, add up the items for each run number across the different characters, and check to see if the numbers decrease as in 4a.

This should give you something reasonable to go on. If say, 5 people performed the same tests and it came up with similar results, then I'd say you had something.

[LiquidDamage]

However, I did notice that magical only drops seem to appear more when the lowest TCs items drops. This point is probably due to a psychological issue as mentionned earlier in this thread.
But, it appears that almost  50% of the time (on a basis of the last 30 hell baal kills) I get  some magical only items.
I did believe that the "first kill drop" should have applied every time. The character has not claimed the quest. It should be rares at the minimum.

How can you explained the fact to get blue stuff instead of yellow ones?

They are failed sets, if that same bug works on Baal (I didn't think it did, does it?).

Check all your magic items that drop from him, and if they drop with double durability, then they are failed sets. These should then be considered "good" drops, even though they suck, in terms of testing out your MF.

If you do these runs with someone with 0 magic find, and find that every magic item that has durability, has double durability, then Baal is indeed doing his quest drop.

It is possible, btw, that the lowest TC has a higher number of items that cannot spawn as set in them. This would explain the pattern you think you are seeing. It also could be psychological or just "bad" randomness.

[Jarulf]

Crystallion asked:
>1. in a SP game the map seed is carried forward from game to game, but
>what about the "other" seed?
>
>2. for a bnet game I'd expect the "map" seed to always vary, but the
>"other" or some seed line to derive from the creating character?
>
>3. 'tickcount based seed or a "performance" counter'... could you specify
>the OS call name at least? (I know them)


To further explain what I know about seeds in the game lets summarize. I have NOT looked much at it, and I don’t have the complete picture. This is especially true for the actual dungeon creation which I have never looked at.

First, a “current” in use seed is 2 32 bit values, the low and high seed value as I call them. To save an initial seed, we only need to store a 32 bit value, the initial low seed, since when initialized, the higher seed is always 0x29a.


First of all, the game has a game data structure (typically called ptGame in the code). It holds general information about the game. On a realm server, it will hold one such structure for each game it hosts.

This structure has a bunch of entries that are related to the discussion here. It has the current “game seed” (a low and a high 32 bit value). IN addition, when the game is initially set up, it will store away some initial seeds (1 32 bit value for each). One is the “map seed”. This value presumably is used to generate the map. This is the one that will end up saved in the character data, which supports the “theory” that it is used for map generation (I have not personally looked at map generation so can’t tell it for sure, but it is the only seed of random value stored with a character that can be used to regenerate the same map for a single player for example). This is also the value that will be found in the map files that the game create while you play (one for each act I think) and hence why people initially called it a “map seed”.

IN addition, when the game is initialized and some data from various data tables are loaded and partly stored in the ptGame structure, it also saves a way (at least) two other initial seeds ( 1 32 bit value). One, I would call “object seed” since it is stored away when the game initializes various object related stuff (NOT generating any objects, just loading data and such). Objects are such things as chests, shrines, and so on. I have NO idea if this is ever used in dungeon/map creation. (I use dungeon and map meaning the same thing.) Another I would call “monsterregion seed”. It is stored away when the game initializes data for monsters that can appear on a map level. Again, I have NO idea if it is used for map creation.


When a game is started, the game do the following initialization. If we did NOT use the -seed command, the game initializes the game seed in the way I mentioned in the other post. It then saves the map seed by basically initializing again the way I mentioned above. Thus, the map seed is NOT derived from the initial game seed (other than the fact that the initial game seed is updated once and used as part of the map seed initialization) but we do get a new tick count (unless the calls comes very fast after each other). What happens between the two “tick counts” is a few assembler instructions storing away the seeds and such) but more importantly a call to “GetLocalTime” and “GetSystemTime”. We should also (I think) get a call to “GetTimeZoneInformation” and a bunch of calcs for seconds since 1900 and so on. There are a bunch of other “house keeping as well”. I think it is actually all standard C (or C++) library calls for initializing a seed, that is, the srand() call or something. I once compared it and it compiled to the same thing. No idea how long it would take but I can imagine that we might get a new value from “getTickCount” (although giving milliseconds, I think the resolution is around 10 ms only). We might even get a new second in the System Time I presume). In any case, they can never be the same since we uses the first seed to factor in as well.

If we DID use the -seed command, the game would set is as both the initial game seed as well as the map seed.

If we then load a character in single player into the empty game, we would replace the map seed with the one saved with the character (unless we use the -seed command I presume or it would be pointless).

The above is the reason why using the -seed command and exiting the game (and then returning) would differ from using the -seed command without exiting, since in the last case, the initial game seed would not be randomized.

Note that when we do NOT use the -seed command, the game seed is updated once when initializing the map seed.

I can’t recall if there is any updates to the game seed in-between this point and the saving of the two other start seeds (for objects and monsterregion). In any case, those two are stored away by updating the game seed and storing away that new low seed.

After this, there might be other things that affect the game seed before we actually start a game, I really don’t know. Once we DO start a game, any creation of a unit (and we have to create all the items on a character for example when loading it), each unit created (with the possible exception of tiles but I am not sure, have to check), will have its own seed created and it will be based on the current game seed which is updated once and the new low seed is stored away as the units initial seed. Things done with the unit from that point on usually use that units seed. The game seed is thus usually not used for any real random number generation. Since missiles also are units, casting spells or shooting bows, will update the game seed.

When it comes to generating items, the initial selection of base item and quality, would use the current seed of the unit spawning it (typically a monster or an object). Hence random actions by a monster prior to dropping an item (like random decisions on how to behave or making an attack) would affect this. Objects (and NPCs in town) should not do much random behaviour at all (perhaps if a trap goes of?) and thus its initial seed (for the unit) should be the one used to pick base item and quality.

Speculation or perhaps educated “guesses” based on what people have told me since I have not tested myself now follows.

If one start a game with the same character (thus same items with him) and use the -seed command and just outside the town, we have a chest, I have been told that very often, it will drop the same thing. This is not that strange based on the above. We know that the initial game seed is set to be the specified seed. We know the chest should get its starting seed when created, which should be right at the beginning for a chest outside town. No variable spawning of other monsters or objects due to player behaviour like going some other place first and no missiles created prior to it. If the chest do nothing random, the selection of base item and quality will be based on the initial seed for it which in turn is based on the seed specified with the -seed command (in a predictable and repeatable fashion). The items magical properties should be the same too since the game seed which it will be based on have still not been influenced by “random” events such as player behaviour going of spawning more monsters further away or tossing of missiles). Basically we could get the same item.

However, if we just start a new game in single player, (or use the -seed command to get back our old game but then exit game and restart it, so still using same map seed) the initial game seed would be “random” and hence, basically all properties of the chest and its items would be different each time since they are all based on the now “random” initial game seed. This seems to match what people post about in forums for single player games and using the -seed command.

End of the speculation section.

Now, I mentioned that all units gets an initial seed from the current game seed. However, nothing in the code would prevent the call spawning a unit from later overwriting this initial seed with another value. I have checked items and in part monsters (and missiles) and nothing such seems to appear. No idea for objects. SO I don’t know what the “object seed” and “monster region seed” mentioned above are used for. Could be more like picking what type of object we should have (like the unit spawning an item uses its own seed to pick item type but then the item itself gets its own seed for other and future things). SO while the object gets an initial seed from the current game seed when created (and used for items), the creation of the object itself, might have used either the map seed (its current value) or the object seed (its current value). Just an example. It would not be that important for the issue here though but of course some stupid bug might exist somewhere.

A thread mentioned the Bishibosh bug, where the problem was the selection of the TC. This of course affects final item drops, and could be believed to be a “run counter effect”. Such bugs can exist of course. That is not the same as a feature with a counter that dimish item quality in runs, which is what this thread primary is about :)

I already in the other post above specified the system calls you asked for.

Also, I have no idea how random quest things (such as which tomb) is handled or calculated or when it is done.

Finally:
>The problem here is that some portion of the forum reading public--
>despite any disclaimers you might have made as to infallibility--will
>take any statement from you such as the one I quoted for this post as
>gospel, and in a broader context than you likely intended.

I certainly hope people DO question things I (and others post). I try to tell when I am unsure and when I am certain, although of course, the difference might be small and it might mean that even if one is sure of something without actually being able to prove it gets problematic.

[Raziel]

I'd like the muddy the waters by adding a subjective observation..

If, at any time while i'm doing a Meph run, I die, I can guarantee that upon returning, re-equipping, and killing Meph, he will drop nothing of value. And when I say nothing of value I mean no uniques at all.

It's really disheartening. Of course, I try not to die :D but that damn iceball rips me apart :(

[gekko]

Well, I don't think any of us are claiming this is a proven fact, it is merely being put forward as a hypothesis (which is where all scientific knowledge starts).

Putting this forward as a hypothesis immediately subjects it to public scrutiny and criticism. If those who believe in the reduction of MF didn't want to hear criticism or arguments against their ideas, they shouldn've have put them forward.

Concerning that we can't "prove" this either way: the burden of proof falls upon those suggesting the reduction, not the other way. As has been said repeatedly, we can't prove the open, closed and single player games run the same code. However, given that the only code we CAN analyze shows NO reduction in MF; and, given that it makes sense to run the same code wherever possible; AND, given the fact it is highly probable the reduction in MF is simply statistics and fallacies kicking in...

It is not up to the 'no' side to prove the same code is used and that there is no such counter. It is up to the 'yes' side to provide some conclusive reasons, examples, or other backing to support their hypothesis.

It has already been pointed out how unlikely such a reduction is: after all, keeping it secret defeats the supposed purposes of a reduction; no such code can be found in the only avaible code we have to scrutinize; implementing a useful, succesful counter that could not easily be "fooled" or bypassed would be so difficult -- the list goes on. Against these logical arguments, we have only stories of a few individual experiences (and yes, even 1000 runs is only a few in the terms of this type of experiment) suggesting a reduction in the quality of drops, all of which can be explained through statistics and fallacies humans and well known for.

Which is more likely: that burried deep within the guts of a b.net server, some mysterious code exists to secretly "punish" players for mf runs...

Or such code simply does not exist?

gekko

[Zallambo]

I did some quick testing. I did 16 Andarial runs one after the other. In each, I recorded the number of uniques, sets, rares, and magics that dropped. I grouped these into 4 groups of 4. Now obviously this is not done well enough to give proof of anything. I did few runs, and only recorded the basic information. Hopefully someone will do more detailed tests, or repeat what I did (then the results could be added together to get closer to an average of what happens).

These were the results:

1-4: 3u 2s 7r 0m
5-8: 2u 3s 7r 5m
9-12: 0u 2s 6r 3m
13-16: 2u 5s 7r 3m

The drops dip in the 3rd run, but it doesn't seem like much to me. Make what you want of it.

[Occhidiangela]

:D Since you have inside information

mainly from asking the programmers (among other things) and if they DID want to have different code for realm and non realm (easy enough with compile switches and so on), why did they not remove for example ALL code and even complete functions (some exported dll functions) that are only ever used on the realms?

Then of course your assessment carries much more weight. Thanks for the amplification.

[Taem]

And as I had said in an earlier post here, "If you have not documented a pattern that can be consistently repeated to occur, then you really have not made a case for your argument in the first place."  How about a listing of what items are dropped, their magical quality (and taking note of if they are failed uniques and set as LiquidDamage has described since few ever take that factor into account) and also note any 'junk' items that you may get in detail also.  And explain in better detail as to what you are meaning by "drops start slowly getting worse and worse" since not everyone will have the same personal definition of what this would mean in context of a progressive series of drops.

And this is not a joke as this kind of detail is what finally helped showed what was happening with some of the drops in the v1.07 to v1.09 game that became known as the "Bishibosh Bug".  It was from a poster at the AB that provided this kind of detailed list concering having problems getting runes from the Countess that ended up providing the final piece of the puzzle as to why there were problems with drops from many of the Super Uniques in the game.  The detailed list showed some specific things that Countess should never have dropped, but few would have realized were important to reveal what had been happening (it was the 'junk' items that were the main clue, not the magic/rare stuff).

Personally if I am going to spend my time looking into a 'problem' with the game at this point, it is going to spent on something that I already know is not been covered correctly.  In the current case it is that the bulk of various speed calculators that are out have some serious fundemental flaws in how they are figure the frames per attack for many of the characters.  At this point the only one that I am pretty sure of being correct is the Dragoons wereform speed calcualtor and then only for the shapeshifted speeds.

No you are right, I should have recorded the drops. I was so happy to "prove", if to myself more than anyone here, that my little MF trick was real that I neglected to record any details. It also crossed my mind that perhaps I am just extreemly lucky with my last seven characters on the first few drops with zero mf against a boss I havent killed yet in a game where he's already dead. I only did ten runs last night, hardly enough to call it a "proof" of anything, however, as usualy for me, my first three drops yielded 1-2 uniques and 2-3 sets. After I stopped getting gold and green, I stopped paying attention to the details and perhaps they were "failed" uniques and sets, or perhaps its all psychological. Whatever the cause, I'll still use my method as it works well for me :D .

[Taem]

Hi,

I did the same testing:
- create a game with a character that has killed Baal
- kill it with an other character that has not yet kill Ball

Miscellaneous:
- MF is 4xx
- This characters has already done numerous runs of this type
- when Baal is spawned, it is killed right away without town return (to avoid "Bishibosh bug")

Currently, it happens that "normal" TC (under TC33) are rolled some times. It is not bad, it is just luck to get a good TC. So it does not matter. However, I did notice that magical only drops seem to appear more when the lowest TCs items drops. This point is probably due to a psychological issue as mentionned earlier in this thread.
But, it appears that almost  50% of the time (on a basis of the last 30 hell baal kills) I get  some magical only items.
I did believe that the "first kill drop" should have applied every time. The character has not claimed the quest. It should be rares at the minimum.

How can you explained the fact to get blue stuff instead of yellow ones?

I am a little bit disappointed  and wondering what I missed  :(

Have a good day,

PS: having gold or potion or scroll does not make me wondering, I understand these drops.

I really don't know. It has worked for me in the past for my last seven characters, but perhaps I am wrong, in which case I concede it may be psychological. I will, however, use this method, as it has thus far yielded fantastic drops for me with zero mf, which allows me to equip better resist items for my hardcore characters.

I do not deny, however, getting blue on more than one occassion which I attributed to a decreasing MF rate since my first few drops seem to always be great (may be failed uniques/sets?).

I would like to mention that you say the first actual quest kill of the boss yields only rares or better, yet I seem to recall seeing blue plenty of times on my quest kills (perhaps a figment of my imagination from all this MF psycho-babble? I wouldn't deny wanting it to be true so unconsciously convincing myself that is what I really saw). Are you sure this is accurate? Until I record some actual drops on paper however, I'll just shut up for now and assume its all in my head :blink: .

[HunkyDory]

Probably because a low level character checked, and therefore spawned, her inventory, before you did.  Shopkeeper ilvl is equal to the clvl of the checking character + 5.  The inventory then doesnt change until some period of time goes by without checking it, or all players that are in that act go out into hostile areas.

Yes that makes perfect sense.

Let me see a level 90+ character on his own in his private game.

And she sells tiny potions on Hell?

What could that be?


Let me think, thinking, thinking..... no idea :D


In fact I have a pretty good idea what causes it. :P



Regards, Hunky

[bigeyedbug]

Probably because a low level character checked, and therefore spawned, her inventory, before you did.  Shopkeeper ilvl is equal to the clvl of the checking character + 5.  The inventory then doesnt change until some period of time goes by without checking it, or all players that are in that act go out into hostile areas.

Yes that makes perfect sense.

Let me see a level 90+ character on his own in his private game.

And she sells tiny potions on Hell?

What could that be?


Let me think, thinking, thinking..... no idea :D


In fact I have a pretty good idea what causes it. :P



Regards, Hunky

Ummm, you'd been saving all of your minor healing potions for 80 levels just to sell them in Hell, and then--after doing so--forgot all about it? :P

Yeah, I do that all the time too.

[Crystalion]

After this, there might be other things that affect the game seed before we actually start a game, I really don’t know.

Thanks for all the info.

A brief summary of the most interesting testing result I got testing in light of your information:

Running various normal Hellforge claim tests, using -seed 0, v1.10 SP...

as expected, the maps held (although I believe I noticed, in passing, differences in what the shrine was)

but even when I pre-loaded the soulstone and hammer, cast no spells and attacked no monster, the gems and rune drop from the HF varied. (exiting game and restoring character save file before relaunch and next test)

This kind of result is not surprising, since the situation is so complex, which is why I earlier mused that audits for the seed line prior to a random being utilized would provide greater illumination... not that this is an important thing to decipher, all things considered.

Of course these results would be consistant with my prior naive notion that the map seed is held by -seed but the other(s) get overwritten, and so having an audit is tempting.

BTW, iirc on older Windows flavors the gettickcount function can be expected to jump in 50ms increments, more or less. Last I checked, on a WinME or later generation system with decent CPU I think you can expect 1ms jumps. I've never considered checking them for accuracy however. The performance counter info isn't strictly required to return anything useful at all, actually, although most recent systems probably give something halfway reasonable.

I could set up my old debugging environment and hold all the external "time" calls to a constant 0 and run the -seed test again, but I have no other reason to do all those installs atm, so I'll likely pass.

If one were mounting an attack on the "security" of the economy (which is a joke, so this is purely an intellectual speculation) it might be interesting to see if knowing the way the random seed line is used to generate gambling items could be subject to inferred computational cracking before buying an item. Avoiding this kind of exploit is one reason why hardware random number generators tend to be "free running".

Thanks again for the info.

[Jarulf]

:D  Since you have inside information



Then of course your assessment carries much more weight.  Thanks for the amplification.

Just to make it clear, this was in earlier versions. I don't know if they have changed that in the latest version. But I don't see any specific reason to hide a few things (while not most others). The only exception I can think of would be some cheat realted things.

[Jarulf]

I could set up my old debugging environment and hold all the external "time" calls to a constant 0 and run the -seed test again, but I have no other reason to do all those installs atm, so I'll likely pass.

When you use the -seed command there is no external time calls of any sort (for the seed part) since it uses the specified seed instead.

I have not had time to play or look at the game (static or debugger) lately so can't offer more info than allready provided for now.