[sc4pac] Let's write our own package manager

[Zasco 105]

3 hours ago, memo said:

Open an issue please.

#11.

3 hours ago, memo said:

For this one, I'm leaning towards 180-flora, as it's more readable, all MMPs are technically Flora, too, and 180-flora also includes god-mode Flora.

The problem is that "flora" relates to plants and trees and might induce a unknowing package author into placing it in "150-mods" instead... I vow for a more inclusive term, while still agreeing with you that MMP might not be the one. Would "180-ploppables" be better suited then?

3 hours ago, memo said:

True, but it's actually quite a tough problem to ensure that both exchanges are in sync. The exchanges do not keep older versions around and do not provide checksums that prove that assets are identical. Until something like that is implemented on the exchanges, I don't think it makes much sense to spend an effort on this. As currently the majority of files is only available on one server, this would rarely be of use.

Of course. The idea was simply brought up to me by the "BSC-VIP Girafe Urbanpack vol01" plugin.

[Flann 1,709]

I'd be fine if it was just

180-flora

I think it's technically precise enough and anyone writing metadata probably has enough experience to not get confused by the terminology.

That said, if there must be a compromise, I think

180-flora-fauna-mmp

makes a decent tradeoff between conciseness and clarity and also matches the way the mods are organized on SC4E.
 

180-ploppables

introduces ambiguity about what the menu could contain.  Lots of things are ploppable, for example lots ...

[Zasco 105]

7 minutes ago, Flann said:

introduces ambiguity about what the menu could contain.  Lots of things are ploppable, for example lots ...

You're right! Forgot about that. I first thought of "180-ploppable-props", but then that it could be shortened without taking this into account.

[nos.17 5,177]

@memo, question about your IRM package. It seems like you're including Shadowstrike's IRM CAM Version with the optional CAM variant, but is that Shadowstrike's A or B version? Version A preserves T Wrecks' distribution of I-M lots between medium-density and high-density industrial zones, on the basis of appearance, and version B allocates all the I-HT lots to the high-density industrial zones and all the I-M (as well as the I-D) lots to the medium-density industrial zones. I personally use version B and would like to keep that option if possible, as people might prefer either option.

 

[memo 1,460]

13 hours ago, nos.17 said:

It seems like you're including Shadowstrike's IRM CAM Version with the optional CAM variant, but is that Shadowstrike's A or B version?

It's option A. My intention was to keep things simple and avoid unnecessary complexity, so I went with option A as it preserves the spirit of T Wrecks's original mod. Option B could be installed manually of course.

[nos.17 5,177]

On 11/17/2024 at 4:16 AM, memo said:

It's option A. My intention was to keep things simple and avoid unnecessary complexity, so I went with option A as it preserves the spirit of T Wrecks's original mod. Option B could be installed manually of course.

Makes sense. I'll create a second copy with both versions and add in the expansions and addons I have done.

[smf_16 1,836]

In light of recent events, I thought it was worth mentioning for people looking to use sc4pac, that not only does it eliminate having to download dependencies manually, it also greatly reduces the threats posed by plugins that come with installers. That's because sc4pac never actually runs these installers. It only extracts the files inside them, which can be done without running the installer. This means that even if someone managed to hack the exchange and replaces the installer with a malicious .exe, sc4pac will never run this installer. Worst case it will just fail to extract any files from it.

Adoption of sc4pac is probably still limited at the moment, but @memo is working on a gui that will greatly enhance the experience. It looks like this is advancing nicely. There's also the issue of insufficient content being available, but that is also worked on. For example, @mattb325's entire residential houses collection and multi-unit collection can now be installed with sc4pac and more is to follow.

TL;DR: I think that once the dust settles on this NAM security issue, sc4pac should be pushed as the preferred way of installing new plugins.

PS: I am aware that the NAM installation process is hard to port to sc4pac, so it will probably keep it's installer for the foreseeable future, but the principle of the attack on the NAM installer can be used for any package that has an installer.

[Zasco 105]

36 minutes ago, smf_16 said:

PS: I am aware that the NAM installation process is hard to port to sc4pac, so it will probably keep it's installer for the foreseeable future, but the principle of the attack on the NAM installer can be used for any package that has an installer.

I already thought about it and porting NAM to sc4pac is possible, but would likely require to make a package for most of it's selections.

[Tarkus 6,932]

3 hours ago, smf_16 said:

PS: I am aware that the NAM installation process is hard to port to sc4pac, so it will probably keep it's installer for the foreseeable future, but the principle of the attack on the NAM installer can be used for any package that has an installer.

One point of clarification to note--the attack on the NAM package was actually on the .bat file that was intended to help users with the biggest pain point in the NAM's current installation procedure, that being the 4GB Patch process, which is required to avoid CTDs if the user is running the full NAM Controller with RHW support.  The actual NAM installer appears to have been unaffected.

That said, the principle is still sound, and I do think trying to get the NAM to be installable via sc4pac is a very worthwhile project, in any case.

-Tarkus

[matias93 7,535]

4 minutes ago, Tarkus said:

and I do think trying to get the NAM to be installable via sc4pac is a very worthwhile project, in any case.

Going back to the package management utilities of Linux, that are the model for sc4pac, what it's done for complex packages that modify others or require user intervention is to launch a small interface to allow for that during the installation, like this one:

It's not the most friendly interface, being text based and all, but it works. Another alternative would be to simply launch the jar executable when the NAM is installed, which would be much easier to implement. In both cases, it still requires user intervention, but honestly, I don't see how it could be done otherwise, except maybe for allowing an unattended alternative that installs the default settings without asking.

[memo 1,460]

It's finally here. I've uploaded the GUI application as a pre-release: Download version 0.2.0. Version 1.0.0 released on the STEX. It's fully functional and should be fairly stable. It supports Windows, macOS and Linux.

It would be awesome if some of you give it a try and report any potential problems. If everything works as intended, I'm going to upload a more official release soon.

The number of installable plugins is steadily growing as well, thanks to major contributions by @smf_16, @nos.17 and @Zasco.

Since the previous screenshots I showed, I've added support for images as well as a few other details. Each plugin not only lists its dependencies, but also which other plugins depend on it. You can even see which of those you've already installed before.

Additionally, I've added configuration options for setting up authentication to Simtropolis. If you set this up, this avoids the download limits that apply to guests, and your name will show up in the list of people who downloaded a file.

 

Regarding the security aspect brought up earlier, as @smf_16 already explained, sc4pac doesn't actually execute any installers, but only extracts files from installers or ZIP files, which is fairly safe.

For files that do get executed (i.e. DLLs loaded by the game), sc4pac verifies the integrity of those files using cryptographic checksums. This ensures that a downloaded file is exactly the same as the one that existed when the metadata was created, which prevents unnoticed modifications of the uploaded file.

 

On 11/28/2024 at 3:50 PM, matias93 said:

Going back to the package management utilities of Linux, that are the model for sc4pac, what it's done for complex packages that modify others or require user intervention is to launch a small interface to allow for that during the installation, like this one:

Indeed, this is an approach that could work. The immediate benefit of this, compared to downloading the installer manually, is that sc4pac could automatically verify the integrity of the downloaded file before asking the user to execute the installer or 4GB patch.

Sc4pac mimics some installer features by use of "variants". These allow users to make choices during installation of a plugin, to select something different from the default settings. For something as complex as the NAM installer, it would make sense to first condense some of the existing installer options though to make this less complex.
 

[smf_16 1,836]

This is an amazing accomplishment. A true game changer in all aspects of the word.

We're doing our best indeed to make more and more content installable via sc4pac. For me personally, when looking for content to add to sc4pac, I'm basing myself mostly on Indiana Joe's Ultimate Plugin Folder. I would say we're at roughly 50% now of that content that can be installed with sc4pac and more is in the works.

I would also like to use the pre-release of the gui as an opportunity to ask content creators to take sc4pac into account when releasing their content on the STEX. The most important thing is to have a clear list of dependencies. Nowadays, new content often simply refers to the BSC Common Dependencies Pack, or Girafe's Flora Pack, but most of the time, content requires only a small selection of those packs. It is therefore advised to always list what part is actually needed. There are ways to figure this out automatically by running a dependency tracking script, but it complicates the process of writing metadata quite a bit.

[Propfam 2,294]

1 hour ago, smf_16 said:

I would also like to use the pre-release of the gui as an opportunity to ask content creators to take sc4pac into account when releasing their content on the STEX.

Good idea. Especially for lot collections which can be hard to download manually. We could have a opt-in for creators to ease out the entry to sc4pac. Or, we can enforce some packaging standard similar to npm with its package.json file. We can use that file not just for sc4pac, but for STEX and even Evermore.

[smf_16 1,836]

@Jidan If you're interested, there are some preliminary ideas on how new content on the STEX can be made available to sc4pac immediately here. It's going to require some thinking because the idea is to avoid requiring the exchanges to do a lot of programming.

[Zasco 105]

On 12/16/2024 at 3:42 AM, memo said:

It's finally here. I've uploaded the GUI application as a pre-release: Download version 0.2.0. It's fully functional and should be fairly stable. It supports Windows, macOS and Linux.

It would be awesome if some of you give it a try and report any potential problems. If everything works as intended, I'm going to upload a more official release soon.

The number of installable plugins is steadily growing as well, thanks to major contributions by @smf_16, @nos.17 and @Zasco.

Since the previous screenshots I showed, I've added support for images as well as a few other details. Each plugin not only lists its dependencies, but also which other plugins depend on it. You can even see which of those you've already installed before.

Additionally, I've added configuration options for setting up authentication to Simtropolis. If you set this up, this avoids the download limits that apply to guests, and your name will show up in the list of people who downloaded a file.

 

Regarding the security aspect brought up earlier, as @smf_16 already explained, sc4pac doesn't actually execute any installers, but only extracts files from installers or ZIP files, which is fairly safe.

For files that do get executed (i.e. DLLs loaded by the game), sc4pac verifies the integrity of those files using cryptographic checksums. This ensures that a downloaded file is exactly the same as the one that existed when the metadata was created, which prevents unnoticed modifications of the uploaded file.

 

Indeed, this is an approach that could work. The immediate benefit of this, compared to downloading the installer manually, is that sc4pac could automatically verify the integrity of the downloaded file before asking the user to execute the installer or 4GB patch.

Sc4pac mimics some installer features by use of "variants". These allow users to make choices during installation of a plugin, to select something different from the default settings. For something as complex as the NAM installer, it would make sense to first condense some of the existing installer options though to make this less complex.
 

I think creating a dedicated topic for this project could be a good idea.

Also, is the channels contents auto reloaded? I currently have to reload the app to reload the contents.

[nos.17 5,177]

@memo fantastic achievement and thank you for your work on this!

I have not had a ton of time to test all the functionality in depth, and probably won't until the new year, but I do have some UI feedback for now.

1. Make the photos section larger. I is arguably one of the most important parts when searching for a mod and determining if I like it
2. Remove the word "explicitly" from "Add to Plugins explicitly". IMO it won't mean much to end users at this point. Actually consider renaming this to "Add to install queue" (or something similar), because pressing this will not actually add anything into the plugins folder - you must then update.
3. IMO prop and texture packages should not show up for a package search with the default filter - most users will probably not be searching directly for one of these, especially since pac will now handle this for users.
4. A small or medium (perhaps customizable sized) image preview in the search screen would be great to have some idea of what the item is before I click on it further. Kind of like the cards in the STEX search, but a bit tighter with higher information density.
5. Functionality for setting the cookies is great! Perhaps add a one sentence description of what may happen if this is not set.
6. Responsive sizing seemed to be implemented very well. Couldn't find any issues.
7. For icons in the category dropdown on the search screen, assuming they'd be ok with it, it would be neat to consider @Panda's icons designed for the submenu dll. Though I'd also understand if they differ too much from the style of the rest of the app.
8. IMO there's a lot of blank space on the package screen that could be better utilized to prevent some scrolling. Move the dependencies pane to the right side above the 'required by' section, making the view effectively two columns. Perhaps put the dependencies into an accordion menu and have up to the first 10 (or so) visible by default. Since pac is handling dependencies automatically, knowing what each and every one is in depth is less important.
9. The edit metadata button is a solid idea, but if I'm thinking from the perspective of a user if they arrive on that screen they might not know what to do. Is there a way to have that link instead be like "report an issue" and then open a new issue in github referencing that file?
10. I'm not sure if this would be an issue for others, but it's a little annoying I cannot select text on the package screen. Why is this?

[Propfam 2,294]

2 hours ago, nos.17 said:

I'm not sure if this would be an issue for others, but it's a little annoying I cannot select text on the package screen. Why is this?

Probably he's added a script and CSS to block unwanted mouse input, especially text selection. It's pretty useful when used in structural elements like navbar but it's debatable for things like in this case, package title. He should consider allow text selection there. There also a possibility that Electron enables such setting and he has to disable it in order to allow it in certain parts. He uses Flutter btw so ignore that.

[memo 1,460]

@nos.17 Thanks for the feedback. Those are some great suggestions.

9 hours ago, nos.17 said:

IMO prop and texture packages should not show up for a package search with the default filter - most users will probably not be searching directly for one of these, especially since pac will now handle this for users.

I've been thinking about this, too, but am undecided on the best UI for this.

9 hours ago, nos.17 said:

A small or medium (perhaps customizable sized) image preview in the search screen would be great to have some idea of what the item is before I click on it further. Kind of like the cards in the STEX search, but a bit tighter with higher information density.

My concern is not to overload ST with requests, so I chose not to display images in the search screen. Also related to the following point:

9 hours ago, nos.17 said:

IMO there's a lot of blank space on the package screen that could be better utilized to prevent some scrolling. Move the dependencies pane to the right side above the 'required by' section, making the view effectively two columns. Perhaps put the dependencies into an accordion menu and have up to the first 10 (or so) visible by default. Since pac is handling dependencies automatically, knowing what each and every one is in depth is less important.

My original plan was to use a 50/50 split-screen layout on larger screens, similar to an email app, with the list of search results on the left and the details for a single package on the right. This would eliminate about 50% of clicks: instead of clicking twice to open and close a package, you'd just click once to open the next package in the list. That way you also get to see the next image quicker (although not as quick as when the images were included in the search results).

Anyway, that's why the screens don't use all the horizontal space currently. Implementing a split-screen layout is not the highest priority right now, though.

For the dependencies, I chose to display them side-by-side so that, at a glance, you don't confuse a long "Required By" package list for a long dependency list. This could happen in the previous UI. A long dependency list would be a downside of installing a package, but a long "Required By" list should be a plus side for installing the package.

9 hours ago, nos.17 said:

For icons in the category dropdown on the search screen, assuming they'd be ok with it, it would be neat to consider @Panda's icons designed for the submenu dll. Though I'd also understand if they differ too much from the style of the rest of the app.

The icons look great in the game, but for the app I think they wouldn't really fit.

9 hours ago, nos.17 said:

The edit metadata button is a solid idea, but if I'm thinking from the perspective of a user if they arrive on that screen they might not know what to do. Is there a way to have that link instead be like "report an issue" and then open a new issue in github referencing that file?

It's possible to add such a link to create a new issue, but GitHub would direct you to a login page if you're not signed in. I might rename the button to "Show metadata" as I think it's important to have a way to inspect the sources, and curious users might just be able to directly provide a fix instead of just an issue report.

7 hours ago, Jidan said:

It's pretty useful when used in structural elements like navbar but it's debatable for things like in this case, package title. He should consider allow text selection there.

There's a copy-to-clipboard button right next to the package title.

The reason that text selection is not enabled is that it's not an HTML webpage, but it's an application. It's possible to enable it on a case-by-case basis, but it's off by default.

[smf_16 1,836]

3 minutes ago, memo said:

10 hours ago, nos.17 said:

IMO prop and texture packages should not show up for a package search with the default filter - most users will probably not be searching directly for one of these, especially since pac will now handle this for users.

I've been thinking about this, too, but am undecided on the best UI for this.

Allow me to pop in on this. I think there's still value in allowing the prop packages to be searchable. Imagine for example a package that is not on sc4pac, but instructs its users to install a dependency with sc4pac. In that case, it's useful that you can search for the dependency.

You could indeed hide them from the default search and then keep them searchable when explicitly looking for props, but that would then have to be known by the users that go looking for dependencies.

[memo 1,460]

On 12/18/2024 at 3:03 PM, Zasco said:

Also, is the channels contents auto reloaded? I currently have to reload the app to reload the contents.

For remote channels, the contents are cached for 30 minutes. For local channels, they are read directly from the file system, but you may have to re-apply a filter or switch to a different screen for this to become effective.

13 hours ago, nos.17 said:

Remove the word "explicitly" from "Add to Plugins explicitly". IMO it won't mean much to end users at this point. Actually consider renaming this to "Add to install queue" (or something similar), because pressing this will not actually add anything into the plugins folder - you must then update.

What would the button say in case of a package that is already installed, either explicitly or as a dependency? In case it's installed as dependency, it can only be made explicit, but couldn't be installed or uninstalled.

[Zasco 105]

On 12/18/2024 at 9:34 PM, nos.17 said:

I have not had a ton of time to test all the functionality in depth, and probably won't until the new year, but I do have some UI feedback for now.

1. Make the photos section larger. I is arguably one of the most important parts when searching for a mod and determining if I like it
2. Remove the word "explicitly" from "Add to Plugins explicitly". IMO it won't mean much to end users at this point. Actually consider renaming this to "Add to install queue" (or something similar), because pressing this will not actually add anything into the plugins folder - you must then update.
3. IMO prop and texture packages should not show up for a package search with the default filter - most users will probably not be searching directly for one of these, especially since pac will now handle this for users.
4. A small or medium (perhaps customizable sized) image preview in the search screen would be great to have some idea of what the item is before I click on it further. Kind of like the cards in the STEX search, but a bit tighter with higher information density.
5. Functionality for setting the cookies is great! Perhaps add a one sentence description of what may happen if this is not set.
6. Responsive sizing seemed to be implemented very well. Couldn't find any issues.
7. For icons in the category dropdown on the search screen, assuming they'd be ok with it, it would be neat to consider @Panda's icons designed for the submenu dll. Though I'd also understand if they differ too much from the style of the rest of the app.
8. IMO there's a lot of blank space on the package screen that could be better utilized to prevent some scrolling. Move the dependencies pane to the right side above the 'required by' section, making the view effectively two columns. Perhaps put the dependencies into an accordion menu and have up to the first 10 (or so) visible by default. Since pac is handling dependencies automatically, knowing what each and every one is in depth is less important.
9. The edit metadata button is a solid idea, but if I'm thinking from the perspective of a user if they arrive on that screen they might not know what to do. Is there a way to have that link instead be like "report an issue" and then open a new issue in github referencing that file?
10. I'm not sure if this would be an issue for others, but it's a little annoying I cannot select text on the package screen. Why is this?

For 6, I did find some troubles for very small screens on the web app.

I agree with 1 and 4 . For 4, the images should not be displayed in the list however, but in a mouse-over pop-over for this reason:

21 hours ago, memo said:

My concern is not to overload ST with requests, so I chose not to display images in the search screen.

21 hours ago, memo said:

The icons look great in the game, but for the app I think they wouldn't really fit.

I agree.

17 hours ago, memo said:

For remote channels, the contents are cached for 30 minutes. For local channels, they are read directly from the file system, but you may have to re-apply a filter or switch to a different screen for this to become effective.

Thx!

[nos.17 5,177]

11 hours ago, memo said:

My original plan was to use a 50/50 split-screen layout on larger screens, similar to an email app, with the list of search results on the left and the details for a single package on the right. This would eliminate about 50% of clicks: instead of clicking twice to open and close a package, you'd just click once to open the next package in the list. That way you also get to see the next image quicker (although not as quick as when the images were included in the search results).

Oooh yea, this is a much better option. Ignore this feedback then.

11 hours ago, memo said:

It's possible to add such a link to create a new issue, but GitHub would direct you to a login page if you're not signed in. I might rename the button to "Show metadata" as I think it's important to have a way to inspect the sources, and curious users might just be able to directly provide a fix instead of just an issue report.

11 hours ago, memo said:

My concern is not to overload ST with requests, so I chose not to display images in the search screen.

Solid reasons. Understood.

7 hours ago, memo said:

 

21 hours ago, nos.17 said:

Remove the word "explicitly" from "Add to Plugins explicitly". IMO it won't mean much to end users at this point. Actually consider renaming this to "Add to install queue" (or something similar), because pressing this will not actually add anything into the plugins folder - you must then update.

What would the button say in case of a package that is already installed, either explicitly or as a dependency? In case it's installed as dependency, it can only be made explicit, but couldn't be installed or uninstalled.

I've played around a little more and now I'm second guessing my original thoughts. I do like your distinction of explicit/dependencies as opposed to explicit/implicit ... not sure why I was thinking that way. Keep the buttons as they are.

 

Also, I just noticed the 'required by' area indicates which packages you already have installed - that's a very cool idea for discoverability of related packages.

[memo 1,460]

Version 1.0.0 of the sc4pac GUI is now available on the STEX.

This marks the first stable release of the GUI, which includes all essential features for a mod manager. A massive thank you to everyone who has contributed to the development of sc4pac so far, especially @smf_16 @nos.17 @Zasco @Flann @Shadow Assassin @Cyclone Boom.

Some of the recently added features are:

• Multiple Profiles: each Profile corresponds to a Plugins folder. This allows you to manage a multiple different Plugins folders, one for each of your Regions, for example. You could set up one Profile for your normal game play and another Profile for testing new Plugins in a sandbox region. Or you could have a Profile with CAM installed and another without CAM, for two different regions. If you use the same Download Cache for each Profile, this means you download files only once, even if they're used by multiple Plugins folders. (Deleting Profiles isn't possible in the GUI yet. If you want to get rid of a profile, just uninstall all its packages for now.)
• Security: When downloading and installing executable files like DLL plugins ("code mods") or files downloaded without a secure HTTPS connection, sc4pac automatically verifies the integrity of these files by comparing cryptographic checksums. This certifies that the files you downloaded are still identical to what they were at the time of creation of the metadata, and ensures that the files cannot be tampered with by malicious actors. This is a big step-up in security for the SC4 community, even though it's a largely invisible feature. If available, DLL plugins are downloaded directly from the author's GitHub page (which features 2-factor-authentication and other security measures). Only DBPF plugin files ("asset files"), which aren't executable, can be installed without checksums. As sc4pac doesn't execute any installers, but merely extracts their files, this means you only need to trust a small number of people: the authors of DLL plugins you choose to install as well as sc4pac itself.
• Mods with complex installation procedures: It's now theoretically possible to use sc4pac just for the downloading of installer files (e.g. the 4GB Patch or the NAM installer). After sc4pac has verified the checksums, the user would have the option to execute the installer manually and perform a manual installation as usual. The benefit of this approach is that sc4pac automatically verifies the integrity of the downloaded files. This would prevent NAM 48.1-style attacks. Currently, there aren't any packages using this technique yet though, as it's only needed for plugins that require manual installation steps.
• Several smaller additions focusing on UX, such as additional filter options, better error handling or the ability to open the GUI by clicking links like sc4pac:///package?pkg=memo:submenus-dll

[Null 45 3,064]

56 minutes ago, memo said:

the 4GB Patch

The 4GB patch has a command line option, from the author's page:

Quote

 It can be used by clicking on it and choosing the file or through command line (e.g.: “4gb_patch file.exe”).

The only user interaction that requires is the UAC prompt for administrator permission on Windows.

On a related note, I recently released version 2.0 of my Startup Performance Optimization DLL which fixes a game limitation with very long file paths that prevented it from being able to load some plugins in various sc4pac packages. It also includes a fix that reduces in-game lag and increases the city load speed if you have a large number of SC4Desc, SC4Lot, and/or SC4Model files in your plugins.

[memo 1,460]

5 hours ago, Null 45 said:

The 4GB patch has a command line option, from the author's page:

The only user interaction that requires is the UAC prompt for administrator permission on Windows.

True. It can be automated, and that's exactly what the batch file included with the NAM does. Sc4pac doesn't know the location of the .exe though and doesn't execute downloaded install scripts. I don't want to hardcode special handling for the 4GB patch into sc4pac, so I think it's fine to ultimately leave the execution of the 4GB patch to the user. It's a relatively obscure case after all.

5 hours ago, Null 45 said:

On a related note, I recently released version 2.0 of my Startup Performance Optimization DLL which fixes a game limitation with very long file paths that prevented it from being able to load some plugins in various sc4pac packages. It also includes a fix that reduces in-game lag and increases the city load speed if you have a large number of SC4Desc, SC4Lot, and/or SC4Model files in your plugins.

Thank you. This is quite a remarkable improvement. The way you changed the loading algorithm complexity reminds of this story about GTA V.

I'll update the description to recommend installing the DLL.

[Jasoncw 11,933]

I was thinking about how to package my STEX files.

Packaging and uploading my BATs is my least favorite part of BATing and over the years I've simplified what I do for it. I would have assumed that supporting this would have added work for me. But adding the metadata.yaml file to one of the .zips is extremely easy. So I can only give more kudos for how far this has exceeded my expectations.

Anyway, I was thinking about how to explain metadata.yaml to users in my descriptions, since it will be a strange and confusing file for most players. I haven't finalized the wording, but I'll be adding something like "Metadata.yaml is a file used by sc4pac. It is not used by SimCity 4 and can be safely ignored." to my future descriptions.

Metadata.yaml only needs to be included in one of the zips. If my upload was "Jasoncw - Building (MN).zip", "Jasoncw - Building (DN).zip", and "Metadata.zip", with Metadata.zip containing metadata.yaml, I wouldn't need to include this strange metadata.yaml file in either of the folders that the people manually installing the files would see (they would be as un-public facing as they could be). But my understanding is that sc4pac will interpret metadata.zip as an actual version of my BAT. Would it be possible to make it not do that, so that I can use this file packaging convention?

I noticed in the documentation that you guys referenced the way I package MN, DN, and CAM versions. I hope the way I've done things made things easier for you guys and not harder! I've always tried to package my files in a clear and user friendly way.

[smf_16 1,836]

7 hours ago, Jasoncw said:

Metadata.yaml only needs to be included in one of the zips. If my upload was "Jasoncw - Building (MN).zip", "Jasoncw - Building (DN).zip", and "Metadata.zip", with Metadata.zip containing metadata.yaml, I wouldn't need to include this strange metadata.yaml file in either of the folders that the people manually installing the files would see (they would be as un-public facing as they could be). But my understanding is that sc4pac will interpret metadata.zip as an actual version of my BAT. Would it be possible to make it not do that, so that I can use this file packaging convention?

We thought about that for a moment. The idea was to allow creators to add a metadata.yaml file as a separate asset. However we chose not to pursue it because it has some other issues as well, and it isn't necessarily clearer for the users if clicking the download button shows you the option to download either "Plugin.zip" and "metadata.yaml".

We realize the current solution of requiring a metadata.yaml inside the download itself isn't ideal, but we're still working on ways around this. The idea was to initially have a working version of the integration with minimal programming needed by the ST admins itself. In the future, we hope to add the option to specify the metadata in a text field in the upload form (like how the description is specified now), but as far as I know there were still some issues with getting this to work properly.

Not only would this hide the metadata from the users, but it would also open the door for validation of the metadata before creating the upload. Currently, there is no easy way yet to know whether the metadata you enter is valid, so you need to wait to have it processed by the @STEX bot, which can take up to an hour. This means that fixing mistakes - which are easy to make for complex packages - can be a bit cumbersome.

7 hours ago, Jasoncw said:

I noticed in the documentation that you guys referenced the way I package MN, DN, and CAM versions. I hope the way I've done things made things easier for you guys and not harder! I've always tried to package my files in a clear and user friendly way.

Your content was among the easiest to backfill! It has a clear and consistent structure, and properly listed dependencies with links (which allows them to be parsed automatically). Ironically, recently plugins often just refer to the BSC Common Dependencies Pack instead of the old SC4D links, which actually made it harder to find the right dependencies, as for the SC4D links, it was just a matter of extracting the file id from the link and then map them to the correct sc4pac dependency (see for example this file).

[kergelen 741]

Hi, thanks a lot for this tool

 

Yesterday I installed SC4Pac and it works well.

Just now I tried to use it again and I get this message:

 

yesterday I downladed with sc4pac ulisse-mediterranena-transport-set to try how sc4Pac works. All works ok, and then I deleted ulisse-mediterranen-trasport-set from my plugins folder. 

Now I get this message, while I was trying to install everseasonal flora by smf16

 

What may I doing wrong?

 

And I have a problem with Opera. When I try to download content with Edge it works fine but with Opera the "download with sc4pac" button don't appear. I'm looged in Simtropolis on both browsers.

[Ulisse Wolf 4,426]

1 hour ago, kergelen said:

Hi, thanks a lot for this tool

 

Yesterday I installed SC4Pac and it works well.

Just now I tried to use it again and I get this message:

 

yesterday I downladed with sc4pac ulisse-mediterranena-transport-set to try how sc4Pac works. All works ok, and then I deleted ulisse-mediterranen-trasport-set from my plugins folder. 

Now I get this message, while I was trying to install everseasonal flora by smf16

 

What may I doing wrong?

 

And I have a problem with Opera. When I try to download content with Edge it works fine but with Opera the "download with sc4pac" button don't appear. I'm looged in Simtropolis on both browsers.

This message is an unwanted effect of the transfer between the memo channel and the Simtropolis channel.

I got the same message is the only solution is to uninstall the mod from SC4Pac and apply an update. There is also another solution but it requires a reset of the plugins folder

[memo 1,460]

45 minutes ago, kergelen said:

yesterday I downladed with sc4pac ulisse-mediterranena-transport-set to try how sc4Pac works. All works ok, and then I deleted ulisse-mediterranen-trasport-set from my plugins folder. 

The problem is that the package was renamed today (to a package name that better fits current conventions), so the old package name isn't found anymore. The sc4pac configuration stored on your local machine says "please make sure this (old) package name is installed", but sc4pac doesn't know how to install it, as the old name doesn't exist anymore.

This is still a bit complicated to resolve. Go to Settings and open your Profiles Configuration Folder. Open the file "sc4pac-plugins.json" in a text editor and rename the package

ulisse-wolf:ulisse-mediterranean-transport-set-vol1

to

ulisse-wolf:mediterranean-transport-set-vol1

Then, once you click "Update", the package will be reinstalled under the new name.

Ideally, package identifiers are persistent and shouldn't change. In rare cases like this one, there can be reasons for it though. I'll think about how to better handle this case in the GUI itself.

59 minutes ago, kergelen said:

And I have a problem with Opera. When I try to download content with Edge it works fine but with Opera the "download with sc4pac" button don't appear. I'm looged in Simtropolis on both browsers.

I suspect Opera might block a cross-origin request to GitHub, possibly for security reasons. That's where Simtropolis obtains the list of installable packages. If Simtropolis doesn't retrieve the list, it cannot display the button. Perhaps, open the browser dev tools and check whether the Console logs any errors to diagnose the problem.