Hi All,

Okay this question has been asked a lot - how do I detect which EP an object actually needs to function.

Most of the time the answer is "You can't" - becuase of the way, I assume, SimPE clones things.

However, what I'm wondering is it the "You can't" is actually more of a "You can, but it'd take X Y and Z in order to do it".

Essentially what I'm thinking is something similar to the way the DDO1.2 handles orphans - by making a HUGE list of every single object and mesh in every single SP and EP and Basegame, and then comparing the custom recolour with that list.

So I guess the first question is: What actually makes an object specifically need a certain EP?

D.

Not an expert on this by any means, but I'll throw in a few things. I'm assuming that we're talking about object clones and recolours, not override hacks, as the latter is a whole different kettle of fish.

This is an or list, not an and list.

- A recolour has in its MMAT the GUID of an object which requires an EP. Maxis recolours actually aren't that hard. Whatever point the object *first* appeared in the game is almost always the required EP. Updates to objects in later EPs will almost never affect recolours. Recolours of clones, however, require knowledge of what that clone requires.

- An object clone has EP flags set for a particular EP. This is stored in the OBJD, and you can find it in SimPE under the "raw" tab.
- An object clone uses a resource version or type which did not exist in the previous EPs. The most obvious ones for me here are the TTABs (which changed in Pets to allow pet interactions with objects) and the BHAVs (format 8009 requires at least one EP)
- An object clone relies on a change in a later EP to function correctly. Eg, some reputation related behaviour was added to an object in Uni. The object resources and EP flags may not specify it, but that object will produce errors in a non-Uni game.

Regarding the "megalist" system of looking stuff up... For most cloned objects, the fallback GUID should be the GUID of the object it was originally cloned from. Some people mess with it though (even though they really shouldn't) so it's not 100% reliable. I think if someone clones a clone, the fallback GUID will probably not be from the Maxis object, but from the in between clone.

By default, when OW clones an object, it leaves the Proxy GUID alone, so it will be the same as the value in the original Proxy GUID. This is usually also the same as the original Object GUID, but I think I have seen exceptions where EA must have cloned an object from one of their others and therefore the Proxy GUID is that of another of their objects.

OBJD version 0x8c, field 0x40, EP version bits. Follows the same progression as all the other EP-installed bitfields.

OBJD Version 0x8B runs in all versions, including basegame.
OBJD Version 0x8C is Uni+, has 0x40 version bits. I believe it crashes basegame-only.
OBJD Version 0x8D is an AL+ only, will crash if installed in older games, uses same 0x40 version bits field, plus a second bitfield for AL+ (forget index, it's not important, as it only functions in 0x8D, which automatically is AL+ only).

An object with the 0x40 version bits set will not appear if installed in a game that lacks the relevant game, even if all necessary parts for the object are actually included. The field is bitwise-OR with the gameversion, so if you set multiple bits, the object appears if any single one of the ticked packs is installed. Any object intended for full basegame compatibility should use only the oldest versions of resource types (0x8B OBJD, 0x4X TTAB, 0x8007 BHAV, etc).

Mkay, excellent - thanks all. Since in the DDO I have lists of every single object GUID in all EPs/SPs, I can easily cross reference the proxy GUID to that list to get a basic idea, and then refine from there.

It doesn't seem that hard to do, in fact, based on the above - if I can get 95% accuracy (not counting all the really weird things and the few cases where people mess with things they shouldn't) then this would be ok.

If I can do a simple program that figures out the "minimum game" would you be interested in testing this?

Thanks!

YES! I've been wondering about this awhile myself. I'd be more than happy to give this a test.

I'd like to also expand this to Body Shop recolours and meshes too.

To whit:

- BodyShop recolours of Maxis meshes can be linked to the mesh itself within that particular EP/SP (which I can do already)
- BodyShop recolours of custom meshes need to be linked to the custom mesh
- If the BodyShop mesh is set ONLY to have a particular catalog type that exists in ONE EP (ie Outerwear) then this will require that EP.
- If the BodyShop mesh is set to have a catalog type of one EP (Outerwear) AND another "normal" type then it requires basegame or lowest EP selected
- Otherwise Custom meshes are 99% always Basegame compatible (see above)

Is this an accurate list?

RE: Body Shop meshes and recolours, that looks basically correct to me except for one thing:

- If the BodyShop mesh is set ONLY to have a particular catalog type that exists in ONE EP (ie Outerwear) then this will require that EP.
- If the BodyShop mesh is set to have a catalog type of one EP (Outerwear) AND another "normal" type then it requires basegame or lowest EP selected

Recolour, not meshes in those cases. The meshes are base game compatible. The recolours may not be due to being set as outerwear only.

I would say the 1% (really, it's less than 1%) of meshes that are not going to be base game compatible with that last point are not worth worrying about and would be a pain in the ass to test for. I'm not even sure HOW you'd test for the few tiny little things that might cause base game incompatibility - like 4th bone assignments, as I haven't heard of them causing trouble at all since the original few hiccups around Nightlife.

Proxy GUID is not necessarily reliable, as a cloned object may be disconnected from all of its source resources and therefore not actually share an expansion with its proxy GUID: Also, some objects are altered in subsequent expansion, and it is not merely the first appearance of the GUID that matters, but also which version of game it is cloned from: If you clone a base-game object from a newer expansion using an 0x8C or 0x8D, it is no longer compatible even if it was once a base game object. Furthermore, unique objects made by people who don't suck may eliminate the proxy GUID because the object is not a characteristic sample and intentionally alter the EP fields to match.

Just forget about the entire proxy GUID and do the OBJD versioncheck instead. This is the actual method the game's code will use to determine the object appearance. The proxy GUID is the wrong tool for this job.

Even that is not totally reliable. If a creator has played about with the object enough, they might have changed its OBJD format, its proxy GUIDs (less likely), imported BHAVs with all manner of formats (8009s won't work with all EP) and even made a call to a late Global or BCON from an early BHAV.

Really, to be able to say a download works in any EP other than by testing in those EPs cannot be reliable.

This is all true: However, if the basic OBJD criteria is not met, the object is guaranteed not to load, period, even if every single other factor is correct. The game will intentionally ignore it if this is so. Other errors represent creator error and will barf in-game with an error log, although performing a TTAB and BHAV version check for 0x8Bs is a good plan, as these errors crash with no warning.

Mkay thanks Inge and Pescado for the clarifications. I'll use the OBJD version check instead.

One question though: Does M&G have it's own EP version (since it acts like an EP)?

All stuffpacks have their own EP versions. All packs pre-AL correspond to bits in 0x40, in order of release, and require 0x8C OBJDs:
0x0001: BaseGame With Any Expansion (Basegame does not load any 0x8C, 0x8B does not use 0x40)
0x0002: Uni
0x0004: NL
0x0008: OFB
0x0010: FFS
0x0020: GLS
0x0040: ZOMGPETS!!!111oneoneone
0x0080: Seasons
0x0100: Celebration
0x0200: HM
0x0400: BV
0x0800: TSS
0x1000: Store
0x2000: FT
0x4000: K&B
0x8000: IKEA

AL and MGS open up OBJD field 0x41, format 0x8D:
0x0001: AL
0x0002: MGS

Note that 0x8D format is compatible ONLY with AL and MGS, anything using 0x8D will crash if placed in a pre-AL game.

BHAV 0x8009 appears in NL, IIRC, and is incompatible with Uni or lower. Anything using BHAV 0x8009 requires NL+, even if the 0x8C:0x40 bits say otherwise.

TTAB 0x54 and up appears in Pets. Anything utilizing this TTAB format is incompatible with pre-Pets regardless of what the OBJD indicates. Example: An OBJD listing as "0x0004: NL" but using an TTAB 0x54 or higher will require Pets or higher(nonspecific) *AND* NL explicitly.

Most stuffpacks other than MGS utilize the OFB engine and do not have Pets compatibility. By combining the OBJD check with the TTAB/BHAV version check, you should be able to form a definitive basic compatibility guideline to run without crashing (there is no easy way to guarantee non-error operation due to the possibility of BHAVs that call functions or constants nonexistent, but these are "soft" errors in everything except the extremely buggy NL engine, which has been known to crash even if the nonexisting functions are not called, but not with any consistency).

Okay who are you and what have you done with the real Pescado? :P

Seriously though, thanks for the list! Very helpful indeed.

It depends whether it's Fairlight or Rhayden operating the "Pescado" persona at the time

Does including an 'uncalled' 8009 in a mod cause base game to do anything weird?

Reason I ask is that 8009 has the memoise bit. If my code detected a game engine less than NL, I could use a more expensive 8007 to perform the same task.

I'm always useful in technical discussions, you know that. It's when you whine about your F-ly personal snivelling that I mock you.

This is unknown. I have had 8009s accidentally sneak into hacks that were used in 8007-era games, but I am uncertain what happened as a result, as the issue was caught and killed before anyone reported it. Feel free to run an experiment. NL, in particular, is unusually sensitive to the mere presence of things which are not even called. The reasons for this are unclear, as NL's sensitivity to uncalled BHAVs does not exist is Uni or OFB+.