stgatilov

Previously there was single main menu UI, now it is recreated when you e.g. start game. So yes, gui vars can get lost if player starts game. This looks like what I would expect from looking at C++ code. And startpos2 should be the name of some entity. If it does not work, should I go through it in debugger?

You should attach files named like tdm_installer_1679746360.log. You can also try: choosing some specific mirror (Get custom version + choose mirror on next page) "No multipart byteranges" setting

The last time (5553) @Daft Mugi reported it "working well". I imagine it should work, no?

Regarding fonts stretching. Maybe I should try to implement width stretching in engine? Suppose that someone specifies "fonts/carleton$aspect=16:9". We break this into font + parameters, load the font, then do some postprocessing. If aspect=A:B, then we scale down by X in (A/B) / (4/3) times, e.g. scale down in 4/3 times in case of aspect=16/9.

I prefer to have one setting like "Motion Sickness" (some better name should be chosen), which simply disables both mantle roll and headbob (and does any future adjustments for the same reason). Most people play OK with default settings, changing these only matters for the minority which feels uneasy with them. At which point it is easier to just disable all the stuff: it does not have any gameplay significance anyway.

That's exactly how the latest dev build should work. With SRT, the sound is extended until the latest end time of all elements. Is it not working as expected?

Everything is rendered to 640x 480, then stretched to whatever screen you have. Giving some GUI element fixed real aspect ratio can only be achieved by computing inverse stretching at the moment when this element is rendered. I think we added "forcescreenaspect" window flag for X-ray overlay, which is usually combined with "hcenter" flag, and it is implemented exactly like this. Making font scale automatically is not a good idea, since it then you'll just get more variety with aspect ratios.

I think we should just add some free font which is scaled in such a way that it looks right after scaling back

I think part of the problem is that fonts are rendered into virtual 640:480 resolution, which is later resized to 16:9 or whatever aspect ratio you have.

Definitely won't do it. The first implementation did not have background, and it was hard to read subtitles on top of some bright parts in briefings. Background is here to ensure that text font is in contract with whatever the game displays below.

dev16783-10307 is available. It would be great if people who had to set "r_useNewBackend 0" try to revert it back to default value. This is the last version with "old backend" code, I'll delete it shortly.

It means that we need to choose a different font. Carleton looks like all caps. With a different font, we will probably get narrower messages automatically.

Yes, I think it is possible to specify efx preset in location entity. Probably worth it to implement cross-fading of EFX settings simultaneously.

There is no such thing as "number of characters that fit", since font is not monospace. The number of characters per line depends on the particular characters. So no, you cannot resize subtitle message while saving exactly the break locations. Except maybe for exactly proportional scaling of both message elements and fonts. I hope that is possible, but not sure.

The problem with tweaking size and font is that any such change breaks existing subtitles. If you do that, you have to review all released subtitles. Maybe now it is only New Job and Saint Lucia, but as time goes, it would become virtually impossible. Just remember what happened recently after a small overflow fix in readables. So the issue of overlaps with item pickup message and HUD should be resolved quickly, and after that fixed forever. Reducing width and font size is perhaps the easiest approach now.

tdm_message is shown on upper left corner, it should not overlap. Yes, I agree that there is overlap with item pickup message, and partly with some HUD elements. My opinion is that we should resolve this for standard GUI size, and simply ignore the problem on larger GUI size. There is not too much space on the screen to fit everything on the maximum that GUI size allows, and I don't like the idea of making subtitles font or amount of text per message smaller.

Every weapon needs vast support both in core scripts and C++ engine, so I'm not sure it is possible to create fully custom weapons. On the other hand, you can take a sword and reskin it to hammer, maybe changing some parameters. Or you can take a bow + arrow, and create a custom type of arrows. The problem is that now the weapons are defined in player entityDef (atdm:player_base), so the only way to change it is to override the whole decl, which can be dangerous, because it is quite likely that the core def is updated. And I think we already discussed this problem once. One generic approach was to allow writing patches to entityDefs without overriding them completely. The other one is of course to just add a second place for setting def_weaponN and checking both of them in future. Somehow, we did not get to implementation. As for turning ordinary items into weapons, that would most likely be harder. For instance, you get the typical inheritance problem: such a weapon must inherit both from atdm:moveable_weapon_base and from atdm:weapon_base, which have a lot of different properties.

Subtitles work during main menu cutscenes (video / briefing), where no HUD is available, that's why they have to exist as a separate entity. One reason why subtitles cannot be included into tdm_hud.gui is that they must be displayed during in-game cutscenes and any other cases when HUD is hidden. The game code maintains a set of overlays, every overlay is a separate UI with its own root "Desktop" window. If in-game subtitles become the part of HUD, then we would have to invent some custom code to not hide HUD but hide almost all the parts of it...

Yes, the original subtitle would apply. What is really bad is that you cannot override subtitle for one sound easily. Now you can override one decl, but a decl often contains many subtitles.

Tracked: https://bugs.thedarkmod.com/view.php?id=6270

If you can provide a way to reproduce it reliably, that would be awesome. I'm pretty sure it was already reported, but I could not reliably reproduce it to understand what's the cause.

It must be just "return *this;" on the second line.

dev16781-10289 is available!

I guess I should just implement the extension for inline subtitles, since now it is just a matter of convenience. SRT can allow you tweak the extension anyway. Would it be good to make duration extension a parsing state like "story" / "speech" ? If you write "inlineDurationExtend 0.5", then duration of all inline subtitles below are extended by 0.5 seconds. If you don't set anything, it is default = 0.2. I'm not very fond of this stateful approach, but it is already used with verbosity, and I believe the main idea was to avoid copy/pasting too much stuff (especially when new parameter is added). I hope that if the decls are kept small enough, then we won't have a problem that finding all the state variables gets too hard and error-prone.

Can you give some examples of what should be extended and what should not?