NW3...
As you pointed out, I did something similar in NW3, where the main mod itself is in a core package, MH stuff is in a separate package, and each weapon also has its own package.
There were a few design end goals with this which were actually achieved, such as not requiring the full 100+MB mod to be installed if you just wanted 1 weapon of it, as well to be able to fix each individual weapon if needed without having to resort to hacks or renaming the entire mod package-wise (due to package mismatches), and if push came to shove and the mismatches were eventually fixed, this meant that you could also update and fix core issues without touching the weapon packages and such.
There were a few design end goals with this which were actually achieved, such as not requiring the full 100+MB mod to be installed if you just wanted 1 weapon of it, as well to be able to fix each individual weapon if needed without having to resort to hacks or renaming the entire mod package-wise (due to package mismatches), and if push came to shove and the mismatches were eventually fixed, this meant that you could also update and fix core issues without touching the weapon packages and such.
So, segregating packages, and extending into new ones does work well indeed.
In addition to this, before 469 was even a possibility, ...
... I had plans to do a new mod, something like a NW4-ish kind of mod if you will.
With all this in mind, I intended it to be even more modular than this and make packages smaller and easier to update/fix/extend, by splitting a single package into 4 modular ones:
Updating the Editor would mean for it to have new functionality for maps that would be supported by a newer Core, but newer Cores would still support older Editor packages.
Updating the Interface would mean a similar thing for mods.
Updating the Core would mean that fixes and optimizations could take place without any headaches in relation to map or mod dependency, and it would be the most frequently updated package.
The Manager wouldn't really be updated much, or ideally at all (it would be probably the weakest point of this architecture, but it would also be the simplest).
But this was (and still is) a rough sketch of an architecture I had in mind, so I didn't work out how everything would work in detail.
With all this in mind, I intended it to be even more modular than this and make packages smaller and easier to update/fix/extend, by splitting a single package into 4 modular ones:
-
Editor: this package would be for exclusive usage of the Unreal Editor, with only actors to be added directly into maps; -
Interface: this package would be for exclusive usage by other mods, to interface with the main mod through a common package; -
Core: this package would be the actual core/engine that made everything work (the other 2 packages above would have mostly "dummies" and such); -
Manager: this package would be the manager that would take care of setting everything up between the 3 packages above, and this is the only package all the other packages above would depend on, whereas the 3 packages above wouldn't have any dependence between them.
Updating the Editor would mean for it to have new functionality for maps that would be supported by a newer Core, but newer Cores would still support older Editor packages.
Updating the Interface would mean a similar thing for mods.
Updating the Core would mean that fixes and optimizations could take place without any headaches in relation to map or mod dependency, and it would be the most frequently updated package.
The Manager wouldn't really be updated much, or ideally at all (it would be probably the weakest point of this architecture, but it would also be the simplest).
But this was (and still is) a rough sketch of an architecture I had in mind, so I didn't work out how everything would work in detail.
However, doing a more modular approach is not something that necessarily makes sense all the time, and is particularly hard to pull off cleanly when working with existing packages which aren't modular to begin with.
And MH is certainly one of those mods: it was built as a single package serving as a gametype to play, a set of tools for mappers to use, and an interface for mods to extend and such, and all-in-one type of deal.
Things like MH2 only came into being exactly because the original MH package couldn't be updated, due to the package mismatch issue.
But 469 quite literally changed the game in that particular issue, by actually solving it, given that package mismatches was an engine limitation that made no damn sense.
So it only stands to reason that MH updates should follow a similar pattern now, years after the root issue of MH updates was fixed by the time the first 469 was rolled out (this was fixed already since 469a, and we're about to have 469c released).
I don't necessarily disagree with new MH functionalities to go into a separate package, but the problem is that the MH package as it is isn't really ready for it, and MH mappers expect to find everything they need inside the main MH package already, and they don't expect and likely won't use all the extra packages that would come with a feature each.
And by "not being ready", I don't mean it to be impossible, but rather "not ready" in the sense of "not having been designed that way", so forcing it now to be different is actually harmful in the long run.
MH2 and its derivatives are already a series of hacks and extensions put together, without any thought into which design patterns it should follow or any consistency whatsoever, so imagine if the original MH package started to be handled the same way, it would end up being a nightmare with MH mappers and server owners not really knowing what to do, it would become too confusing.
But if something like a "MH3" was developed, as something rewritten in terms of packages to be very modular and have meaningful extensions, it would become a lot easier and would accomplish the goals that you seek.
However, someone would need to put in the work for it, and thus far that seems extremely unlikely, because on one hand Shrimp seems to have barely the time for MH alone, and on another everyone else is voicing their "disgust" and their own accomplishments like trophies in the form of MH2 and other mods in this thread, potentially demotivating Shrimp further into doing anything at all for the mod, without even trying to work together with him in a constructive manner to maybe build something actually worthwhile, and in the end that's what the real problem is here, and it has nothing to do with modular packaging or technical issues in the least.
Although its definitively worth fixing, especially considering some pawns use splash damage weapons.
) 