Jump to content
The Dark Mod Forums

stgatilov

Active Developer
  • Posts

    5394
  • Joined

  • Last visited

  • Days Won

    135

Everything posted by stgatilov

  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.
  16. The third-party libs were changed somewhere around that time. Maybe I had some uncommitted changes when published that update?... Try revision 9882, or revision 9888, or 9891.
  17. Fixed libjpeg in trunk. You might want to change r_screenshot_format to avoid using jpeg for savegame screenshots. Although it won't help you if someone uses jpeg file in texture or as SEED map.
  18. Yes, @nbohr1more has them too. TDM does not use system libraries so your version should not matter. That's very strange: the changes in libjpeg first appeared in dev16481-9881, so the same problem should happen on that build too.
  19. I doubt D3 Gui system supports that, so that would be too much of effort for such a minor improvement.
  20. Yes, the plan is to remove only headbob, since it is cosmetic and has no gameplay consequences. As for running/swimming speed, these settings should be taken from mission, or from hardcoded defaults. It is OK if developers can change them for debugging, but such changes should not persist I think.
  21. So... will you commit this removal to assets SVN? I think allowing players to disable head bobbing is more important than allowing mappers to customize it. Do we need more opinions? @Dragofer @kingsal @Goldwell @Springheel @Obsttorte
  22. It is very hard to get OpenGL 3.3 inside VM. For Windows host + Linux guest, VMWare is the only VM I know of which can do it. TDM works rather slowly (enough for testing, but not enough for playing comfortably on my machine). Yes, XP support was totally terminated several versions ago, as @nbohr1more noted. Of course, you can download source code of 2.10 and try to enable XP support. For 2.11, that would become totally impossible, because I believe newer VS does not include XP support at all. I won't be surprised if tablet's hardware is too weak to run TDM even without VM... That's not entirely true. 32-bit binaries are deprecated and are not installed by default. But you can still download them for the latest major release of TDM, there are instructions on website downloads page. But yes, trying older version is the best idea here. Older versions need lower version of OpenGL (e.g. 2.1), are 32-bit and support Windows XP.
  23. I played a bit inside flatpak. First of all, the sound issue goes away after 30 seconds of playing. I guess it is some kind of race condition... I checked that settings are saved properly, games are saved/loaded, missions are downloaded. I think everything works. I did a few changes to the manifest: 1) Changed URL to https://update.thedarkmod.com/zipsync/tdm_installer_fixed110.linux64.zip --- that is fixed version of installer that will be the same in the future. Some sort of compromise between changing sha256 every time and adding tdm_installer binary to the manifest archive. 2) Added semicolon to two lines of .desktop file, because flatpak builder (or maybe something else) prints warnings about them (I suppose these properties are lists, and lists are semicolon-separated and -terminated): Categories=Game; Actions=Installer; Also, I see warning about PrefersNonDefaultGPU property: it says that the property must start with X- because it is not a standard one. I think my OS is too old, and the property was added recently, so there is nothing to do about it. tdm_installer marks installation path as red because it contains dot characters. Don't remember why dots were not whitelisted (it installs fine)... maybe to avoid confusion between files and directories. Is it possible to avoid ".var" subdirectory, and what is $XDG_DATA_HOME ? I don't like that many gigabytes are stored in a directory which is hidden by all file browsers. Yes, renaming last directory from TheDarkMod to darkmod is a good idea. And the bug that I referenced probably triggers only when two directory components are equal to "darkmod".
  24. Ok, I ran TDM within flatpak, and I get terrible noise instead of sound with "[ALSOFT] (EE) available update failed: Broken pipe" spam. It sounds like the game fills the sound buffers only a few times per second, so I hear 3-5 brief pieces of sound samples per second. That's what I see when spam starts: ----- Initializing OpenAL ----- Setup OpenAL device and context OpenAL: found device 'ALSA Default' [ACTIVE] OpenAL: found device 'Ensoniq AudioPCI, ES1371 DAC2/ADC (CARD=AudioPCI,DEV=0)' OpenAL: found device 'Ensoniq AudioPCI, ES1371 DAC1 (CARD=AudioPCI,DEV=1)' OpenAL: device 'ALSA Default' opened successfully OpenAL: HRTF is available [ALSOFT] (EE) Failed to set real-time priority for thread: Operation not permitted (1) [ALSOFT] (EE) available update failed: Broken pipe When I start native TDM binary, it works fine, but prints exactly the same log as posted above. So I suppose lack of real-time priority is not critical. I can only speculate that VM uses some custom sound settings, but flatpak does not catch them. All sounds in-game lag by almost half a second. Also sounds in Firefox play immediately.
×
×
  • Create New...