Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[PatrikLundell]

@ab9rf: Thanks for your suggestion. I may well fail to understand things correctly, but I don't think the issue is designation of the version as "cmake ..\..\.. -G"Visual Studio 17 2022" -A x64 -DCMAKE_INSTALL_PREFIX="%_DF_PATH%" seems to insist on using the 2022 version, producing the following error message:

CMake Error: Could not create named generator Visual Studio 17 2022

Generators
* Visual Studio 16 2019        = Generates Visual Studio 2019 project files.
                                 Use -A option to specify architecture.
  Visual Studio 15 2017 [arch] = Generates Visual Studio 2017 project files.
                                 Optional [arch] can be "Win64" or "ARM".
  Visual Studio 14 2015 [arch] = Generates Visual Studio 2015 project files.
                                 Optional [arch] can be "Win64" or "ARM".
  Visual Studio 12 2013 [arch] = Generates Visual Studio 2013 project files.
                                 Optional [arch] can be "Win64" or "ARM".
  Visual Studio 11 2012 [arch] = Generates Visual Studio 2012 project files.
                                 Optional [arch] can be "Win64" or "ARM".
  Visual Studio 10 2010 [arch] = Generates Visual Studio 2010 project files.
                                 Optional [arch] can be "Win64" or "IA64".
  Visual Studio 9 2008 [arch]  = Generates Visual Studio 2008 project files.
                                 Optional [arch] can be "Win64" or "IA64".
  Borland Makefiles            = Generates Borland makefiles.
  NMake Makefiles              = Generates NMake makefiles.
  NMake Makefiles JOM          = Generates JOM makefiles.
  MSYS Makefiles               = Generates MSYS makefiles.
  MinGW Makefiles              = Generates a make file for use with
                                 mingw32-make.
  Unix Makefiles               = Generates standard UNIX makefiles.
  Green Hills MULTI            = Generates Green Hills MULTI files
                                 (experimental, work-in-progress).
  Ninja                        = Generates build.ninja files.
  Watcom WMake                 = Generates Watcom WMake makefiles.
  CodeBlocks - MinGW Makefiles = Generates CodeBlocks project files.
  CodeBlocks - NMake Makefiles = Generates CodeBlocks project files.
  CodeBlocks - NMake Makefiles JOM
                               = Generates CodeBlocks project files.
  CodeBlocks - Ninja           = Generates CodeBlocks project files.
  CodeBlocks - Unix Makefiles  = Generates CodeBlocks project files.
  CodeLite - MinGW Makefiles   = Generates CodeLite project files.
  CodeLite - NMake Makefiles   = Generates CodeLite project files.
  CodeLite - Ninja             = Generates CodeLite project files.
  CodeLite - Unix Makefiles    = Generates CodeLite project files.
  Sublime Text 2 - MinGW Makefiles
                               = Generates Sublime Text 2 project files.
  Sublime Text 2 - NMake Makefiles
                               = Generates Sublime Text 2 project files.
  Sublime Text 2 - Ninja       = Generates Sublime Text 2 project files.
  Sublime Text 2 - Unix Makefiles
                               = Generates Sublime Text 2 project files.
  Kate - MinGW Makefiles       = Generates Kate project files.
  Kate - NMake Makefiles       = Generates Kate project files.
  Kate - Ninja                 = Generates Kate project files.
  Kate - Unix Makefiles        = Generates Kate project files.
  Eclipse CDT4 - NMake Makefiles
                               = Generates Eclipse CDT 4.0 project files.
  Eclipse CDT4 - MinGW Makefiles
                               = Generates Eclipse CDT 4.0 project files.
  Eclipse CDT4 - Ninja         = Generates Eclipse CDT 4.0 project files.
  Eclipse CDT4 - Unix Makefiles= Generates Eclipse CDT 4.0 project files.

I've looked at the environment variables, and found VS140COMNTOOLS and the corresponding ones for 12 and 10, but notably not 16, which is still picked up by cmake, indicating cmake uses something other than these variables to locate VS generators. Manually adding the 17 version for VS2022 doesn't help cmake find it.

I've also tried to set up the CMAKE_GENERATOR_INSTANCE variable to point to the same location as the VS170COMNTOOLS variable. That failed with the new message "Warning: Environment variable CMAKE_GENERATOR_INSTANCE will be ignored, because CMAKE_GENERATOR is not set." Looking at the CMAKE_GENERATOR documentation, it indicates this variable is used only when there is no generator specified via the -G parameter, so I suspect this set of environment variables isn't really applicable to the DFHack usage.

[Clément]

You should update cmake. It is not that it does not find MSVC, it's that it doesn't know it.

[ab9rf]

@ab9rf: Thanks for your suggestion. I may well fail to understand things correctly, but I don't think the issue is designation of the version as "cmake ..\..\.. -G"Visual Studio 17 2022" -A x64 -DCMAKE_INSTALL_PREFIX="%_DF_PATH%" seems to insist on using the 2022 version, producing the following error message:

CMake Error: Could not create named generator Visual Studio 17 2022

Your cmake is too old. cmake versions prior to 3.21 do not know what VS 2022 is and thus cannot use it.

[PatrikLundell]

I tried to check for a cmake update, but "choco install git cmake.portable strawberryperl -y", which is also claimed to be useful for updating them, does not think there is anything to update.

I then went one step back to try to see going to the chocolatey web page and install it again would work. Firstly, that web page has changed, so the command you're instructed to locate isn't present (i.e. the Compile.html document needs to be update). Secondly, using the "choco upgrade chocolatey" command buried in the script for when it's already installed does not upgrade the cmake.portable version past v3.16.2 (I didn't note what version it used before running that command, so it may or may not have been the same), which is lower than the one required.
Trying to run the installation script resulted in the expected result, i.e. refusal to proceed due to the presence of an earlier installation and the recommendation to run the upgrade command.

Ah, bugger. "choco upgrade chocolatey" apparently only upgrades itself, not any of its sub packages. "choco find cmake" shows that it actually "knows" about newer versions that the higher level installation decided not to mention were available, in favor for what was installed. Thus "choco upgrade cmake.portable" actually installs a current version. Presumably the same manual upgrade process has to be applied to git and strawberryperl as well. It's possible "choco upgrade all --noop" might do this in one go, but I haven't tried it (I'm just finding choco commands in choco.summary.log, trying to find what needs/can be done).

Well, strawberryperl doesn't want to be updated on my system, so I'll just leave it be.
I'm currently at the stage where I'm actually able to generate DFHack. Hopefully this rambling might be helpful to someone else trying to upgrade to the current standard.

Thanks to @ab9rf for identifying the root of the issue.

Edit:
OK, it looks like I'm stuck for the time being. DFHack doesn't seem to recognize the Classic version, which is what I'd intended to use until keyboard support has been restored (at which time I intend to buy it via Itch.io, not Steam, which may have a different layout from the 4 steam versions it seems to recognize, based on the stderr.log contents).

[lethosor]

OK, it looks like I'm stuck for the time being. DFHack doesn't seem to recognize the Classic version, which is what I'd intended to use until keyboard support has been restored (at which time I intend to buy it via Itch.io, not Steam, which may have a different layout from the 4 steam versions it seems to recognize, based on the stderr.log contents).

I believe Steam, Itch, and Classic are all different executables. Steam is definitely different, at least. I might be able to generate symbols for classic. We do fully intend to support all of them, but most analysis has been happening on the Steam build so far.

It's also worth noting that the three builds have exactly the same keyboard support (not quite sure if you were aware).

[PatrikLundell]

Thanks @lethosor for confirming that there are probably 3 different executables.

I was indeed aware that the underlying code (and thus keyboard support) was the same for all versions. However, since I don't actually intend to play DF in the near term, but I don't want to pay for an unplayable version (being a stubborn old bugger), I thought Classic would be a good version to use for layout investigations. After all, the layout differences between the versions ought to be a matter of an offset (or possibly a small number of them), so any layout investigation results ought to apply to all of them once the version offsets have been figured out.

However, don't bend over backwards for my sake, as I'm not in a great hurry: I won't cry if someone beats me to finding something . I did think, though, that many of the prominent DFHack figures were using Linux, and thus that there might be a bit of a shortage of Windows using investigators compared to the normal situation.

[lethosor]

Yeah, lack of a Linux build is slowing us down a bit. We've gotten DF and MSVC running through Wine, but some of the Linux-specific tools don't work.

[ab9rf]

OK, it looks like I'm stuck for the time being. DFHack doesn't seem to recognize the Classic version, which is what I'd intended to use until keyboard support has been restored (at which time I intend to buy it via Itch.io, not Steam, which may have a different layout from the 4 steam versions it seems to recognize, based on the stderr.log contents).

we have yet to analyze either the itch.io or classic executables yet, so we only have symbols.xml for steam releases. it's on the agenda, certainly, but i haven't done it in part because we know that a major structure (gamest) is larger in Steam than in classic (and probably also itch) because there's stuff in there for the steam workshop, and so we need to come up with a strategy for dealing with having a structure that is different between releases of the same version on the same platform, which we've never had to deal with before now. we discussed this a few days ago, but honestly i've been sick since christmas eve and haven't had the chance to process the discussion and turn the results of it into a working strategy

[PatrikLundell]

Thanks for the info. It's probably better to wait with decisions that aren't urgent until the brain is back up to speed than to rush things only to potentially redo them later (and forcing a reluctant body to do things that aren't required is no fun either).

I guess the variant handling strategy would differ depending on whether the extra guff is just a big lump somewhere or whether it's sprinkled in little annoying pieces throughout the structure.

[Clément]

I have built the latest DFHack using BenLubar's docker image. When I copy the files over the Steam directory it seems to work (at least the basics, I get a console window and I can load a game). If I do the same with a copy of the steam version outside of steam and run it with Fedora's wine (wine-7.22 (Staging), running "wine Dwarf\ Fortress.exe"), I don't get a console and DF freezes when I load a game or quit. Without dfhack the same wine version and prefix appears to work. Does dfhack requires a special wine configuration that Steam has, but my distribution wine doesn't?

[lethosor]

Try

Code: [Select]

wine explorer "Dwarf Fortress.exe"
Another oddity I've noticed under Wine is that "die" seems to hang indefinitely, but closing the console window has been a working alternative for me (and works before or after I run "die")

[Clément]

Thanks, it worked.

[jecowa]

Wow, you already have a build of DFHack going. Is v50 a bigger load of work to update DFHack for than previous major updates? Or is every major update about the same for DFHack?

[ab9rf]

Wow, you already have a build of DFHack going. Is v50 a bigger load of work to update DFHack for than previous major updates? Or is every major update about the same for DFHack?

This one is easily the most substantial amount of work to update for since the shift to 64-bit builds in 2015.

[Roses]

So I'm thinking about getting back into modding after years away, but I was recently reminded that the Steam version was released and have been reading through this thread to try to understand the impact of that release. Are there any immediate changes that I should be concerned about? I know I saw that ruby is planned to not be supported anymore, but I only wrote in lua anyway so that doesn't impact me. Nothing else jumped out at me, but I'm unsure if there was something I missed.