Backwards-compatibility redirects

[Cervator]

Spun out of #760 comments for future notice so we can do this one day - possibly far in the future so putting this in a "Beta" milestone :-)

Idea is that every time we move something substantial like a world gen from one module to another it may break old worlds that can no longer find a stored reference. @immortius mentioned introducing some sort of redirect that can be left in changed code/modules to probably register as alternative/outdated paths.

I've wondered about the similar issue of entirely renamed modules, where again leaving some reference to the old name would be nice to not break worlds expecting said module. Even if one day a new module with the same original name will then cause conflicts at least we cover the most common scenario

[Cervator]

A somewhat related thought: With assets for Light & Shadow in one module, so that they can easily be used by other modules as well, the override textures take effect there merely by being in the override directory.

Maybe there needs to be a way for one module to declare override assets sourced from outside itself (module.txt ? a module-level prefab?). That way the functional L&S module could declare the override but the (potentially useful elsewhere) assets stay in LASR. You can then avoid having the override in place simply by having LASR enabled.

[immortius]

Good point, and I'll argue worthy of a separate issue (could replace the
entire override directory with a file declaring overrides).

On 8 January 2014 07:04, Rasmus Praestholm [email protected] wrote:

A somewhat related thought: With assets for Light & Shadow in one module
so that they can easily be used by other modules as well the override
textures take effect there merely by being in the override directory.

Maybe there needs to be a way for one module to declare override assets
sourced from outside itself (module.txt ? a module-level prefab?). That way
the functional L&S module could declare the override but the (potentially
useful elsewhere) assets stay in LASR. You can then avoid having the
override in place simply by having LASR enabled.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/763#issuecomment-31773734
.

[Cervator]

Curiously, do you think it could be worth supporting both? It seems like a nice convenience, akin to the "auto" directory, to be able to just drop stuff into an override directory. Maybe also for a use case where a server controls a module and the user wants to use a hi-res texture pack or something.

Like "auto" it would be better to develop onwards to a full declaration eventually - but handy to get started

[Cervator]

During a bit of brainstorming the idea of using an "Index" repo on GitHub to store added metadata for modules came up, to be available for launcher / game / module tracking sites (pretty much modules.txt and maybe some release/version info and a link or two). That could be one way to support renamed modules - in that case make a new index entry for the new name and change the old one in a way marking it as a redirect/rename

Still theoretically possible to embed an "old module names" field in the standard module.txt, but it sounds like that could be a mess (and would not be authoritative like a central index repo)

[Cervator]

Came across asset redirect support in gestalt-asset while studying something else, thought it worth a mention plus link here: https://github.com/MovingBlocks/gestalt/wiki/Gestalt%20Asset%20Core%20Quick%20Start#redirects