i would never run a ´´copy´´ of supcom 2 ^^
i have a steam version with the gameversion 1.250 but i haven´t bought the dlc yet
where the modmanager runs perfekt but lets just say a pal has a ´´copy´´ of the game which is in v 1.240 with the dlc installed ^^

Then the manager wont work it reads the steam path of the gamedata folder only, the only way would to place the files into your copied gamedata folder.

tried it but the game still doesn´t recognizes the mod....will probably be caused of the gameversion i guess.....then the only way would be to wait for an ´´non official´´ upgrade.....are the new units like the seraphim bomber only awailable with the dlc installed?

Something doesn't sound right. Why would a "pal" have a "copy" of the game, especially a copy that is not up-to-date? It sounds to me like what your "pal" has is a torrented/hacked copy of SupCom 2 that is not up-to-date, and obviously you can't go online to update it. If your "pal" has a legitimate copy, then just go online with Steam and have Steam automatically update the game since it doesn't cost anything. There is no such thing as a "non-official upgrade", unless you mean an updated torrent/hack. If this is the case, then no one here will help you with getting the game to work.

The seraphim bomber only works with the DLC and if you don't own the game you should buy it its not like it cost a lot.

its just that i have still so much fun with supcom fa that i first wanted to test
if the modded version of supcom 2 is worth buying the game because the unmodded obviously isn´t.....and i already bought the standard game but i thought if its worth it to buy the dlc....but because of the fact that the mod development for supcom 2 is steadly increasing i will give it a try.....and yeah the dlc costs almost nothing but see it this way.....even if i get the chance to buy a sausage for 10 bucks i wouldn´t do it ^^

====>madface

i wasn´t asking for help to get it working....it works perfectly
i just wanted to know if the version 1.240 of the game can recognize the new version of the mod
===> how could this ever sound right xD

Well different versions would no matter in this case because the scd files are the same in bother versions.

hmmm.....strange
...forget it i just gonna buy the dlc ^^

I'd like to clarify that pirated versions of SupCom2 will probably not work with this, and I have no intention of "fixing" that.

CerusVI: Just letting you know that I have successfully used SC2MM to install/uninstall my 'All Factions' mod (which is now implemented differently from what I have posted in my thread), and the SC2MM launches the game without any problems. The final version of my mod is an independent scd. FYI, I'm using Win 7 x64. No errors or error messages.

Also, I think it might be a good idea for the group of us who are actively using and promoting your manager, and you yourself, to advertise that all 3rd-party mods be extracted to "mods/<mod name>" in the game's installation directory to standardize the process. I would also suggest putting more emphasize on the fact that SC2MM is not just a mod manager, but also the game launcher.

Another thing: I think you should talk to Mithy about the possibility of him allowing you to package his new non-destructive hooking minimod to be bundled with the manager. There is now a huge potential for future mods to require his mod in order to work. My mod requires his mod. It might be tedious and confusing for end-users of several 3rd-party mods constantly being directed to download Mithy's minimod. If his mod is automatically bundled with your manager, then we can just distribute our own mods without having to always direct people to download his mod as we know it's already there.

@madface: when are you going to release the mod manager version of your mod?

I uploaded it on moddb and its awating authorization. I'm forecasting that it should be approved and available for download some time today. I'll update my thread with relevant info as soon as it's available.

I dunno about bundling - I do want to be able to update it myself. But implementing that 'required mod' feature I requested would solve most of the problem, by making the support mod automatically enabled whenever a mod that needs it gets clicked, and keeping those mods from being enabled without it (and greying them out).

This could be simply expanded upon by including a $ReqModURL <> in the mod.cfg that creates a clickable link (that launches the default browser) somewhere in the SCMM UI whenever the required mod isn't available. If you're concerned about safety, make sure the links can only point to a thread on these forums, and that should address any malware/redirection concerns.

Require-support would allow other mods to use these features as well, rather than just favoring this one support mod, and it would put the burden of managing which mod(s) are specifically required or 'essential' on each individual modder.


I'm ambivalent about using a 'standard' mod folder. I don't think it should be enforced by the program, but having the installation instructions recommend that you use a certain path for the program (e.g. supremecommander2\mods) and then download/extract all mods into that path would be great. Each mod's installation instructions should just say to install into the SCMM path, and could then refer to the default path for people who don't know where it is.

There is an issue with the mod manager. Please bear with me as this is going to be a long-winded explanation...

1. Let's say you create a single directory where you will keep all of your mods to be used with the manager.

2. You start up the manager, load up the mods, and play the game.

3. When you are done playing the game, you come back to the manager screen. You simply close the manager keeping the mod list there for future use.

4. You go to your mod directory, delete mods, rename mods, whatever.

5. You start the manager, you still see the old list. You click on a mod to enable it, and the old version is still enabled (is it cached somewhere?) even though the mod has been, lets say deleted, renamed, or updated with the same file name!

If you simply replace one mod with an updated version, this version will not be automatically updated in the manager. The old version will still be loaded.

Solution: upon starting have the manager scan the mods previously loaded and unloaded (but still in the mod manager list) for any changes (existence, file size, date modified, etc.) and prompt the user if any changes are detected. Have the manager scan mod.cfg to determine if it is a new version and prompt if the user want the manager to automatically update the mod in the manager list. Otherwise, remove it from the list.

There was a problem with updating from Revamp 1.0 to 1.01. Simply copying over the new 1.01 version to the location of 1.0 (overwriting it) was still resulting in 1.0 being loaded. The only way that 1.01 was loaded by the manager was to manually remove the previous 1.0 listing in the manager and re-add the 1.01 version.

The manager does cache everything, which is what causes this complication.

Just deleting the mod's .scd from the folder you're adding it from does not remove the mod from the manager, and putting a new .scd in there doesn't remove the old mod from the manager's cache.
I understand why it's set up this way, and I don't really have a problem with it, as the ideal install method is to download the .scd, add it to the manager, and delete the .scd. But it definitely makes it a bit confusing for people who don't know how the whole process works.

Solutions:
Make it clear when you add a mod that it's being copied to a new location (e.g. dialog window with an initially-unchecked 'don't display this next time' checkbox), and make the cache folder user-configurable so those of us with multiple disks can decide which disk to put it on (this is important for really large mods and small boot disks, e.g. SSDs).
I would also include an option for 'move rather than copy files for installed mods' when the cache/mod folder is on the same disk as the game, again to optionally eliminate the long copy time for a 200mb+ mod.

Edit: Sorry if I'm coming across as demanding - I really appreciate that you've taken the time to make the program, and by and large it works very well. These are just nitpicks, and if you can get around to fixing them, then great, but it's not a big deal.

Hm, ok, I did just notice one thing that is kind of a big problem when you have several large mods installed - the cache contains not just one, but two copies of each mod. One containing the original .scd(s) and another containing the contents of the .scd(s). When you have 500mb of mods installed, that means at least 1gb of space consumed on your boot disk, plus whatever space is used by the original downloaded .scds if you don't delete them. This second extracted copy does not seem to be used for anything at all that I can tell.

While most people do have huge secondary disks, enough people have small primary SSDs or limited boot partitions that this could be problematic (I only have about 2gb free on my boot partition, and when I add two large mods, that space is basically gone, which is bad for a wide variety of reasons).

This also means that a ~300mb mod like Neph's map pack takes several minutes to 'add' to the manager, and around 5-30 seconds to 'install' into \gamedata, depending on how fast and defragmented the disks you're using are. It also has to do this install process again every time you start it up with mods enabled, which can take a very very long time with 600-700mb of mods selected.

Just to follow up Mithy's point, on Win 7 the directories where SC2MM caches the files are:

- C:\Users\<user name>\AppData\Roaming\SC2MM\scd
- C:\Users\<user name>\AppData\Roaming\SC2MM\mods

The "scd" foler contains the mods in .scd format and the "mods" folder contains the mods in their extracted forms.

You can manually delete these cached versions if you are low on space.

Everything in the \mods folder can be deleted, yes, so the question is why create it at all? The \scd folder contains what it actually copies to install the mods, so make sure you don't delete anything in there.

I think he's extracting to the mods folder in order to merge mods together, using the tmp folder in the process of doing so, archiving the result as a .scd in \scd and loading that into gamedata.

Mithy, I think it's ok to also delete from \scd once the manager is closed as long as you uncheck the mods in the manager before closing. Once the manager is closed, the original files are restored in gamedata regardless, even if you keep the mods checkmarked. The problem will occur if you leave the mods checkmarked, close the manager, delete \scd and then open the manager. Since the manager will automatically recopy to the gamedata folder any mod that is checkmarked upon starting the manager, if the mods are not present then the manager will encounter an error. The only way around this is if you manually copy over the scds before starting the manager. But then this defeats the purpose of a manger...

Just closing down the manager with the mods unchecked doesn't actually delete them. In order to have the manager delete them you have to actually remove them from the list in the manager. But then you have to add mods each time you start the manager, which is a pain in the arse.


CerusVI: some ideas:

(1) have options of what people want to do with individual mods, i.e., let them choose whether to cache or not. Allow this on a per-item basis. You might have a bunch of little mods of just a few MB in size that you can afford to leave on all the time and this saves you time and effort having to manually add them each time.

(2) enforce the rule that people have to install the mods to /.../supreme commander 2/mods, and perform all your manipulations there. Chances are likely that the hdd/partition where Steam is installed will have a LOT more space that maintaining a complete cache wont necessarily cause problems for most people. But still allow for (1).

(3) allow directory-loading of mods.

Cerus: I just installed vs c# and started playing around with your src code. I removed the restriction to overwrite conflicting files, but the manager doesn't properly layer mods. At this point, I am not interested in merging mods together, but simply using an addon mod to overwrite only a subsection of a particular mod.

In my particular case, I would have the following flow (as your manager implements it): base game -> load revamp -> load a hot-swappable tech tree submod (z_lua_dlc1.scd) -> unload tech = base game, where the ideal behaviour would have it revert back to revamp when we unload tech. In other words, as soon as I load the tech tree submod on top of revamp, the z_lua_dlc1.scd portion (and only that portion) of revamp is lost.

Now, I've never used c# before (I normally use c++), so, i'll have to learn the proper syntax to implement the desired changes (don't know how long that'll take. Hopefully not too long). I don't want to just spew things out to you "change this, change that, blah blah blah", so I'll divest some effort into implementing some of the changes I'd like to see. I'll send you code whenever I get things working so that you can incorporate it in future releases if you want.

Despite that Mithy made his hooking support mod, there might be some limitations in hooking some ui-related stuff, and until that's sorted out we should have something that will at least be more friendly to hack-modding.

It does not do this. It copies individual mod .scds from AppData\SC2MM\scds to \gamedata. The stuff in AppData\SC2MM\mods is not used at all, and the mod manager functions just fine without it.

I'm trying to work through the syntax (SC2MMData.cs)...

His methods for adding mods and finalizing mods rely on the tmp and mods directories. It seems that he's ok with unzipping the mods in his adding method (in cases where several scd files are distributed as part of one bigger scd file), but there seems to be some problem with zipping the mods in the finalize method. The command for zipping is actually commented out. The entire method for finalizing the mod is split into an if/else statement. The else statement reads:



There would be no point in trying to zip the file if it wasn't being merged. The current mod manager implementation only requires that, if warranted, the main scd be unzipped and the inners scds simply copied over to gamedata. No zipping is required.

Then, if you look at the if statement with regards to conflicting scd in frmMain.cs, it does absolutely nothing to try and merge the mods at this point. It simply does not enable the conflicting mod, i.e., does not even attempt to perform any operation on it.

The contents of the scds are extracted to those folders for later examination and action(such as getting the mod.cfg data). The zip(scd as uncompressed archive) method was commented out because of a file access problem that could pop up. I'm still sorting that one out, but it's been slow going recently due to a fairly annoying illness.

It's correct that the /mods folder has no current use. The anticipated usage is primarily previewing and detecting conflicts at a deeper level.

The reason for keeping it's own copy of the scd is to keep the users concerns as far out of the filesystem as is practical, which is why it has some version checking and update logic. Having an option for an advanced user to select a working directory is an excellent suggestion, it'll be in the next version.

Edit: oh, and at least one reason beyond merging for re-zipping the scd was to trim duplicates of potentially large $LongDesc .rtf files.

Edit2: as far as large mods being loaded goes, one idea in mind was to include a toggle for keeping mods loaded on exit instead of forcing an unload. Other suggestions are welcome.

Well, like I said, a configurable path for the mod cache along with an option to move instead of copy the .scds for an installed mod-- when on the same logical drive-- could completely eliminate the load time and cut down on wasted disk space.

It already tracks which mods are installed and what their filenames are, so in the event of a crash, it could simply move the files back on next run (or next exit, leaving them in place on run if they're still installed) instead of deleting them as it does now.


I wouldn't focus too much on 'scd merging' with any future development. In practice, that's not very useful for SC2 mods, because most of them are replacing the same files within the same .scds. This is even more true for mods that use the hooking minimod - the only files they need to replace are the same two unhookable files inside z_lua_dlc1.scd that any other mod would need to replace, making any hooking mod that replaces z_lua_dlc1.scd (research tree mods) fundamentally incompatible with all others that do the same.