stgatilov

You can download binaries and they'll probably run. Then you can download source code, and follow instructions in COMPILING.txt. If it won't build due to third-party libs, then read ThirdParty/readme.md thoroughly. Rebuilding dependencies is not very reliable though.

The implementation of volumetric lights in 2.10 uses dithering to reduce performance impact. What you show here is exactly the dithering effect: the image looks good in large scale, but on small scale it is a mess of pixels. Moreover, the more high-frequency details you have, the more apparent the dithering artefacts become. So there are only 2 explanations why scene looks better with stencil shadows: Because when you use stencil, volumetric light is disabled --- that's default behavior of volumetric lights in 2.10. Because when you use stencil, volumetric light is used without shadows. This makes dithering artefacts hardly noticeable, since the light itself is very low-frequency, while shadows are high-frequency. With new dev builds, you'll have dithering artefacts as you see in 2.10 with shadows maps, but now you'll see them regardless of your choice. And the reason for that is that now volumetric lights always take shadows into account if mapper wanted them to exist. We plan to add blur and thus remove dithering artefacts: 5850

@Obsttorte, I recommend searching for "ko_angle_horiz" spawnarg and bumping it at least to 180 degrees to improve situation with helmeted guards. I don't think you need to touch alerted counterpart. Also, there is tdm_melee_debug cvar, under which I added some debug visualization. With your changes, it is a bit messed up, but still usable.

Here is one example. To be honest, it is confusing that whether KO is successful or not changes while guard slightly moves around due totally idle animation. But I think I waited for long enough in this case...

I tried the latest trunk and saw the blackjack animation. I'm not sure what the animation itself intends to solve? I see cases where hand is not raised but hit causes KO. Aside from that, the target often moves, in which case this animation lags too much behind. And it feels like a visual noise in general, because the hand goes up and down all the time. As far as I remember, I detected only two problems with KO: Ceiling or doorway blocks it: very annoying for everyone. Helmeted guards are hard to KO, meaning that some hits fail pretty randomly. There are some standard rules about when and how someone can be KOed. I suppose it's something like: Civilian: in any state from any direction Guard: from any direction (maybe only from behind when alerted) Helmet guard: only when not alerted and only from behind Helmet + face grill: no way to KO I recall I suggested removing the additional difficulty in KOing helmeted guards. Because adding such unpredictable difficulty in this case only makes player's life more annoying: if he wants to KO helmeted guard, he'll do it anyway, but after a series of reloads.

Committed the rename in svn rev 10080.

Regarding packaging. The easiest way is to take some existing build, then use zipsync patch to overwrite some of its files. Before that, you need to do zipsync normalize + zipsync analyze to create a small package from the files you want to overwrite. Regarding server. Yes, you need to make it available on any HTTP server. The HTTPS protocol requires an additional TLS library to make it work, and tdm_installer does not include one currently. To be honest, I don't understand what's the benefit of forcing HTTPS for statically hosting a bunch of files. HTTP 1.1 from 10 years ago works perfectly well today, while in HTTPS they release new version of TLS every so often, then declare the old one as insecure, then block all software from working with it, breaking tons of websites. Maybe I should just add TLS to tdm_installer and allow https:// kind of URLs. Although it can cause even more confusion because people will write https:// instead of http:// and be surprised that it does not work. Regarding installing it. Yes, the user needs to go to "Custom Version" screen, paste the URL of your build and select which stock TDM version it was based on. That's because stock versions have yet another manifest which describes all dependencies between them, but your custom version does not. Regarding shaders. I have been changing shaders extensively, including some changes after the most recent dev build. You need to combine engine with the shaders of the same version. So if you build executable from latest SVN but use glprogs from dev build, then they won't work together. You need to copy glprogs directory from you darkmod_src repo to your zipsync patch, so that your package includes them as replacement. That is rarely a problem today, but now is a particularly unlucky moment.

dev16599-10071 is released. See second post for changelog.

Yes, all those missions have incorrect GUIs, including Saint Lucia and New Job. The original GUI engine did not report any kind of error, just tried to continue doing something. And it had some bugs. The latest GUI engine reports almost all issues as warnings, has most bugs fixed, and still tries to continue despite errors.

There are more changes in dev16599-10071, please read the original post. Basically: vector component indexing is fixed expression evaluation order fixed don't disable auto-updates of register because of a reference to it Set command can now have expressions on right side I wonder if we have information about GUI scripts anywhere that should be updated?

We did some refactoring related to shadow modes, and as the result we can now easily switch between stencil and shadow maps on per-light basis. Starting from dev16599-10071, volumetric lights display properly with stencil shadows mode selected in settings menu. It works by forcing the particular lights with volumetrics into using shadow maps instead of stencil shadows. The special "volumetric_noshadows -1" setting is useless now, as well as the whole volumetric_noshadows spawnarg.

You are not alone with this problem. I have added this thread to https://bugs.thedarkmod.com/view.php?id=4109#c14687 Yes, we'd like to fix it. But I'm afraid it won't happen soon.

There is platform-specific piece of code which creates OS timer that wakes up every so often and bumps "tic number". This code is completely different on Windows and Linux. Perhaps Linux code is just bad in some way.

Are you going to start an initiative on choosing the most-liked default value? Unless the majority of people thinks they like different default value, it's better to not change default.

Committed the change as svn rev 10042.

CMake + make is no different from that! When I run my script, it only compiles the cpp files that have changed. Of course, with massive PCH you often have to recompile everything, which is not a problem for Windows, but a lot of time for Linux. Also, there are some first steps (like creating PCH) which take much time, which is rather annoying too.

I sometimes have mouse cursor lockup due to messing with game console, and pressing Alt a few times usually fixes it. Unfortunately, Alt is a system hotkey, at least in Ubuntu. Aside from that... use windowed mode? tweak some in_XXX cvars?

Ok, I think it depends on how you ran CMake. This is the script use: cd ../darkmod_src cmake -B build/linux64 -DCMAKE_BUILD_TYPE=Release cmake --build build/linux64 -j 6 cd ../darkmod If you did not set it, then you have it in some different place.

By the way, you can also reduce size of console font now, with cvar con_fontSize. Immensely helpful if you look through it often! I almost halved it and my life has become so much better

Object files should be inside build\linux64\CMakeFiles\TheDarkMod.dir Actually, they are in a similar location on Windows too. Saving intermediate build files near source code is very annoying

I wonder if we should just have one mega-var, which would disable all kind of camera deviations? Maybe even attach it to a checkbox in main menu gameplay settings...

I'm open about GUI engine improvements, as long as they don't break too much existing code. I don't think I want to spend much time on the actual GUI code, aside from fixing planned issues: 5852 5282

If I had such problem, I'd look for the object files of GLAD, where these functions are defined. If they are present, then run objdump to check that the missing symbols are indeed there or missing (they might have slightly different name for instance). If they are missing, then review the whole compilation log for appropriate .c files.

dev16574-10036 is now public. This includes tons of assets fixes, GUI warnings, and BVH-assisted optimizations. Quite a lot of breakage potential

When a light interacts with a surface, Doom 3 engine goes through all triangles of the surface in order to detect which ones are within light volume and front-facing. If the light constantly moves, then this processing has to done every frame. If stencil shadows are used, then engine has to look through triangles once again in order to build shadow volume. This implementation detail means that large static meshes with small dynamic lights nearby can be surprisingly slow. I think this issue happened several times recently: Black Mage: the lava cave Moving Day: rocks in the starting area The workaround was usually to split large mesh into several pieces. The latest dev build dev16574-10036 includes BVH-assisted filtering algorithm, which is enabled by default. It does the same job faster, without the need of touching clearly out-of-volume triangles. As far as I know, it totally solves the original problem, so you no longer need to be wary of how large your terrain mesh is. The new algorithm is enabled by two cvars, which can be changed at runtime: r_modelBvhLightTris r_modelBvhShadows Default values 3 and 1 mean precise filtering with BVH (default), zero values mean precise filtering using Doom 3 code. Note that the new algorithm reorders triangles in static meshes, so it has some influence even if you disable the above two cvars. The total kill switch which disables all BVH code is cvar r_modelBvhBuild, which must be set before starting mission. Here is a test map to show results (Bikerdude stripped for me from NHAT forest). All the terrain and stones are a single LWO mesh: 28 MB size, 127K vertices and 212 K triangles. P.S.: There is no performance difference on most existing missions. You can notice the difference only in critical cases.