Jump to content
The Dark Mod Forums


Active Developer
  • Posts

  • Joined

  • Last visited

  • Days Won


stgatilov last won the day on May 16

stgatilov had the most liked content!


2005 Deity

About stgatilov

  • Birthday 08/26/1989

Contact Methods

  • Website URL
  • Jabber

Profile Information

  • Gender

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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.
  3. 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
  4. 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.
  5. 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.
  6. 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.
  7. No idea. To be honest, md5 models are not just "models", maybe they are in different category (like reloadAnims or reloadMd5) ?
  8. 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.
  9. 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
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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...
  15. dev16487-9919 is public. At the very least, the Linux crash should be fixed there.
  • Create New...