stgatilov

As far as I remember, taaaki is not the first one who hosts TDM server. As long as someone controls thedarkmod.com domain, it is always possible to migrate to new hosting without changing urls. You can of course create an ini file, but wouldn't it make your installer as complicated as tdm_update current is (in the very end)?

I have disabled the optimization on SVN, the problem is gone.

Yes, most likely we should make it easy to tweak alsoft.ini. Right now it is loaded in order: 1) From global settings: %APPDATA%\alsoft.ini or another location on Linux. 2) From alsoft.ini in the path where executable file is located. In case of TDM it is the root directory of TDM installation. 3) From the path specified in ALSOFT_CONF env. var. I think distributing the default configuration file near TDM executrable is the right way to go. It is OK to set cf_level in the distributed ini file, but it won't affect anything if headphones are not detected. And I don't think it should, since the tweak only makes sense when you have headphones. The better approach would be to log somewhere whether headphones are detected or not and explain players how to override it. Another approach is to add a setting in the main menu "headphones" with values "auto" / "yes" / "no" and propagate this setting into OpenAL.

I think the old cvars no longer work after switching to OpenAL. OpenAL has its own ways of fixing the problems. They are: 1) HRTF, controlled by hrtf. I can be enabled by following these instructions. 2) crossfeed, controlled by cf_level. It can be enabled in alsoft.ini just as hrtf. Also all of this depends on whether you use headphones or not (stereo-mode in the ini file). It seems that crossfeed closely corresponds to what s_minVolume did previously. And HRTF seems to be an even better approach. Moreover, it seems that HRTF should be enabled by default if OpenAL sees that you use headphones. It least it looks like it from the default openal.ini contents. I'll try to play with it and see what has to be done to enable HRTF.

Sounds great! I think that the current location of updater can be hardcoded. For instance, the location of tdm_mirrors.txt file is hardcoded inside tdm_update: const char* const TDM_MIRRORS_FILE = "tdm_mirrors.txt"; const char* const TDM_MIRRORS_SERVERS[] = { "http://mirrors.thedarkmod.com/", "http://www.thedarkmod.com/update/", "" }; So tdm_update goes to hardcoded paths to download tdm_mirrors.txt if it does not have one nearby. After that it uses the mirrors written into that file. Some sort of bootstrapping here I think it's better to ask Grayman or Springheel: they can say how often the location of tdm_update.exe on website have changed over years. If you cannot find updater online, then... report error, I guess?

Yes, this is the problem of the algorithm. In the first pass it tries to find closest blocker in a rather large cone going from light source to the fragment being rendered. The blocker is searched for by sampling the shadow map texture in some vicinity. In this particular case it seems that all samples are shadowed, so the algorithm declares the fragment as fully shadowed. Here is the guilty optimization: //shortcut: all blockers in search angle => fully occluded if (blockerCnt == u_softShadowsQuality) { gl_FragColor.rgb *= 0.0f; return; } It seems that it is not robust enough. Often the search code is very large and has all samples shadowed, but if we then compute the penumbra radius, it is much smaller, and some samples during real evaluation are lit. This is sad because it disables optimization for fully shadowed surfaces

In the latest code, positive radius means "deduce radius from light source". The negative radius means just "use this value always" and is much safer. The code for positive radius is: if ( !args->GetFloat( "size", "-1", renderLight->radius ) ) renderLight->radius = 1e-2 * idMath::Fmin( renderLight->lightRadius[0], renderLight->lightRadius[1], renderLight->lightRadius[2] ); In my opinion, this is wrong. Moreover, given the number of different lights in existing TDM missions, this is a dangerous idea which may sometimes produce completely wrong results. Spooks, do you have problems with positive value only with r_shadows 2 ? Or they are present with r_shadows 1 (stencil shadows) also? This question is very serious, because we need to decide now whether we save this behavior for 2.07 or not. Most likely a problem in implementation. I have r_shadowMapSize 1024, r_softShadowsQuality 24, r_softShadowsRadius -2. I did not notice such problems. Could you write about some specific place (you can post coordinates which getviewpos console command prints) ? P.S. I have also noticed the "aas out of date" message in Betrayal mission on the current SVN. This is very strange, I think someone has to bisect over SVN history to find out when it started to happen. By the way, dmap has the ability to precompute shadow volumes of static objects, and by default it is turned on.

This problem was already detected before. That's the bad change I did at the end of 2.06 beta. If you want to have new (i.e. nicer) shaders, then: 1) rename tdm_base01.pk4 to tdm_base01.zip. 2) find file /glprogs/interaction.fs inside the zip file. 3) open it in text editor and change two lines (explained below). 4) rename modified tdm_base01.zip back to tdm_base01.pk4. 5) now enable r_useGLSL 1 and play. Of course, it would be wise to backup the whole tdm_base01.pk4 before doing this. In interaction.fs you need to find the lines 161 and 162: vec2 alongDir = mat3x2(gl_ModelViewProjectionMatrix) * alongDirW; vec2 orthoDir = mat3x2(gl_ModelViewProjectionMatrix) * orthoDirW; And replace them with these two lines: vec2 alongDir = (mat3(gl_ModelViewProjectionMatrix) * alongDirW).xy; vec2 orthoDir = (mat3(gl_ModelViewProjectionMatrix) * orthoDirW).xy;

I believe it is possible to create updated version of shaders for 2.06. Someone needs to unpack all shaders, then switch their version pragma to 120, then use glslvalidator on all of them. Replace some in/out-s with varying/whatever, probably remove some code, and it will work.

It is possible to write a script which will query FPS every second. When you finish playing, it will produce file with a list of locations sorted by FPS increasing (x y z + pitch yaw + timestamp). Then you can take any of these locations and use setviewpos to teleport to it. Note that if player knows which place poses a problem, you can ask him to write getviewpos, and then use setviewpos to move there.

What does "beam over" mean? There is a command setviewpos (and teleport), which puts player to specified coordinates. In all the publicly available versions it can only set yaw view angle, they have no way to specify pitch angle (although it would be changed in next version). What exactly do you want to do?

As it often happens with bug reports, it would be useful to get two things: 1) Console messages. Enter condump command into game console, then find the file and attach it here. 2) Config file. Attach darkmod.cfg which you use. In this particular case, which version/build of TDM is it? The console log could clarify this.

In the latest SVN version (not publicly available yet), I have supported user actions in automation. Believe it or not, but the main incentive of this major work was to be able to bypass "Press Attack to start" screen programmatically. Now you can use automation to make player walk, rotate view, attack and do various special actions internally known as "impulses". Meanwhile, I did not extend the watcher script. As I wrote above, I need a help from experienced mappers to implement automatic reloading of anything (except GLSL which I needed for myself).

Another way to run updater is to install packages for running 32-bit programs. Unless you have done horrible things to your Linux, it should be rather easy.

Ok, so you don't need real network. The TDM-side support was started after 2.06. So you cannot run scripts against TDM 2.06, but you will be able to run them against 2.07. Also, the latest unofficial build from moddb most likely supports it on TDM side. The python code itself is contained in assets SVN, I have posted a download link above. Not yet. The amount of documentation which will appear on 2.07 release depends on how much functionality I can implement now Right now it can only help you to reload GLSL, which is a purely developer's feature. Probably not. Some people say you can take ordinary CPython installation, configure paths and it should work. Also, you can convert Python code into standalone executable, although it feels less secure for potential receivers.

I tried to change some texture while being in-game, but all my changes have no effect. First I tried to change a guard at the main entrance to the tavern in Inn Business, and changed all jpg textures in /models/md5/char/guards/proguard. Then I tried to change the carpet in the tavern (near two guards playing cards), and changed \textures\darkmod\carpet\runners\geometric01_red_ed.jpg. Every time I did reloadImages, reloadModels and reloadDecls in all combinations, but nothing changes. Could someone please write complete steps how to change a texture without reloading engine? I mean something like: 1) Load "..." FM and go to "..." well-known place and look at "..." object. 2) Find jpg file at "..." and modify it. 3) Run "..." and "..." console commands in TDM console. 4) Notice that the object looks different now.

The TDM game and the script are connected via ordinary TCP connection. So in theory yes, you can ask user to enable automation in his TDM, and then configure the script to connect to remote machine. If you can reach the player's machine by IP, then it should work. My machine is not reachable directly from internet. If you are interested to test it out, I can write a simple script. It would connect to specified IP and allow you (me) to run TDM console commands with getting back whatever TDM writes to console. Note that the system was never designed with network latencies in mind. It should not matter much for running console commands.

reloadDecls + reloadModels after changing anything like *.mtr. reloadImages after changing something like *.tga, *.dds, *.jpg. More examples?... Do I understand right that reloadXXX commands only actually reload files which have changed (I saw that "last modified time" is checked somewhere), so they work pretty fast?

I meant the latest experimental/unofficial beta-or-not-beta build, supposedly available on moddb. They won't work with TDM 2.06 The scripts can be downloaded from here, they are supposed to be run from some subdirectory of TDM installation directory. Could you please be more specific? Do you mean that changing only image file is sometimes enough, but reloadDecls is required in addition to reloadImages? Note that I have almost zero idea about how this all works. Unless someone helps me with particular rules, all of this won't work.

OpenGL 4.0 is from 2010, while OpenGL 3.0 is from 2008. I agree that we should probably stick to OpenGL 3 with extensions (e.g. stencil textures, which are already used in 2.06 for soft shadows). But the difference is not as big as the major versions suggests.

The most recent TDM has the "automation" system, which allows an external Python script to connect to TDM game and programmatically do some stuff within it. Right now only one basic action is supported, which is: run a given command in console. Originally, the whole system was intended to implement automatic testing, and I hope I'll have time to get it there some day. However, I already find it useful. Recently I implemented a simple watcher script for interactive shader editing. It works like this: 1) Python script watches over all files like glprogs/*.fs, glprogs/*.vs and glprogs/*.gs. 2) Whenever one of them changes, reloadGLSLPrograms command is run automatically. As a result, you can edit GLSL shader file in Notepad++ on the left half of the screen, which TDM on the right half reloads immediately after each save. You can see some sort of demo: Probably this scenario applies to other TDM resources which are reloadable without restarting map. Something like reloading texture while editing it in special software, or doing the same with mesh/model. In fact, it is even possible to auto-reload map with something like: getviewpos // this gives coordinates and orientation dmap {mapname} // make the updated map playable map {mapname} // start the updated map setviewpos {saved coords} // teleport to the same exact locationIf you have any ideas about using this system to reduce amount of dull work, please share.

I think you don't have access to cvars inside scripting system. It should not be hard to implement basic arithmetics in console. For instance, add a command "set" which parses its arguments as arithmetic expression with cvars in it.

I agree. It would be great to have some sort of cap on OpenGL stuff. Now shadowMapA.gs has GLSL version 430. This is like saying that we require OpenGL 4.3. Isn't it a bit overkill? Do you really need this late version? On comparison, interactionA.fs only states version 130, which is OpenGL 3.0 (plus extension for texture gather).

You can modify the following cvars in console: cv_ai_vision and cv_ai_hearing. They control how well guards see and hear you respectively. The nearly blind / nearly deaf levels are at value = 0.2.

All current TDM developers use Windows as primary system. Nevertheless, I regularly check TDM in a Linux VM. But using a VM adds one more level of weirdness to how input works, so it won't help. Cabalistic also used native Linux for testing TDM. Maybe he can try it out, but it is unlikely he has Fedora. You see: there are much more Linux distros than TDM developers. Probably adding some call like XSetInputFocus in proper place can fix the problem, but someone who has this problem needs to test it.