stgatilov

I guess footstep sounds are played from within source code. So their volume can only be changed there without information loss. There are already many cvars about that, but a brief glance shows that perhaps they are ignored...

Yeah, it should be renamed so something generic like "Next", because internally all these buttons point "forward" now.

I don't understand what you are talking about. From the point of engine, there is one long sound, and many messages in SRT subtitle. The engine cannot distinguish between messages inside a single sound file. SRT file fully controls how long its subtitles are displayed for. The tdm_subtitles_durationExtensionLimit is merely a sanity limit, to make sure subtitles don't go wild and behave independently. No. I suppose all overlapping messages are displayed at once. Duration is computed from the maximum endtime of all messages.

No... nobody requested it yet. Do you want to make a discussion in Editor's Guild forum?...

The duration for SRT is min(LastMessageEndTime, SoundDuration + tdm_subtitles_durationExtensionLimit)

The subtitle cvars are not for user configuration, they are internal. They would change only if if TDM developer decides that... if player changes that, it would be his problem. Just like very many cvars which are totally not for the user to change. I just committed it in svn rev 10358, so expect it to arrive... I guess I'll publish dev build this weekend. I decided that options always start with minus, while commands always start with letter. That's how parsing can work in well-defined way, regardless of linebreaks. The final syntax is: -durationExtend 0.5 -dx 0.4 Also, for now it only work on inline comments (warning and subtitle removal when applied to SRT).

I still don't like the idea of -x parameter. That would make subtitle decl files linebreak-dependent, i.e. its meaning would change from adding or removing a linebreak. Can you recall any other decl file type that behaves like this?... UPDATE: Although it we forbid commands starting with minus, it can be parsed unambiguously regardless of linebreaks. It's not that -x style is widespread in decl files, but perhaps we can live with it...

The extend parameter for inline subtitles is not implemented yet. Verbosity does not matter. Inline subtitles will be displayed for min(max(c + x, 1), c + 5). Here x = 0.2 by default, or whatever value is set in the extend parameter. Of course all these constants are controlled by cvars, I used their default values for simplicity.

I think it is better to decide on case by case basis.

Made it default.

As far as I see, it uses the bytecode + file indices and line numbers.

These are attempts to show direction to the source of sound. I would be glad if you propose a more understandable but still well implementable different way I set "noevents 1" in tdm_subtitles_common.gui.

You can go to idProgram::Restore, delete "saved_checksum != checksum" check, build the code and try again. But it is quite dangerous. The savefile does not store your scripts, it only stores their hash.

A hotfix release "release211a" is available in tdm_installer. Right now you need to select this version manually. As usual, the savegames are compatible both ways between 2.11 and 2.11a. In fact, the hotfix uses the same executable files, so there is almost no risk of breaking anything. We only fixed a bug with wrong map icons in one def file. Please update your 2.11 installation to this version. It is very unlikely you can meet any issues, but if you do, report them here

Revert scripts to their original state. Script mismatch immediately make savegames incompatible.

I think this can be implemented as postprocessing shader which takes a part of traditional render and bends it to get conformal projection. I.e. when conformat projection is enabled: Find minimum FOV so that camera view contains the whole thing visible in conformal projection Render everything with traditional camera and this larger FOV During tonemap, compute texcoords to sample input from using some nontrivial formula Of course, step 3 will stretch or bend the pixel-perfect render in pretty weird and non-uniform way, so perhaps it would look blurry by 1 pixel in the middle, perhaps it would have aliasing near boundaries. But it will achieve the desired effect with very little intervention into rendering.

"r_useNewBackend 0" will be removed in next release. It is already removed in the latest dev build. You would do us a favor by downloading dev build now and checking whether it works fine or not

That's because invisible full-screen overlay of subtitles block hover events... but not click events for some reason Fixed in svn rev 16790. Also, there is no color highlighting here implemented. Maybe just add hovercolor property?...

I'm pretty sure we will change the formatting/layout soon. Existing messages would fit the new limits (they would be a bit larger), hopefully without exceptions. But the particular look will change, that's for sure. Your question is exactly why we should choose the new format as good as possible and fix it in stone afterwards.

Changed the type of gameLocal.m_StartPosition from "const char*" to "idStr". Purely technical thing.

I'm against offering these setting in the menu, because it would result in subtitles look like trash for all players who have changed them from defaults. Something like cvars for experiments --- yeah, why not. I think it is OK, but this optional parameter must be preceded by keyword, like durationExtend. Otherwise you'll block possibility for adding other additional settings in the future.

dev16789-10349 is available.

I fixed it in svn rev 10348.

I have added support for aspect ratio correction in font: 6283 I'm not very keen to introduce aspect-dependent GUI layout without major need. Unless anyone is interested in 4:3 and 5:4 aspects, better hardcode 16:9 for now. Also I noticed a defect in fonts/stone font: some of its letters overflow their rectangle in font atlas, so neighboring letters render with a thin white line on the left. It is not nice but not critical either. It would be great if someone proposes several layouts & fonts for subtitles, so that people could choose which one to use. The requirements from me are: The amount of text must be a bit larger than what a subtitle currently can hold. Don't obstruct weapon/inventory icons and "you acquired compass" messages on default GUI size. Preferably readable font with 16:9 aspect correction, large enough to be readable when TDM takes half of monitor size. P.S. Did we agree on the syntax for extending duration of inline subtitles?...

Or with different font