stgatilov

The third-party libs were changed somewhere around that time. Maybe I had some uncommitted changes when published that update?... Try revision 9882, or revision 9888, or 9891.

Fixed libjpeg in trunk. You might want to change r_screenshot_format to avoid using jpeg for savegame screenshots. Although it won't help you if someone uses jpeg file in texture or as SEED map.

Yes, @nbohr1more has them too. TDM does not use system libraries so your version should not matter. That's very strange: the changes in libjpeg first appeared in dev16481-9881, so the same problem should happen on that build too.

dev16485-9903 is now available.

I doubt D3 Gui system supports that, so that would be too much of effort for such a minor improvement.

Yes, the plan is to remove only headbob, since it is cosmetic and has no gameplay consequences. As for running/swimming speed, these settings should be taken from mission, or from hardcoded defaults. It is OK if developers can change them for debugging, but such changes should not persist I think.

So... will you commit this removal to assets SVN? I think allowing players to disable head bobbing is more important than allowing mappers to customize it. Do we need more opinions? @Dragofer @kingsal @Goldwell @Springheel @Obsttorte

I played a bit inside flatpak. First of all, the sound issue goes away after 30 seconds of playing. I guess it is some kind of race condition... I checked that settings are saved properly, games are saved/loaded, missions are downloaded. I think everything works. I did a few changes to the manifest: 1) Changed URL to https://update.thedarkmod.com/zipsync/tdm_installer_fixed110.linux64.zip --- that is fixed version of installer that will be the same in the future. Some sort of compromise between changing sha256 every time and adding tdm_installer binary to the manifest archive. 2) Added semicolon to two lines of .desktop file, because flatpak builder (or maybe something else) prints warnings about them (I suppose these properties are lists, and lists are semicolon-separated and -terminated): Categories=Game; Actions=Installer; Also, I see warning about PrefersNonDefaultGPU property: it says that the property must start with X- because it is not a standard one. I think my OS is too old, and the property was added recently, so there is nothing to do about it. tdm_installer marks installation path as red because it contains dot characters. Don't remember why dots were not whitelisted (it installs fine)... maybe to avoid confusion between files and directories. Is it possible to avoid ".var" subdirectory, and what is $XDG_DATA_HOME ? I don't like that many gigabytes are stored in a directory which is hidden by all file browsers. Yes, renaming last directory from TheDarkMod to darkmod is a good idea. And the bug that I referenced probably triggers only when two directory components are equal to "darkmod".

Ok, I ran TDM within flatpak, and I get terrible noise instead of sound with "[ALSOFT] (EE) available update failed: Broken pipe" spam. It sounds like the game fills the sound buffers only a few times per second, so I hear 3-5 brief pieces of sound samples per second. That's what I see when spam starts: ----- Initializing OpenAL ----- Setup OpenAL device and context OpenAL: found device 'ALSA Default' [ACTIVE] OpenAL: found device 'Ensoniq AudioPCI, ES1371 DAC2/ADC (CARD=AudioPCI,DEV=0)' OpenAL: found device 'Ensoniq AudioPCI, ES1371 DAC1 (CARD=AudioPCI,DEV=1)' OpenAL: device 'ALSA Default' opened successfully OpenAL: HRTF is available [ALSOFT] (EE) Failed to set real-time priority for thread: Operation not permitted (1) [ALSOFT] (EE) available update failed: Broken pipe When I start native TDM binary, it works fine, but prints exactly the same log as posted above. So I suppose lack of real-time priority is not critical. I can only speculate that VM uses some custom sound settings, but flatpak does not catch them. All sounds in-game lag by almost half a second. Also sounds in Firefox play immediately.

Somehow it has helped. With this installation, can you load savegames properly? The word "darkmod" occurs twice in the path, which is known to cause problems.

I have stopped on adding flathub repo (Ubuntu 16.04): user@ubuntu:~$ flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo error: Can't load uri https://flathub.org/repo/flathub.flatpakrepo: Unacceptable TLS certificate Obviously, many people have the same issue, but simple solutions like reinstalling ca-certificates or similar do not work. Also, I can download the file at this URL using wget without any problem. It looks like something that flatpak uses for HTTPS is messed up.

Which cvars did you change? The following cvars are marked as "archive", meaning that they should be saved between sessions: idCVar pm_crouchbob( "pm_crouchbob", "0.2", CVAR_GAME | CVAR_NETWORKSYNC | CVAR_ARCHIVE | CVAR_FLOAT, "bob much faster when crouched" ); idCVar pm_walkbob( "pm_walkbob", "0.3", CVAR_GAME | CVAR_NETWORKSYNC | CVAR_ARCHIVE | CVAR_FLOAT, "bob slowly when walking" ); idCVar pm_runbob( "pm_runbob", "0.35", CVAR_GAME | CVAR_NETWORKSYNC | CVAR_ARCHIVE | CVAR_FLOAT, "bob faster when running" ); idCVar pm_runpitch( "pm_runpitch", "0.001", CVAR_GAME | CVAR_NETWORKSYNC | CVAR_ARCHIVE | CVAR_FLOAT, "" ); idCVar pm_runroll( "pm_runroll", "0.003", CVAR_GAME | CVAR_NETWORKSYNC | CVAR_ARCHIVE | CVAR_FLOAT, "" ); idCVar pm_bobup( "pm_bobup", "0.035", CVAR_GAME | CVAR_NETWORKSYNC | CVAR_ARCHIVE | CVAR_FLOAT, "" ); idCVar pm_bobpitch( "pm_bobpitch", "0.001", CVAR_GAME | CVAR_NETWORKSYNC | CVAR_ARCHIVE | CVAR_FLOAT, "" ); idCVar pm_bobroll( "pm_bobroll", "0.0015", CVAR_GAME | CVAR_NETWORKSYNC | CVAR_ARCHIVE | CVAR_FLOAT, "" );

Fixed that. Emm... it means that static libs for OpenAL and pugixml use some symbols which your VC/CRT installation does not provide, or something like that. I'd say that's not something for non-professional C++ programmer to debug This might happen because of wrong VS version. If you have some VC projects/solutions open, close all of them. Use SVN client to ensure that TDM source repository is perfectly clean, i.e. there are no local changes in any files (especially in .sln and .vcxproj files) Make sure to open the solution in 2022 version of Visual Studio (especially if you have not deleted version 2017 yet). Try to rebuild whole solution.

The problem of dependencies is quite severe on Linux. We minimize it by linking almost everything statically, except for OpenGL and glibc. I'd be happy to link glibc statically too, but it does not work So instead I simply build official binaries on a pretty old Linux distro. Flatpak solves the glibc problem at least. Speaking of checksum. If you absolutely need one, you can bundle tdm_installer archive with the manifest. Then checksum will not change. And the installer should self-update to the latest version anyway on the first run. That's how @freyk does it in his installers. As a user, I'd be happy to forbid programs access to anything outside their directory, but I doubt they will work properly after that I hope TDM does not break from this restriction: in my opinion, it should never go outside installation directory (unless the user tweaks some filesystem cvars that should not be changed). Additional 100-200 MB is not a problem at all for a 3GB+ game. I think I should try to install flatpak and install TDM via it myself. I must admit I don't want to maintain anything like this myself. However, this manifest basically wraps our official installation instructions, seems to require almost no maintenance, and allows to publish TDM on a well-known distribution system without legal burden (like on Steam).

Welcome to forums! Thanks for sharing this! The main problem with having more ways to install/build TDM is maintaining all of them, and making sure players don't get into more problems. That's why we keep away from having official TDM packages in Linux distributions and similar stuff. Is there any benefit in this flatpak approach, compared to running tdm_installer manually? P.S. You should not specify checksum for tdm_installer.linux64.zip, because this file is regularly updated, and each update changes the checksum.

Can you at least provide the pkg-config code that you use? Preferably for all third-party libs used, except for probably header-only ones.

I assume pkg-config defines the same variables like openal_INCLUDE_DIRS and openal_LIBRARIES ? Since some packages have different names, the pkg-config path needs to do set a few cmake variables too, so that the rest of the CMake file could use conan names. And the last question is: whether it should be put straight into CMakeLists.txt, or it should be put into ThirdParty/cmake_find_package/FindXXX.cmake. The second option is probably better, but means a bit more bolierplate (basically the same "if" and the same "include" in every "find" file).

Is it true that pkg-config provides more libraries or does so more accurately than cmake's built-in find_package? (at least on Unix-like systems)

Oh... I thought pkgconfig is something installed as system package, which knows how to find many libraries by their standard name. If you have to write this UsePkgConfig.cmake yourself, and enumerate all libs there, then there is absolutely no point in using it: why not do the same with cmake?

Speaking of CMakeLists changes, you can minimize the changes on your side, then share the patch. I'll see what you had problems with. Maybe I'll find a better way to fix something, maybe I'll apply it "as is" under appropriate option.

Applied the second commit as svn rev 9892. Also, I accidentally noticed that tdm_installer build is now broken because I changed the name of curl cmake package, so I changed that. We take libs from conan, so we have to use its convention: now we do "find_package(CURL)" everywhere.

I applied the first patch with minor changes in svn rev 9890. Regarding the second one: Why did you add cast to (const uint8_t *) in Hasher::Update? It seems that blake2s_update accepts const void * regardless of platform... UPDATE: It turns out that older versions of BLAKE2 received const uint8_t * (commit).

Because inlined geometry of a model goes through dmap processing. The more such models you have, the longer dmap takes. Chance of complicated geometric algorithms failing also increases. Are there any benefits of inlining? One less entity is not a reason any more (and probably combining close models into one is better than inlining models). Yes, dmap can remove some invisible geometry and precompute stencil shadows. But with the costs outlined above.

If you travel by air, then you have to fill customs declarations when you come to a foreign country. Or go through green corridor, implicitly saying that you have nothing to declare. It has nothing to do with airlines. Given that we will have two laptops and a miniPC for three people, I think carrying excess computer parts can cause issues on the customs. As far as I understand, one laptop per person is considered OK by customs, but not more.

At this moment I consider two options: Send it via international post to one of my future colleagues Take it with me to airplane I'm only considering taking the chassis and everything inside it. I'll definitely let monitor, keyword/mouse, speakers rot. Regarding international post: does anyone have experience sending PC abroad? I'm trying to understand how to fill customs declaration, and how to specify cost. For instance, how to estimate cost of component which is no longer sold (the oldest piece is SB Audigy 4, which is about 15 years old)...