Windows running issues

[botanicvelious]

Latest nightly build on windows 10, using original cd's not gog version

1. Running the x86 version requires copying the "shaders" folder to "C:\Program Files (x86)\3DO\Might and Magic VII" should just auto detect the shaders folder in the local folder

2. Running the x64 version requires copying the data to the "current directory" and does not use the install path https://i.imgur.com/TmdNZB1.png

3. should probably store the openenroth.ini in the local directory if it cant write to data directory as C:\Program Files (x86)\ is write protected. Currently it just says Couldn't save config file 'C:\Program Files (x86)\3DO\Might and Magic VII\/openenroth.ini' would be better if it cant save it saves the config to the current directory as a fallback

4. when starting a newgame with the data in programfiles you get a crash

INFO: [2023/07/22 17:59:31] OpenEnroth, compiled: Jul 22 2023 11:32:34
INFO: [2023/07/22 17:59:31] Extra build information: windows/x86/msvc beed1d3
INFO: [2023/07/22 17:59:31] Using MM7 directory: C:\Program Files (x86)\3DO\Might and Magic VII\
WARN: [2023/07/22 17:59:31] Could not read configuration file 'C:\Program Files (x86)\3DO\Might and Magic VII\/openenroth.ini'! Loaded default configuration instead!
remove: Access is denied.: "C:\Program Files (x86)\3DO\Might and Magic VII\DATA\new.lod"
[Press any key to close this window]

5. Running GameTest inside MSVC throws an error however it works when using ninja

--test-path is required

C:\Users\u\Documents\GitHub\OpenEnroth\out\build\x64-Release\test\Bin\GameTest\Release\OpenEnroth_GameTest.exe (process 576) exited with code 1.
To automatically close the console when debugging stops, enable Tools->Options->Debugging->Automatically close the console when debugging stops.

[CkNoSFeRaTU]

1, 2 and 3 are expected. OE as of now is working with single root directory for everything, same as vanilla did. There were multiple talks in the past to use platform-specific directories for our stuff instead. Like user's documents directory on windows, ~/.openenroth on linux and so on, but no concrete decisions were made.

Currently OE determines root path like this:

• is OPENENROTH_MM7_PATH variable is set? if it set use path from it
• if previous step failed, on windows only try to check known registry paths and if they found use them
• if both steps failed use current directory as last resort option

I tried to initiate talk couple of times in the past about removing registry path step entirely as it is more harmful than useful in my opinion but it also lead nowhere.

4 Is also expected as write access permissions to program files directories was available only on XP and prior by default. Vanilla will fail just as well, maybe not crash but you won't be able to save. Run exe with administrator permissions or fix your permissions for this folder. Or don't install vanilla to program files. That's bad practice anyway. 5 That's because when you run GameTest from MSVC's debug routines you are not using cmake, but running exe directly. So you need to manually specify arguments and env variables in launch.vs.json, same as for normal game executable. Something like this should do a trick:

  "configurations": [
    {
      "type": "default",
      "project": "CMakeLists.txt",
      "projectTarget": "OpenEnroth_GameTest.exe (test\\Bin\\GameTest\\Debug\\OpenEnroth_GameTest.exe)",
      "name": "OpenEnroth_GameTest.exe (test\\Bin\\GameTest\\Debug\\OpenEnroth_GameTest.exe)",
      "env": {
        "OPENENROTH_MM7_PATH": "d:\\Games\\mm7\\"
      },
      "args": [
        "--test-path ../test_data/data",
        "--renderer null"
      ]
    }

If you want to run through cmake you should manually go to Class View, right click on GameTest or GameTest_NullRenderer and select desired variant to run in Debug option.

[botanicvelious]

oh I totally understand vanilla did it, vanilla came out before any of these possible issues existed and imo making things easier on users is a good thing.

for #5 id say have a fallback location it reads from

[captainurist]

@botanicvelious points 1, 3 and 4 are fixed in #1694.

I'd say we should fix point 2 and close this issue. Can you test if point 2 still reproduces?