221 posts in this topic Last Reply September 21

Recommended Posts

Tiger, I share your intuition: if we raise the legal topic, we'll surely end finding that EA is the owner of everything created, even if they hadn't done anything to create it. As there is a comfortable legal statu quo, we shouldn't try to alterate it, but to play nice to it, and accomodate our solutions to what can be done on those standards. This, as Fantozzi says, has nothing to do with the due moral aknowlegdement and respect for communitarian rules, that operate independently.

I'm also with Fantozzi on worrying that automating and straightforwarding the installation process could reduce the incentives to tinker with the custom content. What keeps this community alive isn't just people playing, but people actively engaging on the continuous upgrading of the game contents.

That's why I'm advancing a proposal for a modular system, able to automate and ease the downloading and installing, but keeping all the sources open for users to modify and change. To give a simple example, I would prefer a method that installs non-DATpacked versions of the plugins and prompts the user to DATpack, making transparent where each element is on each folder, and keeping them easy to access and alter. It's something that Doc Rorlach's DIC indeed does, saving an uncompressed copy of the plugins folder to be always able to modify what's DATpacked.

It's the same with dependencies. The APT system (and it's Windows versions, Chocolatey, apt-cyg, NuGet, etc.) all respect the same modular principle: deliver the most simple and disgregated possible packages, link everything as a dependency and let the user to have the ultimate decision to what to install, always providing the optimal setup as the default one.

So, as a mock-up, if the MODPACC would work like APT, we would see something like this (using @T Wrecks last relot as an example):

#on the simtropolis repository, we would have called it sc4-irm-h2ochemistry#the user types (or pastes from the web):
modpacc install sc4-irm-h2ochemistry #if we do an application called modpacc#or
choco install sc4-irm-h2ochemistry #if we use, for example, chocolatey as the application#either way, it would display what is going to be downloaded
MODPACC will install sc4-irm-h2ochemistry on D:\\docs\Simcity 4\Plugins\ (default directory),
you can change it using -folder
#as the packages would include a declaration of their dependencies, the application can find and #offer to install them automatically
sc4-irm-h2ochemistry has dependencies, they will be automatically installed: sc4-irm-basepack
sc4-matheman-h2ochemistry sc4-bscprops-jestarr1 sc4-bscprops-jestarr2 sc4-bscprops-jestarr3
sc4-bscprops-jestarr5 sc4-bscprops-jestarr8 sc4-bscprops-sg1 sc4-bscprops-gascooker1
sc4-bscprops-dae1 sc4-bscprops-cp1 sc4-bsctex1 sc4-bsctex2 sc4-bsctex3 sc4-ncd-railmegapack
If you dont want to get dependencies installed, you can change it using -only
#also, the application can look for recommended packages, including cascading ones (as the PEGMTP#superpack in this case)The package reccomends sc4-irm-id-addon1 sc4-irm-im-addon1 sc4-irm-id-filler1 sc4-irm-im-filler1
sc4-irm-iht-filler1 sc4-heretic-irm-diagfillers sc4-irm-logisticfiller sc4-peg-mtpsuperpack
Do you want to install them?[y]Yes[n]No(default=yes)#we accept the default settings and launch the installerDownloading sc4-irm-h2ochemistry v.1.0.0from http://stexrepo.simtropolis.com/171.67 kiB 100%Downloading sc4-irm-basepack v.1.1.0from http://stexrepo.simtropolis.com/8.53MiB100%[...]Downloading sc4-matheman-h2ochemistry from http://repo.simcityplaza.de/435.69 kiB 100%#it can download from different sources[...]Downloading sc4-ncd-railmegapack...
MODPACC detected that sc4-nam-rrw is installed, replacing sc4-ncd-railmegapack with
sc4-rrw-ncdtexture-update
#and looking at the list of installed packages, can detect conflicts and superseedingsDownloading sc4-rrw-ncdtexture-update v.1.0.0from http://lex.sc4devotion.com/3.37MiB100%[...]Decompressing sc4-irm-h2ochemistry on
D:\\docs\Simcity 4\Plugins\IRM\IRMExpansion\I-HT SFBT H2O Chemistry(OM)\...4 files decompressed
[...]
MODPACC sucessfully installed sc4-irm-h2ochemistry and its dependencies on your computer.Do you want to DATpack your Plugins folder?[y]Yes[n]No(default=no)

As you can see, the process is almost fully automated but the user has tight control over it, and gets to know where to look if wanting to change things. With a graphic interface it would be the same, but nicer...

Share this post

Link to post

Share on other sites

Lovely! I was just saying this at the same time you were typing your reply.

And the scripted install is looking more and more like a very good way forward.

As I said, it's none of my creation, the DIC accustomed me to it and its a very smart approach for servicing the installation.

Two things I left out of the example for lack of a more complete case:

1. Proper ModPacks, which are called metapackages on APT. So for example, if I want to get all the Industrial Revolution Mod installed, I would be able to run

modpacc install sc4-irm-full

which is an empty package with all the IRM packages signalled as dependencies

2. Configurable installations: Many relatively complex mods have options; some of them, as the driving side, are better to left unattended (so the application checks the language file used by the game and installs RHD or LHD accordingly), but some others, like cosmetic textures, should be selected by the user.

APT uses a command-line dialog to ask the user (see thumbnail at the right), but NSIS installers (as the ones done by @rsc204) are more clear and friendly, so we should try to strike a balance of useability and ease of programming there.

EDIT: and a third one, updating and upgrading!

APT has this two neat functions, that respectively check for updates on the repositories (finding new packages and changes on existing ones), and installing new versions of already installed packages. So, for example, I was using the RUM for RRW like 6 months without updating it, and had the annoying maxis textures on all viaduct curves. With the MODPACC, it would have been as easy as:

#entering
modpacc update
MODPACC is checking for changes on the registered repositories:
http://stexrepo.simtropolis.com/...5 new packages and1 updated package
http://lex.sc4devotion.com/...3 new packages and1 updated package
[...]There are upgradeable packages installed.To upgrade them, run modpacc upgrade
modpacc upgrade
The following packages can be upgraded:
sc4-rum-rrw (you have version 2.0.0, last available version 4.0.0)Do you want to upgrade?[y] yes,[n] no (default yes)[...]

Share this post

Link to post

Share on other sites

@matias93 that looks great. I have now talked to @Begabee via email and he has this to say

Quote

Oh yes Cathy, by all means go ahead. I am on the verge of two development releases within a week, and have an entire site to migrate to the clouds so I am afraid I am not going to be in a position to throw in my pound for a wee while, but will happily join up in about two weeks. Please remember though that at this point, although it "works', it is just a sandbox app and nowhere close to being suitable for release in its present form - its best purpose at this stage may be as a humble idea generator. Ideally, I think the solution would be a cloud hosted app with a single hosted database maintained by a small group of experts which would allow users to get on and play the game instead of spending the vast majority of their available time shepherding plugins into catacombs (subject of course <groan> to all the legalities).

So now to some pictures with Begabee explanation for each one as we go ...

Main Screen

Picture No. 2 is

Quote

I added some additional categories to help with finding desired items. These may be searched in filters – more later.

Each plugin may contain any number of images. Apart from identification, also useful for documenting things that you may have found out when using the plugin. Useful for NAM for example.

Any number of readmes or notes may be associated with each plugin .

Casual comments or self reminders may also be added that pop up when hovering over the item.

Drop down provides for rapid location and selection of a plugin,

Picture No. 3 is

Quote

Or a more detailed list selector that includes pictures is also available, a click on a picture brings up a full size image for better identification

Picture No. 4 is

Quote

Or one can view in a spreadsheet type format

Picture No. 5 is

Quote

Clicking the Docs button brings up the selected readme or document (only one available in this case)

Picture No. 6 is

Quote

Filters provide search facilities and support partial search, therefore, if you are looking for houses for a slummy area you would simply type “house” in the plugin description field and click on Slum in the wealth section (and probably Plop as well) and you would be presented with all plopable slummy houses to choose from. If you wanted OLD slummy houses you would also click the Historic button in the era section.

“All plugins” would include deprecated or superceded lots,” Active plugins” would only return current versions.

Picture No. 7 is

Quote

Any number of dependencies can be associated with a lot

When a lot is selected to add to a Plugin set all dependencies are automatically included, more about Plugin Sets later

Picture No.8 is

Quote

A Plugin set is a selection of Lots, Mods, Dependencies etc that are built into a plugin folder for use with the game. 10 selection sets are available.

For example, Set 8 is shown below and is a selection of Natural Items. I selected these by filtering the database to provide a list of all such plugins available, and then picking out those that I liked. Once my selection is complete, I click the BUILD button and the program extracts all files and associated dependencies to plugin folder number 8.

Picture No. 9 is

Quote

Now if I would like this Plugin set to be the currently active Plugin set, I can change this to be set 8 (restart of SC4 required of course).

Picture No. 10 is

Quote

I can also add a plugin to the current set by locating the desired plugin (is on the main screen) and Adding (restart required)

Picture No. 11 is

Quote

If the plugin currently shown in the main screen has been used in any Plugin sets, it will be ticked, The current plugin has not been selected to any sets at all.

See next Post .....

Edited July 15 by catty-cbsorry for delay, my site decided to stop hotlinks again

Share this post

Link to post

Share on other sites

Continuing on from my previous post, I have checked above post in a smart phone and all the hot links appear to be working, what an absolute pain hotlinking protection is and I say this as the website owner concerned, if the links stop working then I'll have to attach the pictures to the post.

There should be a total of eleven pictures, hopefully I have matched Begabee explanation up to the right picture.

Share this post

Link to post

Share on other sites

I admit the scripted ways look very neat and very user friendly as well as automated. From an end user point of view, no doubts at all there...

But I do have some niggling questions: in light of the fact that everything is becoming more expensive to run...here I see more and more donation messages for instance, it's a fact that the webmasters - on whom we all rely - are feeling the pinch. Also, unless the solution is quite a graphical gui, it would seem to heighten @Fantozzi's concerns about anonymity and loss of getting to know the author.

So the questions are:

1) How does this automated script to install a plugins suite add real, monetary value to the websites to ensure that the websites remain an ongoing concern? It's great for the end user, but I don't see value for the webmaster (and I might be missing something).

2) These files will increase the download volumes, bandwidth and hence cost - I don't see how a user could be charged to use the solution, or how you could make a 'starter pack' plugins from this unless the gui is very limited from the get-go

3) I assume one would need to be logged in to access the modpak feature; that removes some of the existing revenue stream - a large number of users just download without being logged in and have to sit through an advert to do so.

4) Who is going to reclassify all of the STEX files to make the searches that build the plugin packs meaningful? The files date back to last century and it has always been an open exchange, so varied stuff and indeed varied results. Also the script at the top of the page would rely on a plugins folder not being datpacked (or any other end-user created dats)

5) Going back to an earlier example, where a pack contains work from a number of authors, what is to stop an inactive user logging in once more, seeing that their work is now part of a pack which is being pinged by automated scripts and saying 'heck no! I didn't sign up for this' and locking, deleting, or replacing their files with a text pad...while I believe the delete option isn't available in our current site, updating files to a simple text-pad has been done before - and en masse.

6) How does it fix the older, non-functioning files; to give an example - let's say the community wanted a dutch-themed pack.......There are several makers of dutch bats and lots who come to mind - one was a prolific batter (he has 5 pages of stuff) whose buildings are among the most exquisite bats ever, ever made, but only about 30% of them actually work in game. The rest are all bugged and either don't show up or CTD. If you want to use his work, you have to mod it yourself. On an automated model, you would be installing bugged files into a plugins pack. How does this add value to a user and how could you charge a nominal amount for it?

It certainly appears that while scripts are incredibly easy for the end user, it looks like a lot of work getting all the files aligned to a script and then somehow being able to put the brakes on bandwidth as well as somehow engineering it as a 'value' proposition, like the CD is now (i.e give $, get gift). Perhaps, @catty-cb, @cycleboom or @tarkus might be better placed to answer some of these questions from a webmaster pov.

Edit: The last thing any solution should do is have the unintended consequences of cannibalizing Dirk's existing revenue stream (that is the sale of CDs and the ad revenue from anonymous downloads) - any solution must complement these - because it will drive up costs associated with hosting the site and bulk downloads.

Share this post

Link to post

Share on other sites

I am a proponent of the KISS principle (Keep It Simple Stupid). I feel like we've come to a consensus regarding the repackaging and distribution of content already submitted to both the STEX and LEX. Authors that are no longer active in the community will get rightfully credited, and Authors that are still active can be contacted. I seriously doubt that anybody will have an issue with seeing their content become part of a 'starter kit' that will keep SC4 up and going for years to come. If they do, well, there is so much content available it won't matter if a few members choose not to participate.

That said, I feel the quickest way to achieve a 'starter pack' would be to build it and release it as a single download. It could certainly be a way to spur donations like the current CD's are. Even if we go the scripted route, there is going to need to be some members of the community that get together and mod and lot this project.

And that is where the heavy lifting really is. I think the reason this topic got started was to introduce casual or new players who just wanted to jump into SC4 and have all the stuff ready to go. A 'starter pack' mod is going to need some serious work and won't be achievable through an automated system alone.

Share this post

Link to post

Share on other sites

Regarding SC4D, we have a way of putting the brakes on bandwidth consumption built right into our exchange software, thanks to @CasperVg. There's a daily cap, and there are different tiers of it--there's one for regular users, as well as one for donors (which is about triple the regular user cap). That would be our mechanism for keeping people from being gluttonous at jeronij's expense. We can adjust the caps if it appears there's a need to do so. If, on the ST side, things are being directly downloaded from the STEX, there's obviously the AdFly routine in place already, to recoup some costs.

Now, if we start going to a user-side client, it depends in large part on how exactly it is going to be accessing the files on the exchanges, if it'll be automatically registering an account to use the tool on the exchanges, or if it'll take in the user's existing accounts and work that way. The LEX should automatically still cap things that way (there already is a LEX Downloader tool out there--wouanagaine did the first edition, Casper made the newer Java version), and while I don't know all the mechanics of the current STEX setup, I'm not aware of there being any sort of quota on how much registered users can download from here during a certain timeframe. We could, in theory, code a cap on STEX bandwidth usage into such a tool if needed, which could somehow be upped for donors, by providing them with a validation code of some sort once they donate to ST.

Going back to the model of packs on the exchanges, there's also the question of whether or not packs like this would actually increase bandwidth usage. As far as how bandwidth would be counted by a webhost, it's my understanding that there'd be no difference between someone "binge downloading" 2GB of plugins in the current setup, and someone downloading 2GB of MODPACCs. 2GB is 2GB. The effect on the server may end up being different, downloading 300 small files versus 5 much larger files, but it would make no difference on the actual bandwidth meter.

Granted, though, I'd imagine there would probably be a "rush" on the MODPACCs when they first go live, similar to what one would expect when a new NAM version is released. The first "monolithic" NAM (NAM 31.0 in March 2013) did put a bit of a run on SC4D's bandwidth. That initial rush, however, does level off and plateau, and given that there's not likely to be regular updates to the MODPACCs like there is with the NAM, that wouldn't be a recurring pattern (unless there's an article in the gaming press that causes a sudden, brief surge).

There is also the ModDB route--that'd mitigate bandwidth concerns, but it would potentially cut the traffic to the SC4 sites and exposure for potential donations.

are the community life blood, they bring people in and once here they usually go rummaging thru the site, without them how many visitors would the CJ's get or the creators getting comments from people.

Whatever path we take its got to be doable and long-term, starting something off and then having it die because there aren't enough people who are willing to keep it current ... see MEGAMOD over on the Banished sites who also tried to come up with starter pack for the the users to just download and is now very out-of-date.

If you take BegaBee program as an example of what's possible, you will note he's built in the ability of having 10 plugin folders which you can swop around and add more plugins into it if you want ...so (and this isn't me saying this is the way we should go) ... if we went down this path

Folder 1 - The best 100 plugins (plus dependencies) at SC4Devotion

Folder 2 - The best 100 plugins (plus dependencies) at Simtropolis

Folder 3 -

Folder 4 -

And so on, with each site deciding what they want to showcase or alternatively

Folder 1 - The best 100 Commercial Hi-Rises (plus dependencies)

Folder 2 - The best 100 ..............

It doesn't have to be big, just has to get people started and wanting more and not wiping out the site bandwidth limits in the process.

Share this post

Link to post

Share on other sites

I have my doubts that site traffic would take a hit from hosting this stuff offsite, heck it might even do the opposite. We could have links on the download page / documentation pointing to the community's sites.

As @SimCoug mentioned, we need to keep things as simple as possible for the first package. This undertaking would still involve a lot of work but can be used as a trail run / test for future packages. Call it the guinea pig if you will.

We're doomed to fail if we want to please everybody. For now, I think we need to turn down the scope of this project and start small.

Share this post

Link to post

Share on other sites

That said, I feel the quickest way to achieve a 'starter pack' would be to build it and release it as a single download.

My idear was - to make the starter packs only accessible via a tutorial page that would explain what's in there, what is good for, how to use it and who were the original creators.

Imho - what new players really need is a guided tour through the 'sc4 museum' not simply all exhibits collected in one room.

I also agree on this for another reason - we should always figure out things the way that community as a whole can survive us, the individual player. What if sites move (to another country, to another technology, to another dimension in space-time), get a new software and all the links need to be updated . Who will be responsible for the client software in five years? Who will care for this if we are gone?

The more simple the solution is - the higher the chance someone will care for it in the future. So the question might be also: how many people will be able to nurse a client software if we are gone, how many people will be able to nurse a simple webpage and zip-packed file if we are gone?

4 hours ago, Haljackey said:

For now, I think we need to turn down the scope of this project and start small.

I absolutely agree. First step first. We might block other developments with what we are doing. I think @T Wrecks showed a good way. Let's first think of the data we can pack together. If I remember right, he mentioned girafe trees. And if I remember right @rsc204made some additions/correction to them so all of them are mmp and prop. So to collect those things together in packs first of all - there is spread out content and fixes by different authors are even spread out more.

To do this work first doesn't exclude to make a client later. It doesn't exclude the creation of starter packs. So as this doesn't block further developments - imho this is the action to start with first. If you make the client the first task you most probably will block further developments regarding consolidation of content.

Share this post

Link to post

Share on other sites

I have my doubts that site traffic would take a hit from hosting this stuff offsite, heck it might even do the opposite. We could have links on the download page / documentation pointing to the community's sites.

As @SimCoug mentioned, we need to keep things as simple as possible for the first package. This undertaking would still involve a lot of work but can be used as a trail run / test for future packages. Call it the guinea pig if you will.

As of right now, because the NAM Team's FTP account for ST has been down since sometime before the release of NAM 35, the NAM downloads here on the STEX actually point over to ModDB, and ModDB is presently beating SC4D by a 4:1 ratio. The STEX pages are getting a lot of clicks, however (the GOG article likely helped a lot), but I don't really have reliable stats on them due to the situation.

That's also obviously skewed by the current logistics, however, and my older stats do support your theory. I do have my figures for NAM 33 and 34 handy, both of which were releases where the NAM was directly hosted on the STEX. Both ST and SC4D beat out ModDB in terms of their share of overall downloads--ST by a wide margin, SC4D by a slight one. With NAM 34, the market share three months after release broke down to 60% ST, 25% SC4D, 15% ModDB. With NAM 33 (which only lasted a month as the "current" NAM release), it was 56% ST, 24% SC4D, 20% ModDB.

One positive with ModDB is that the mainstream gaming media does actually browse around there, and the NAM's presence on there did actually start getting them to pay some attention to the SC4 community in late 2013. Rock, Paper, Shotgun picked up the NAM 32 Pre-Release, and then the full release of NAM 32 ended up being PC Gamer's "Mod of the Week"--both outlets mentioned and linked to SC4D in the process. While the gaming media had kind of been forgetting we exist since C:S was released, and became a bit of a darling for them, we are starting to get on the radar again, evidenced by this Kotaku article from earlier this week.

The NAM usually goes straight to #1 on ModDB whenever there is any sort of press about it outside the usual SC4 community outlets . . . I'd imagine the creation of these MODPACCs would be pretty big news, even now, and if we can leverage it the right way, we might be able to parlay that into increased traffic here.

I'm also in agreement that we need some sort of a build put together first. A rolling release of different types of packs might also be a good way to sustain interest in the project over time.

3 hours ago, jaredh said:

You might actually get MORE ad revenue. You bake ads into the download and installation in the script program.....

That's certainly a possibility--links all over, at the very least. I think we can use this as a gateway, if we set it up right.

2 hours ago, Fantozzi said:

The more simple the solution is - the higher the chance someone will care for it in the future. So the question might be also: how many people will be able to nurse a client software if we are gone, how many people will be able to nurse a simple webpage and zip-packed file if we are gone?

---

To do this work first doesn't exclude to make a client later. It doesn't exclude the creation of starter packs. So as this doesn't block further developments - imho this is the action to start with first. If you make the client the first task you most probably will block further developments regarding consolidation of content.

The webpage and zip-packed file is obviously going to be easier to keep around. @simmaster07 actually designed a pretty awesome PHP-based online NAM installer back in the NAM 29 era . . . sadly, however, it's not around anymore, as he didn't have a permanent place to host it. I'd also agree that the existence of the MODPACCs and a client aren't mutually exclusive . . . arguably, they're both solutions we need. The MODPACCs can be for an entry point, and the client can be for when we get them hooked on SC4 custom content.

Another comparison would be the RHW ramp interfaces. We have two newer overrideable implementations of them, the draggable versions (DRIs) and the FLEX piece versions (FLEXRamps). We intentionally maintain both . . . some users prefer not having to reach for the menu, but others don't want to memorize the drag patterns, and prefer to just plop the FLEX pieces down. Sometimes, it's necessary to have different points of access.

Share this post

Link to post

Share on other sites

I think there is a general consensus that packaging together all the Maxis fixes and stuff that makes the game work as it should, would be a high priority. Why don't we simply start there, no new content per-se, but a simple download once and you are done package that gets all the fixes into the game. We could also try to bundle with that all the add-ons from Maxis (new landmarks) as an option. Not forgetting things like the SC4Fix.dll and maybe Buggi's Extracheats too. It is possible to include into an installer the option to DAT Pack the I-HT fix whilst we're at it, but as the CAM 2.0 installer proves, that needs a lot of testing to ensure it works with all setups. For me, that's the first thing almost every new user would want to have, before custom content muddies the waters.

Here's the problem part, lots of people talking, who's going to be doing this stuff? I could take care of the installer, it's not actually that difficult. But it would need people to test it and provide feedback, that's something in my experience that rarely happens.

However, the one benefit is that I had already started on such a package and have a lot of prep-work already done. But I would want a firm green light before resuming work on it, so I'd be certain having done the work, that I wouldn't be blocked by restrictions on re-distribution. In addition to some assurances that there would be help with testing, so we could check various platforms and variants of SC4 would all work with the installer. It's not a one-man job by any means if this is to work. Because if it doesn't work reliably, we're just creating more problems, not less.

The good part is that this is a one-time job, unless suddenly we find later new fixes that need to be added. I'd be happy to open-source and upload the NSIS code and installer build though, so anyone could in theory update it later on if need be.

@Fantozzi makes an excellent point though that this shouldn't be simply a bunch of files for installation. It should be linked from a tutorial that explains what the pack does and links out to additional information. For example explaining how to use/setup the command line switches. Since nearly everyone should be using them, if only the -CPUCount:1 line to prevent CTDs. It could also link to topics on setting up the best graphics for SC4 (DirectX), explaining the rendering options, limitations and showing how to fix the common problems. So any new players have a one-stop shop for getting their game running optimally and patched. Once we see how that option works in practise, we can start to think about expanding such packs to cover custom content. But I do think massive packs are a disservice frankly. Trying to have "localised" content packs may be very useful, but if there are going to be many, we need a solution to avoid duplicate dependencies.

Trying to index-link all the existing content is a job that would take a herculean amount of effort to realise, idealistically I approve, practically I have strong doubts it's achievable. That said, I do recall once saying, if we don't ever start, we'll never achieve anything. This "it can't be done" way of thinking has for too long been stopping any attempts at progress towards what must surely be the most ideal solution to the worst problem of the community. However, to do it right would not only take a lot of work and a long time, it would require absolute destruction of the notion of rights over how a creators work is distributed currently. We, the community must have the rights to re-package as is best for everyone, not the creator. Feeling idealistic, let's go mad and right for the best solution possible, pie in the sky thinking if you will...

Some software that knows the IDs of everything and can download just what you need, all whilst ensuring your plugins folder is always adapting to those requirements. If we started off with limited support for a bunch of just the key dependencies, it would be a start at least. Expanding that to everything would be a big deal though time-wise. What I'm thinking of is doing away with dependency packs altogether and indexing just the single model/props by splitting them up. Filenames would be IDs only, so duplicates would sort themselves out. The application would just keep the non-packed files somewhere and when things changed, re-datpack a new set of files from the vast number of individual ones. Content you download would work with this software and be downloaded from the exchanges as it is now. Only you'd run the download through the application which would ensure you had everything you needed from a central repository. Not to mention, bandwidth (much more expensive than hosting) would be limited to a much smaller amount of just the specific files needed, it would be a huge improvement in efficiency, making it cheaper to run. It would also be a no brainier to compress the living heck out of everything for storage/downloading and have the server and client side handle those operations so they are invisible to the end user.

Of course the problem with such a solution is that we create a two tier-system, the old way and the new. We'd probably need to separate that content which works with the new system from the old. But over time we'd be able to build something that will be infinitely better and deal with all these problems once and for all re: dependencies. It just requires a new category on the STEX/LEX for files designed to work with the new system. Only the dependencies would change in terms of how they were hosted. It would also require tools that would work with the new system. For example some modification to SC4 PIM-X so it could spit out the files automatically to work with the dependency manager app.

The great thing about a two tier system is that we don't have to ditch how we used to do things to get it off the ground. The two options could always exist, those who just want the easy life would be restricted to using the new compatible content only, but it'd be a start. Those who want flexibility and hate change could just continue to do things the old way.

Whilst a lot of this is really ignoring the huge amount of work and change needed to realise it, quite deliberately I might add. I can't think of a better solution and if we are going to invest a lot of resources into any such project, why do it in any other way but the most optimal one? Lets at least reap the most rewards for our efforts. So the real main barriers would be summed up as:

Designating a host for this new dependency content. Finding a revenue source for the costs of hosting/distribution.

A software developer who can make the client side and server side software a reality.

Someone with the knowledge to create or adapt a tool like SC4 PIM-X so lotters/modders aren't overburdened from working with it.

People willing to devote their time to index and modify the files to work with the new system.

A consensus form the community guardians that content should be freed to make things better for the community. Rather than simply worrying about creators rights.

A lot of hurdles, sure. But, I believe it could work and would be great for the community if it did.

Share this post

Link to post

Share on other sites

I would advise against trying to outright adapt apt, chocolatey, npm or any package manager for Linux distributions and software tools. These are all specialized for distributing libraries and executables for systems or source code for development and carry a lot of complexity that would make it difficult for community members to contribute to its development and adoption.

It shouldn't be difficult to implement a basic package manager for our purposes in a cross-platform language like Python over several stages. We can start something extremely basic and work our way up to more supported use cases. I have a possible roadmap for this, but this starts to move away from the topic of distributing modpacks and becomes an entire discussion on actually implementing a package manager for SimCity 4 mods.

Share on other sites

1) How does this automated script to install a plugins suite add real, monetary value to the websites to ensure that the websites remain an ongoing concern? It's great for the end user, but I don't see value for the webmaster (and I might be missing something).

To address this concern, I like the concept @Tarkus proposed in the next quote.

10 hours ago, Tarkus said:

We could, in theory, code a cap on STEX bandwidth usage into such a tool if needed, which could somehow be upped for donors, by providing them with a validation code of some sort once they donate to ST.

A 'Pay for Convenience' scenario that seems like it would be fairly straight forward to implement.

11 hours ago, SimCoug said:

I am a proponent of the KISS principle (Keep It Simple Stupid).

This is a good thing to keep in mind no matter what your doing.

9 hours ago, Haljackey said:

We're doomed to fail if we want to please everybody. For now, I think we need to turn down the scope of this project and start small.

You are absolutely correct, you can't please everybody. Normally, the sweet spot is when nobody is 100% happy.

4 hours ago, Fantozzi said:

The more simple the solution is - the higher the chance someone will care for it in the future. So the question might be also: how many people will be able to nurse a client software if we are gone, how many people will be able to nurse a simple webpage and zip-packed file if we are gone?

So true, no one lives forever.

4 hours ago, Fantozzi said:

To do this work first doesn't exclude to make a client later. It doesn't exclude the creation of starter packs. So as this doesn't block further developments - imho this is the action to start with first. If you make the client the first task you most probably will block further developments regarding consolidation of content.

It does make sense to stock the shelves before you put out the 'OPEN' sign.

41 minutes ago, Tarkus said:

I'm also in agreement that we need some sort of a build put together first. A rolling release of different types of packs might also be a good way to sustain interest in the project over time.

Rolling releases is a great idea, it should sustain the interest of users if it's done with some regularity. And your offering compelling content.

31 minutes ago, rsc204 said:

I think there is a general consensus that packaging together all the Maxis fixes and stuff that makes the game work as it should, would be a high priority. Why don't we simply start there, no new content per-se, but a simple download once and you are done package that gets all the fixes into the game.

There seems to be some consensus on this point and since I am almost finished a project that I think will do this for Linux users, I have to agree.

33 minutes ago, rsc204 said:

@Fantozzi makes an excellent point though that this shouldn't be simply a bunch of files for installation. It should be linked from a tutorial that explains what the pack does and links out to additional information.

This would help new users and address concerns of giving credit where credit is due.

33 minutes ago, rsc204 said:

For example explaining how to use/setup the command line switches. Since nearly everyone should be using them, if only the -CPUCount:1 line to prevent CTDs.

Also part of my current project, I plan to include a tool to create a launcher for the user.

34 minutes ago, rsc204 said:

So any new players have a one-stop shop for getting their game running optimally and patched.

This is what drove me to start my project. It was also suggested by rsc204 after I posted my commandline tutorials.

34 minutes ago, rsc204 said:

Trying to index-link all the existing content is a job that would take a herculean amount of effort to realise,

Truly an enormous amount of work. I think the KISS principle may have to be applied here and Fantozzi's thoughts about after we're gone. I like the pre-packaged zip file approach mentioned earlier.

Share this post

Link to post

Share on other sites

The last thing any solution should do is have the unintended consequences of cannibalizing Dirk's existing revenue stream (that is the sale of CDs and...)

Oh, there we go. What if these themed, organized and easy-to-install collections are released only as DVDs for donors, using the same terms as the earlier STEX collectors' discs? We would create a revenue stream instead of killing one.

Share this post

Link to post

Share on other sites

Trying to index-link all the existing content is a job that would take a herculean amount of effort to realise,

Truly an enormous amount of work. I think the KISS principle may have to be applied here and Fantozzi's thoughts about after we're gone. I like the pre-packaged zip file approach mentioned earlier.

I don't see why we should avoid developing a package management system for content just because we plan on making starter packs. These are two totally independent efforts that can happen in parallel, and I'd go so far as to argue that the package manager is an even more pressing concern. Once users try to install content outside of these prepackaged sets it becomes exponentially harder to keep track of dependencies and conflicts while also trying to maintain a folder structure that lets you keep track of what the heck you downloaded in the first place. Focusing only on the latter could just lead to people sticking only to starter packs (which could conflict with each other anyway) at the expense of other individual releases.

Share on other sites

As I see it, the concept for APT type system (following @matias93's post here) would be the ultimate universal solution for distributing content. Bridging the gap between both accessibility and ease of use. Greatly simplifying the process of batch installation -- that's what this is all about. Therefore as such, it should leave no stone left unturned. If this is the way to go, it needs to cover all the main aspects of plugin management.

The whole incentive aims to reduce the steps needed to add BATs, lots & mods in bulk. We want to make it easier for everyone involved. Whether a newcomer to SC4 or a veteran player. People want to have the option of adding custom content, without going through the arduous and headache-ridden task involving dependencies and testing for conflicts, binary searches etc. The mise en place would be done beforehand, and then the system takes care of the rest. After all, that is the main appeal of fast food restaurants...

I imagine a key benefit is it'd be relatively simple to modify the master list for each pack. Effectively being a central reference and set of instructions. Adding new files accordingly, and the same if needing to point away from obsoletes.

By sourcing the original files, something worth considering is if authors decided to release updates. The STEX (at least) uses versioning, where any previous revisions are saved and are by default still available for separate download. We'd need to ensure should any given file be updated, the system retrieves only the version it expects. This would be the one incorporated inside the MODPACC, already checked for compatibility with the others included. Any changes would need manually approving for inclusion. Then the instruction commands could be altered, pointing to the new version and any additional dependencies. The authors supply content, and those tasked with arranging the packs determine how it gets compiled. Otherwise the more extra variables, the greater chance of all sorts of potential conflicts and chaos. Without cohesion, it'd defeat the purpose.

For the user, the process of updating ought to be as simple as re-running the tool, to synchronize with the pack's contents. Removing obsolete files (in the modus of Cleanitol), and replacing them with the newly released ones. For the sake of bandwidth and convenience, it'd be grossly inefficient to re-download the entire content set more than once per installation. Above else, all this needs to revolve around simplicity. Streamlining at both ends of the spectrum.

Going down this route, I'm very much in favour of it being implemented cross-site to the fullest extent possible.

Personally, I must admit the finer mechanics of all this is beyond my current technical expertise. I know the IPS suite does provide a standard REST API which may help provide the platform for integration. However, this would absolutely require a team not only willing to work on this, but obviously have the knowhow to understand how all the procedures work to bring this to fruition.

So essentially looking ahead in this direction, we'd need at least 3 core groups of people:

Developer(s): Creating the base framework, integrating it accordingly with site software, and creating the commands for processing.

Organisers: Determining the contents of each MODPACC, considering compatibility between items.

Testers: Basically quality assurance for functionality, and checking each MODPACC works correctly in SC4 (and ideally when combined with other packs). This would need to be in a standardised environment as determined by the package manager.

Content & Community Cycle

While I like the idea behind automation and packaging content in general, I feel @Fantozzi's earlier concerns are very valid.

Following on...

How would the batch distribution of plugins (automated or otherwise) affect the motivation of active or aspiring content creators?

Knowing a MODPACC bundle is far more appealing, there's a chance of individual entries on the STEX or LEX being overlooked, especially if included. With a package containing multiple items, individual creations are less likely to be recognised and cherished in their own right. I suspect at least for some, this plays a big part with motivation -- knowing what you create is valued by those who decide to pursue it.

For any aspiring creator, the task of earning appreciation may then become steeper. If all the plugin packs attain most of the the limelight, and you receive no feedback, why would you bother to continue sharing your own works? It'd be very hard to compete on such a scale. I imagine this is one reason why there's been so very few transport mods other than the NAM and RTMT, or based around them with compatibility in mind. The reason being, a MEGA mod is designed to be an encompassing solution for a specific need. Tried and tested, and proven to achieve just that.

Anything much more than a collection of fixes, I think we need to proceed with a degree of caution to ensure authors are respected for creating individual uploads. I very much agree with @rsc204's summation, including the points about informing people about custom content as a whole. At the same time, I think we also still need to encourage newcomers to ask questions. A starter pack should be strictly limited to just that -- an introductory taster.

The thing is, there's a cycle where people enter the scene, slowly learning their trade. First starting small, posting on the forums, or seeking advice. Sharing progress, while progressively becoming familiar with how the game and custom content functions. Maybe delving into BATting, lotting, modding or map making of your own. All the time expanding on your knowledge and gaining vital experience. Finally completing the loop by passing it onto other newcomers who come along. While the so called 'golden era' for new creations may be over, what we're seeing nowadays is quality over quantity. We therefore still need to be careful not to break the cycle, otherwise closing the door and potentially discouraging those interested in taking up creating BATs, lots, mods or maps for the first time.

That cycle is what keeps any learning community alive and well. This isn't and rightly shouldn't simply be a museum.

Bandwidth Considerations

Anything involving mass online data distribution brings this into the picture. Here at Simtropolis, the STEX is unsurprisingly the biggest overhead in this regard. Putting it in perspective, the past 30 days has seen 630GB of bandwidth used from all files downloaded. I can confirm within the IPS suite, there are standard usergroup settings to cap bandwidth quota, download speeds and also quantity. So there are options to limit the flow, should that be required.

Using an external host such as ModDB is a possibility. At least on the STEX from files, it's possible to link the download location set via a URL. That way the user would either by redirected to the page (as the NAM does currently), or perhaps a direct link to start the download.

2.3 You warrant that you are the owner or creator of any User Developed Content, or any User Generated Content you choose to upload, or that you have received permission from the owner or creator of any such content to make such submissions and to licence that content as set out in this clause 2.

If we can help it though, I think it's best to keep everything hosted here. Nothing on the internet is certain. But the recent Photobucket debacle proves yet again how relying on external sites puts full trust in their policies and services. Integrating any system is also much harder without direct access.

Indeed, through a system allowing MODPACCs to be batch downloaded on site, or even compiled and offered as individual entries, it can only result in a sharp rise in the amount used. As @Tarkussaid above, it's difficult to predict the scale or trends of such an increase, and we'd need Dirk to clarify whether this may overflow the upper limit costs of the site. Depending on the scale, the question is: Do costs need to be covered? Then if so, where possible, finding the best method(s) to recoup this without restricting the packs to an isolated group of users.

I've mixed views about packs being withheld and not openly available. On one hand it'd prevent bandwidth mounting, but on the other would be contrary to making them accessible to all SC4 players. Similarly with putting each on a DVD or in an exclusive section say for site donors (min $X amount). The deciding factor here is whether or not it's sustainable to cover the costs of any extra bandwidth. It's tricky to have it both ways. But if we can avoid it, I'd be in favour of keeping them available to the masses. If we're looking at lowering barriers for newcomers, this I feel is necessary.

Overall the entirety of this project would undoubtedly be a mammoth task. But when there's a will, there's a way... right?

Like most things: start small, gain momentum, get off the ground, with the ambition to expand.

Share this post

Link to post

Share on other sites

For any aspiring creator, the task of earning appreciation may then becomes steeper. If all the plugin packs attain most of the the limelight, and you receive no feedback, why would you bother to continue sharing your own works? It'd be very hard to compete on such a scale. I imagine this is one reason why there's been so very few transport mods other than the NAM and RTMT, or based around them with compatibility in mind. The reason being, a MEGA mod is designed to be an encompassing solution for a specific need. Tried and tested, and proven to achieve just that.

The NAM is actually a really interesting case, as it is a product of the game's file architecture. Each of the RUL files that tell the game how to construct transportation networks has a specific function, and only one copy of each RUL can be loaded into memory by the game. As a result, the only real way to ensure cross-compatibility with all mods that involve RUL modification is to assemble all third-party RUL additions and edits are assembled in a single, unified source. It has essentially required all of us who modify RUL files to work together. That's certainly come with its own set of challenges, but it's something that everyone (well, just about) in the transit modding community has agreed was necessary for the greater good.

Functional airports and seaports have a similar restriction, in that there's a single exemplar file for each that defines all the allowable ports. The former Aerospace Consortium (AC Team) handled the airports--the seaports, however, were the victim of political wrangling, so there's two conflicting controllers out there.

29 minutes ago, Cyclone Boom said:

Personally, I must admit the finer mechanics of all this are beyond my current technical expertise. I know the IPS suite does provide a standard REST API which may help provide the platform for integration. However, this would absolutely require a team not only willing to work on this, but obviously have the knowhow to understand how all the procedures work to bring this to fruition.

The API for the LEX is REST-based, so it sounds like there's already a window there for compatibility. It's also open-source, so ST is welcome to use it. Getting to simmaster07's idea, there's even a Python wrapper for it already. I'm in the same boat with you on all the technical details, so I'm going to see if I can alert Casper to this.

29 minutes ago, Cyclone Boom said:

If we can help it though, I think it's best to keep everything hosted here. Nothing on the internet is a certain. But the recent Photobucket debacle proves yet again how relying on external sites puts full trust in their policies and services. Integrating any system also is much harder without direct access.

Indeed, if we're going off APIs and the like, ModDB isn't going to work. It's just a place to upload mod files (very large ones, even).

The way the NAM Team uses it is as an extra point of redundancy in our official distribution network, to ensure the mod remains available, in cases where SC4D and/or ST may be down and/or needing to conserve bandwidth. If we are going with pre-assembled packs, and as long as we're not all-in with it (like many were with Photobucket--SC4D actually had been hosting CML images there ), it can be a useful tool, as long as one is aware of its limitations.

Share this post

Link to post

Share on other sites

If all the plugin packs attain most of the the limelight, and you receive no feedback, why would you bother to continue sharing your own works? It'd be very hard to compete on such a scale.

Imho - it depends on how the MODPACCs are presented. It could be regarded as honor to become a part oft them, part of the community selected essential works.

I don't see downloading and installing the main issue. The main issue is - well, you can look on forums. Most popular f.e.: where can I find it? What do I need? How do I created this or that? The problem is not only collecting the elements but also to gain a structure, to stick the elements together the right way. And this points towards tutorials.

I strongly recommend to see MODPACCS as some invitation to get into SC4. And therfore not to think those things isolated - but combining MODPACCS with showcases from cj and instructions, 'how to'. If you ever purchased a box of LEGO you may know - there is always a nice construction manual within the box that suggest some constructions you can create with the bricks. To me it's crucial to use MODPACCS as an 'easy access' for newbies to SC4 - to do the same here. The 'packing issue' is only a half of the issue - the other half is packing not only bricks, but bricks in a systematic way, so you can built something of the set.

That's why I think you need introduction into MODPACCs - as for every MODPACC there should be a logical reason.. If you say, we pack all the standard fixes - you gave a criteria on a logical level. And if you offer the pack for downlad at least you would tell the reason - why you did pack the stuff. So it mostly would be about 'importance' - the criteria.

On STEX creators describe their uploads themselves. This would be different on MODPACCs. It's more like a wiki - a comment on the content, an explanation what they are, what the original creators did, why those are packed together - it's all from a 'third persons view'. And obviously there must be a good reason to download the MODPACC. And therefore they could be some 'walk of fame' without the need of creating a walk of fame - because they are by logical reason.

It's like the NAM - what makes into the NAM, what remains some extra download. If your mod becomes part of the NAM, as an author, don't you feel honored? Regarding MODPACCs - me personally, I see the NAM as some kind of antetype. And for the NAM there are many tutorial videos (again it's like a LEGO box, it's not simply content thrown together but working together. The meaning of the word 'working' - what does 'working' mean here, that's imho the central part.

To create a MODPACC there should be a logical or systemic relationship between the elements - not simply stuff that's packed together because it is 'nice'. As you solve several questions doing so. As the whole is more than the summ of its elements - you get also motivation for creators to be part of the MODPACCs f.e.

But this would mean - we had to think a little bit more about criteria what makes a MODPACC and what not. I noticed in this discussion -opinion about this is quite different. So far we agreed about 'fixes'. But nothing else.

But we had to make some concept as we had to avoid that MODPACCS soon overlap in content. And we start, make one or two and then we get stuck.

So I think that needs to be discussed more - and as a result there could be a list of needed MODPACCS.

Thanks, Cathy--looks like there was at least one (Battlecat) that hadn't gotten the image link switched over to the on-site folders. Unfortunately, it's also wiped out a few folks' avatars, however, as they were using off-site hosting for theirs on Photobucket.

1 hour ago, Fantozzi said:

It's like the NAM - what makes into the NAM, what remains some extra download. If your mod becomes part of the NAM, as an author, don't you feel honored? Regarding MODPACCs - me personally, I see the NAM as some kind of antetype. And for the NAM there are many tutorial videos (again it's like a LEGO box, it's not simply content thrown together but working together. The meaning of the word 'working' - what does 'working' mean here, that's imho the central part.

Indeed, for pretty much anyone out there who gets into transit modding, NAM Team membership is the pinnacle. It's a sign you have skills to be useful to the biggest mod in the SC4 world. I still remember how elated I was a little over 10 years ago, when I was brought onto the team.

The MODPACCs, being a newer invention, might not have quite the same level of tradition associated with them as the NAM, but being included would, IMHO, be a certain sign that one's creations are valued enough to be part of a curated "taster" to get users acclimated into the world custom content.

Share this post

Link to post

Share on other sites

.....The MODPACCs, being a newer invention, might not have quite the same level of tradition associated with them as the NAM, but being included would, IMHO, be a certain sign that one's creations are valued enough to be part of a curated "taster" to get users acclimated into the world custom content.

I remember being extremely pleased when I got notified by the staff here that they wanted to include two of my park LOTs in STEX DVD4, which is just as well as turns out as all four of them disappeared off the STEX sometime after that ... sort of a relief in a way as it stopped the complaints about the number of dependences they each had ....

Share this post

Link to post

Share on other sites

I'm also with Fantozzi on worrying that automating and straightforwarding the installation process could reduce the incentives to tinker with the custom content. What keeps this community alive isn't just people playing, but people actively engaging on the continuous upgrading of the game contents.

To be clear: I don't believe these are irresolvable contradictions. It's just to think about how they can work hand in hand - installation routines, starter packs, presentation. To me these are layers of a complex task. Sometimes it seems we run out of topic but it's only to check out what is involved - social, ethics, communication, usability, technology, dependencies, sustainability, law ... it seems, we leave no stone unturned.

German Gründlichkeit?

Me, I'd like to see the following MODPACCs:

- basic fixes and mods (including also the most popular gameplay mods on water supply and pollution but with installer options for those)

- A CAM pack including civics adjusted for higher CAM stages, a base set of custom content covering all CAM stages for residentials, commercials and industry etc.

- the IRM with its dependencies all included in a starter pack

I think those are all good ideas, but besides the basic fix modpacc, the others are pretty specialized and not exactly what I would think a beginner would be comfortable getting into - at least not initially.

I propose going back to the basics. When I first got into custom content, the main reason was that I was getting sick of all the maxis repetition. I'm sure Deppiesse's Diner is a great greasy spoon, but she has a near monopoly in every town I make! Ray Krok would be proud. My sims need some variety!
So I went exploring on the STEX and started downloading alternatives... specifically, alternatives that said "NO DEPENDENCIES" because dependencies were just a scary word when I was first starting out.

With that in mind, I think the first modpacc (after the 'fix' option... that is a must) should be a growable RCI compilation that effectively competes with all the maxis content. As far as I can see, the best way to organize such a project, would be to break it down into the 4 tilesets that maxis included with SC4 Deluxe (industrial would be a different beast, so this is just Res and Com):

-Chicago
-New York
-Houston
-Euro

As much as I would like to start with the Chicago set , I believe the most popular and desirable would be the Houston (basically 'modern') tileset. I envision that each tileset would include 2-3 alternatives to each of the maxis buildings that populate that tileset. Each of those alternatives would need to be lotted in the same vein as what the original maxis lots looked like. I just did a quick look, and there are about 100 buildings in the Houston tileset. That means between 200-300 new models for this modpacc.

Then comes the lotting - it shouldn't be too hard considering how basic most of the maxis lots appear. And yes, I think we should just stick with the basic maxis props. This is a beginner starter set, so lets just stick with the basics.

I would look at this project as a true expansion pack - one that Maxis never got around to making.

If we as a community could get all 4 tilesets finished, we'd be looking at over 1000 new buildings that would fit in along the basic maxis set. For the beginner and casual SC4 players, it would be as essential as the NAM is for transportation. It would certainly be a huge first step into the world of custom content.

I'm not going to pretend that this would be a simple endeavor, but I would certainly lend my Lotting/Modding expertise to such a project. And with enough help, I think such a project is certainly feasible.

Anyway, that would be my vision.

As an aside - We could add and "industrial" pack to the tileset list, but with the incredible work that @T Wrecks has accomplished with the IRM, I'm not sure that it's necessary. Perhaps an IRMmodpacc could fill the Industrial roll.

Share this post

Link to post

Share on other sites

@matias93@Cyclone Boom and all, I am in full agreement! Some sort of APT/RPM-type system has been the clear solution to the organization and distribution of plugins, for years. I have experience packaging software for both dpkg (apt-get) and RPM Linux package managers, as well as development of various tools, and might be interested in prototyping something at some point. "sc4get" sounds like a beautiful paradigm shift.

I'm not sure if it's been discussed, but the much-longed for "Packs" are expressed through simple dependencies in such a system, so they exist as empty-ish packages which contain only documentation and many dependencies (which themselves have dependencies of (prop) libraries, more packs, etc).

This can be cascaded, so if Pat makes a Mega mega pack containing every package in the plugin folder, the new mega pack's package "Pats_fun_but_messy_plugins.sc4pkg" can specify "Pats_favorite_CS_mega_pack.pkg" in its dependencies, which in turn contains familiar lots, etc. Package managers always have tools to print out information about all currently installed packages, to make it possible to build packs like this. There is also reverse dependency listing, files belonging to specific packages, caching, and other good things.

The real pain will be going from an unmanaged plugins folder to a managed one, but getting your favorite content available will be a great motivator to be a package maintainer, so content availability shouldn't take too long!

Bandwidth is traditionally handled by mirroring the package sets around different servers (volunteers/donors) and having the client software use a random mirror/closest mirror/fastest mirror. ST wouldn't have to shoulder the whole load.

Share this post

Link to post

Share on other sites

As you can see, I'm all for a full revamp of the current plugins management approach, but I understand that it could mean a really huge amount of work. In that sense, I feel that it would be sensible to deliver some packs on the traditional way, to resolve the most pressing needs of the new users without requiring too much time. Checking my SC4 downloads folder as a reference, my first plugins were indeed fixes to silly errors in the game, as the 'crime doesn't pay' mod, together with a couple of automatas and the USL. But as I'm a latecomer (and sort of an addict), this rapidly derailed on binge-downloading like half of Jason's buildings. Little knew I that on matter of mods, bingeing isn't the viable option, so one has to choose, for example, between Mandelsoft's lighting mods or between tree controllers (with all those complexities added).

So in the purpose of de-vanilla-fy the game for newer users, we should use a 'bicefalous' approach: packs for binge-able things, like buildings and lots, and Cori's Shoppes for mods that require exclusivity.

* * *

1 hour ago, SimCoug said:

With that in mind, I think the first modpacc (after the 'fix' option... that is a must) should be a growable RCI compilation that effectively competes with all the maxis content. As far as I can see, the best way to organize such a project, would be to break it down into the 4 tilesets that maxis included with SC4 Deluxe (industrial would be a different beast, so this is just Res and Com):

-Chicago
-New York
-Houston
-Euro

I don't want to say this, but I have the instintive impulse to overcomplicate things, so there it goes: why not take the opportunity, when reissuing all custom content, to fix the clearly weird and unsystematic way in which tilesets are ordered? [ok, it's done]. Jigsaw made a try on 2010, but as it was an individual endeavour, it cannot go so far. Nevertheless, the concept was clever (even if I would have distributed Maxis' buildings on the other categories and keep the fourth slot for third world styles):

Bandwidth is traditionally handled by mirroring the package sets around different servers (volunteers/donors) and having the client software use a random mirror/closest mirror/fastest mirror. ST wouldn't have to shoulder the whole load.

I had forgot this!! And while I'm not sure if we could manage to find another altruist Dirk or Jeronji to take full charge of a continuous server, we could operate a network of smaller domestic mirrors around the world, offering substitute sources just while using our computers and being connected to internet; I would gladly donate a part of my bandwidth for that, and as I'm a crazy completationist, my SC4 downloads folder would make a good enough mirror. Surely many other members are on a similar situation, so volunteering could be a good option. Of course, this would mean to develop and manage a mirroring system (something tha APT and similars do), so it's more workload for the programmer.

And talking about forgotten points, I think that keeping the application as barebones as possible would be a plus. It doesn't only would reduce the complexity of its development, but would profit on the use of already established means of searching and finding plugins. This is: the LEX and the STEX galleries doesn't need to be replaced to work with this application, but only to include, alongside the traditional download button, a selectable field with the name of the package and a link to a MODPACC FAQ. So the user just copies and pastes the package name on the command line and gets the plugin installed.

That way, the sites don't get abandoned, the traffic passing for them can be still monetised (on an extreme case, requiring to see ads to get the package name and download button) and the chances of people participating on the forums doesn't degrade.

We need to continue to raise enough money each month to pay for expenses which includes hardware, bandwidth, software licenses, support licenses and other necessary 3rd party costs.

By way of a "Thank You" gift, we'd like to send you our STEX Collector's DVD. It's some of the best buildings, lots, maps and mods collected for you over the years. Check out the STEX Collections for more info.