Gradual Reduction in MF Effectiveness
#69
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.
There are three types of people in the world. Those who can count and those who can't.
Reply


Messages In This Thread
Gradual Reduction in MF Effectiveness - by Samka - 02-18-2004, 01:05 AM
Gradual Reduction in MF Effectiveness - by Samka - 02-18-2004, 08:11 AM
Gradual Reduction in MF Effectiveness - by Vash - 02-18-2004, 08:43 AM
Gradual Reduction in MF Effectiveness - by Jarulf - 02-18-2004, 09:52 AM
Gradual Reduction in MF Effectiveness - by lfd - 02-18-2004, 01:18 PM
Gradual Reduction in MF Effectiveness - by Vash - 02-18-2004, 03:57 PM
Gradual Reduction in MF Effectiveness - by rriggs - 02-18-2004, 04:30 PM
Gradual Reduction in MF Effectiveness - by jahcs - 02-18-2004, 09:19 PM
Gradual Reduction in MF Effectiveness - by Taem - 02-18-2004, 10:57 PM
Gradual Reduction in MF Effectiveness - by Samka - 02-18-2004, 11:36 PM
Gradual Reduction in MF Effectiveness - by Taem - 02-19-2004, 04:48 AM
Gradual Reduction in MF Effectiveness - by Samka - 02-19-2004, 05:42 AM
Gradual Reduction in MF Effectiveness - by Vash - 02-19-2004, 05:45 AM
Gradual Reduction in MF Effectiveness - by Taem - 02-19-2004, 07:55 AM
Gradual Reduction in MF Effectiveness - by Vash - 02-19-2004, 01:54 PM
Gradual Reduction in MF Effectiveness - by Jarulf - 02-19-2004, 02:43 PM
Gradual Reduction in MF Effectiveness - by Raziel - 02-19-2004, 02:46 PM
Gradual Reduction in MF Effectiveness - by adeyke - 02-19-2004, 02:48 PM
Gradual Reduction in MF Effectiveness - by Jarulf - 02-19-2004, 02:51 PM
Gradual Reduction in MF Effectiveness - by Jarulf - 02-19-2004, 03:52 PM
Gradual Reduction in MF Effectiveness - by Taem - 02-19-2004, 11:00 PM
Gradual Reduction in MF Effectiveness - by Samka - 02-20-2004, 06:56 PM
Gradual Reduction in MF Effectiveness - by Raziel - 02-20-2004, 08:36 PM
Gradual Reduction in MF Effectiveness - by Jarulf - 02-21-2004, 08:23 AM
Gradual Reduction in MF Effectiveness - by Samka - 02-21-2004, 07:32 PM
Gradual Reduction in MF Effectiveness - by Samka - 02-22-2004, 06:31 AM
Gradual Reduction in MF Effectiveness - by Jarulf - 02-22-2004, 08:34 AM
Gradual Reduction in MF Effectiveness - by Jarulf - 02-22-2004, 08:48 AM
Gradual Reduction in MF Effectiveness - by Jarulf - 02-22-2004, 05:59 PM
Gradual Reduction in MF Effectiveness - by Jarulf - 02-23-2004, 07:21 AM
Gradual Reduction in MF Effectiveness - by Taem - 02-23-2004, 07:49 AM
Gradual Reduction in MF Effectiveness - by Vash - 02-23-2004, 08:15 AM
Gradual Reduction in MF Effectiveness - by Jarulf - 02-23-2004, 11:03 AM
Gradual Reduction in MF Effectiveness - by Samka - 02-23-2004, 11:20 AM
Gradual Reduction in MF Effectiveness - by BOB2 - 02-23-2004, 12:22 PM
Gradual Reduction in MF Effectiveness - by Jarulf - 02-23-2004, 01:01 PM
Gradual Reduction in MF Effectiveness - by Raziel - 02-23-2004, 01:58 PM
Gradual Reduction in MF Effectiveness - by gekko - 02-23-2004, 03:59 PM
Gradual Reduction in MF Effectiveness - by Taem - 02-24-2004, 12:52 AM
Gradual Reduction in MF Effectiveness - by Taem - 02-24-2004, 01:06 AM
Gradual Reduction in MF Effectiveness - by Jarulf - 02-24-2004, 06:29 AM
Gradual Reduction in MF Effectiveness - by Jarulf - 02-24-2004, 07:58 AM
Gradual Reduction in MF Effectiveness - by Jarulf - 02-25-2004, 06:24 AM
Gradual Reduction in MF Effectiveness - by Jarulf - 02-25-2004, 09:26 AM
Gradual Reduction in MF Effectiveness - by gekko - 02-25-2004, 03:04 PM
Gradual Reduction in MF Effectiveness - by Jeger - 02-25-2004, 03:15 PM
Gradual Reduction in MF Effectiveness - by adeyke - 02-25-2004, 03:31 PM
Gradual Reduction in MF Effectiveness - by Jeger - 02-25-2004, 11:43 PM
Gradual Reduction in MF Effectiveness - by Jeger - 02-26-2004, 12:14 AM
Gradual Reduction in MF Effectiveness - by Jeger - 02-26-2004, 01:15 AM
Gradual Reduction in MF Effectiveness - by adeyke - 02-26-2004, 02:08 AM
Gradual Reduction in MF Effectiveness - by Jeger - 02-26-2004, 02:44 AM
Gradual Reduction in MF Effectiveness - by gekko - 02-26-2004, 04:24 AM
Gradual Reduction in MF Effectiveness - by Jarulf - 02-26-2004, 08:39 AM
Gradual Reduction in MF Effectiveness - by Jarulf - 02-26-2004, 03:54 PM
Gradual Reduction in MF Effectiveness - by Jeger - 02-26-2004, 04:17 PM
Gradual Reduction in MF Effectiveness - by Jeger - 02-26-2004, 04:26 PM
Gradual Reduction in MF Effectiveness - by adeyke - 02-26-2004, 08:37 PM
Gradual Reduction in MF Effectiveness - by Jeger - 02-26-2004, 09:18 PM
Gradual Reduction in MF Effectiveness - by Jarulf - 02-26-2004, 09:54 PM
Gradual Reduction in MF Effectiveness - by Jeger - 02-26-2004, 09:57 PM
Gradual Reduction in MF Effectiveness - by Jeger - 02-26-2004, 10:14 PM
Gradual Reduction in MF Effectiveness - by gekko - 02-27-2004, 12:30 AM
Gradual Reduction in MF Effectiveness - by Jeger - 02-27-2004, 12:51 AM
Gradual Reduction in MF Effectiveness - by Jeger - 02-27-2004, 02:51 AM
Gradual Reduction in MF Effectiveness - by GreyReaper - 03-11-2004, 06:40 PM
Gradual Reduction in MF Effectiveness - by adeyke - 03-11-2004, 08:20 PM
Gradual Reduction in MF Effectiveness - by dkass - 03-16-2004, 04:31 AM
Gradual Reduction in MF Effectiveness - by adeyke - 03-16-2004, 04:56 AM
Gradual Reduction in MF Effectiveness - by dkass - 03-16-2004, 08:08 PM
Gradual Reduction in MF Effectiveness - by dkass - 03-16-2004, 08:09 PM
Gradual Reduction in MF Effectiveness - by adeyke - 04-12-2004, 01:12 PM
Gradual Reduction in MF Effectiveness - by pmpch - 04-17-2004, 12:04 PM
Gradual Reduction in MF Effectiveness - by Thrugg - 04-19-2004, 05:50 PM
Gradual Reduction in MF Effectiveness - by AtuM666 - 04-19-2004, 11:24 PM
Gradual Reduction in MF Effectiveness - by adeyke - 04-20-2004, 12:30 AM
Gradual Reduction in MF Effectiveness - by gekko - 04-20-2004, 03:20 AM
Gradual Reduction in MF Effectiveness - by IKKE - 04-25-2004, 10:18 PM
Gradual Reduction in MF Effectiveness - by IKKE - 04-28-2004, 03:55 PM
Gradual Reduction in MF Effectiveness - by adeyke - 06-05-2004, 03:15 PM
Gradual Reduction in MF Effectiveness - by adeyke - 06-05-2004, 03:45 PM

Forum Jump:


Users browsing this thread: 5 Guest(s)