Jump to content
The Dark Mod Forums


Active Developer
  • Content Count

  • Joined

  • Last visited

  • Days Won


stgatilov last won the day on July 26

stgatilov had the most liked content!

Community Reputation

558 Legendary

About stgatilov

  • Rank
    Lead Programmer
  • Birthday 08/26/1989

Contact Methods

  • Website URL
  • Jabber

Profile Information

  • Gender
  • Location
    Novosibirsk, Russia

Recent Profile Visitors

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

  1. 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
  2. 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.
  3. 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.
  4. Having all static geometry duplicated thrice in VBOs would mean serious increase in video memory requirements... which is not cool, I guess...
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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).
  10. 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.
  11. Just to be sure: did you try to delete darkmod.cfg file? In case you have it left from the old version...
  12. Well, timestamps in pk4 files differ between installations. And compression might differ also. Unfortunately, the date and time in the posted pk4 is exactly the same as I have. Moreover, I can normally start TDM 2.07 x64 (with hotfix) with this pk4, without any crash. I guess I have to do more code digging, probably look more closely at the dump.
  13. This is tdm_base01.pk4 --- the image which crashes TDM is in different file tdm_textures_base01.pk4
  • Create New...