stgatilov

I temporarily removed the mission from in-game downloader by @geegee request. Could please someone who had the T-pose guards issue update to the new version of FM and post whether they still have the issue or not?

I'm very sorry for the long delay on this matter. I have extracted two fixes from the patch and committed them to SVN (no cvar): 5961 Fix rope/ladder speed while crouched 5973 Change crouch state on key down with crouch toggle Speaking of the rest of the patch (5962), I did not commit it. As I said, I personally don't like this behavior change, and given that it adds some stuff to the code, I'd commit it only if several team members agree that it is worth it. However, @Daft Mugi has found two more issues which are still present: 4247 Using the crouch key when climbing a ladder or a pipe 1746 Climbing physics should use crouched player bounding box I think the real problem here is that when player is on rope/ladder he can oncrouch, but he cannot crouch. I have no idea why. I'd say: we should allow player to crouch and uncrouch regardless of whether he is on rope/ladder or not. That would be simple and consistent, and will solve the issue of going into narrow ventilation shaft immediately after climbing a ladder.

We have never removed any FM from the new database yet. Looking through the scripts, I think simply removing the directory should work. The best thing would be to "svn move" the directory outside "fms", so that later we can "svn move" it back with some updates. @geegee, Should I do it right now?

It takes the latest quicksave. Perhaps main menu does not display both keys because one is "loadgame" but another is "loadgame quick". While they are functionally equivalent, the code which displays controls in the menu is not smart enough to understand that. Of course, it would be more appropriate to use the same command for both keys, which will probably fix the display error. Or even better: change to F5/F9 scheme without alternatives

I am also annoyed with F4+F5 combo every time I reset my config or take a fresh release installation. I think F5+F9 combo is more standard today, and it would be great to change. I see the following in default.cfg: bind "F4" "savegame quick" bind "F5" "loadgame" bind "F6" "_impulse20" bind "F7" "_impulse22" bind "F9" "loadgame quick" How "loadgame" is different from "loadgame quick"? void LoadGame_f( const idCmdArgs &args ) { console->Close(); if ( args.Argc() < 2 || idStr::Icmp(args.Argv(1), "quick" ) == 0 ) { idStr saveName = GetMostRecentQuicksaveFilename(); sessLocal.LoadGame( saveName ); } else { sessLocal.LoadGame( args.Argv(1) ); } } There is no difference. You pass filename as argument, or "quick" to load latest quicksave. But if you don't pass an argument, it just default to "quick".

Yes, I think it is very likely. If they stay dormant since the beginning of the mission till the moment you see them (which is a bug of course), then you should see them as T-pose still figures. If someone can reliably reproduce the issue from fresh start, then it would make sense to drop the spawnarg on these AIs and check if it helps. To be honest, I recall seeing guards in T-pose some time ago, most likely when I tweaked/broke something. I'd suggest to check if people who have/haven't the issue have the same version of TDM: maybe e.g. they use dev build where this is broken. UPDATE: I think I got T-pose guards after I set wrong cvar related to AI interleaved thinking. Surely not the problem that people have, but the mechanics is the same: AI has never "think"-ed -> you see T-pose AI.

I'm pretty sure developers will find this thread useful! Personally, I'm not very good with assets, so I'll avoid integrating these myself... But I'd like to warn about one thing. Sometimes moving/renaming an asset or file looks like a simple fix for a problem or a warning, but keep in mind that this asset can be referenced elsewhere, even from unexpected locations. So careless moving/renaming of core assets can do more harm than good. I created a script in assets SVN (devel/find_in_fms.py or something similar) which can search files in FMs for a particular string or regex. Perhaps it is not very easy to use, but it helps to find all usages. Of course, it requires all FMs be downloaded locally (from missions database SVN).

TDM 2.11 should work perfectly on Windows 7. It is only dev builds which are affected, and I hope to fix that. There is no reason to avoid TDM updates: tdm_installer allows you to downgrade your installation if you find that new version has some critical issue.

It applies to all dev builds I think. I have added it to changelog as "known problem". For more detail, go here:

Yeah, one of the libraries does something which does not allow it to boot on Windows 7. We hacked around it for 2.10 release, but for dev builds we returned back to clean state. Actually, the developers of Tracy has changed the way it works, so if we update Tracy, the problem should go away. Unless I forget about it, I hope it will be fixed in the next dev build, sorry. P.S. Or you can actually try to update your dbghelp.dll by installing Windows 10 SDK. Note that it would eat some hundreds of MB of space on your drive.

Personally, I don't see a reason for having a cvar for "crouch toggle on key down". I think it is a universal improvement, and it does not go against people's habits. As for ladder/rope thing, I'd better wait to hear more opinions.

Hey, most of the new C++ features are added in minor updates of VC! They arrive under new compiler switches, though It just shows that even great developers like STL in companies like Microsoft sometimes break things which must not be broken, and that brings major suffering onto many users I wonder if they'll fix this issue on VC2022, or simply let it live until the next major version of VC.

That's very strange. I believe your installation was not perfectly "clean", and the saintlucia directory was present before update. I have seen such behavior many times after update, but never on fresh install. Here is the full story. the original version of Saint Lucia mission had codename saintlucia. That's how the directory and the pk4 file was named. At some moment it got a major update, and the new version was called stlucia. Right now it seems that changing codename was not a good idea, but I can imagine it being more convenient at the time when the change happened. Now the thing is: tdm_installer does not remove empty directories. It removes existing files if it believes the files are part of the core game (start with "tdm_" or belong to a hardcoded list), but if a directory becomes empty because of that, it remains. That's why if you upgrade TDM from an old version before the Saint Lucia update to the new version after the update, you'll get an empty directory. Just let it be. Sometimes being perfect is hard and yields no benefit anyway

Yes, the engine uses limited number of threads, so most of the CPU cores cannot be utilized. Also, don't look at memory utilization. TDM loads the whole level into RAM & VRAM, so unless you have too little memory, its size does not matter. Enable frontend acceleration (helps if limited by CPU). Reduce antialiasing and soft shadows quality (helps if limited by GPU). Prefer stencil shadows if limited by GPU, and shadow maps if limited by CPU. Just accept that FPS will drop at some places. Mappers cannot make it 100% sure any system will handle map perfectly in every corner.

Yep, this diff format can be naturally applied with TortoiseSVN. Speaking of the code: You don't save/restore the new flag in idPlayer. Cvar description "Set to 1 to make toggle crouch on key press instead of key release"... standard terminology for keyboard events is keydown/keyup, and keypresss, where keypress is a composite event which happens only when the button is released Maybe clarify it as "to toggle crouch on keydown instead of keyup" ?... Speaking of the testing: It feels much better when crouch toggle triggers on key down instead of key up. I like it I don't like the auto-standup behavior on a ladder. The old behavior makes more sense to me To me, these two changes (keydown vs keyup and ladder+rope interaction) are orthogonal. Maybe I miss something? Is there some problem with the old behavior regarding ropes/ladders? Other opinions on the change of behavior are welcome.

I'm trying to get TDM build working on my laptop. Just installed VC2022, and now I get the following error: 1>OpenAL32.lib(alc.obj) : error LNK2019: unresolved external symbol __imp___std_init_once_begin_initialize referenced in function alcOpenDevice 1>OpenAL32.lib(alc.obj) : error LNK2019: unresolved external symbol __imp___std_init_once_complete referenced in function alcOpenDevice Searching has lead me to this issue: https://developercommunity.visualstudio.com/t/-imp-std-init-once-complete-unresolved-external-sy/1684365 https://github.com/microsoft/STL/issues/2655 Obviously, developers accidentally broke binary compatibility on minor update of Visual C++ compiler (in version: 17.2 Preview 2). While they are seeking the way to fix it, I'd recommend to not update your Visual Studio in the near future. If you already suffer from this issue, then you can workaround it by adding the following e.g. to the end of Lib.cpp: #if defined(_M_IX86) #pragma comment(linker, "/ALTERNATENAME:__imp____std_init_once_begin_initialize@16=__imp__InitOnceBeginInitialize@16") #pragma comment(linker, "/ALTERNATENAME:__imp____std_init_once_complete@12=__imp__InitOnceComplete@12") #elif defined(_M_X64) #pragma comment(linker, "/ALTERNATENAME:__imp___std_init_once_begin_initialize=__imp_InitOnceBeginInitialize") #pragma comment(linker, "/ALTERNATENAME:__imp___std_init_once_complete=__imp_InitOnceComplete") #endif I'm not yet sure if we should commit this workaround, to be honest In theory, it does not break build, but adds a last resort option: if linker doesn't find symbol {nameonleft}, then it tries to use symbol {nameonright} instead of it.

No idea. To be honest, md5 models are not just "models", maybe they are in different category (like reloadAnims or reloadMd5) ?

No, we simply use the recommended directory structure, and everything works out of the box. I mean: C:\thedarkmod\darkmod_src\TheDarkMod.sln C:\thedarkmod\darkmod\TheDarkModx64.exe One thing I'll say for sure: better not mess with paths without critical need You can break too much stuff.

I fear there won't be any fix for this. Drivers won't get updated because I suppose this series of GPU is considered to be too old today. And to the best of our knowledge, there is no good way to detect this driver defect on TDM side. The best idea yet is to automatically create a screenshot of the menu after a few seconds, then run some heuristic image analysis to detect if it is broken . That's totally unreliable, and will need considerable effort to implement. Regarding FAQ... If you have looked through several FAQ locations, please post links to them, and we'll add information. One of the problem with community-driven wiki is that it gets filled with too much information over time, with most of it becoming irrelevant/outdated

Sometimes people leave such prefix, sometimes they don't. It is especially helpful when you do a small change to the code you did not originally implement, so that it is clearly modification by another person. In the worst case, one can always do svn blame and see author + commit message.

The material paths will certainly remain as they are. I think the question is more about the workaround for 63 character limit in Blender models. Skins can probably do, although... won't you get a warning if your skin maps a nonexistent material name into something? Maybe we can optionally write material mapping information in some other section of Blender file? Like description or some kind of extra? Then take it into account in converter.

About ways to share a patch. If you have SVN working copy, you can simply create SVN patch and attach it to forums post. Better mention which SVN revision your patch is based on. If you don't have SVN working copy (e.g. downloaded source code archive), then I guess you have to use some diff tool between directories. To be honest, I don't remember doing it myself. WinMerge is good for directory diff, but I don't know if it can actually save the changes as some patch... I'm currently travelling and don't have access to TDM development, so I'll trust the decision of "how should it work in various situations" and testing to the other members of TDM team. But I'd be happy to read a source code patch anyway.

Ok, thanks! I'm afraid I can't work on TDM for uncertain amount of time (week or weeks)... Speaking about putting this to flatpak repo. I won't be surprised if they accept only the manifests which build stuff from source code. At least, I heard that's the policy of Linux distributions.

Ideally, you should have checked out "trunk" directory only, so that its contents get into "tdm11dev/darkmod_src" instead of "tdm11dev/darkmod_src/trunk". Do you BTW have all the "branches" and "tags" directories near "trunk" ? Maybe not, because they are still closed for public for some weird reason...

dev16487-9919 is public. At the very least, the Linux crash should be fixed there.