stgatilov

Get the game or its source code, and read the LICENSE file. I hope it would become easier after we get a GitHub mirror

There is no way to do it in main menu GUI. Playing a debriefing video is the only option. Of course, it is possible to add an optional DEBRIEFING state after the video, and make its .gui file overridable. Somehow, it was not added when debriefing videos were added, perhaps no one wanted it. The new main menu system does not support dynamic debriefing videos out of the box. Perhaps you could check gui variables which are responsible for objectives, and choose different path in mainmeni_debriefing.gui, if it was available to begin with. But I'm not sure the necessary information is available at proper time and in proper form. Another approach is to look at "Somewhere Above the City" by @grayman. It shows some cutscene after the game is over, which is different depending on whether you killed someone or not. However, it is done in the game itself, not in the main menu. I think it is also possible to display arbitrary GUI in-game. The mission "Hare in the Snare" by @Frost_Salamander and @Kerry000 uses this approach to workaround problems of main menu debriefing.

Yes, the background is gone in the old versions of TDM (<=2.09). It will work only properly only in the new versions (>=2.10). Read the original post for details.

This criterion was already used to split main menu into MAINMENU (left half visible) and EXTRAMENU (whole screen used). The background figures are only visible on MAINMENU, but not present on EXTRAMENU --- which includes choosing FM and settings by the way. I'm afraid there are many sensible ways to unite individual macros into groups. I think I'll only make one "meta" macro which would cover everything except for success and failure screens. The rationale is that such macro strives to remove "switches". Except for a switch from failure/success screens back to main menu. Also, that's how most of the existing FMs work. Failure/success screens depend a lot on their current backgrounds, so if someone wants to override them, he has to do it explicitly anyway.

Usually when someone overrides main menu background, they do the same for difficulty selection and shop too. Briefing does not matter because it is usually replaced completely, and background is not visible anyway on briefing video state. Parchments are not included into backgrounds. However, all the graphical effects on success/failure screens are considered backgrounds. So if you override those with simple image layer, then you won't see skull or mission success text.

I don't understand what's in the images that you posted. I see gray rectangle in the second one, and gray rectangle with some outlines in the first one. Almost surely this is the problem of DXT compression in OpenGL driver, since you provide non-DXT data, and engine uploads it as DXT. It is possible that the problem does not happen on drivers of other vendors. You can workaround it by forcing high quality in material, or providing DXT-compressed DDS (it should work). It can be related to the problem with DXT compression on AMD that you had before you turned image_useTexStorage off.

All effects? I thought about having single macro like MM_BACKGROUNDS_ALL instead of many individual ones, but should it replace background on success and failure screens too? And if not, then how should it be called to avoid confusion? Maybe something like MM_BACKGROUNDS_META_ALLBEFOREGAME ? Material is not required, you can reference texture directly (as usual). File mainmenu_background_custom.gui already contains a stub of GUI window:

Tried to repack "A house of Locked Secrets" by @Moonbo This one is perfectly valid again, just it seems to use "briefing video controlled by SDK", since it is a campaign. Also, it has a very important debriefing video. First of all, mainmenu_custom_defs.gui starts with three letters "bri", which should be syntax error, affecting the rest of the file in unpredictable way. I have removed these letters. Then I commented out the "controlled by SDK" thing: //stgatilov #5323: use default way of setting up videos //#define BRIEFING_VIDEO_CONTROLLED_BY_SDK 1 //activated for campaign Then enabled debriefing state for second mission (it is disabled by default): #define ENABLE_MAINMENU_BRIEFING_VIDEO 1 //stgatilov #5323: enable debriefing video after second mission #if MM_CURRENTMISSION == 2 #define ENABLE_MAINMENU_DEBRIEFING_VIDEO 1 #endif Finally, I provided debriefing information for second mission (similar to how we do it for briefing videos in non-campaigns): //stgatilov #5323: set up debriefing video after second mission #if MM_CURRENTMISSION == 2 #define MM_DEBRIEFING_VIDEO_MATERIAL_1 "House_Credits" #define MM_DEBRIEFING_VIDEO_SOUND_CMD "music House_Credits;" #define MM_DEBRIEFING_VIDEO_LENGTH_1 71000 #endif Now everything works as before with new TDM build (also music in debriefing is now fixed). In 2.09, the updated FM works fine, except that debriefing/credits video is skipped.

GUI accepts material path, just like any other place in the engine. If you put path to image, then material is auto-generated. Of course you can create material manually instead.

Repacked Hidden Hands: Initiation by @JackFarmer. This one overrode background. So I added custom background in mainmenu_background_custom.gui and put the following into mainmenu_custom_defs.gui: //stgatilov #5323: customize background in main menu the new way #define MM_BACKGROUNDS_MAINMENU_NOTINGAME BackgroundCustomHHI #define MM_BACKGROUNDS_EXTRAMENU_NOTINGAME BackgroundCustomHHI #define MM_BACKGROUNDS_MAINMENU_INGAME BackgroundCustomHHI #define MM_BACKGROUNDS_EXTRAMENU_INGAME BackgroundCustomHHI #define MM_BACKGROUNDS_BRIEFING BackgroundCustomHHI #define MM_BACKGROUNDS_DIFFSELECT BackgroundCustomHHI #define MM_BACKGROUNDS_SHOP BackgroundCustomHHI The behavior is now the same as it was (although I find it strange that background changes to default one for briefing, but then changes back for difficulty selection). The updated FM works properly in 2.09, except that custom menu background is gone.

It is deprecated, and will be removed soon. It is more complex because it is more flexible. What about reloadGUI console command?

I think this is yet another precision/tolerance issue in dmap code. It is caused by brushes with almost parallel adjacent faces and large coordinates. I hope I will fix it one day: https://bugs.thedarkmod.com/view.php?id=5648

Quite interestingly, there are two almost parallel planes/sides which most likely cause the issue. However, they are not present in the original brushes: they are added to brushes as "bevels" when brush is expanded by AAS box. The bevels are generated from edge of brush and coordinate axis (in fact it is Minkowski difference), and it seems that the parallel edges are not exactly parallel here...

I think these clip brushes are solely responsible the issue. The horse matter only because if you remove it, then AAS won't be compiled at all. Also the type of AAS used by AI matters, since the brushes are enlarged by the AAS size before building BSP tree. Dmap is not very good with sloped brushes, and I suppose this is the bad case. If you offset all the brush planes and intersect them with each other, you will probably see some subspaces which are very thin. At least dmap manages to find such bad volume. I think if it is possible to modify the brushes slightly, the error should go away.

Ok, I see why this warning prints random numbers. When BSP tree is build from brushes, there are two types of brush splits by chosen plane: Splitting brushes from the map Splitting the "volume" of the BSP node In the first case, the split brush has entityNum and primitiveNum set, so it displays proper numbers. You get the second case. The "volume" brush does not come from the map (it's simply the whole space progressively split into smaller and smaller chunks), it does not have entity/primitive number set. So it prints uninitialized data. As for why this happens: as usual, the volume becomes too small, and splits start failing. I doubt it is fully fixable. The coordinates should still hint at the location which causes the problem.

Wow, this is impressive I think crash on shader compilation is like getting internal compiler error from ordinary C++ compiler. Except that GLSL compiler is embedded, so consequences for crashing are much worse. Luckily, the problem can be worked around by simply removing the manylight shader. I think the black screen issue will return back to you after that By the way, do you want to go into the quest of reporting the issue to AMD? I recall I did it with the bug that texture fetches in global variable initializers didn't work, and got response like "upgrade GLSL version". At least that was response from someone from AMD, as far as I understood. Maybe a crash will get more attention. Also, it is very easy to debug if you attach a full crash dump...

Hey, do you still have some map which shows the original problem? The warning itself happens occasionally (I guess Painter's Wife had a bunch of them), but printing random numbers is definitely not good. In any case, I think it is worth looking at.

Anything. If you want to mess with it now, you can download artefacts for 1.4 from somewhere, and play with it. But I'm quite against committing FLTK 1.4 to SVN at this moment. Of course, if your changes to installer code happen to be small and simple, you can commit them to SVN under some ifdef (maybe FLTK even provides a macro for checking its version), so that they can be enabled later.

We use 1.3.5. The latest stable version is 1.3.6, and 1.4 is not considered stable yet. If authors don't consider it stable, then I'll do the same. Maybe delay this question for a year? It seems that 1.3 branch is not going to have any more releases. Well... what can I say --- that's definitely good for the users It's better if they cannot install TDM to such path, than if they can install but something goes silently wrong afterwards. I think it can be checked on directory selection part: it already marks "bad" path as red, and it can be extended to treat paths with any bad characters the same way.

If I upload it now, then players will play your mission without custom background and with empty briefing until February. Read the original post, it describes where the missions are and when will they be published properly.

Because SVN is used in gamedev, but git is not. Anyway, I'm sick of this question already. Yes, there are plans for official mirror on GitHub for the engine.

Why did you touch tdm_update solutions at all? Just revert the changes. Perhaps it would be easier to put the fix directly into C++ code, by setting #ifdef _MSC_VER for 2019 and above.

I only removed tdm_update.exe, but I did not remove tdm_installer_old.exe --- this one is used now, according to the code. Moreover, the TDM_installer_by_freyk.exe binary that you built does not include it, as seen from its size.

@freyk, I have created another pull request to cover most of these issues. Unless you have any objections, I'll build and publish this version.

Add include <string> I think. As for filesystem, you can probably set _SILENCE_EXPERIMENTAL_FILESYSTEM_DEPRECATION_WARNING define.