Good day all,

I hope one of you can help me with this problem. I own the following two shoe sets:

Modern Shoes - http://www.renderosity.com/mod/bcs/modern-shoes-collection/88052/

STZ Footwear collection - http://www.renderosity.com/mod/bcs/?ViewProduct=82115

Both use an OBJ files called Shoes1, Shoes2, or Shoes3, but they are installed in completely different directories:

program filessmith microposer pro 2014downloadsruntimegeometrymodern shoes

program filessmith microposer pro 2014downloadsruntimegeometrystz footwear collection

Regardless of this, when I have both sets installed, all shoes from both sets load with the models from the STZ Footwear Collection.  Which of course really messes up the Modern shoes as those are the completely wrong OBJ files.

How do I fix this?

Well I popped open the CR2 files with Notepad to take a quick look.

Modern shoes points to :runtime:geometries:modern shoes:shoes1.obj

STZ points to :runtime:geometries:stz footwear collection:shoes.obj

So this should be working shouldn't it? Why is modern shoes loading the shoes1.obj from STZ?

This is what happens when 2 different vendors name their files the same - Poser finds the first instance of shoes.obj and loads it.

Poser is doing exactly what it should be doing.

The vendors need to re-name their objects to something less generic.

Well dang it!

Shouldn't Poser be following the path specified in the CR2 though and loading the correct OBJ from the correct folder?

Unless you are using Windows XP or a MAC, it is because you decided not to use the default content location and instead have the content installed in the runtime in the Poser program directory in Program Files, so the content isn't actually installed to that path due to Windows User Access control, so Poser has to hunt for it... 

You may be right WandW, but that doesn't really make sense to me. If that is the case, then why are we allowed to put our runtime folder anywhere or to have multiples of them? If it is a relative path being specified as ":runtime:geometries:modern shoes" then it should not matter where runtime is located, as everything before that reference is relative. But I don't know, I'm not a Poser Programmer. :)

Anyway, I managed to fix it. I renamed all of the STZ footwear collection OBJ's to "STZ ShoesX.obj", where X is a number from 1 to 5 just like it was before. Then I edited the CR2 files and changed any reference to "ShoesX.OBJ" from its original reference to "STZ ShoesX.OBJ". That seems to have worked. Both shoe sets load correctly now.

It's because the actual file path for the content that wasn't installed with Poser is somewhere in 'c:usersuser*AppDataLocalVirtualStoreProgram FilesSmith MicroPoser Pro2014runtime...' and Windows UAC is converting it to 'c:Program FilesSmith MicroPoser Pro2014runtime....'  Poser will work with directory shortcuts in same aspects but not with others; I'm surprised Poser is finding them at all....

GAH!!  Were did all of the back slashes go in the paths???  Stoooopid Fricking Forum!!!! >:(

It's ok. I could read it anyway. :)

I think the same think happened to me some years ago. My problem then was that I didn't set the Search Files to Deep in preferences.

From my experience and I have experimented a lot with this it's not a problem with Windows UAC nor with Poser external runtimes or such.

The simple truth is that it is a bug since Poser 4 there directories had been of low significance. Poser isn't using the path structure correctly. It's happening with obj-files absolutely every time and with image files used as material resource mostly every time. I never found out why it worked sometimes with images. For me from my programming experience it looks like Poser is not absolutely ignoring the path but by holding all entries in a internal list it looks like the search key in such lists is not set to the complete path AND filename structure than only to the filename. Therefor finding a file with identical name it looks to Poser like having this already without seeing that the path is different. So the deepth of search is not having impact. A deeper search will only last longer but gives no better result.

I have posted this problem while version 7 to the trouble desk and have had a longer mail discussion with the guys but we came to no satisfying solution. There was a bit trouble in discussion cause I used V4 (DAZ) for the examples and this is not a Poser original ... pou ... I was in hope that someone would find that bug while programming newer versions .... ok, hope is never dying ... :-))

The only workaround for this is indeed to rename such duplicate files and to edit the CR2/PP2/PZ2/MT5 etc. depending what is involved (obj or images).