stgatilov

Most of the errors about missing files do not terminate TDM. Missing assets usually allow to run the game, but corresponding objects look weird. There are only fatal errors which actually terminate stuff (where Windows users are dropped out of rendering engine and see a small blue window), and they happen rather rarely. Also, there are crashes, where application does not have reliable ways of doing anything. In which cases do you suggest to return nonzero exit code? I think right now you can see if anything bad happened by enabling qconsole.log via cvar and grepping it for ERROR: after TDM terminates. But note that perhaps you would see errors which don't stop users from playing the game normally.

I would be glad to check it, but I guess I'm stuck at a rather old SVN revision for now.

I guess there emscripten supports OpenGL-to-WebGL translation. But the OpenGL currently used in TDM is surely wider than a "subset of GLES 3". Moreover, WebGL does not support some of the features used right now. Clearly, all the window system integration, threading, and probably many more has to be rewritten in order to make it work. To be honest, I personally dislike the trend of putting everything into the browser. Doing so to hardcore games is the worst idea I ever heard.

I have built RelWithDebInfo x64 library for versions 1.18.2, 1.19.0, and 1.19.1. There are here. You can replace the lib "rel" version with any of them, build TDM, and it will produce PDB with symbols for OpenAL. On the other hand, if you want to see the place in debugger, then you will have to download source code and point MSVC to it. Maybe we should build most of the libraries with debug info to make debugging easier. P.S. Conan has one major issue: it has steep learning curve. I wish more people try to use it, but understand that it is not trivial.

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.

Where did you take PDB (debug symbols) from? Are you sure it matches the executable?

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.

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.

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 ?

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.

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.

Having all static geometry duplicated thrice in VBOs would mean serious increase in video memory requirements... which is not cool, I guess...

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.

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.

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.

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.

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).

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.

Just to be sure: did you try to delete darkmod.cfg file? In case you have it left from the old version...

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.

This is tdm_base01.pk4 --- the image which crashes TDM is in different file tdm_textures_base01.pk4

Put it somewhere and let me download it. It might be corrupted.

What about tdm_textures_base01.pk4 file?

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.

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/')".