Zasco

This topic is specifically for the Simtropolis sc4pac channel. For sc4pac related questions, use the associated topic. These questions should have been in that (the later) topic: ↓ sc4pac only handles required dependencies (and variants). If you have recommended dependencies, you can put them in the package description. Here's what you can do: The package description supports Markdown, so you can hyperlink the name of the plugin(s) you recommend. If the plugin has an associated sc4pac package, you can put it's package name inside back-ticks (``) and a link to that package will be created on the sc4pac main channel website (example here). That link will also be handled by the GUI. (I'm not sure how well cross-channel is supported however... @memo) Uninstall what? sc4pac? A package? Please be more specific... I also "datpack" some of the plugins I use, mostly the ones with loads of files. Here's what you can do: You can set a folder other than your default ".../plugins/" folder as the one used by sc4pac. In fact, you can have multiple folders used by using "profiles". For manually installed plugins, use custom odd-numbered folders. Then, every time you update your packages, you can "datpack" that folder into your real ".../plugins/" folder. This solution however requires you to either manually install "root-installed" plugins (such as DLLs) or "symlink" them... The other solution I came up with is to make a custom channel with custom "datpacked" source assets for the plugins I need to. I only need to write the asset part, as long as I keep the same asset ID. The right channel load order will override the default config. If you need ALL of your plugins to be "datpacked", I would suggest you to go with option 1; otherwise option 2 may have a bit more overhead on the short term, but less on the long...

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: I agree. Thx!

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.

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.

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.

#11. 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? Of course. The idea was simply brought up to me by the "BSC-VIP Girafe Urbanpack vol01" plugin.

I know, but maybe it means the source code has to be changed to allow this. I can open an issue on this, but I don't quite know how to formulate it. I'll review it asap. I agree keeping this feature is important! Maybe the solution is to have both? And it wouldn't be as complicate to integrate to the code and as computing heavy as versions resolving. I think in the case of conflicts it's pretty much unavoidable as one package has to "be aware" of another to declare a conflict with it... In such case, I don't think it's coupling as changes in one wouldn't affect the other. Souldn't "180-flora" be renamed to "180-mmps"? "flora" is a bit restraining for what might belong in this subfolder... Allowing multiple sources for an asset would be great for redundency. See for instance the plugin right below. It is hosted on both Simtropolis and SC4E. What should be done following recent update of this file?:

Just to let you know, I've already implemented it, I just didn't commited/pushed it yet. I'll show you in PM.

Respectfully, I don't agree with either. You may however be more qualified than me to adjudicate on this. Here is why: It makes Gizmo's "secondary". Why this way and not around? What if a better and more modern "dark night" mod is released? Would then @SimFox's be relayed to secondary? With option 2, @SimFox's metadata would have to be refactored everytime a new "dark night" mod is added. All of this is code smell (on your approaches) in my opinion. I think an approach like the following would easily handle this and ensure decoupling: variants: - variant: { nightmode: maxis.default } assets: - assetId: "group-package-mn" - variant: { nightmode: simfox.day-and-nite-mod } assets: - assetId: "group-package-sn" - variant: { nightmode: gizmo.day-night-mod } assets: - assetId: "group-package-gn" I could have shortened the variant values to only the provider, but this way allows for a provider to release a new night mod (no matter how likely it is). Please note dots can be replaced by colons in the above example. That's in part the why of my approach. Coupling may not be a problem here and now (<1000 packages), but may become overwhelming later on (>10000 packages). The above example doesn't take that into account. However, this one does: variants: - variant: { nightmode: standard } assets: - assetId: "group-package-mn" - variant: { nightmode: dark, nightmode-mod: simfox:day-and-nite-mod } assets: - assetId: "group-package-sn" # Or "group-package-dn" - variant: { nightmode: dark, nightmode-mod: gizmo:day-night-mod } assets: - assetId: "group-package-gn" # Or "group-package-dn" This way it wouldn't require packages to define any "nightmode-mod" variant but would still allow it which would also allow for different "dark night" assets. * Note that the linter of the current implementation of sc4pac in 0.4.6-SNAPSHOT will accept this, but not the channel builder. Why is the "conflict" field of string format? Shouldn't it be an array like "dependencies"? This way, sc4pac could check if any two conflicting packages are installed and throw an error.

How would you handle the addition of the Day-Night Mod by Gizmo? The "nightmode" variant currently has "standard" and "dark" defined. This mod also is a dark night mod. Adding a new variant would mean refactoring of every already written package to add it. Otherwise it would then throw a linting error. I think it also reveals coupling, meaning a package has to be "aware" of every other package.

Unless it's something you can fix with your DLL magic.

@memo is likely better suited at answering you, but here's my try: Not it's not. In fact, it's quite the opposite. Channels can be complementary or concurrent, depending on metadata and load order. Mine is an extension of the default channel; it only provides packages not listed in it. No you don't. You can have both channels registered simultaneously. In fact, you can have an unlimited amount of channels registered. Yes, packages from one channel can depend on others in a different channel. Although, you need to have that "different channel" registered for it's metadata to be fetched. More details about channel registering here.

For those interested, I just launched my own channel: Zasco's sc4pac channel * Follow the link for more details.