Direct file access mode not working

[kraileth]

After following diasurgical basically since it appeared on GH, I've finally found the time to setup a Linux box yesterday evening (Debian testing after finding that even Ubuntu 18.10 has a too old version of cmake in the repos). DevilutionX builds just fine. Thanks a lot to all the devs for the incredible work you're doing here!

But then I had a problem. I've owned 3 or 4 Diablo CDs (for multiplayer purposes) in the 90's, all of which I probably left at my parent's house so that they are unaccessible for me right now. However I've been a modder back then and found the extracted (and unaltered) assets from the MPQ file on an ancient backup drive.

Since 0.5.0 devilution's debug builds are meant to support "direct mode" to read files from the filesystem instad of the Mopaq file (see diasurgical/devilution#456). I'm not a programmer unfortunately and couldn't figure out where I'm supposed to put the assets so that devilutionx would read them. I've tried to put everything into the same dir as the executable, in a subdir called "diabdat", "diabdat.mpq" and so on without success.

Being a curious person, I just bought Diablo once more on GoG today and can confirm that devilution runs when it can use diabdat.mpq. As it has been implemented, I still wonder though how to use direct mode. Could anybody please shed some light on where to actually put the extracted files and how to start devilutionX to work with it? I'd volunteer to document this on the project wiki afterwards.

As a side note: A lot of games have simply used ZIP files (often with different file endings like .pk3 for Quake3) for their resource containers - either with or without compression. Since devilution aims for making life easier for modders (ah the good times!) such a feature would probably be much appreciated by a lot of people. Is support for something like this planned or do the devs already see a reason why this is not likely to be added in the future?

[AJenbo]

Welcome @kraileth

The feature from diasurgical/devilution#456 has not yet been ported to DevilutionX, the reason being that StormLib does not implement this in the same way as Storm did. It should, however, be a fairly easy thing to implement, basically, all that is to it is:
1: SFileSetBasePath should be implemented

devilutionX/SourceX/storm/storm.cpp

Line 659 in d88215f

DUMMY();

2: Have SFileEnableDirectAccess set the either SFILE_OPEN_LOCAL_FILE for calls to SFileOpenFileEx

Support for other formats are also considered, and we do already depend on libzip so ZIP files would be the obvious chouse, but no decision has been made yet as it is still early days in terms of working on mod support.

We also plan to support png based sprite, external data sheets for defining monsters and other entities as well as refactoring the code to make it easier for modders. Possibly we might also add scripting and an archive of common patches (like run in town etc).

We will also be working to lower the CMake requirement, it should already work for Ubuntu 18.10, except when building for Windows, for that I would recommend Debian 9 with backports enabled. You can see exactly how we use it for doing the automated builds here: https://github.com/diasurgical/devilutionX/blob/master/.circleci/config.yml

[kraileth]

@AJenbo Ah, I see! That feature not yet being part of DevilutionX explains fairly well why I could not get it to work! Thanks for confirming that. Since my abilities to mess with C code are extremely limited, I'll just wait until this lands. I'll be sure to give it a try then, though.

Modding: That sounds totally awesome! A version of Diablo that flexible was just a dream twenty years ago - it's great to see it becoming reality after all those years of hoping for Freeablo, DGEngine and so on... Looking very much forward to it.

CMake: I wish that the more popular distros weren't so conservative in their package choices. It takes ages before you can count on nifty "new" features to be widely available... Then again being on roling-release operating systems for years might have spoiled me in that regard. But yeah, we have to deal with what we've got, right? So it probably makes sense to support older CMake.

[AJenbo]

@kraileth CMake requirement has now been lowered to 3.7 #47

[AJenbo]

This is now implemented. Be aware that on systems where paths are case sensitive the files will be converted to lower case. Most tools for extracting files from the MPQ will do so in lower case, but there are a few exceptions because of the list file they use are inconsistent.