I have been thinking about this, and I think it is a mistake to encourage end-users to install individual mods instead of modpacks. Putting together a modpack is an advanced operation and I don’t think your launcher should allow the creation or modification of modpacks.
I think it is unrealistic to expect your average player to download hundreds of small content mods and also a number of advanced mods and expect all that to work together. There are bound to be compatibility issues just because you want to make the game so customizable. For example what happens if two mods try and use the same crafting recipe? Or if they both hook into the same event for the same reason?
Letting end-users choose only complete modpacks has the added benefit that end-users will go to the modpack author if they have problems, they won’t bother a mod author when the error is from a different mod. I’m sure you know about this problem because you maintain GregTech for Minecraft.
Then nothing will break because this isn’t fucking Minecraft where adding a Recipe makes it impossible for others to add an identical looking one.
I know the reverse problem where the Modpack Devs dont give a shit for something that is a Mod Bug, and the Issue gets never resolved.
There is going to be easy ways to bundle multiple Mods together, so that you can go “hey these two Mods are installed, lets recommend the Mod that adds Compat between the two and is made by one of the two Authors”.
In Minecraft mods have compatibility issues because modding is hacked on. There is no way to tell if you are overwriting something and causing a conflict until after you try to load up and things go funny or crash.
Later Forge revisions circumvented this somewhat with warnings and greater feedback but it’s far from perfect.
If you take modding into consideration from the beginning, plan out the tools to use, procedures to follow and have systems in place to detect, correct and report what went wrong it shouldn’t be as big a problem.
Also I thought there was going to be categorization and segmentation of mods hence the quantity? There would be no advanced mods. the advanced mods would be modpacks of smaller mods. If you wanted to be really clever you could even decide on which parts of the advanced mod you wanted to use.
I see the mods like Lego or parts of a computer, they have set ways to work together. You can mix and match the different parts but ultimately you aren’t going to get compatibility issues because you aren’t going to be able to add like two health systems or whatever.
Yeah, Mods could lock features that they build on, in case there is a whole System in that Mod, so only one Health System adding Mod can be installed at a time.
And in case of Health System Mods, the Mod could easily define a Number that defines “Normal People Max Health”, so Damage Values can be adjusted accordingly. At least that would be an Idea.
And it would be more like LEGO than Computer Parts, because Computer Parts bundle a LOT of Stuff, unlike LEGO where you need to build things out of it.
Also nobody stops a Modder from ALSO being a Modpack Dev, so you can make a ton of tiny Mods and then make an Official Modpack that contains all your Mods assembled together, or at least the ones that make sense together. And you can ofcourse advertise your own Packs on the Mods Description Page too, which can give you an advantage if you want parts of the Mod to be “canonical” or “the intended way” of sorts.
If you can do that, great! But I am having trouble imagining it. You want thousands of mods and then you also want compatibility mods for every combination? I thought the modpack (“larger mods” from post #1) would be the compatibility mod, that is, I thought modpack authors would essentially fork mods as needed and/or write the compatibility code themselves. It occurs to me that you have a different vision for modpacks.
This is what I’m talking about. If a user wants the functionality of two certain mods, and each of those mods relies on a different health system mod, then those two mods are not compatible.
By “advanced mods”, I meant these:
With your computer analogy it would be like wanting the functionality of two particular dongles, but each dongle attaches to a different video card and the board only has one video card slot.
Most of the time Compatibility is “Add a Recipe that accepts these special Resources instead of the original ones” and similar. Though in that case it would be easy to add such Recipes in the CSV Files of the Mods themselves and don’t need extra Compat.
And with Compat mods I mean the ones that are similar to “RF<->EU Converter” Mods that bridge two Systems.
This is going to be complicated early on, and i bet a lot of legacy bullshit is going to happen because of this (so that I would have to personally fix those Mods myself), but I am willing to do that bit of extra work on other peoples Mods if needed. Not like I was not already doing that with GregTech anyways.
Yeah that would be an Issue indeed, though I would always recommend Modders to have their Mods as tiny and generic as possible so you can slot in different Health Systems or similar.
Though also remember that a Health System is basically ONLY a Health Bar, a Normal-MAX-HP Number and allowing negative Health to happen or not. It is that tiny.
As an example implementation I could see 3 types of Health System Mods, one that you only have 1 HP and if you get hit you’re dead/down, one where you have a simple Number of 20 or so Zelda alike Hearts so the granularity is different, and one where you have a huge floating point Number to work with.
Oh and I mentioned negative Health, that is basically at 0 HP you are down and can be “revived” though you’re bleeding out, but at negative MAX-HP you are absolutely unrecoverably dead and need to respawn or something.
Also it is recommended to rely on the concept of a Health System being there instead of a specific Health System.
That is why Mods should be as tiny as possible, so such Monopoly Collisions dont happen.
Web Assembly Programmatic Interface. It basically lets you define how things map across boundaries, meaning that you can do things without copying memory for example, you can make function calls be no cost, etc…
That’s what wasm interface types are for, It allows you to define types across the boundary that are not just numbers. It’s still a heavy development but there’s a lot of push to get it finalized and implemented into engines due to the speed boost it can give. Right now if you use fully safe code and marshall things slowly across and it won’t be any more costly than using something like the Lua API, except of course the actual execution of the code is significantly quicker, and you can use basically any language you want that can compile to WASM. Once interface types come out even the binding layer should become near native link speed.
To be honest much of the concepts in that project are over my head. Lin Clark’s blog posts make sense to me though
As far as I can tell we would use wasmtime as a run-time library to load mods (WASM based) into Mechaenetia (Rust based). With wasmtime we can call WASM functions from Rust code, with code that looks reminiscent of Java reflection. This is what the call looks like:
// store holds compiled WASM for a function "test_func()" which takes no
// arguments and returns an i64. instance is an instance of the store.
let test_func = instance.get_func(&mut store, "test_func")
.unwrap()
.typed::<(), i64, _>(&store)?;
println!("testfunc() = {:?}", test_func.call(&mut store)?);
// store also holds compiled WASM for a function "test_func2()" which takes two
// u32s as arguments and returns an u64
let test_func2 = instance.get_func(&mut store, "test_func2")
.unwrap()
.typed::<(u32, u32), u64, _>(&store)?;
println!("test_func2(2, 8) = {:?}", test_func2.call(&mut store, (2, 8))?);
These are the calls the Mechaenetia team would use to interact with the mod API through WASM, if test_func() -> i64 and test_func2(u32, u32) -> u64 were in the API. Right?
Nintendo’s Flat HP mod, which adds a configurable integer based health system. When your HP runs out it trigger’s the player death event through the Mechaenetia API. This mod has its own API for determining the current player HP and max HP.
Eidos’s Body HP mod, which keeps track of hitpoints for each body part. By default it is configured such that when the core/torso or head body parts run out of HP, the player death event is triggered. This mod has its own API for determining health for each body part, body part specific hurt events, etc.
Now imagine some more mods that build off of these basic health systems.
Mario’s Hitpoint Pie mod, which requires Nintendo’s Flat HP mod to query player HP and max HP. HP is rendered as a circle with each individual hitpoint represented by a slice. If HP > 2/3 of max HP, the color is green. If HP < 1/3 of max HP, the color is red. Otherwise the slices are yellow.
Link’s Heart Display mod, which requires Nintendo’s Flat HP mod. HP is rendered as hearts on the top of the HUD.
Nintendo’s HP Alert mod, which requires Nintendo’s Flat HP mod and beeps if player HP falls below 1/3 (configurable) max HP.
JC’s Health Display mod, which requires Eidos’s Body HP mod and displays the body in a diagram with a small green HP bar next to each part. Each body part will change from green, to yellow, to orange, to red depending on its HP as a percentage of max HP for that part.
JC’s Cripple mod, which requires Eidos’s Body HP mod and applies a negative movement speed modifier to the player when their legs are damaged.
DarthMaul’s Teras Kasi mod, which requires Eidos’s Body HP mod and allows for bare-hand martial arts attacks that hit specific body parts.
Let’s say our player wants the Teras Kasi mod, but also wants Nintendo’s HP Alert mod. Therefore our player installs four mods:
Nintendo’s Flat HP
Nintendo’s HP Alert
Eidos’s Body HP
DarthMaul’s Teras Kasi
He starts up the game with a friend to try out the Teras Kasi (basically kung fu). They start fighting, and expect to hear Nintendo’s beeping noises when one’s HP is low. Then a player dies without hearing any beeps. What happened?
The Teras Kasi attacks use Eidos’s Body HP API to deal damage to specific body parts. Eventually the Eidos health system tells Mechaenetia that the player has died. The attacks do not affect Nintendo’s Flat HP whatsoever, as DarthMaul didn’t write the mod to use that health system. The HP Alert only goes off when Nintendo’s API says the player is low on health, but the Nintendo health system is unaffected by Teras Kasi attacks.
The Mechaenetia Events that cause HP to be lost would contain also the Body Parts that got hit and the Damage Type. So a Flat HP Mod would just not care about those Parts and simply change your HP Bar depending on amount of Damage (or on amount you get hit), while all others do. Also the Flat HP Mod could be a buffer BEFORE damage is taken to the individual Body Parts, kindof like a Shield.
That may sound like an okay Idea until you notice how for example the head being at 50% HP might not be a good thing, you effectively get all the cripple statuses at once when your HP reaches 10% or something.
