stgatilov

@snatcher, I uploaded second debug executable: https://drive.google.com/file/d/1vP_XcRAo8-YQeibMsprT72ANZFKZo8Iq/view?usp=sharing This time I hope to learn who posts the event for deleting attachment...

According to the last three events, someone deleted the arrow from script: The first two events happen inside GetWeaponDef when player switches from blackjack to bow. This should be the only place messing with the weapon. Two attachments (aimer + arrow) are added here. But then the arrow gets destroyed inside ServiceEvents, which is unexpected. Normally, it should be destroyed in the same GetWeaponDef at the very beginning, before creating new attachments. This is either triggered by script code, or by C++ code which posts delayed event.

Yeah! I can successfully reproduce it now! It's really next page + close book sequence. In my case it work both with mouse scroll + Enter and with NextInvItem key + Enter. Also it works both directions (next or prev page). UPDATE: can reproduce on New Job as well, so I guess any pickable book is affected at least. Created an issue: https://bugs.thedarkmod.com/view.php?id=6313

I built a custom TDM 2.11 executable with console logging when entity is attached and destroyed: https://drive.google.com/drive/folders/1gdXD9nugu4rgHwCIx-KX3ZefdteHizjI?usp=sharing So you can do the following: Unpack both files to TDM game directory. Run thegame with new executable. Set "logfile 2" so that all console text is recorded. Reproduce the crash. Find qconsole.log in the FM directory and post it here. When this is over, make sure to revert cvar "logfile" back to its default value, and run tdm_installer to recover old executable if you didn't save it.

I uploaded a new version of installer. Of course, you need to rename old version to its original name for it to self-update. The nonsense is fixed Now self-update URL is hardcoded at build time. I did not remember whether periods in path are forbidden because they don't work or because they would result in confusion for Windows users (accidentally writing/copying filename would result in installer eagerly creating a directory with such name). I simply added this information to the tooltip. Apparently, your confusion came from the fact that you read the tooltip, but its contents did not mention that periods are not allowed (it's not mentioned anywhere at all). I added the button to "Browse" GUI. The installer is using lightweight FLTK for GUI, so it looks different from native applications, but it should work. The problem had nothing to do with permissions. But speaking of permissions, the installer shows a warning if user runs if with escalated privilages and discourages user from proceeding. That's because the installer does not mess with OS-specific stuff, so if it creates all the files under admin, the game will only be properly playable under admin too.

I think I have already seen such a state. The crash happens in idWeapon::BeginAttack because "idEntity *e" is NULL. Player's weapon has two attachments: "idStaticEntity_atdm:attachment_aimer_8" --- this one is alive and OK. Some second entity which has already died by this moment. So the question is: what is this second entity, and is it OK that it is dead at the moment of attach? UPDATE: The second attachment usually is something like "idStaticEntity_atdm:attachment_broadhead_30"...

As far as I know, it contains complete virtual memory contents of TheDarkMod process at the moment of crash: https://learn.microsoft.com/en-us/windows/win32/wer/collecting-user-mode-dumps Maybe it has some stuff in the header (like OS build, CPU info), but I can't say anything for certain. It should not contain any data from other programs of OS, as far as I know. Note that kernel-level dumps are a very different thing: https://learn.microsoft.com/en-us/troubleshoot/windows-client/performance/generate-a-kernel-or-complete-crash-dump They indeed contains memory contents of OS and probably other programs, so don't send them to anyone untrusted (or just don't send them).

It's probably updated on timer, nobody cared about book lagging behind a bit.

Crashdump should compress very well. Please share it somewhere It is version 2.10, right?

You are talking about DOF effect exclusively, I don't see how antialiasing can be achieved this way. Also, blurring does not actually antialias, except if it is strong blur.

I guess the reason is that there are several platforms (3 actually), and this behavior was a simple way to support them all without hardcoding all the platforms into source code. But yes, the fact it stops working after rename is not good I'll try to fix it somehow. I'm not sure what the problem is exactly. The red color for installation path is set based only on the text only. As I see in the code, having a dot character in path is the reason. I cannot recall why exactly I did it, but I'm pretty sure I was aware of some problem with this case, so I blocked it out. I'll try to add this button, why not.

TDM has such an implementation, called something like camera jittering. It was used to create high-quality screenshots. It jitters both camera and light positions, which results in perfect antialiasing and soft shadows. But it is very slow, and the resulting images are basically a lie. As far as I remember, it stopped working at some moment because the engine is constantly being modified. Anyway, this idea is useless to combat complaint about MSAA being slow. And simply blurring the whole image would result in trash of course.

As far as I remember, there are some presets hardcoded in source code. There is no "default" preset: when you select preset, all the individual presets are assigned values as hardcoded into the source. So preset is not like cvar, it's more like a command.

dev16818-10434 is available. As for renaming Stealth Score, I see lengthy discussion but no resolution yet...

Frob outline is dead since 2.11. People can still use it because the code for frob outline has not caused much trouble yet. The frob stages are still used. The main difference is that now they are automatically generated for all materials, and tweaking them takes less text in most cases.

I committed your patch. Not sure this is about standards BTW.

Yes, these states were added during the big main menu refactoring. At that point I supported skipping states because of well-known "how to skip GUI briefing after video?" issue (also Grayman asked to skip something like success screen). Of course, dozens of old missions still target explicit state. They do work as intended. If you want to modify them to skip something, better fix their GUI to new conventions first.

Perhaps you look at missions which explicitly specify MM_STATE_OBJECTIVES as the state to switch to in their customized GUI code. You cannot simultaneously disable a screen and switch to it As a rule of thumb, only MM_STATE_FORWARD and MM_STATE_BACKWARD should be used to switch screens. This approach should play nicely with disabling states.

I think there is a define for difficulty selection screen in custom_defs which can disable the difficulty selection. But to be honest, I don't know what would happen with difficulty-dependent things in this case...

Perhaps you did some OS/driver update? The only other thread with same error is: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8350 And it is some kind of shadere compiler bug that has been fixed. Maybe you can update or downgrade something in mesa...

A known appraoch is to do screen-space raytracing from rendered fragments as additional check. But it is quite costly this would return some shadow boundaries to hard shadows... and also I'm sure it will bring even more artefacts as screen-space technique.

Yes, exactly. There is single code piece which handles "fromVideo", and it accepts material name, as FFmpeg video wiki says. And the virtual sound sample is named like "fromVideo {mymaterialname}", by this name you assign subtitles to it. Yes, but you need to change the SUBTITLE_NAMEPREFIX to something unique, or you'll get a ton of warnings about name collisions. I think standard debriefing video should not be skipped. As for debriefing, we don't have anything like that yet in core.

I'm pretty sure I tested this case. Note that subtitles display only if there is appropriate GUI. If you have your own overlay or own GUI file, then you might be missing proper #include of subtitles.

Simple reason to avoid local shadowing parallel light of any kind: And this is fully within one area. When walls, areas and portals appear, things get worse.

Actually, "parallelSky" spawnarg implies "parallel" in the engine. You don't need to set both flags, just make sure to set "parallelSky". For a noshadows light, they both behave exactly the same and have no issue. In terms of spawnargs, "parallel" spawnarg without "parallelSky" spawnarg should be deprecated. I think this is what I can check in dmap and give a warning. Maybe I'll exclude noshadows "parallel" case because it is equivalent anyway. In terms of functionality, there is nothing being deprecated: parallelSky serves as better replacement or is the same in every case. Yes, local shadowing parallel lights never worked, still don't work, and I'm afraid will never work. If someone wants to use them, he can slap "parallelSky", but I'd seriously advice against the very idea.