Menu

LEX File Exchange EA Support Files
SC4 Wikipedia Network Addon Mod
Dependencies Chat

Author Topic: New IDs generation  (Read 3948 times)

0 Members and 1 Guest are viewing this topic.

Offline cogeo

  • NAM Team
  • Forums Parliamentarian
  • *
  • Posts: 1158
  • Reputation: 18
  • CL:
    SC4 Station Master
New IDs generation
« on: November 09, 2010, 04:53:16 PM »
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

Offline mightygoose

  • 3RR Team
  • Forums Parliamentarian
  • *
  • Posts: 1885
  • Reputation: 12
  • duck duck....
Re: New IDs generation
« Reply #1 on: November 09, 2010, 05:09:05 PM »
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....

Offline RippleJet

Re: New IDs generation
« Reply #2 on: November 09, 2010, 05:18:06 PM »
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.

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.

Offline cogeo

  • NAM Team
  • Forums Parliamentarian
  • *
  • Posts: 1158
  • Reputation: 18
  • CL:
    SC4 Station Master
Re: New IDs generation
« Reply #3 on: November 09, 2010, 05:34:08 PM »
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...

Offline RippleJet

Re: New IDs generation
« Reply #4 on: November 09, 2010, 05:44:00 PM »
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? ::)
« Last Edit: November 09, 2010, 05:51:01 PM by RippleJet »

Offline null45

  • Lex Certified
  • Forums Mayor
  • *
  • Posts: 221
  • Reputation: 18
  • CL:
    All formats lead to FSH
Re: New IDs generation
« Reply #5 on: November 09, 2010, 07:27:44 PM »

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

Asking nicely does work.  ;D

from GZCOM.cpp:
Code: [Select]
///////////////////////////////////////////////////////////////////////////////
// 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:


Offline RippleJet

Re: New IDs generation
« Reply #6 on: November 10, 2010, 03:02:16 AM »
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! :)

Offline cogeo

  • NAM Team
  • Forums Parliamentarian
  • *
  • Posts: 1158
  • Reputation: 18
  • CL:
    SC4 Station Master
Re: New IDs generation
« Reply #7 on: November 10, 2010, 04:10:54 PM »
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?
« Last Edit: November 10, 2010, 04:30:15 PM by cogeo »

Offline Lowkee33

  • BSC Team
  • Forums Parliamentarian
  • *
  • Posts: 1645
  • Reputation: 19
  • Dream Crusher
  • CL: The SC4 Tinker
Re: New IDs generation
« Reply #8 on: November 10, 2010, 06:30:01 PM »
from GZCOM.cpp:
Quote
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.

"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).

Offline RippleJet

Re: New IDs generation
« Reply #9 on: November 10, 2010, 06:53:42 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.