stgatilov

Apparently, the cloud mirror is still unreliable. I'm afraid I'll have to bring it down UPDATE: Disabled my mirror. Try again: it should work now.

Did anyone try 32-bit executables?

I guess I'm the main source of this attitude. Yes, that's mainly because of maintenance burden. TDM has reached the state where compatibility is much more important than development. We cannot say "we have upgraded this feature, but as the result these FMs no longer work, and we decided that breakage is well worth it", that would be betrayal of TDM mappers. But since we want to do some development in future too, we have to constantly think about how to avoid getting locked by backward compatibility. And that's the main reason why I was so pissed off by GUI customizations. Yes, I agree that my initial reaction was too aggressive. There was a set of conventions for mappers, established by the original developers of the menu GUI, which were there in order to provide backwards compatibility without compatibility lock-in. But due to lack of some customization features, the protocol was broken by mappers. I have already spent at least a month working on the new system (because GUI scripts are damn painful), and I will spend even more on it. Then even more on fixing the missions which break the convention (in case authors won't do it). And I know I can't drop this work because otherwise GUI will become more and more locked due to compatibility. Now consider jittered screenshots. Is it an important feature?... well, it is not. I would say TDM can safely live without it: only a few people use/know about it, and most likely rarely use it. And it has absolutely no effect on gameplay. However, we have to fix it because "it was there from the very beginning". My immediate worry in such situation is that trying to fix this unnecessary feature would break something necessary. For instance, there was considerable risk that the fix would break portal sky in some situations (although @nbohr1more's fix is very isolated, and I guess it won't break anything). Doesn't it sound counterproductive trying to fix unimportant feature risking to break something important? Keep in mind that leaving it in the code means that it will most likely be broken again in the future (especially given the pace of graphical changes), and the same dilemma will return again. So the best decision would be to remove the whole feature of jittered screenshots, which I honestly wrote about. Of course, it is the responsibility of TDM team members to fix the existing features, even if they don't want to or don't agree with their existence. But wouldn't everyone be more happy if the time wasted on fixing these minor things would better be spent on something more useful and important?

Another major message is pcm_dmix.c:1075:(snd_pcm_dmix_open) unable to open slave, which is probably the reason by default device cannot be used by ALSA.

Judging from Could not open playback device 'default' message, "default" device for ALSA is not configured properly. I hope someone more familiar with ALSA configuration could explain how to change the default.

Which version of TDM exactly do you use? You can open game console (Ctrl + Alt + Tilde) and post here the 4-digit number written in its botton-right corner. Or post condump. Which OS do you use? I assume you use 64-bit executable. Which FM do you try to boot? Could you check for FM updates in the following way: Uninstall mission. Go to in-game mission downloader and check if this mission is in the list. If it can be downloaded, download it. Now install the mission and try again.

beta209-06 is available. Don't forget to check "Custom Version" on the first page of installer. This beta is "release candidate", meaning that unless something very bad happens, it will become final 2.09 release. It has only a few minor changes compared to the previous version. However, there are several important differences between this beta and the previous ones: The archive with 32-bit executables can be (downloaded from here | not any longer) . It should be unpacked into the installation directory, and includes both Windows and Linux 32-bit builds. It is important that at least someone tests these versions. If you decide to do that --- please write about your experience. In order to test mirrors system with tdm_installer, I have established a second mirror on CDN. Now it used with 80% probability. This should be enough to check if there are any emergent problems with mirrors in tdm_installer. But I must say that I'm not confident in this second mirror, so if you see any errors on the installation screen (during Download, Verify or Repack), please post a screenshot and log. Unfortunately, I could not use the mirrors which were used for TDM delivery previously (long story). The new mirror is rather weird: it is very fast but not 100% reliable. It least I had some problems with it a few years ago which I could not resolve. Now I have changed its configuration and hope that these problems won't return. But I'm not sure.

There will be effect on all programs started with these env. vars. I'm not good in bash, but I think the export-ed env. vars only take effect on all programs started from the shell where you did export, and until you close the shell. Also the only "unexpected effect" would be OpenAL writing log files.

Popup texts in the settings menu is the most wanted feature since something like 2.06 ...

You are not able to do it for quite some time already (on Windows). It is not necessary with FBO-based rendering. Because everything can be rendered at 25% or 50% of your native resolution (you choose), and then stretched over the whole screen.

Hmm... I guess it is confusing text. Perhaps I should hide the top text when installation is over. The config restoration happens immediately. You cannot hit Cancel because you cannot cancel the installation: it has already finished.

The bug should be fixed now. Please try again.

New version of installer is available. Suppressed errors from user file having bad named in TDM installation directory. Disabled buggy free space check on 32-bit Linux.

No comments: #include <experimental/filesystem> #include <stdio.h> namespace stdfsys = std::experimental::filesystem::v1; int main() { stdfsys::space_info stdres; stdres = stdfsys::space(stdfsys::path(".")); printf("free : %0.3g\n", double(stdres.free)); printf("cap : %0.3g\n", double(stdres.capacity)); printf("avail: %0.3g\n", double(stdres.available)); return 0; } user@ubuntu:/mnt/hgfs/thedarkmod$ g++ temp.cpp -std=c++11 -lstdc++fs user@ubuntu:/mnt/hgfs/thedarkmod$ ./a.out free : 4.93e+11 cap : 1.02e+12 avail: 4.93e+11 user@ubuntu:/mnt/hgfs/thedarkmod$ g++ temp.cpp -m32 -std=c++11 -lstdc++fs user@ubuntu:/mnt/hgfs/thedarkmod$ ./a.out free : 3.53e+09 cap : 1.99e+09 avail: 3.53e+09

Well, I think in some nearest future we will remove the resolution selection, so the problem will be eliminated. You can change resolution of TDM window by dragging its corner (but only on Windows).

Wait for an update. Or remove the mentioned file from installation directory (but there can be others).

On the second thought, it wouldn't help with this problem. Users are free to have their files in installation directory, and the files can be named in any way they want. Installer should skip them properly.

One day I'll rename this stupid model, I promise! Just... not today

You should try to enable OpenAL logging. It is done by setting two environment variables: export ALSOFT_LOGLEVEL=3 export ALSOFT_LOGFILE=openal_log.txt

Hmm... so you see this stupid warning on native Linux. I guess I'll have to disable it for 32-bit Linux build. Because I don't see where it happens, it is likely some implementation issue.

I think changing resolution in fullscreen mode simply has no effect. It is reverted back on restart.

I think I have fixed the problem with spaces on Windows. Of course, update to this new version still won't work, but updates to subsequent versions should work properly with spaces in paths. Also, I have published 32-bit Linux built of tdm_installer. It would be great if someone (who knows well how to run 32-bit stuff on Linux) tries to use it and reports if it works properly.

Most likely that's because of RGTC normal compression. I'm afraid @duzenko removed the code which was used in 2.08 for DXT compression. But you can try "image_useNormalCompression 0" to see if the difference is big enough. Also note that AMD cards compress more slowly than NVIDIA ones. The plan was to use on-the-fly RGTC compression by default in 2.09. And if there are no complaints about quality, then convert TGA files to DDS for the next release.

beta209-05 is available. Changelog is provided in its usual place. Use tdm_installer to get the new version, and don't forget to check "Get custom version".

Fixed the triangular particles bug in svn rev 9100.