stgatilov

It was already reported here: https://bugs.thedarkmod.com/view.php?id=5538 Except there the crash happen after the first conversation, while I think you are talking about the second.

The build is created off the current development trunk, so it incorporates all the changes done during 2-3 months since 2.09 release. In fact, it is closer to the last development build than to 2.09 release. Of course, development builds are much less tested and include new features, so you might have various new problems on them. We would be happy if you test dev builds and report any new issues/bugs you see, but it is strongly advised to have a clean 2.09 version nearby (and probably use it most of the time for ordinary playing). By the way, savegames are most likely incompatible between 2.09 and dev build.

Also, it seems that game console works to full extent now, as Windows version. Previously I had problems with up/down for repeating previous commands, and probably with autocomplete too.

It seems that dragging lower-bottom corner of TDM window changes resolution. But unlike Windows version, it is very hard to get control of mouse cursor to actually do it. I only managed to drag corner when FM is loading, since at that moment the game is not responding and its mouse-locking feature does not have effect. After loading is over, the resolution indeed changes.

I assume grayscaling is performed by OS in Windowed mode:

By the way, do you have AMD gpu?

Please provide savegame before the crash. And instructions how to get to the crash...

Caulk surfaces are not rendered at all, normal surfaces are rendered, even through you don't see them. No idea how big the performance difference is. I bet the actual rendering of invisible brush surfaces takes negligible time, but additional frontend processing and shadows might take some time. I'm not sure it is worth wasting your time replacing the brushes now. But it is probably a good idea to use caulk in future missions.

On latest dev build, we have dedicated dmap diagnostic for this type of problem: 5354

Do I need to worry about glfw update? To be honest, I hope glfw won't need constant updates like OpenAL did...

There are almost no lights outside, and almost no shadows. @Gadavre has already discovered that shadow settings have absolutely no effect on this scene.

Also I believe these bushes eat too much performance for their relatively unimportant role: When I stand the shore and rotate camera, I get severe FPS drop at the moment when my frustum starts including this thing.

Here is what I mean: Although I must admit the wall/fence is not tall enough to occlude the whole castle. But still, should improve performance, I hope

I have looked into the outside visportals in the map. The visportals on the left/right of the castle are pretty good, I think they do their job well. The visportals in front of and behind the castle are strange, they don't help rendering in my opinion. Since I doubt they help with sound propagation too... it seems that removing them will not changed anything. Remove them all. If you have vast space without notable blockers, everything is generally visible from everywhere, and sound travels straight, then there is no reason to put any visportals. Another problem with these portals is that they seem to be intersecting. I think intersecting portals is a very bad setup in any case. Now here is the idea of what might actually help. It is a great luck that your map includes a fence/wall in front of the castle, which reliably blocks the whole castle in the mentioned camera shot. We just need to put portals in such a way that they don't allow light to go through this wall. To achieve it, add two portals in the plane of this wall: One huge portal just above the wall. From below, it should contact the top of the wall. On the other three sides, let it span over the whole map. One small portal where player enters the yard (goes through the wall). UPDATE: Actually, there is more than one entering, an each one should have its own portal of course. With such portal setup, anything which is not behind these two portals will be culled away, which should include the whole castle. UPDATE: A rough plan:

I remember how I got an excellent idea how to place visportals in starting outdoors area of "Hidden Hands: The Lost Citadel". Spend several hours on putting it into place (I'm not a mapper), but in the end it did not make considerable difference I'd suggest asking some experienced mapper to take a look...

It is quite likely that simply downloading the missing FMs won't fix the installation. The symptoms look like a permission problem, as @freyk suggested.

That's the problem of the AUR package then. The proper install of TDM should include Training Mission, New Job, and Saint Lucia FMs. If you want to install the game via official way, you should follow the instructions from the website. Just be sure to select appropriate installation directory, the one where you have full write permissions without going root.

Yes, there are already discussions on development forum about simplifying blackjacking. The latest status was that we wanted to understand which of the rules cause the most problems. On the latest dev build, you can set cvar "tdm_melee_debug 1", and it will show you what went wrong during blackjacking: If you see AIHit:head after hit, then you hit the right part of the body. If you see AIHit:torso or something else, then blackjacking failed because of hitting the wrong part. If you see red sphere after hit, then you failed the so-called "cone checks". These checks forbid hitting directly into face and also take into account helmets (and probably alarm/alert status). Play for some time, write down the reason for every fail, then post statistics. Also please write down for each case whether the guard had a helmet, was he sitting/slipping, and was he alerted. If he had weapon drawn, that is also worth mentioning. For me personally, there are two big problems: Blackjack hits low ceilings and doorways before hitting a guard. That's damn annoying and there is no workaround. Helmeted guards are harder to blackjack. I'd better drop any helmet-related adjustments for blackjacking, because with such an unclear KO system, this "added difficulty" only adds frustration. If guard is not alerted, has no helmet, and stands/walks around, I generally have no problem blackjacking him.

I have run ldd on thedarkmod.x64|x86 to see if the situation has changed. Obviously, TDM 2.05 linked both glibc and C++ library dynamically, and recent TDM only links glibc dynamically. So the problem of glibc compatibility has been like that for ages: in fact the situation has probably improved a bit with migration to CMake. Here is the ldd output (darkmod_205/* is 2.05 and darkmod/* is your binary):

Yes, I tried to add -static, added a bunch of additional X libraries, and in the end built static executable successfully. But 1) it crashes on start even on my system, and 2) it prints sane warnings that it will need exact same version of libdl.so in order to run, making the static linking pointless. So we can: build on old Ubuntu and hope it works... suggest people who cannot run TDM executable to built it themselves... dive into the great world on Linux compatibility. I'll choose the first two ways

I get this on Ubuntu 16.04: ./thedarkmod.x64: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.27' not found (required by ./thedarkmod.x64) ./thedarkmod.x64: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.24' not found (required by ./thedarkmod.x64) Which is rather strange, because as far as I remember, we wanted to link all runtime statically. UPDATE: Looking at UCM source, it seems that we only link С++ standard library statically now, but glibc is linked dynamically. I wonder why no one has noticed it yet: my Ubuntu is only 5 years old, I'm pretty sure there are people who have older OS...

No.

New dev build is available: dev16225-9284

@r.a.sattarov, I have done major refactoring around SSE and x86-related features (see 4550). Aside from the fact that I could have broken compilation on Elbrus (or maybe SSE2 simd processor), I think these changes do not change much for Elbrus, because the compiler handles SSE intrinsics perfectly well.

I have covered all the x86-specific trash in proper ifdefs (see 4550). Even managed to cross-compile TDM for 64-bit ARM (stopped at linking phase). Note however that: Recent trunk requires OpenGL 3.3. Even Raspberry Pi 4 does not provide it. In order to link TDM, you have to build all third-party libs for your platform via conan --- that could be hard.