Replies: 4 comments 6 replies
-
|
Regarding mods and BAR version: mods need to always keep up with the latest version of BAR. This guarantees that running multiple mods will be not-impossible (note this doesn't mean it will always be possible). More importantly, it keeps all lobbies on the same version of the game. |
Beta Was this translation helpful? Give feedback.
-
|
Regarding curation, I don't see us curating mods, outside of select mods getting an "official" seal of approval, and some kind of showcase in the UI. The important thing is that the player can browse, install, and configure mods within the application. |
Beta Was this translation helpful? Give feedback.
-
|
beyond an mvp it would be useful to specify mod dependencies in an ordered list |
Beta Was this translation helpful? Give feedback.
-
|
I have started PRs for these repos: |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Since I see a lot of confusion about how recoil supports modding and ideas - for true mod support roadmap for BAR on discord - I'll post some information and open discussion on true modding support. I'm not a stakeholder of this effort, but I believe opening the channel and having a reliable reference for the task is valuable.
Overview and current BAR modding support
Just to clarify, there are actual mods and the thing often done in bar via "tweak" modoptions.
A mod is basically some directory that contains a
modinfo.luaand some files to overwrite/add to the original game. Being a very simple format, already supported by the content distribution scheme BAR uses (rapid with custom CDN) and friendly for version tracking, makes it a prime candidate, as supported directly by the engine, for modding instead of some ad-hoc implementation.Here's an example of an actual mod see the
modinfo.luawithzk:stablein the list of dependencies. It's a mod of ZeroK, its contents either overwrite or add to the virtual file system tree so modding is very straightforward and simpleThe other bit, which are the custom widgets and tweakoptions, the only modding-like feature BAR supports atm is just a hack so players can get something done. Recently @itanthias also implemented tweakscript which is basically allowing units to have their animation scripts tweaked, with the drawback it only supports LUS scripts (Lua Unit Scripts as opposed to BOS/COB format that BAR employs for most units), but this approach only goes so far until you get a mess of exposed inputs that are eval'ed by the game from modoptions - with both maintainability, usability and security concerns.
About engine capabilities
From the standpoint of modding requirements, to what concerns being able to accept changes to the game from a trusted source and running the game with those changes, this is a solved problem as far as I know, there should be no blockers preventing BAR to implement support for true mods as far as engine capabilities go.
The complexity lies in management, curation and distribution of mod packages, allowed to be served via some BAR lobby client and the hosts. This is not a small task, it's very complex and effortful.
Remark: Mutators
I didn't assess the use case for mutators on the analysis of this post, if more information is provided the roadmap could be revised to contemplate them. There is a current engine issue and a hard limit of 10 mutators, this is very likely to not be a relevant issue at early stages of modding support implementation.
An example roadmap
Some sort of curation would be necessary at the initial implementation, this is especially relevant since BAR wants to enforce some "standard of quality", an idea (this is just the strictest possibility for a start):
modname:mybarmod repo:"github.com/badosu/mybarmod" sha:123456, mods are always pinned to a versionrapid://mybarmod:123456, or is manually built on the first implementation attempts (to reduce implementation complexity, just upload the mod.sdz)rapid://mybarmod:123456available in its archiveRequires a multidisciplinary effort spanning multiple projects and configuration files (lobby client, spads, teiserver, BARs rapid CDN and glue it all together).
On mod maintainability
It would be very important for BAR to leverage some versioning scheme for mod dependencies at some point. I am not too familiar with rapid and BARs custom CDN on top of rapid to know if this is alreasy feasible, but to keep things from breaking you'd want one of two:
depends = { rapid://byar:654321 }inmodinfo.lua. Pro: mods perform as well as they performed when submitted, don't break with BAR updates. Con: mods that are not actively maintained might lag and show some version of BAR that BAR itself doesn't want to be shown (as part of the "quality standard" thing), mods spam updates where they only change thedependsline onmodinfo.lua(this might be more of a pro than a con, since in theory the mod maintainer should have tested the mod against that version)Beta Was this translation helpful? Give feedback.
All reactions