Does anyone know if it's possible at this point to access the thumbnail data? I'm not looking to create a custom thumbnail, but rather to change the camera angle of the auto-generated thumb to that of another object.

And environment score? Where is that located?

Also, does a shader exist that allows for partial-transparency of a .dds texture? Tweaking the transparency level on Phong seems to do nothing, and all the glass shaders I've been able to find don't reflect the texture image.

Thanks to all who reply!

~Rachael

The environment score is located in the OBDJ. Use the grid to go to CommonBlock; Unknown 2 is the environment score.

Emmad69uk, thank you , I didn't know that!

Purplepaws, I don't think anyone has been able to change that camera angle for the thumbnail yet.
For transparency, people have been using the glass shader of the transparent screen from the EA Store, that one can take textures. (See here: http://linna.modthesims.info/showth...769#post2893769)
Usually the transparency of a DDS texture is determined by its alpha channel, but I haven't experimented with that yet to create, say, translucent objects.. If you try that, make sure the "AlphaMaskThreshold" in the mtlsrc file is set to something other than zero.

Hey, thank you both! You've been very helpful.

Now if only I could solve the last problem... *browses future.modthesims.info for the answer*

Is it invariably? Because I thought those were in motivenumber/score pairs.

And I also thought they were for catalog display purposes only and did not affect the actual score the object gives.

Actually, changing the "Unknown 2" value didn't appear to change anything, including the catalog display number. Besides that, the original number listed didn't even match the purported score of the cloned object.

The first time I changed Unknown 2 from 1 to 2 it changed the environment score, in the catalog at least, I didn't get chance to see if it actually affected the room score. However, when I tried to recreate that again it didn't work so I must have changed some other value and wrote down the wrong one. If I figure out how I did it the first time I will let you know!

Thanks! I may do some rooting around myself.

Sorry to resurrect this thread, but I was just wondering if there were any new developments on the home front regarding auto-generated thumbnail camera angles.

The reason this piqued my interest again was that I recently downloaded some objects that had been created with TSR Workshop and noticed that each one was perfectly centered within the catalog thumbnail. I tested out a new package created with the Workshop, and sure enough, that was auto-centered as well. So we know it's achievable, but how did they do it? Does the Workshop itself create the new camera angle, based on some calculation of the object's overall shape and size, or are there some coordinates along the way that get essentially "wiped clean", allowing the game to regenerate the camera angle? And in either case, where is this data stored?

I was considering asking this on the TSR forums since they ought to know the inner workings of their own tool, but I figured I'd just be shunned for not using it as an end-all for all my modding needs. :p

I just thought if we could understand how the TSR Workshop fixes the thumbnail, we could possibly apply the same method manually to objects cloned with s3oc.

I haven't created anything with a thumbnail issue, but I don't think I've created anything drastically different in size either so maybe that is why I have not had this issue. I started out creating my own thumbs, but recently I have begun to leave them out and take the auto generated one from the thumbnail package and add that resource back in later. So far all are auto centered. And I don't use TSRW.

But if I were guessing, I'd say either FTPT or VPXY or a combination of both is what generates the thumb. I think the TSRW is adjusting those values when the mesh is imported based on the obj. FTPT is the footprint size and the VPXY is the bounding box. Which in TS2 was also the grab area.

Ah, I think I've cracked it. It is the bounding box, but not the one contained within the VPXY file. If you look at a mesh within the TSR Workshop, it shows multiple bounding boxes--one each under Visual Proxy, Model, and all the mesh groups. It appears that the bounding box coordinates pertaining to the main mesh groups (everything except for the groundshadow mesh) must be updated to match the coordinates listed under "Model." This has effectively fixed the thumbnail issue for a test package I imported into TSRW.

However, when I tried to recreate this fix outside of Workshop, I ran into some problems. I found what appeared to be the Model and Group bounding box information located within the mcfg file and edited accordingly. But upon recompiling, the numbers reverted back to the originals. Is the mcfg file not what I should be editing?

*Edit* Success! It was in the binary files. While I have no intention (or knowledge) of editing hex numbers, I was able to run my package through the Workshop, edit the boundary boxes, export, decompile the MLOD and MODLs, and copy the new binaries into the old package. Works perfectly! I'll have to see if this affects the thumbnail zoom as well as the horizontal and vertical centering (as the object that I tested is very similar in height to the one that I cloned), but I presume it does. Of course, this method won't work for objects that are unclonable with Workshop, since nothing will show up under the mesh tab, but sticking to a strict list of clonable objects is a small price to pay for having perfect thumbnails.

Excuse my double post, but it's been more than two days and I doubt anyone would see this if I simply hit the "edit" button. (But feel free to merge or delete, anyhow.)

I just wanted to add that I figured out the environment score. It's located in "Unknown 15" of the OBJD, number 4. And not only does it change the value listed in the catalog, but it actually seems to affect the objects "worth" as well. I had two sims test view an object which I had increased in value from 2 to 10, and each time, they enthusiastically clapped and cheered. No word yet on the moodlets, but I suspect they are affected as well.

Yes, when sims are considering an object they are aware of its catalog values such as price, and maybe environment. But I think you could find that it doesn't help the actual scores that count towards moodlets.

Oh, okay. Well, I'll stick close to the object's "true" score, then, so as not to completely polarize the effects. It's still a major breakthrough for me, though, as I can be a little obsessive about surface details, and don't care as much about minor contributions to overall room score. (Especially since I can never seem to get rid of the "beautifully decorated" moodlet. :P)

I gave an object its own class and changed the enviroment score, and changed the values mentioned by PP. The cataloge score changed, but how can I tell if the actual score changed?

If you give an object its own class then you can also give it its own tuning xml, where you can set the actual environment score the sim receives, which will of course affect stuff like moodlets.

Yeah, thats what I did. What I'm asking is how do I know it worked as far as the score is concerned?

Well there is no reason to suppose it would not have done - I know it does affect breakage/dirtying rates as expected. I guess you set it to some hugely exaggerated environment score and see if the sims get a moodlet a lot quicker than you would expect for an unmodded object of that type. Lock them in an empty room with nothing but that object to be sure nothing else gave it to them

Thanks, I'll give it a go...



Edit: My object isn't referencing my class. I think either I didn't include the .dll in my package correctly, or it isn't referenced in the OBJK correctly. When I mouse over my object, it shows the class name.

The compiler calculates the bounding boxes from the edited mesh group(s), all of them. That is what goes into the binary files. The MODL, which is where the composite boinding box is stored normally does not have a bounding box group.

The data in the MCFG file came from the decompiled file and was there originally during my research, but it is no longer looked at by the compiler because it tracks the vertex positions as they are written to calculate the boxes.

It would appear that "it's doing it wrong", at least on your mesh. Would it be asking too much to post the MODL file that you fixed? I can compare that with a version decompiled and recompiled and use it for a test case.

<* Wes *>

Sure, here you go. I've made several clones of the notepad w/pens, and each one of them kept the bounding box of the original mesh. An object I cloned from the daffodil vase did this as well. In fact, the only time when I haven't noticed it is when the new mesh was so close in size to the original it would be very difficult to detect a change anyway.

*Edit* Oh, wait a second. You asked for the MODL? Why would that be of help if the fix was in the MLOD?

There is a bounding box for each group in the MLOD files (in the MLOD chunk), the MODL file is the only one with a MODL chunk, which has a bounding box for all of the groups.

But telling me you fixed it by remaking the main MLOD file is a twist on what I thought you were telling me.

It is very possible that I calculate the bounding box and end up exporting the wrong values, because early (unreleased) versions of the tool just copied the values from the MCFG file, and maybe that code is still being used. I will look at this.

Thanks for doing this.

EDIT: The values in the MLOD chunk never get changed, they remain binary copies of the values in the original file. I will change that.
EDIT2: I posted V1.01 of the ObjTool (in the same place as the previous version), that fixes this problem. I don't think the bounding box for the groundshadow matters, as your file had the bounding box for the first group repeated for the second. The previous version simply had no code to place those values in the compiled binary (while it was updating the rest of the information). The values in the MCFG are outputs, not inputs. After compilation, the new values are in the MCFG. I think this was originally just to help me analyze the files, but since it is there it stays, as it doesn't hurt to have extra information if there are any problems remaining.

Wow, that was fast! Sorry for the MODL/MLOD confusion; I meant to mention that I had narrowed it down to the MLOD (block00, to be precise). The reason I updated the ground shadow as well was simply to cover all bases and didn't see any reason to redo it when I already had a working package.

Thanks so much for the ObjTool fix. I'll give it a test run a.s.a.p!

Six little code lines; it could have been done with two if I had rolled it in a loop, but that probably would have been no smaller when compiled.

Things like that bug me, because I should be able to do better. It's like writing a term paper and forgetting to turn in one page.

It worked for me. I ran an object I previously made back through the new tool and it's 3d thumb and grab area is perfect now. Thanks, Wes!