[0.4.2-4d45117] [Engine/Duke3D] -addon not working anymore

[mjr4077au]

With the recent changes to remove the duplicate entries from the startup list, the -addon [0-3] switch doesn't work anymore...

If I was to hazard a guess, it appears that -addon just sets -gamegrp appropriately, but -gamegrp only mounts grp files in a mounted path. Because the paths to the extensions aren't mounted, they can't load.

Code: Select all

addon
{
	// This is for loading the addon from the megaton edition without setting the path.
	name "Duke Caribbean: Life's a Beach"
	flags GAMEFLAG_DUKE|GAMELAG_ADDON
	dependency DUKE15_CRC
	mustcontain "addons/vacation/vacation.grp"
	loadgrp "addons/vacation/vacation.grp"
	gamefilter "Duke.Vacation"
}

Reverting the Duke-specific parts of this commit and shitcanning all the addons from grpinfo.txt that have the comment "// This is for loading the addon from the megaton edition without setting the path." fixes the issue perfectly and maintains the intention of not having duplicates.

mainWindow.png

[Graf Zahl]

Actually no, it won't. It needs to be able to look for a few more file names. Currently it only checks for GRPs in the search path.

[mjr4077au]

Actually no, it won't. It needs to be able to look for a few more file names. Currently it only checks for GRPs in the search path.

Well, the parameter works now, the games load the same as before from the screen when not using the parameter, and the display name includes the grp filename in brackets like the others which is more consistent.

Seems pretty good to me? . These are also Megaton files it's picking up of course, so this workaround in the grpinfo.txt seems like what should have been removed instead of changing the RegistryPathInfo array in searchpaths.cpp.

[Graf Zahl]

The addons work for YOU. They may not work for others having similar but not identical setups.

[mjr4077au]

The three other grpinfo definitions for Duke Caribbean are still in the file, only the ones indicating Megaton Edition workaround were removed.

Changing line #116 in searchpaths.cpp from:

Code: Select all

	{ L"SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\Steam App 225140", L"InstallLocation", dukeaddons },

To:

Code: Select all

	{ L"SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\Steam App 225140", L"InstallLocation", gameroot },

Which was what I was indicating to partially revert would only affect people with identical configurations to mine.

[Graf Zahl]

You are forgetting the other part - detecting the addons in the subdirectory when not having your specific installation.

[mjr4077au]

The comment in grpinfo.txt is a bit erroneous so I'm sorry but you'll have to forgive me on that one. I'm also confused how the engine can load a GRP file from a somewhat absolute path ("addons/dc/dukedc.grp") but couldn't load a CON file called in the same way.

Regarding loading from 'addons/<name>/<name>.grp' within the running directory of Raze, that's not something EDuke32 does anyway from my testing. For drop-in replacement, it's probably better to maintain compatibility, unless you're trying to promote a different way of organising grp files?

The functionality is important to me because I use '-addon [0-3]' (or could just use '-gamegrp <name>.grp') in scripts that just load the game and add CON/DEF files as necessary. Right now neither way works, it can't find the specified GRP file so it askes me what to select at start.

Absolutely not trying to be confrontational, just trying to assist in solutions and thought what I found might be viable and save you the grunt work considering all the other important stuff that's going on.

[Phredreeke]

In the case of Life’s a Beach and Duke it out in DC aren’t all the CON files already in the GRP itself?

[mjr4077au]

In the case of Life’s a Beach and Duke it out in DC aren’t all the CON files already in the GRP itself?

I have a voxel pack that I load that has a CON file a DEF file of course, among a few other things. Regardless of that, the CLI switch isn't working anymore the way the GRP files are being detected but they are when I make the changes to the source that I've indicated.

[Graf Zahl]

It seems this cannot be done in a robust and portable manner with an addon descriptor, so I did what was suggested and reverted to the old state. Sorry for those negatively affected, but having that Steam installation work as intended is more important here.

[mjr4077au]

No worries, thanks and I appreciate you taking my suggestion onboard