(1) 1968 *.conf files with this removed:
Code: Select all
graphics_set.old: gfx_gdash_boulder_dash_1
graphics_set.new: gfx_gdash_boulder_rush
sounds_set: snd_gdash_boulder_dash
music_set: mus_gdash_boulder_dash_1
(3) First Star Software levelsets omitted
Clearly, 2 & 3 must stand. But (1) could be done by not editing 1968 *.conf files; rather, providing 'stub' versions of those graphics etc. sets, which point to the standard RnD sets. OR -- I forget, but, isn't it the case that if the desired sets are missing, RnD just automatically falls back to its defaults? (But, I think, probably with some ugly error messages, so that's no good.)
Anyway, just seems like this package could be a lot closer to 'pristine'.
=====
One thing my suggestion would degrade is the possible ability to install both of these 'sets of levelsets' side-by-side, allowing one to play any of the caves easily with either sets of artwork. BUT, this possibility is already made difficult by the levelsets using the same names -- the archives extract on top of each other, the levelset names are the same (so would not capture things like, possibly, variances in people's scoring ability with different artwork, or level of skill when soothed-and-or-assaulted by different music :)
Since that possibility is already more or less kaput, I don't think there's much harm in shipping Boulder_Dash-x.x.x.zip with the 'full artwork' config statements + stub artwork.
I half want to suggest that the stub artwork be stored in filenames like:
Boulder_Dash/artwork/mus_gdash_boulder_dash_1/music/musicinfo-fallback.conf
-- with the RnD binary following the rule: if I can't find [path-to-artworktype].conf, and [path-to-artworktype]-fallback.conf exists, use that. That way, installing both pkgs at once, in either order, would result in the 'better' configuration in which the 'real' artwork is used.
BUT. I am aware that RnD's conf-file scan at startup is already kind of painful and full of a very large number of retries, failed lookups, etc. I hesitate to suggest something that might potentially double it. So something at a higher level might be more appropriate. (Have not studied the search cascade in some years: perhaps there are things it *already* searches for in a sort of 'fallback' role, which could be exploited here by merely knowing the already-looked-for name to use rather than proposing a new sidecar namespace...)
