Jump to content
The Dark Mod Forums

stgatilov

Active Developer
  • Content Count

    1904
  • Joined

  • Last visited

  • Days Won

    29

stgatilov last won the day on July 26

stgatilov had the most liked content!

Community Reputation

566 Legendary

About stgatilov

  • Rank
    Lead Programmer
  • Birthday 08/26/1989

Contact Methods

  • Website URL
    http://dirtyhandscoding.github.io
  • Jabber
    stgatilov@gmail.com

Profile Information

  • Gender
    Male
  • Location
    Novosibirsk, Russia

Recent Profile Visitors

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

  1. Only if you will build it yourself. I can try to make some experiments, probably it could work with little changes --- then I could send you a patch on source code. Separating one DLL from EXE means you will either have two CRT or you need to separate CRT into its own DLL too, in which case you also need to install VC redistributable on every player's machine... Let's say we had this for 2.06 and 2.07 and it did not work well enough, so we have reverted to the old way, "acknowledging the wisdom of our ancestors" For the majority of players having one EXE with everything is much better. UPDATE: BTW, setting cvar s_nosound or something like this should disable all sound. It would probably circumvent the crash, but of course at the cost of sound. We can try to update OpenAL. Initially, we had version 1.18.2 in 2.06. Then I updated it to 1.19.0 somewhere after 2.07, but it caused some problems, so we reverted it back. Now 1.19.1 is out, maybe it would fix both problems.
  2. Where did you take PDB (debug symbols) from? Are you sure it matches the executable?
  3. The thing I am really worried about is supporting custom GLSL shaders. We have discussed it a bit without any conclusion. Imagine some mapper creates a custom GLSL shader for his material and it works. Then developers have to change something, e.g. move to newer GL version. Suddenly these custom shaders stop working because something also changes on GLSL side and the syntax must be changed. It is not clear how this could be resolved, aside from developers converting all such custom shaders and repacking missions. In case of ARB shaders, it turned out that there is only one custom shader in all the FMs ever created, and it is used only on one TV box. No player would notice it if it stops working. But GLSL is much easier to use than ARB, so it is much more likely that mappers would use it. This is probably the only reason for weak public exposure.
  4. I'm trying to find usages of every shader we have. It might be interesting to note that this murky water is used in Volta 2 FM . It seems to be the only usage to this date. It was also copied into maps ws4_warrens, penny3, northdale1, but none of them actually use such materials.
  5. Speaking of workaround: I think it is possible to override timezone for one process only. Just set TZ environment variable in the shell from which you start TDM. See more details in this comment. Duzenko, the DST flag should have been set to "uncertain" (negative value). I have started discussion in developer forums about how should we fix the problem, and I believe removing the whole piece of code is much more reliable than trying to fix it
  6. Glad it helped! And thanks for going through all of this The problem happens only if all the conditions hold true: You have a very recent version of glibc (like 2.29). You have a timezone where DST (i.e. daylight saving time) is not used (and was never used). I guess it also depends on some undefined behavior (uninitialized variable). I have already created issue 5042 about it. Can't say exactly how we would fix it, but we definitely would do that for 2.08. Don't want to rush decisions right now. Bad news is that it is highly unlikely that an official fix will come out before 2.08, given that we have already had one "hotfix" version of 2.07. Meanwhile, setting any timezone which has DST can be used as workaround.
  7. I'm leaving for vacation in a few hours. I won't have Linux VM and fresh 2.07 version with me, so I won't be able to build Linux executable or analyze core dumps. Also, I will have no internet connection for the first two days.
  8. Having all static geometry duplicated thrice in VBOs would mean serious increase in video memory requirements... which is not cool, I guess...
  9. Speaking of the original issue with projectile spread. Do we have any shooting weapons except for arrows? The base class atdm:projectile_arrow has spawnarg fire_along_playerview set. Theoretically, TDM once had weapons who fired directly from muzzle, instead of from view origin. Any idea if we have such weapons now (for purpose of testing) ? Created issue 5041 about weapon spread. UPDATE: Committed the fix to SVN. The spread works well with it, in my opinion.
  10. We are discussing the case when custom script method is called instead of builtin drop. I have checked the script in SVN, and did not find inventoryDrop method anywhere. So I guess we have no custom-droppable items in the stock game.
  11. Perhaps related: https://bugzilla.redhat.com/show_bug.cgi?id=1653340 Which version of glibc you have? I guess trying to downgrade it is a bad idea... Meanwhile, you can also try to set OS timezone to something which has DST. For instance, Asia/Tehran or USA/New York. Maybe it would help.
  12. I think the original intent was: if you are eager to customize item dropping, then you should take care of everything yourself. I have managed to make spyglass droppable with custom method by adding the following code to class definition of playertools_spyglass: void inventoryDrop(entity ownerEntity); and the following code at the file scope: void playertools_spyglass::inventoryDrop(entity ownerEntity) { ownerEntity.changeInvItemCount(getKey("inv_name"), getKey("inv_category"), -1); } It properly removes the spyglass from inventory. I have checked the C++ side, and it seems to do proper thing. Probably you miss a parameter in your inventoryDrop method. Or maybe your item doesn't have the corresponding spawnargs.
  13. Another attempt. Copy this text into file mktime.cpp. Then compile it like: g++ mktime.cpp, and run ./a.out or whatever it builds. EDIT: I suspect the problem comes from mktime library function. Perhaps it depends on locale settings (time zone, daylight saving time, etc).
  14. Yes, it can be. Please do the following: Run gdb thedarkmod.x64. Enter command: break *(&R_LoadImage+0x856) (it should print something like "Breakpoint 1 at 0x5e5796") Then enter command: run When it stops, see the last messages in console. Also enter command backtrace and copy stacktrace here. Lastly, execute p *pic and p *timestamp and report results. The reason: I'm trying to understand where it fails to load the image. The cryptic command sets a breakpoint in R_LoadImage at the case when TGA load is considered to have failed. If it triggers, then we would get somewhat closer to the reason.
  15. Just to be sure: did you try to delete darkmod.cfg file? In case you have it left from the old version...
×
×
  • Create New...