• Welcome to SC4 Devotion Forum Archives.

extract single prop from megapacks

Started by vortext, October 27, 2010, 04:05:59 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

vortext

hi, how do I pull a single prop from a megapack?
Tried simple copy-paste everything related (fsh/3ds) into a blank dat but it didn't show up in the sc4pim  &mmm
Note, I do not want just the examplar since it would still need the original pack as a dependency but a prop as standalone.

thanks, V.
time flies like a bird
fruit flies like a banana

Andreas

Usually, you need the prop exemplar file, the associated XML file (if available), and naturally, all FSH and S3D files for this prop. You can omit the BMP and JFIF preview pics, though.
Andreas

vortext

secretly I knew it should make sense what I was doing  $%Grinno$%. It took a while though for me to figure out there are SD3 files for all directions, instead mistankingly presumed there was just one 'cause it is a 3d model (? correct me if I'm wrong). Thanks for the quick reply, much appreciated.
time flies like a bird
fruit flies like a banana

cogeo

Quote from: vortext on October 27, 2010, 04:05:59 PM
Note, I do not want just the examplar since it would still need the original pack as a dependency but a prop as standalone.

If you want to release your work (and include the prop into your upload), you must first get permission from the author. Otherwise your upload will be regarded as "plagiarized".

Lowkee33

I often think about taking certain props out of MEGA packs (Trees that are dependencies for tree-controllers).  Is there are "best" way to do this, or is it just a matter of picking out all of the images that look like the right prop?

vortext

Lowkee is exactly right 'bout the trees, so never had the intent to show other people's work off as my own. Nor be foolish enough to do so I might add  ;) 
time flies like a bird
fruit flies like a banana

Andreas

Quote from: vortext on October 28, 2010, 10:17:12 AM
It took a while though for me to figure out there are SD3 files for all directions, instead mistankingly presumed there was just one 'cause it is a 3d model (? correct me if I'm wrong).

All SC4 models consist of rendered FSH textures that are applied to S3D models - for each rotation and each zoom level, so there are 20 S3D files and at least the same amount of FSH textures. For larger models, the FSHs are broken into serveral pieces (at least for the larger zooms), and then there are also the night textures, if the object has nightlighting.

Quote from: Lowkee33 on October 28, 2010, 10:35:54 AM
I often think about taking certain props out of MEGA packs (Trees that are dependencies for tree-controllers).  Is there are "best" way to do this, or is it just a matter of picking out all of the images that look like the right prop?

Well, I don't know if there's a "best" way to do it, but usually, you'll open the DAT with the Reader, and go through the list of files. There are two ways to identify which files belong to each other, but in most cases, it's rather obvious. gmax-rendered models have a certain Group ID (the same for each individual file of a model), whereas 3DStudioMax-based models usuall have the same Group ID for all files, but a different Instance ID range for the individual models. But the files for one particular model are usually placed one after the other in the list, so you just need to pick a group of continous files in said list.

Then you find out which prop exemplar file belongs to them. The exemplar file might be placed at the top or bottom of a group of files, but sometimes also in between or at a completely different place, depending on which method was used to package the mega pack. But if you check the ID in the Resource Key Type 1 property, you should be able to determine the group of (S3D and FSH) files easily. The XML file is not needed for the game, but the Plugin Manager uses it to identify it as a model (I think SC4PIM does the same, but if not present, it can create a new XML file). Sometimes, you might need to find additional files, such as LTEXT files that contain the name of a prop, but they should be somewhere in the vicinity, too.
Andreas

Lowkee33

Thanks :) I did as you said and it worked.  I didn't realize they were grouped like that.

So this is why PIMX sometimes names things "xml not found".

Andreas

Quote from: Lowkee33 on October 28, 2010, 11:52:49 AM
So this is why PIMX sometimes names things "xml not found".

Probably. For the SFBT releases, I usually remove all preview images and the XML files in order to reduce the size of the prop packs, and I think some other developers do this as well. On the other hand, I'll try to group the props as logical as possible, so there's no real need to disassemble the prop pack. ;)
Andreas

Lowkee33

#9
  I am pretty new to custom content, and am most familiar with the older dependencies.  I have been finding quirks in some of them (buildings exemplars, prop exemplars to buildings in other packs, strange looking beach goers...) and so I have been thinking about the feasibility of taking out specific models and making my own prop exemplars.  Sometimes people go "family crazy" and the LE gets bogged down.  I also want to add more timed-tree props so that I can have a forest that doesn't change all at once.

  It certainly seems possible now.  I can say that my plugin folder is completely empty but for a terrain mod...

Andreas

Yeah, it's entirely possible with a little effort. Just make sure that whenever you change the properties of an exemplar file, such as adding time or seasonal properties, you'll make a new copy with different ID - as we're all aware of those props that have been modded without ID change and that are known to be a trigger for the prop pox...
Andreas

vortext

Quote from: Andreas on October 28, 2010, 11:28:25 AMThere are two ways to identify which files belong to each other, but in most cases, it's rather obvious. gmax-rendered models have a certain Group ID (the same for each individual file of a model), whereas 3DStudioMax-based models usuall have the same Group ID for all files, but a different Instance ID range for the individual models. But the files for one particular model are usually placed one after the other in the list, so you just need to pick a group of continous files in said list. Then you find out which prop exemplar file belongs to them.

Wouldn't it be faster to use the navigator to see both the exemplar and the Resource Key Type 1 which belong to a prop? That's how I do it and with 'add to patch' method, extracting props isn't as tedious as I thought it would be (still boring though  ;))

Quote from: Andreas on October 28, 2010, 02:03:52 PMJust make sure that whenever you change the properties of an exemplar file [...] you'll make a new copy with different ID

Does this goes for every change made in an exemplar? (e.g. lowering cost or deleting base textures)
I'm also quite the newbee and don't want 'the prop pox'. Even though I don't now what it is the ominous dots give me a scare  :D
time flies like a bird
fruit flies like a banana

Andreas

As for the "best" method for extracting props, I described what I do, but I guess working with the navigator is another nice method - as usual, there isn't just one way to do it. Changing the value in existing properties shouldn't do any harm, however, in most cases it's mandatory to bulldoze all lots in existing cities before changing anything budget-related, otherwise the dreaded "phantom slider bug" might occur.

I think lot texture changes are displayed immediately, like any transit-related texture edits, but added or removed props will be displayed properly only after bulldozing as well. As I said before, be careful with adding/deleting properties like the time/seasonal stuff, as this changes the size of the prop exemplar file (and the amount of prop-related data that needs to be stored in the savegame) and thus might damage the city.
Andreas