openmw.org

Yeah, that sounds like RelWithDebInfo.

I'd prefer to not modify the generated solution files when building, to make my own life easier and also minimize the difference between the official builds and what other users can do, hence why I've been using RelWithDebInfo to get the working debug info.
What about adding a CMake flag to decide on if the console should show or not for Windows builds?

Edit:
And such a flag already exists, right. I'll flip it for the remaining builds.

As I've said, that's not viable. RelWithDebInfo disables a few key optimisations like inlining (/Ob1 vs /Ob2) and the OPENMW_USE_LTO flag only does anything in Release mode, so that would make the official release slower.

Possible solutions include:

• Adding /Zi to CMAKE_CXX_FLAGS_RELEASE and CMAKE_C_FLAGS_RELEASE, and /debug to CMAKE_EXE_LINKER_FLAGS_RELEASE, CMAKE_SHARED_LINKER_FLAGS_RELEASE and CMAKE_MODULE_LINKER_FLAGS_RELEASE in your CMakeCache.txt. These are cache variables, so just as configurable as USE_DEBUG_CONSOLE (well, technically they're flagged as advanced settings, so you need to check the Advanced box in the CMake GUI to make them show up). It's just that for dumb legacy reasons string-valued options and bool-valued options use a different CMake command.
• Add the same flags within Visual Studio, which you're not keen on.
• Modify CMakeLists.txt to make these changes. This has a few sub-options:
  • Commit these changes, and cherry-pick the commit onto this and every future release branch.
  • Get the change on master, potentially behind a setting.

Whichever of these you use, I'm pretty sure it'll stick the PDBs in the installer if they're present in the build directory, so it'd be a good idea to cut them into a separate zip in between building the binaries and the installer.

While looking into this, I realised the documentation string for USE_DEBUG_CONSOLE is wrong. It does just toggle whether RelWithDebInfo and Debug builds are built as subsystem Windows or subsystem Console, i.e. whether there's a pop-up console behind them and the entrypoint is main or WinMain. The thing that determines redirection from stdout to the Visual Studio Debug Console (or anything else that subscribes to debug messages from OutputDebugString) is whether _DEBUG is defined.

Why is this happening and how can I fix it? https://radikal.ru/lfp/b.radikal.ru/b07 ... 2c.png/htm

I tested openmw and openmw-cs with RC4 and RC6 for 0.47. Running Example Suite content, and everything runs fine. This setup is on Linux Manjaro and locally built OpenMW-OSG with some minor (likely irrelevant) custom changes related to Collada.

Undo-redo sequence crash issue is present with OpenMW-CS in 0.47 RC6 https://gitlab.com/OpenMW/openmw/-/issues/6235

Reproduce:
1) Do land height edit
2) Change to Instance editing mode
3) Press undo

I'm working on a better fix for 0.48, but if we need a quick fix fox 0.47, commenting lines 13 and 18 at https://gitlab.com/OpenMW/openmw/-/blob ... ds.cpp#L13 might fix the crash while breaking terrain selection rendering during land edits, especially undo-redo sequence. edit: I tested that commenting does indeed make 0.47 redo-undo while switching editmodes stable. However, this change makes the terrain selection rendering glitch during redo-undo, so there's room for improvement.

Edit/addition:

Testing git master 0.48 branch with the proposed fix gets rid of one crash, but there are others reproducable by:
1) Do land height edits
2) Undo a few edits
3) Do another land edit -> crash

This is a separate crash that occurs at TouchLandCommand. Not sure if this affects 0.47, but to my knowledge it used to work when terrain editing was first introduced. edit: This bug is a regression in 0.48, it doesn't affect 0.47.

When this gets merged https://gitlab.com/OpenMW/openmw/-/merge_requests/1165 I assume we're going to need new RCs?

The problem was solved the problem was in the Fonts folder

Please tell me can I turn on the printing house as in MCP?

Another round of RCs please.

We're getting shinier.