stgatilov

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.

Probably it's late to say this... But I think the contents of missions.tdminfo and the recursive list of files in TDM directory (meaning all directories and files with their names) would be helpful to understand what is going on.

It compiles fine for me. It would be faster if you simply commit the Linux compatibility changes or send a patch.

Post the exact error message, please. msvc100 is not suitable for TDM 2.06.For TDM 2.06, you need msvc120 (Visual C++ 2013), I think.

Well, me too =) If you use the old gamma/brightness for something, try to achieve the same with the new ambient settings. You can also compare the effect of r_gamma to the effect of very similar r_ambientGamma. The new settings are not attached to any slider. So you'd better modify cvars in console. Note that each cvar has default value, which efficiently means "no adjustment". It is 1.0 for everything except r_ambientMinLevel, which has the default of 0.0. As it usually happens with cvars, changing one does not automatically affect any others. You have to reset cvars to defaults yourself. For instance, to compare old (global) and new (ambient) gamma correction, you can switch between two commands: r_gamma 1; r_ambientGamma 1.4 r_gamma 1.4; r_ambientGamma 1 The first one resets old gamma and sets new (soft) gamma, and the second does the opposite. I have no clear idea for myself. One option is to remove brightness slider and switch the gamma slider from r_gamma to r_ambientGamma. Another one is to leave gamma/brightness sliders as they are, but add one more slider for whatever of r_ambientGamma and r_ambientMinLevel seems more useful. Almost like this, but with two differences: 1) You can only specify grayscale color in range from 0.0 to 1.0. No way to set red/green/blue levels separately. 2) Setting r_ambientMinLevel to 0.2 is not just adding light value 0.2 to everything, but it is rather similar on low values.

I have restored the old gamma correction and moved the new gamma correction to two new cvars. It would be great if some of these cvars die out by 2.07 release, but for testing purposes all the options are available now. The new version is committed in svn rev 15320, only TDM developers have access to it as of now. If you are TDM developer and the fate of gamma correction is important to you, please spend some time testing all these cvars in the near future. So in this new version we have: 1) r_gamma and r_brightness work exactly as before. They are configured when you move sliders in main menu. They affect the very-very final picture, even affect the main menu itself. They work via modifying the device gamma ramp, which is i) quite annoying if TDM crashes, and ii) can easily lead to color banding. The formula is: color -> pow(brightness * color, 1 / gamma); 2) r_ambientMinLevel and r_ambientGamma are the new parameters for "soft gamma" discussed here. They can only be configured by modifying the cvars in console yet (sliders to be discussed). They affect only the ambient lighting, so they don't work in menu and they don't affect light sources behavior. They work by applying conversion formula at the end of ambient shader, so they i) don't mess with your Windows settings, and ii) do not exhibit any color banding. The formula is: color -> pow(minLevel + (1-minLevel) * color, 1 / gamma) The r_ambientMinLevel cvar linearly transforms the colors so that everything which normally receives zero light will have color = minLevel. The r_ambientGamma cvar has exactly the same mathemetical effect as the old r_gamma (but it affects only ambient lighting). Note that most of these ways are not intended to be used together. E.g. You should use gamma correction either global (r_gamma) or for ambient only (r_ambientGamma). You probably should not combine r_ambientMinLevel and r_ambientGamma together. So it is like: use r_gamma + r_brightness as before, use r_ambientGamma only, or use r_ambientMinLevel only. But of course you can use several types of adjustment at the same time if you want, they'll combine rather nicely.

I wonder where this discussion ended? It seems that now the ordinary exponential formula is also implemented in ambient shader, so it should look rather similar to the original gamma correction. However, the new gamma will never affect light sources, it can only affect ambient. On dark scenes it is probably almost the same, on the bright ones it can differ. Maybe make some way to have both the old and the new gamma correction alongside (with yet another cvar --- just don't forget to kill it before release ), and then ask team members (at least) to test stuff by switching back and forth? I agree that making gamma correction "correct" instead of just one way to adjust contract/brightness/... is very unlikely to happen ever in TDM, since it depends a lot on the assets. Maybe the new way is just "good enough" or "better" subjectively, so everyone would screw the old gamma.