• Welcome to SC4 Devotion Forum Archives.

New IDs generation

Started by cogeo, November 09, 2010, 02:53:16 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

cogeo

Hi all,

I have some questuions about IDs' generation.

All below tools
- The Lot Editor can supposedly generate universally (?) unique lot instance IDs.
- PIM-X generates such unique IDs.
- Even the reader can generate "new" IDs.

I have some questions:
- Do all these packages use the same algorithm?
- How can these be unique? The reader, for example, does NOT load all the plugins, so it doesn't really "know" which IDs are in use.

And my final question:
"Is it possible to allocate (use) a range of lot consecutive IDs, some 10-32 IDs wide, preferrably close to the upper end of the IDs space (eg values like 0xFFhhhh##)? Can all IDs in such a range be unique? Can we know if (any of) the tools may create "new" IDs in this range in the future? Maybe LE (which loads all plugins on startup) won't, but how about the others?"

Thanks

mightygoose

i always thought it only mattered locally.... and it was textures that it mattered with, buildings and lots and props are called by there instance name if i am correct.

thats the reason we have the texture index.
NAM + CAM + RAM + SAM, that's how I roll....

RippleJet

PIM-X and Maxis PIM/LE use the same algorithm, based on the date and time (down to the second) the file was created.
This covers the 7 least significant digits in the IID.
The highest digit is a random digit, which starting at 2005/08/05 21:24:16 is odd (1, 3, 5, 7, 9, B, D, F). Before that it was even (0, 2, 4, 6, 8, A, C, E).
I believe Reader's IID generator is completely random though.

Quote from: cogeo on November 09, 2010, 02:53:16 PM
And my final question:
"Is it possible to allocate (use) a range of lot consecutive IDs, some 10-32 IDs wide, preferrably close to the upper end of the IDs space (eg values like 0xFFhhhh##)? Can all IDs in such a range be unique? Can we know if (any of) the tools may create "new" IDs in this range in the future? Maybe LE (which loads all plugins on startup) won't, but how about the others?"

No, I would strongly recommend against using any fixed ranges.
Files created between 2005/01/23 17:04:00 and 2005/05/08 21:24:15 may have IID's starting with FF...
Maxis' tools will again start to create plugins beginning with FF... 2013/07/27 at 14:28:16.

The risk of clashing is a lot smaller if the IID is based on the second the file is created, than if people would randomly allocate ranges.

cogeo

Oooh, thanks!

Do you have the exact algorithm? (your calculations are down to the second)

The reason I'm asking this is because there's otherwise no way to control the order items appear in the detailed budget of the Parks and Recreation lots. Maybe if we choose some time between 4:00 and 6:00 in the morning, chances would be dim...

RippleJet

#4
I've sent you a link to the thread at BSC where wouanagaine cracked it. ;)

Basically here it goes:

The format for the IID is 0xRTTTTTTT
Starting on 1997/02/02 00:00:00 the IID is 0xR0000000
The R is random, and even after that date.
TTTTTTT is simply the number of seconds from the above date & time.

After 0x10000000 seconds we start all over again:
On 2005/08/05 21:24:16 the IID was again 0xR0000000
The R is still random, but odd after this date.

Starting 2014/02/06 18:48:32 we will start over again, with R being even again.
This time there will be a small risk of clashes with plugins made in 1997...

EDIT:
I wonder who was around making plugins in 1997, when the PIM was released in 2004? ::)

null45

Quote from: simmaster07 on October 25, 2010, 07:31:12 PM

EmptyPluginCOMDirector.cpp
GZCOM.cpp
GZCOM.h
RZCOMDirector.cpp
RZCOMDirector.h

Asking nicely does work.  ;D

from GZCOM.cpp:

///////////////////////////////////////////////////////////////////////////////
// CreateGuid
//
// A GUID is a Uint32:
//   -------------------------------------------
//   | 3 bits        29 bits                   |
//   |-----------------------------------------|
//   | Random        Seconds since Feb 2, 1997 |
//   -------------------------------------------
//
// 29 bits of information is good for 17 years of unique seconds.
// Because there are 3 bits of randomness, the result is that with every
// second that passes there are 8 new GUIDs that can exist. If you call
// this function more than once within a second, you could get a repeat
// of the returned GUID value.
//

Hope that helps. :thumbsup:


RippleJet

Quote from: null45 on November 09, 2010, 05:27:44 PM
Hope that helps. :thumbsup:

Yes, it does! :thumbsup:
The 29th bit explains why the highest digit changes from odd to even and v/v every 268,435,456 (2^28) seconds! :)

cogeo

#7
Thanks Tage and null45!

As stated above, I need this for listing some Park Lots in their original order (otherwise the order is not preserved, and they are mixed up with other park lots. Having no other way to do this, I will finally need to use this technique (hoping that no conflicts will take place).

I'm considering this range: 0xFFFB5000. If my calculations are correct, this corresponds to Mon 03-Feb-2014 05:28:32 (a quite unusual date and time for SC4 custom content development, though I'm not sure if the algorithm works with the universal or local time).

What do you think?

Lowkee33

from GZCOM.cpp:
Quotethe result is that with every second that passes there are 8 new GUIDs that can exist. If you call this function more than once within a second, you could get a repeat of the returned GUID value.

"could"?

If there are 8 instances per second, and the algorithm "rounds" to the second, then we will never create 7/8 of the algorithms.  Perhaps starting in 2014 instance making programs could add 1 to the instance the algorithm returns (or at least make itself one of the 7 that would never be created).

RippleJet

Quote from: Lowkee33 on November 10, 2010, 04:30:01 PM
(or at least make itself one of the 7 that would never be created).

The thing is that one of those 8 numbers is selected randomly.
Thus, you'd never know which seven of the eight numbers are unused from second to second.

And you'd never know if somebody else out in the world maybe would have happened to use one of them...
If two creators globally would be creating a plugin on exactly the same second, the 29 bits (second) would be the same,
but there would still be only one chance out of eight that those two plugins would get the same IID.