Jump to content
The Dark Mod Forums

stgatilov

Active Developer
  • Content Count

    2274
  • Joined

  • Last visited

  • Days Won

    38

Everything posted by stgatilov

  1. 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.
  2. Having all static geometry duplicated thrice in VBOs would mean serious increase in video memory requirements... which is not cool, I guess...
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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).
  8. 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.
  9. Just to be sure: did you try to delete darkmod.cfg file? In case you have it left from the old version...
  10. 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.
  11. This is tdm_base01.pk4 --- the image which crashes TDM is in different file tdm_textures_base01.pk4
  12. Here is the relevant code: float spreadRad = DEG2RAD( spread ); for( i = 0; i < num_projectiles; i++ ) { ang = idMath::Sin( spreadRad * gameLocal.random.RandomFloat() ); spin = (float)DEG2RAD( 360.0f ) * gameLocal.random.RandomFloat(); //dir = playerViewAxis[ 0 ] + playerViewAxis[ 2 ] * ( ang * idMath::Sin( spin ) ) - playerViewAxis[ 1 ] * ( ang * idMath::Cos( spin ) ); dir = muzzleAxis[ 0 ]; // Dram: Make the weapon shoot directly from the barrel bone. Found by Ishtvan if (projectileDef->dict.GetBool("fire_along_playerview", "0")) { // greebo: Fire the projectile along the playerview direction dir = playerViewAxis.ToAngles().ToForward(); } The corresponding commit: Revision: 1417 Author: dram Date: 10 октября 2007 г. 13:08:24 Message: -Changed weapon and player so that the arrow is launched from the muzzle angle rather then the player angle -Changed the drifting to use 3 fracsins so that each axis is irrelevant of the other, thus giving a more random drifting ---- Modified : /trunk/game/player.cpp Modified : /trunk/game/weapon.cpp I think the original intent was to change the shooting direction from "view" to "muzzle". The spread was removed in process. The option to shoot by "view" direction was later returned under fire_along_playerview arg. It seems that we can restore the spread back, but there are two problems: If some existing weapons accidentally pass nonzero spread, we will have to fix them too. If we fix the code, it would be hard for you to use it right now. Although I guess it is not impossible: we can build executable at current SVN, and give you folder with current shaders to override the ones from 2.07.
  13. Sourav, please also try the following. Open file darkmod.cfg for editing, and add a line seta fs_debug "1" to its end. This is only for the period of investigation, better remove it back when everything is over. Now start TDM again. Share the new contents of game console, it should contain many lines like: "idFileSystem::OpenFileRead: glprogs/test.vfp (found in 'C:\TheDarkMod\darkmod/')".
  14. Thank you, Sourav! For other developers: the stacktrace is printed above. The crash happens in R_ParseImageProgram_r in "makeIntensity" case right after recursive call. The whole image being parsed is "makeintensity( lights/squarelight1a)" or "makeintensity( lights/squarelight1a.tga)". The pic is not null, but *pic is null. Some more values: pic = 0x7ffffffdff08, *pic = 0x0 timestamps = 0x5031598, *timestamps = 0 *width = 64, *height = 8, c = 2048 Interestingly, the sizes of the image are correct, so it has found the file and managed to read size 64 x 8. However, *timestamps is zero, so I guess the "if (timestamp == -1)" condition triggers at the end of R_ParseImageProgram_r (right after R_LoadImage call). Perhaps it is some timestamp issue again. @Sourav, could you please share your local file tdm_textures_base01.pk4 from your TDM directory?
  15. Could you post some steps to reproduce? The name of the fan mission you play? What is this weapon?
  16. I'm afraid you have to run TDM under gdb. Did you use gdb before? I guess we should incorporate automatic crash dumps in future... Run in console: gdb thedarkmod.x64 When it loads, enter command run and hit Enter. When it crashes, write backtrace and hit Enter. Copy the stuff it prints here. Also, try to run generate-core-file command. If it saves some file, share it please. I'm not very experienced with crashdumps on Linux side, and we have no wiki tutorial on it unfortunately.
  17. This link goes to Azure. Unless it was unavailable for a little time, it is very strange that you cannot access it. Here is link to google drive.
  18. You can unload TypeInfo project, it is only needed for the weird "Memory Log" configuration. As for linking error, I guess Duzenko should fix it. Meanwhile, you can comment everything related to r_legacyTangents, and it would work.
  19. Do I understand it right that it crashes at the moment when it prints "/proc/cpuinfo CPU frequency: 2000.07 MHz" and "signal caught: Segmentation fault" ? Could you please save your thedarkmod.x64 executable somewhere, and replace it with this one (this is for latest 2.07) It is larger, because it has all the debug info inside. Then start it with gdb like: gdb thedarkmod.x64. When it crashes, try to get a stacktrace (bt or backtrace). Post it here.
  20. Recently we fixed issue 4514 about random sluggishness with default settings. There is some hope that the problem will not appear any more in 2.08.
  21. Meanwhile, it is the System Administrator Appreciation Day today! Thank you for all the hard work, taaaki! I really appreciate what you are doing!
  22. Definitely not. SVN is and will be the main version control in the nearest future.
  23. Only as long as you don't want to change shaders ? BTW, I have intention to create official GitHub one-directional mirror for source code. Hope to post details soon.
×
×
  • Create New...