RobustToolbox icon indicating copy to clipboard operation
RobustToolbox copied to clipboard

Resource Pack support

Open LudwigVonChesterfield opened this issue 3 years ago • 1 comments
trafficstars

Being able to specify a Resource Pack with a fallback if a resource is not found would be very useful to any downstream fork, as well as enable a feature of localized visuals (such as "med->" sign being "мед->" for somebody who has chosen a localized resource pack)

This brings up an issue of "player experience cohesion"/"cheaters abusing resource packs for ..."(see Minecraft X-ray texture packs) (If the implementation permits users to load their custom-baked Resource Packs), which could be countered by... not enabling resource packs on forks that wish to avoid customization/cheaters so much.

I imagine a high-level implementation to be something like:

List<CanFail<ResourcePack>> resource_packs = [
    // This is how this or that build could ignore user defined resource packs
    // UserResourcePack(),
   DownstreamResourcePack('Resources/Downstream'),
   DefaultResourcePack('Resources/Default') // Or simlply 'Resources'?
]

LudwigVonChesterfield avatar Jun 10 '22 19:06 LudwigVonChesterfield

As a thing for forks/downstreams, all this would really require is:

  • For full release: forks can just update their own build.pys to combine resources from two different folders, prioritizing their custom "pack" over the normal resources folder
  • For local testing: ProgramShared.DoMounts() could be updated so that users can load a "pack" before the standard resource folder, so that it gets prioritized
    • Could be as easy as moving the cmd line mount options before the resource mount, but should probably be done by using the resource.pack cvar.

As to whether that's useful, by the sounds of it the general opinion appears to be that downstream should just use the main resource folder and resolve conflicts, rather than having a separate resources folder. Though given how easy it would be to add I wouldn't be opposed to supporting that for whoever might want to use a separate folder instead

For clients, it would also be pretty easy to allow them to load resources from a folder/zip in their user data directory. Tough AFAIK there is currently no way for different servers to use different user data dirs, which really would need to be supported for this, in addition to enabling server specific keybindings & client_config.tomls. But I'm really not sure if any server would ever actually want to enable that, given that AFAIK it would make it completely trivial for anyone to disable things like fov, lighting, the crit/death shader, etc.

ElectroJr avatar Jun 10 '22 20:06 ElectroJr