Plugin Detector for sc4pac [Development Thread]

[nos.17 5,177]

One of the main issues users face when converting their old plugins folders over to using sc4pac to manage their plugins is the difficulty of knowing a) what they have that is available in sc4pac and b) whether they have accidentally installed any duplicates of the same content.

When moving plugins, all of your existing plugins should go into the 075-my-plugins or 895-my-overrides folders. For the purpose of discussion these will be called "manually installed" plugins. As you install plugins via sc4pac, you would want to manually delete the now redundant items from your 075 and 895 folders. This may not be simple if you are not intimately familiar with the contents your plugins folder, or if your plugins folder is particularly large. This tool is designed to assist with this process.

 

The goals for this tool are:

• Identify what manually installed plugins that duplicate what has been installed with sc4pac
• Easily remove the manually installed plugins, in favor of the sc4pac installed ones

A stretch goal:

• Determine which manually installed files are available in sc4pac for install

 

I'll save space in this post for future content when the project is released.

[nos.17 5,177]

Until the program is ready I'll use this thread as a development blog to show off progress and also take feedback should anyone have opinions or advice.

All of my other programs in the past (SC4Cleanitol and SC4LTEXTT) have all used a GUI framework called WPF. WPF is a framework originally created by Microsoft in 2004. Having been around for a long time, it is fairly robust, and there are tons of code examples and tutorials which make it pretty easy to pick up. However, development on it has stagnated quite a bit and it's biggest drawback is that it is not cross-platform - it supports Windows only. Linux & Mac users are out of luck unless they want to spin up compatibility layers around the program to make it run. For this program, however, I wanted to take a different approach. Since sc4pac is cross-platform, and this program is designed to be used along side sc4pac, building something cross-platform just makes sense.

Enter Avalonia. Avalonia is one of the successors WPF and has many huge advantages: The biggest:

Quote

Windows, macOS, and Linux apps from one codebase

Avalonia is a mature WPF alternative. Avalonia provides a familiar developer experience, allowing you to create rich, highly performant desktop applications for Windows, macOS and Linux, all from a single codebase.

Cross platform? Check? It also has very similar syntax and structure to WPF, to the point that most WPF code can be copy and pasted into a new Avalonia project and it will work out of the box. This is super nice because sometime in the future I can go back and give SC4Cleanitol and SC4LTEXTT the same treatment.

Here's what I have working so far:

The top section (in light purple) groups the controls around selecting a Plugins folder to scan. Use the 'Choose Folder' (or type into the text box) to select the Plugins folder. After that you have the ability to scan the contents of the chosen folder, and the results are displayed below. in the example above, I installed b62:safeway-60s-retro-grocery via sc4pac, but I also had the STEX file manually installed. The program detected that six files are duplicated between "my plugins" and "sc4pac plugins", and recognized that they're all part of one sc4pac package, so it grouped them together.

Right now, the duplication recognition is "dumb" and only works off of the file name, so it won't work if you datpacked your plugins, or if you renamed any of the files. An option for a more advanced scan might look at TGIs to find duplicates, but that may come later. Similarly the recognition of what package the file is part of is also done through it's filename - the sc4pac package is part of the folder structure, so extracting that information is easy.

I think my next steps are to put the files in each group inside of a accordion-style control so the detailed content of each group is hidden unless clicked on, and add buttons that allow you to easily navigate to the files in the OS file explorer and delete the duplicated files

[Kel9509 1,475]

33 minutes ago, nos.17 said:

Right now, the duplication recognition is "dumb" and only works off of the file name

Where are you getting the file names from?  Are you scanning the archives on the STEX?

[nos.17 5,177]

14 hours ago, Kel9509 said:

Where are you getting the file names from?  Are you scanning the archives on the STEX?

 No, this just examines the files in your Plugins folder for the moment. I am collecting that information as part of the new Prop Texture Catalog though (example). That may or may not make it into this tool yet. Not sure.

[memo 1,460]

Excellent. Thanks for tackling this problem. I've spent some time thinking about this as well, but got all hung up on all the hard cases that are difficult to solve. So it's good to see that you just give it a go and start with the simpler cases where file names match. That will cover a large amount of plugins after all.

A few random thoughts:

• It's likely that manually installed plugins are out-of-date in some way or another.
• File names often change when new versions of plugins are released, e.g. due to version numbers or unification of naming schemes. This could be solved by looking at the DBPF contents.
• When new versions of plugins are released, often additional content is inserted into the files, or multiple files are datpacked. This is extremely difficult to solve I think. Cleanitol lists could provide some info.
• Perhaps some form of fuzzy hashing could be used. This seems to be a science unto itself though. The quality of the hash when applied to DBPF files would be crucial. The idea is to create a small database of fuzzy hashes of all DBPF files in each package. Then, manually installed files can be compared for similarity against those fuzzy hashes.
• Package variants complicate things, especially when there are many combinations. This isn't a problem when scanning the local Plugins folder for duplicate files, but is a complication for the stretch goal of finding suitable packages that aren't installed, as the exact contents of a package can vary a bit.

[nos.17 5,177]

Thanks for the points.

2 hours ago, memo said:

• It's likely that manually installed plugins are out-of-date in some way or another.
• File names often change when new versions of plugins are released, e.g. due to version numbers or unification of naming schemes. This could be solved by looking at the DBPF contents.

I am thinking about a second "advanced" scan the user could toggle on or off which would be able to pick up and report on TGIs. Perhaps a second level after the file names have been processed.

2 hours ago, memo said:

• When new versions of plugins are released, often additional content is inserted into the files, or multiple files are datpacked. This is extremely difficult to solve I think. Cleanitol lists could provide some info.
• Perhaps some form of fuzzy hashing could be used. This seems to be a science unto itself though. The quality of the hash when applied to DBPF files would be crucial. The idea is to create a small database of fuzzy hashes of all DBPF files in each package. Then, manually installed files can be compared for similarity against those fuzzy hashes.

If plugins are datpacked, I might just say you're SOL. It's been recommended since the beginning of datpacking to keep a non-packed backup. Solving that issue here doesn't excite me. Hashing is a very neat idea. I do see how it can get gnarly to compare things - and how it should compare if a user has customized a plugin. 

2 hours ago, memo said:

Package variants complicate things, especially when there are many combinations. This isn't a problem when scanning the local Plugins folder for duplicate files, but is a complication for the stretch goal of finding suitable packages that aren't installed, as the exact contents of a package can vary a bit.

I wasn't thinking about this before, but it may also factor in now when finding files. If different variants are used between manual and pac plugins, the program wouldn't report on files not in common between the two. I was thinking about a button to press to delete the files, but now I wonder if it may be wiser to have a button open the folder instead and have the user manually delete the files/folder.

[CorinaMarie 29,777]

4 minutes ago, nos.17 said:

I was thinking about a button to press to delete the files, but now I wonder if it may be wiser to have a button open the folder instead and have the user manually delete the files/folder.

Or your button moves them out of Plugins to some sort of Date/Time Stamp Named Holding Bay folder with the recommendation that the user can manually delete them? (But it wouldn't hurt anything if they just left them there.)

[nos.17 5,177]

On 12/15/2025 at 4:53 PM, CorinaMarie said:

Or your button moves them out of Plugins to some sort of Date/Time Stamp Named Holding Bay folder with the recommendation that the user can manually delete them? (But it wouldn't hurt anything if they just left them there.)

Cleanitol style? I like this a lot more than straight deletion.

 

I have cleaned up the styling a bit and added a few new buttons. The box icon opens that package directly in sc4pac. The folder icon opens the folder that contains these items. The broom icon will be used to clean those files. The files for each package are now nestled in a little accordion control so they can be expanded and contracted as desired.

[Kel9509 1,475]

I fear I will not ever be able to use sc4pac, because I've modded the heck out of various downloads by turning some landmark eyecandy lots into lots with cap relief and other rewards.  I wouldn't want those overridden by sc4pac's downloads, and I'm not sure if there's a way to go through them all to make sure they wouldn't get overridden.  And this plugin detector, while great for those who want original files, might end up being a problem for anyone else who's modded or customized their downloads.

[nos.17 5,177]

18 hours ago, Kel9509 said:

I fear I will not ever be able to use sc4pac, because I've modded the heck out of various downloads by turning some landmark eyecandy lots into lots with cap relief and other rewards.  I wouldn't want those overridden by sc4pac's downloads, and I'm not sure if there's a way to go through them all to make sure they wouldn't get overridden.  And this plugin detector, while great for those who want original files, might end up being a problem for anyone else who's modded or customized their downloads.

Do you modify everything you use in Plugins, or is there a chunk that remains "stock", so to speak? The same file naming schemes to override files work with sc4pac still, so there's nothing to say you couldn't use both at the same time if you're careful. Now that you bring this up, perhaps I could include a feature to ignore conflicts this app finds so they don't re-appear each time a user scans.

Yes, any modification of the files will be a problem and something I will clearly caveat in the instructions. I suspect that the number of people who customize their downloads like you or I is extremely small; I technically won't find a use for this tool for my personal plugins either, but from seeing posts on Reddit and Discord, I still think there's a lot of opportunity for "regular" players.

[memo 1,460]

On 12/19/2025 at 4:21 AM, Kel9509 said:

I fear I will not ever be able to use sc4pac, because I've modded the heck out of various downloads by turning some landmark eyecandy lots into lots with cap relief and other rewards.

Generally, instead of modifying files directly, my recommendation is to leave them in their original state whenever possible. Instead, copy just the subfiles you want to change (e.g. some Exemplars) into new .dat files that override the originals by loading after them. That way you have a clear separation between the original files and your additions, making it easier to replace the originals by updated versions, for example. This approach of creating patch files is also what we typically use to make changes to the NAM files, for example.

[Kel9509 1,475]

On 12/20/2025 at 4:21 PM, memo said:

Generally, instead of modifying files directly, my recommendation is to leave them in their original state whenever possible. Instead, copy just the subfiles you want to change (e.g. some Exemplars) into new .dat files that override the originals by loading after them. That way you have a clear separation between the original files and your additions, making it easier to replace the originals by updated versions, for example. This approach of creating patch files is also what we typically use to make changes to the NAM files, for example.

For the most part, I'm not even using the original building exemplars anymore but instead am creating entirely new ones and removing the originals.  Although I do sometimes tweak the originals but I haven't copied them the way you suggest.  I work mostly in PIM-X instead of Reader because arguably PIM-X is faster and can do more.  Also, working off the originals does mean my plugins folder is smaller and has less files.  But you're right that it's not ideal if you want to maintain a separation.