stgatilov

Yes, you are right. I guess I thought I would catch something suspicious by looking at it. Well, I will inspect it --- maybe I'll have some clues about how it happens. Thank you! Speaking of savegame before getting stuck, I won't be surprised if the issue is not reproducible

I believe "mission finished" savegames are not broken between versions. Not sure though. Completely separate code for main menu results in various inconsistencies there. A lot of menu stuff is not customizable on per mission basis. I don't remember anything serious about the gameplay itself.

It is already possible, check out e.g. No Honor Among Thieves FM. However, there are many small technical issues with campaign support, so it's probably wise for mappers to avoid using this feature without need.

I'm afraid I need a savegame before the problem happens. The attached savegame demonstrates that the problem can happen, but does not show how the game can get into such bad state.

As the refactoring in 5323, there would be option to skip success screen completely. Although it probably won't work for campaigns. Also there would be option to replace music/background for success screen. The music along can already be overriden, although the approach cited by @Dragofer is not the best one. Better find this text in mainmenu_custom_defs.gui, uncomment it and set the sound shader you want: // Uncomment this to override the default mission success sound //#undef MM_MISSION_SUCCESS_SOUND_CMD //#define MM_MISSION_SUCCESS_SOUND_CMD "music mission_complete;"

I think some version ranging from 2.05 to 2.07 should work, but not sure. Old versions are available in the new TDM installer.

Let's spawn @greebo here.

Did you download the updated version of your FM? It should be in the in-game downloader.

Not really But now if a map entity uses rotation hack, then the game embeds this "rotation" into the model automatically during map load, i.e. creates a scaled model. So yes, the game engine has said goodbye to it completely. As for maps and mappers... don't know.

Bikerdude fixed The Elixir. I think by explicitly resizing everything. This was the last FM, so this issue is over.

New dev build of the game is available. See changelog in the second post. We would be happy if someone checks out the added gamepad support

By the way, could you try setting rt-prio to 1 instead of changing period_size?

Nevermind, I bumped the version. Also verified that the new version boots properly on SVN. Thanks!

I won't do it. I am far less competent in OpenAL that the OpenAL developer. I think he knows better what he is doing. It sounds like buffering is not synchronized properly, causing holes occasionally. How many CPU cores do you have? If it is too low, maybe sound thread is not executed as frequent as it needs (something else has high priority).

No, you should not. It won't change anything. And versions like this will happen anyway. The internal version in FM database must be bumped to 6.

With minor exceptions like water volumes, brushes don't exist when you play the game. The dmap compiler uses them to determine visleafs/portals structure, and to produce triangular "surfaces" which are actually rendered in-game. If you have too many brushes, then you will mainly experience slow dmap compilation and perhaps occasional buggy output (e.g. missing triangles in a wall) or dmap crashes. Serious issues are rare as long as you use axis-aligned brushes. But if you decide to e.g. make nice-looking trees out of brushes, I'd say you are risking . Even spiral stairs sometimes cause problems. I think it is useless. If you have a room which is a visleaf area, then the inner wall faces (visible from inside the room) will be put into a mesh surface assigned to the room visleaf, the internal/side faces will be removed since they don't separate opaque from non-opaque, and the outer wall faces will be put into surfaces assigned to whatever visleafs present outside (if there are any). When the player is inside the room, he will most likely not see the outside visleafs through the portals, so the outer faces won't be rendered. P.S. Note that I'm a programmer and not a mapper. What I say comes from "theory", not practice

Oh, crap! Yes, it is alsoft.conf on Linux if you place it near executable. There are some other paths also, and some of them probably have higher priority. You can check the openal_log.txt: it should show where it looks for config file and where it finds it. The s_driver is remnant of pre-OpenAL sound, it should have no effect right now. This setting is used: it selects the sound device to use. E.g. if you have headphones and speakers, you can specify which one to use. But it cannot change OpenAL backend. It is buried deeply inside OpenAL and quite likely cannot be controlled by application at all. But perhaps it can be controlled by the ini file. At least I see buffer-size setting for jack backend there. There are also period_size and periods which are somehow related to buffering.

When I checked this FM in the database before this update got released, it said "version 5". When I now check it in the database, it still says "version 5". Consequently, when I check the in-game downloader, it does not offer me the update because it thinks that my current version is the most recent one (since it has same version), which is clearly wrong. Most of the people won't download the update if we don't bump the internal version. @nbohr1more?

Fixed Rightful Properly. There was one moveable boulder with x1.5 scale, I simple commented it out.

And what's the point in all these updates if every version has its own bugs? I think we have tried 1.18.2, 1.19.0 and 1.19.1, and none of them was issue-free.

I suggested trying other OpenAL backends. Maybe it is backend-specific.

The installer tries to download the manifest file, and if this download does not work, then the mirror choice is restarted without this option. So if mirror is down, or it does not have the wanted version (e.g. was not synced in time), then the installer should be able to ignore it automatically and find a better source. If the mirror gives away bad data, than the whole install will stop with error during "verification" phase. That's a bad situation which I hope won't happen. In any case, I hope such issues will be reported quickly, so that we could remove the failing mirror from config and see what's going on. If the mirror is slow... that's very sad Note that currently when you install fresh 2.08 version, you have to download full 2.00 version and 8 differential packages, and each of these 9 packages is downloaded from independently chosen mirror. So if one mirror of three is 100 times slower than usual, then everyone will suffer by various degree. The user can manually remove some mirrors. To achieve it, run the installer at least once to the version choice page, then exit. Open tdm_installer.ini and comment out the failing mirror from [MirrorSet TDM_MIRRORS]. Then restart installer and check the "Skip config file download" in advanced settings.

Speaking of tdm_mirrors.txt, it is replaced with tdm_installer.ini. I don't think user needs a way to choose mirror.

Repacked Night To Remember. I simply commented out the transformations. Now the trees are huge if you teleport there. Also, I played the mission myself, and did not see neither the trees nor the sky, so I guess these trees are some random trash left from early experiments. Uploaded the new version to mirrors, internal version bumped to 3.

I guess it was darkmod.cfg retained from the previous version. It is best idea to delete it on any version change in case of any issues. I have even added a button to the new installer for it. I wonder if we should just rename the config file by default to something like darkmod_old5.cfg.