Some questions about prop modding

[Edvarz 1,985]

Hello. I have some questions on modding props, so I'll put them all on the same thread.

This is the pack I'm planning to mod. And this post illustrates the props I want to mod.

Spoiler

 

1. I plan to make prop families out of an existing prop pack, I want to add them to a family without having to edit the prop pack or having to make new descriptors, I've digged around a bit and found about cohort files. Would this be the way to go?

1.1 If it isn't possible then, what would be best?

A) To edit the props on Reader and create a file that overrides the original exemplars (i.e. by putting it on a z_whatever folder).

B) To create entirely new descriptors.

2. (Related to 1) I've been using Debussyman's props for my lotting project, and I noticed that some of the props are set to be visible only on zoom levels 2, 3, 4, and 5. It is super easy to fix them, but I plan to release the lots to the STEX, so obviously I can't include a modified .dat file (even if it's for a fix). Is Debussyman still avaliable? Or could I contact someone to fix the files?

2.1 Again, if it isn't feasible or convenient, what would be best, A or B?

 

EDIT: After further delving into the LBT Mega Pack and Debussyman's Mega Pack I decided to override the original descriptors so that I could fix some of the props' properties. But I would still like to know what can I do with cohort files.

3. Some of the models seem to have been rendered a bit off-centre (this, I've found, is a common problem with LBT models) Since these are car cluster families, any prop that doesn't line up will stand out of the designated parking slots and invade other spaces when it shows. I understand the Model Tweaker can fix this, but, will the quality of the model be affected too much? These weren't rendered in HD, so...

EDIT: Extra question, I would like to export the fixed models to an override file, but since the original is a .dat file, the Reader doesn't show .SC4Model files only a huge bunch of S3D and FSH files. How do I group all of a model's files together so that I can paste them in a new DAT?

If any questions are superfluous I'll gladly edit them out. Thanks a lot!

  Edited April 30, 2016 by Edvarz  
Obsolete questions, sorry.

[rsc204 21,859]

Cohorts would be ideal for such situations, if it weren't for two issues:

• First, for a cohort to work, each prop must reference the cohort, so one way or another, you'd still need to modify the original prop exemplars.
• Secondly, cohorts just don't seem to work with prop exemplars, having wasted many hours trying, I got nowhere. Information on cohorts in general is really sparse too.

It strikes me what you want to do, is take a copy of the prop exemplars for those props you want to modify. So long as you only include exemplars in your upload, you are pretty much free to do what you like here. If you keep the same TGI (ID) for these new exemplars, provided your file is loaded after the originals, it will override them. Thus, your changes would be applied wherever these props are already in use.

Sometimes, overrides are not really ideal, you have to think about any unintended consequences for existing content using them. In such cases, simply re-ID the prop exemplars to make new, unique instances of each props. This is real easy, highlight all your props in reader in one go, right click and select "Generate new Group and Instance". You might also want to rename the props, so that your modified ones are distinguished from the originals in the lot editor.

You are also free to modify S3D files and distribute them, so you can offset props or return them to centre. Really, this is a bit of an error many batters tend to make, since all items should ideally be centred before rendering. Such modifications really need to be unique props, but there is a way to do this, whilst referencing the original FSH files. Pretty much that's the part you can not re-distribute. Here's the best way to accomplish this (warning, it's a bit long):

 

When you use model tweaker, you affect the model itself. Since new exemplars, even with new IDs, still reference the same model (via RTK property), changes will affect all instances of the model.

You can't release modified FSH files without the author's consent, but you can release modified S3D files. There is a neat way to link a modified S3D file to the original FSH files, here's how:

1. Open the file containing the model you want to change in the reader.
2. Find the particular model you want to use, it will have 20 S3D files and 20 or more FSH files, the Group ID is what ties them together, you can ignore the Type/Instance #'s.
   For prop mega packs, this is no fun. The easy way, is to click Navigator at the top. Then props should be under "Object". Once you've found the object you want, right click it and select "Synchronise". The main reader view will goto the prop exemplar for this model. If the file has the prop exemplars separate from the models, you may need to find it manually using the GID (Group ID) specified in the RTK property of the exemplar though.
3. For each group of 20 S3D models you want, right click and select "Add to patch".
   You can do this multiple times whilst finding each model in a given DAT.
4. When you've got them all (not a bad idea to copy the Prop Exemplars too at this stage), click on Patch at the top.
5. Create a new DAT containing only the items you need.
   It can help a lot at this point if you have a spreadsheet with the names and RTK IDs as a reference.
6. For each group of 20 models, change the Instance ID of the S3D files so that the first 0 becomes a 1 (up to F for subsequent copies, max 15 with this method).
   The format of Instance IDs for S3D models is usualy 00030XYZ (Day) and 00038XYZ (Night):
   • Where X = Zoom 0-4 (1-5)
   • Where Y = Rotation 0-3 (N/S/E/W)
   • Where Z = Unique number for each texture, since some zooms may need more than 1.
7. Now you just need to alter the corresponding RTK IDs to match your changes and generate new group/instance IDs for the prop exemplars.

Now you are armed with a unique copy of the model, but it links to the original textures. To understand why, click on the MATs tab, with an S3D file selected. Select a texture in the list, see how you can set the TGI of this texture, it still has the old texture ID, you should not change this. If you make a model smaller, it's the LODs that map that texture, so whatever adjustments made to your unique S3D will be applied to the original textures on this new model.

A good example of this is the file "Girafe_Bikes_T21 Prop Pack.dat" inside my SAM 7 mod, assuming you install the T21 mod. I've taken the original models and made two duplicates of each which are offset, one forwards, one backwards. In combination with a family and T21s, randomly it will display either the Front, Middle, Rear (using the property Prop Random Chance - NOTE: Must be RTK4 prop to work). This makes them flexible and stops things from looking too similar or like patterns.

A small note of caution here. In theory you can change all the first three proceeding 0's using this method. Honestly, I've never needed more than a few copies so never tried. But if you change the group ID, or in other circumstances my memory is fuzzy on, they won't reference the correct FSH files. This is why I stick to this method, since the likelihood of these ID's being used is very low. There is no way to reserve ID's for S3D files sadly, so you have to try it in the knowledge that should a conflict be brought to your attention, you may need to simply alter the ID's once more. But just incrementing one more time should be sufficient. Also, I've yet to run into such a problem myself.

Lastly, some models (thankfully very few) are linked via the Instance ID not the Group ID, it's like the setup of group and instance is switched around. If you come across such models, have fun with that . I'm not sure if this method would work in such a case.

If they are simply for personal use, you could save a lot of bother and just copy the FSH files as well. But I wouldn't, you'd have to re-ID the FSH files, then also alter the ID for every texture in the Mats tab, which is a PITA. After a couple goes with this method, you can churn them out in no time. You are also free to release them, linked to the original dependency for the textures. Plus you have no redundancy (copies of the same textures with different IDs) hanging around in your plugins folder, win-win-win I believe .

[Edvarz 1,985]

Hey! many thanks for the information. Currently I don't have access to my computer so I won't be able to try anything until a couple of days, but I do have a couple more doubts (simpler ones) in the meantime if you don't mind. 

On 1/5/2016 at 2:37 AM, rsc204 said:

Cohorts would be ideal for such situations, if it weren't for two issues:

It seems that I will have to forget about Cohorts for my prop mods. I got the idea when I checked nos.17's Essentials, he seems to have used cohorts to group his LBT car families. In any case, I'll keep them in mind should they be convenient for the building exemplars in my packs of lots.

On 1/5/2016 at 2:37 AM, rsc204 said:

It strikes me what you want to do, is take a copy of the prop exemplars for those props you want to modify. So long as you only include exemplars in your upload, you are pretty much free to do what you like here. If you keep the same TGI (ID) for these new exemplars, provided your file is loaded after the originals, it will override them. Thus, your changes would be applied wherever these props are already in use.

Sometimes, overrides are not really ideal, you have to think about any unintended consequences for existing content using them. In such cases, simply re-ID the prop exemplars to make new, unique instances of each props. This is real easy, highlight all your props in reader in one go, right click and select "Generate new Group and Instance". You might also want to rename the props, so that your modified ones are distinguished from the originals in the lot editor.

Regarding the new prop exemplars. I messed around a little on Reader and PIM-X. First I found that Maxis props' properties vary from exemplar to exemplar, i.e. a car cluster prop doesn't have a Flammability property but it has a "Requires power to appear" or an "Active lot state" property. So In the Reader I deleted and added properties to a couple of my prop exemplars where I thought it was applicable. I deleted "Flammability" and "Max Fire Stage" (For example in fountain props: How exactly would you set fire to a fountain? ) I also deleted the "Query as main building" and "Light" properties and copied and added the "Active Lot state" and "Requires power to appear" properties to car clusters.

So, my instinct tells me that I sould re-ID these props instead of using them as overrides, correct? (because they will be RKT4, the car props are so far the only ones with new Instance ID's, should I also generate new group ID's?) Also I'm curious to know how many properties can I delete from a prop to keep it functional? I also noted that some of the props had a "User Visible Name Key" property and some didn't, from the Reader's description it seems like it has to do with LText names, should I keep this property if there is no LText name or should I add the later? does a prop need to have an LText name? I guess these questions fall in line with the more general one: how are prop exemplars modded properly?

On 1/5/2016 at 2:37 AM, rsc204 said:

You are also free to modify S3D files and distribute them, so you can offset props or return them to centre. Really, this is a bit of an error many batters tend to make, since all items should ideally be centred before rendering. Such modifications really need to be unique props, but there is a way to do this, whilst referencing the original FSH files. Pretty much that's the part you can not re-distribute. Here's the best way to accomplish this (warning, it's a bit long):

And lastly, regarding the FSH and S3D files. Since the models I want to centre are for timed props, I will have to make new instances anyway so it's good to have this info. I planned to also use model tweaker later on my lotting project to desaturate the color of some models, this would affect the FSH files wouldn't it?

Anyway, thanks again! I will try this as soon as I can. I know I ask a lot, but I intend to give a lot back to the community, actually, I intend to give lots of lots back! See what I did there ?...

Ok, I'll show myself out.

[rsc204 21,859]

By and large, you should just experiment with the properties of prop exemplars. You don't need many to actually have a functioning prop. I'd avoid adding the requirement for power to most props, for cars this seems especially unnecessary. For example, if you don't need a prop to have a wealth or be flammable, you can simply remove the properties and be done with it.

Some objects require a specific group ID to work properly, but this does not apply to props. Therefore, it makes it much less likely you will have a conflict if you randomly select both a new group and instance ID for new props.

There are benefits to using an LTEXT for props, which should probably only need a "User Visible Name Key" property. The exemplar name is what you see in the Lot Editor. If you prefer not to use LTEXT's, simply delete the property and replace it with the Item Name Property. PIM-X can create the LTEXTS automatically from the Item Name or Item Description (not so useful for props) properties, should you require them. If you had plans to localise (make multiple language support), for a given item, you should always use an LTEXT. This is why Maxis content will mostly have them.

As for S3D adjustments, you can modify them to your heart's content. The FSH files will still work without modification, since it's the S3D files themselves that dictate how the textures are mapped to the models. If you need to modify the actual textures (FSH files), such as to de-saturate them, then the only way another user can have the same changes is if you distribute the modified FSH files. Which you can't do without explicit permission of the creator. Bear in mind also, getting good results from such modifications is far from easy. You need to modify the MipMaps, since you can't recreate them from the largest textures, like you could with Lot or Transit textures.