Problems with recent commits

I just tested commit 36e4f46 under linux and there are 2 problems:
1. doomsday can not find it's files unless I set /usr/share/doomsday as a working directory
2. Mod support is partially broken: box mod folders are no longer considered as mods but are scanned recursively instead adding each individual pk3 file as a separate entry to the mod list.

Comments

  • Thanks for reporting. I'll check these out when I have a suitable moment.
  • Something's wrong with refresh rate detection:
    ar25exx2qdi8.png

    Displayed rates are obviously bogus
  • Can not edit renderer settings, application crashes when I press Renderer->Cogwheel->Edit.
    Also I can not provide crash report since debug build fails:
    CMake Error at /mnt/d/projects/git/Doomsday-Engine/build/doomsday/libs/core/cmake_install.cmake:50 (file):
    file INSTALL cannot find
    "/mnt/d/projects/git/Doomsday-Engine/deps/products/lib/cmake/the_Foundation/../../lib_Foundation.so":
    No such file or directory.
    Call Stack (most recent call first):
    /mnt/d/projects/git/Doomsday-Engine/build/doomsday/libs/cmake_install.cmake:47 (include)
    /mnt/d/projects/git/Doomsday-Engine/build/doomsday/cmake_install.cmake:47 (include)
    /mnt/d/projects/git/Doomsday-Engine/build/cmake_install.cmake:47 (include)
  • At least editing renderer settings works for me on the Mac. I'll test how it works on other platforms.
  • Displayed rates are obviously bogus
    Fixed.
    application crashes when I press Renderer->Cogwheel->Edit.
    I can reproduce this on Ubuntu.
  • edited 2020 Dec 29
    Mod support is partially broken: box mod folders are no longer considered as mods
    Should be fixed now.
    doomsday can not find it's files unless I set /usr/share/doomsday as a working directory
    Cannot reproduce this one. Although I don't have a system-wide doomsday package installed, I just use CMAKE_INSTALL_PREFIX to "make install" to a directory under $HOME and run doomsday from there.
    application crashes when I press Renderer->Cogwheel->Edit.
    Should also be fixed.
  • edited 2020 Dec 29
    can you reproduce if you set "CMAKE_INSTALL_PREFIX" to /opt/doomsday?
    I was having that can't find sky.morning issue when make installed to /opt/doomsday
  • edited 2020 Dec 30
    Mod support is partially broken: box mod folders are no longer considered as mods
    Should be fixed now.

    Partially fixed. Hexen XARP is detected properly without additional actions, but there's a problem with JDRP: game thinks that JDRP set in game profiles earlier and JDRP it finds now are two different mods
    5e8mwmg0c0aj.png

    doomsday can not find it's files unless I set /usr/share/doomsday as a working directory
    Cannot reproduce this one. Although I don't have a system-wide doomsday package installed, I just use CMAKE_INSTALL_PREFIX to "make install" to a directory under $HOME and run doomsday from there.

    As far as I understand CMAKE_INSTALL_PREFIX is set to the directory inside build directory to make a package, but package contains global paths (without build directory prefix). But why it worked before? For example commit 339b410 didn't have such problem, doomsday could be started without explicitly setting working directory.
    application crashes when I press Renderer->Cogwheel->Edit.
    Should also be fixed.

    I can confirm it's fixed.
  • Found possible reason for JDRP problem. There's strange pack version detection problem. In JDRP info file version is set to N/A which was initially detected as 0.0.0 and saved as such to game.dei. But now game detects pack version as 0.1970.101.300, which is weird, info file hasn't been changed, the version is still N/A.
  • OK, I changed the default version for .box so it doesn't try to look at the file timestamp. Now jdrp.box should again be version "0.0".
  • Thank you, mod is now recognized, but something is wrong with saved games:
    zj1xu7b3hyj2.png
    I have exactly same mods enabled, but game thinks they are different.

    Attached one of the saves for plutonia, rename .zip to .save

  • It appears the package IDs are being composed incorrectly. For example, there is "file.pk3.jdrp.spinalcolumn-1" instead of "file.pk3.jdrp.spinalcolumn".

    I'll see what's up with that...
  • Hello again and Happy New Year! With the recent commit saves are recognized again, thank you!
    Here's however a couple more problems:
    1. TNT31.WAD changed it's id
    uihym9v2k6aq.png

    2. Something is wrong with external texture support. Whatever game I load (Ultimate Doom, Doom 2, TNT Evilution or Plutonia),the title screen always looks like Ultimate Doom one.
  • 2. Something is wrong with external texture support. Whatever game I load (Ultimate Doom, Doom 2, TNT Evilution or Plutonia),the title screen always looks like Ultimate Doom one.

    I think there maybe a problem reading subfolders inside pk3 files which have names like game IDs. Here's how dhtp pk3 looks like inside:
    mhux89dlep0v.png

    I think before the game used texture files from subfolder with matching name and only if there's no corresponding texture there it used texture from main folder. Maybe now it forgets to look in subfolder?
Sign In or Register to comment.