Gradual Reduction in MF Effectiveness

[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.