stgatilov

Added beta207-06, and fixed beta207-05 on tdmcdn.azureedge.net (way 2b).

New release codenamed beta207-06 is out. Update as usual for beta. Changelog added at the very beginning of this thread.

I updated the wiki page with information about Version 2 of EFX file. I think whether I should delete the section "Legacy info (Version 1)" altogether or not...

Please also provide your config file (darkmod.cfg). Also could you explain what exactly you did before crash? Was it immediately after a fresh start of TDM? UPDATE: I tried stupidly to fresh-start Arena mission 100 times, got no crash.

The issue with arrow keys may be not as easy as it seems. Probably worth adding a bug for it. Note that a change for Linux side has been merged: 4190. It changes the way TDM interacts with system controls, for better or worse... Nightcrawler, I seriously suggest testing 2.07 beta.

Ok, if my eyes properly see the difference on the pipe, than the problem is due to different interpolation of directions. I guess I made a few mistakes Anyway, I would be glad to see a bold example of the problem to be sure that I fix it completely.

Ok, I see that it is different. Is there any oustanding case of this problem? I looked at the pipes in Matter of Hours, and it is hard to recognize which version is the new one, and which is 2.05.

All of this happens on GPU. The old ARB shaders operated on tangent-space vectors, however the new GLSL code transforms them into world in fragment shader and uses them. Normally, this is not something to worry about. This change was introduced because TDM 2.05 worked that way: it clamped this value to [0, 1]. It was done by Rebb in 2012. No idea why. I guess unclamping it has a potential of overbrightening some zones, but no idea how critical it is.

The behavior was reverted to how 2.05 looked. Please compare with 2.05 look and report if there is any difference. Yes, most likely. However, if the new behavior is equivalent to the one of 2.05, then the question is not so obvious.

There is no plan to turn automation commands syntax into real programming language --- there is python for that! Just write your own Python script and use automation class there directly. For gameplay actions you can either try to use game_controls directly or try to invoke console.py (I seriously plan to move commands execution engine from this script to library). Did you look for this file on your machine? Was it present or not? empty or not? When did this happened? Does your script rerun TDM process? install different FM? Do you normally have logFile cvar enabled? This may be some sort of race condition.

To be honest, I hoped that script will only be used for massive testing over many FMs, not for ordinary checking. Probably it's better to keep it that way, because otherwise a lot of stuff will fill it over time. There is another script called repeat.py, which is very small and not really important. It's better to fill it with regular testing stuff. For instance, I used it for testing crashes in 4919 the following hacky way: 1) I created a file finish_mission.seq, which loads a quicksave, moves forward to mission exit, waits until mission finish screen loads up. 2) Then I created another file finish_mission_10.seq, which had one command @file finish_mission.seq copy-pasted 10 times, and exit at the very end. 3) Then I run repeat.py finish_mission_10.seq. So it boots TDM, performs sequence 10 times in a row, then properly exits. Repeat 100 times. If something crashes, repeat.py will catch nonzero exit code.

The beta207-05 should be working with this updater. I tested updating from TDM's mirror.

Yes, beta207-05 was packaged about 20 hours, just could not find time to announce it. Feel free to update to new version now. Changelog is in its usual place.

While this is not an interesting request, it is quite small. There is Windows TDM installer made by Freyk. We plan to place it on official site soon. It would be great if you contact him and suggest proofreading from your side. I think all the user-visible text is located in this file, but it's better to ask Freyk.

Created new thread. Merely loading a FM does not test anything. FM rarely breaks to the point when it does not load, and most issues do not produce warnings. So it is a question of serious test suite checked automatically. That is the original dream due to which automation was created. Multiple version support is a terrible idea from the point of stability: all those old stuff will not be tested. Such change decreases test coverage even further. People can have several versions of TDM locally, and run older version if they know the mission is broken with the new one. The main problem is that in most cases players don't know that the mission is broken before they catch an issue. Sometimes they don't know it even afterwards I plan to change tdm_update completely, so that it could be possible to switch between versions. A very rough prototype is already available. One last step would be to allow saving cache of uninstalled versions on the hard drive. Then it can be used by updater for switching versions (so that you don't need endlessly redownloading same diffs). I'll keep it in mind for the new updater.

I can reproduce the problem with shadow maps too, both soft and hard. Just take the candle and move it near the beds, and you'll see black quads too. So this problem is not stencil-specific. The ragdoll issue on this map turned out to be caused by wrong rotation matrix (see comment). I suspect the shadows problem can be caused by the same problem: "rotation" matrix is not orthonormal and performs scaling on the object.

Never used anything except CPython myself. People use py2exe or pyinstaller to produce a standalone executable. I'll try them in future (after I get rid of ugly sys.path hack). Thou shalt not confuse the great Far Manager with the ugly Midnight Commander! Anyway, all of them are descendants of the same Norton Commander.

I have checked all missions downloaded on January, 2nd with beta207_04 version. All the missions except "Mission of Mercy" and "Pearls and Swine" started properly. To keep this thread free of unrelated discussions, I have posted details about automation stuff in another thread.

Just now automation has been used to start every FM released to date. It is about 125-128 missions already That's a huge number , and merely starting and cheat-completing them all takes something like 90 minutes If anyone is interested in this feature, see complete_any.seq (commands sequence) and foreachfm.py (the runner script) in the automation package.

Here is a video showcasing automation commands (you can type them into console.py, and I intend to integrate them into automation library in future). I managed to complete the shortest TDM mission without directly interacting with the game. Beware: the video is long and very boring

I have previously posted about automation efforts in this thread about watching over asset files. I decided to create a more generic thread for whatever discussions related to automation. The most recent version of automation library and scripts (by the time this topic was created) can be downloaded from this link. More information can be found in readme.md. It should run properly against any beta version of TDM 2.07. Some new Python 3 is required to run automation stuff. I'm afraid that decent skills in Python are needed if you want to do anything advanced with it. If you have some tedious work that you regularly do with TDM, and feel that it can be automated, post ideas here. UPDATE: Current version (2019.02.22) is available here. It should run properly against TDM 2.07.

Do I have to restart the whole game for each mission to make sure that all warnings are printed?

I have downloaded all missions. I can write an automation script which iterates over all these maps, installs each of them, starts new game, and checks if specified text is present in game console. Does it sound like a good idea?

This change was never committed to trunk.