TL;DR
Replace the current dichotomy of mods and scenarios with some combined system that has the functionality of both without forcing players and mod/scenario authors and server admins to choose between multiple competing almost-equivalent options.What ?
Mods and scenarios do mostly the same job, in mostly the same way. Any mod without a data.lua (or settings.lua?) is a valid scenario. Any scenario without a necessary blueprint.dat is a valid mod if you add a boilerplate info.json. You can literally just copy/unzip things between the mods and scenarios directories and get useful playable results.I propose that these two systems be combined. Make them a single system, with the distinction in features used affecting whether the game has to restart, whether they can be downloaded from a server, etc.
Why ?
Less work for server admins, who currently have to painstakingly hand-craft a scenario by copying and renaming files from separate mods, and/or copying and pasting code, finding and renaming conflicting variables (say, two mods that use a table named `global.chests`), etc.Less work for mod authors, who currently have to publish mods to the mod portal if they want players and mod-friendly server admins to play it, and scenarios somewhere else if they want mod-averse server admins to be able to host it.
Less work for players, who currently have to download mods and mod packs manually to join a modded server. I know the 0.17 road map plans to automate that, but players will still (presumably?) have to restart the game even if the mods in question don't have any data/settings. I also expect management of different versions of the same mod to be problematic there, where it wouldn't be if it was managed like scenarios are now with a server being able to serve its own pack.
More options for players, who currently cannot load two scenarios at once:
- The Supply scenario and the OffWorldShippingCo mod do very similar things, providing an ever-increasing difficulty curve of things you need to produce, one where you put them in chests and the other where you put them in rockets. You can add OffWorldShippingCo to any game, even when playing a scenario. You cannot add Supply to other scenarios, which seems like an entirely arbitrary limitation. If you simply copy scenarios/supply to mods/supply_0.0.1 and toss in a boilerplate info.json then suddenly you can add Supply's scoring to another scenario. A minor hiccup is that Supply expects the scoring chests to have come from its blueprint.dat, which won't get loaded as a mod, but that's a trivial thing to fix such that it works the same way in both cases; the scenario even already has code for creating the chests. Alternately the scenario could allow the player to add new output chests, and that would have Just Worked as a mod too.
- The PVP scenario and Wave Defense scenario could be made compatible with each other as well written mods. Their starting layout would need to be scripted instead of blueprint.dat, and Wave Defense would probably need some logic for handling multiple teams.
- PVP + Supply? sounds fun to me
- Supply + Wave Defense? ditto
Currently there seem to be only four reasons to make a scenario instead of a mod:
- blueprint.dat, which doesn't do anything that can't be done with entity/tile creation in a mod but is a lot more streamlined with `factorio --map2scenario` which would be a nice feature to make use of in mods anyway
- joining mp servers without restarting, which could be done with mods if the game simply detected whether or not the mod contains data/settings before deciding whether or not to restart, which would be nice functionality to have in the mod browser too.
- so you can guarantee it never gets loaded with another scenario, which is effectively just a piece of pseudo-"conflicts" mod metadata and an excuse for being lazy when making your code robust which will fail anyway if someone loads a mod that does the same thing as the scenarios you're trying to avoid.
- to ensure your code is loaded when a new map is created, and never added to an existing map.