IID ranges for props and exemplars?

[FrankU]

I have done quite some modding lately. For this I needed to make a lot of new prop exemplars and building exemplars.
While making these I needed a lot of new IID's. I let Reader and Pim-X decide the new IID's. Was that smart or should I use some range that can be obtained the same way as it works with Prop Family ranges and texture ranges?
If yes, I have to do a lot of modding....  So please?

[Diggis]

Only prop families and textures need ranges assigned.   This is because the tools we use for these create the IID's based on previous numbers, not randomly.  Prop, model and exemplar IID's are all randomly created so have a better chance of not impacting other works.

[FrankU]

So how large is the chance that two prop exemplars get the same IID? And what will happen in game when this is the case?
Also: is there a problem when two exemplars have the same Instance ID, or does a problem arise when also the Type and Group ID are identical? In other words: what ID's are neccessary to identify a file/prop/exemplar/?
Uhh, do you understand my question?

[Lowkee33]

Also: is there a problem when two exemplars have the same Instance ID, or does a problem arise when also the Type and Group ID are identical? In other words: what ID's are neccessary to identify a file/prop/exemplar/?

Lot exemplars all have the same GroupID.  Props and buildings are referenced (as the last rep in the LotConfigProperties) by their instance, so even if their group values are different there will be issues.  What issues? Not to sure, but I guess the game would have to pick one.

So how large is the chance that two prop exemplars get the same IID?

Reader is completely random, so your chance is about 1 out of 4 billion when you generate a new instance.

PIMX is not random.  The first digit of an instance PIMX makes is a random even digit.  The last 7 are actually the date down to the second (or the one your computer thinks it is).  As long as we all don't make Instances at the same time, we should be fine. (and say that every night before bed  ).

[FrankU]

So as long as the InstaceID is identical there could be a problem. Right?
Sometimes strange things are reported: a wrong prop or building shows up on someone's lot. I myself had this occasionally; once or twice.

Would it be wise to start working on some kind of IID exchange for props? Somehow it would make me feel better if I knew that my IID's need to be in a certain range, so that I am sure there will be no problem with someone else's stuff. On the other hand: how many people will work together and how many IID have been used already?
Will it still be useful when we start now?

[Lowkee33]

So as long as the InstaceID is identical there could be a problem. Right?

Right.  Lot Exemplars all use the same GroupID, so it is more important that the Instance is considered (as well as flora and textures).  Buildings and props can have any GroupID, but only the Instance is used in the Lot Exemplar.  Then come families.  If one were to only use families, then the Instances of the buildings and props wouldn't be important.  You would just need to keep track of family ranges.  It would be far more likely that someone messed up a family value to get the wrong building/prop appear on a lot than duplicate exemplar Instances (though, if you are dealing with a lot of exemplars, the temptation to simply clone them gets pretty high).

If you keep making Instances in PIMX, your chances are pretty low that there is a duplicate.  Someone has to make an exemplar at the same second as you, and even then there is a 1/8 chance that it is the same Instance.

In a few years we have a problem.  Eventually, the time will be 0x#FFFFFFF.  At this point, the first digit will switch back to being odd, and the last 7 digits will start from zero.  We will have chances that we override Maxis.  A few years after that, and we start to override custom content.

I feel like we would need a lot less people actually playing SC4 for any major changes happen to the way things are organized.  Reader 1.4 can take care of a lot of the grunt work using scripts.

[FrankU]

OK, thanks. So for the moment I will stop worrying.