Search the Community

Yep I assumed it was all 16:9. The code can be modified so referenceAspect is no longer const. It could use 16:9 as default and for other aspect ratios perhaps forceAspectWidth/Height can be set on those screens and the referenceAspect would be calculated based on those values. I agree it would be nice to drop special images for different aspect ratios. I was able to change the spyglass & keyhole images to always use the 16:9 image and it worked nicely. The issue is just finding a way to have the black background continue outside the letterbox area so the game viewport is not leaking through. With the fullscreen changes I was hoping to find some general way of correcting the UI without having to change the content too much, ideally so mission creators wouldn't have to go back and change their content to support different aspect ratios. I did however hit a roadblock because it seems that loading screens and briefing screens are copypasted for every mission so this content may need to be patched anyway. If a whole pass on the GUI files is necessary anyway I would skip the fullscreen hack and aspectAware parameter and go with something else that makes sense.

I created the page: https://wiki.thedarkmod.com/index.php?title=Lightgem In the source I placed the following text: <!-- Page text made by forum user Fiver: https://forums.thedarkmod.com/index.php?/topic/22327-how-can-i-create-an-account-on-the-tdm-wiki/&do=findComment&comment=491145 --> Personally I think the page isn't really necessary because the info is already present under HUD.

I don't know if it's mentioned anywhere else on the Wiki, but it's worth mentioning that the first global keywords are for sound: // Use on of the predefined surface types like: // none, metal, stone, flesh, glass, wood stone And this: //surftype15 //description "carpet This is a carpet texture." I think this is sound as well, but I also think 'description' does other stuff, for example for using with vine arrows: stone description "vine_friendly" If someone has a list (or link to code) where all this is defined for TDM so mappers are aware, that would be useful. I would also move the 'special keywords' section up so it's before the obsolete stuff - that old stuff needs to be relegated to the very bottom. I would also change the title of that section from 'No ambient and frob -stages needed' to something like 'Deprecated stages' and say it's just there for historical reference.

@Geep Regarding 0.24 vs 0.25 font scale. I think there was purpose, though I can't say now which exactly. Maybe it was to ensure that all the text fits, maybe it was to make vertical padding symmetric. Anyway, why do you think 0.24 and 0.25 differ? I did not look in the code yet, but I think what engine does is 1) choose most suitable image, 2) render quad texture with it. Indeed, we can avoid some blurring if the pixel size of the quad exactly matches the image size. But I guess the engine counts font size in 640x480 virtual resolution. So even if the font size would be "12", it would later be stretched over whatever width you really have (if your aspect ratio is 16:9 then height would be stretched equally, but otherwise it would be stretched with different factor).

Since a few versions the settings are saved by minor version - so DR 3.7 is storing its settings in a "3.7" subfolder, and DR 3.8.0 is saving them in "3.8". (DR 3.7.1 and 3.7.2 would use the same "3.7" folder.) Settings are carried forward the first time you start a newer version. So, when DR 3.9 first starts up, it will use the settings of the highest previous version available, then store its settings in the "3.9" subfolder to not overwrite anything from previous versions. (This is similar to what's Blender is doing, at least I think it is.) What's correct though is that the "portable" version is not differing from the installed one in terms of where it stores it settings. They both behave the same. One could maybe vote for having the portable version to store its settings right next to the executable. But to support this, we'd need a configurable code path or maybe even a separate compilation for the portable edition.

In the first post of the other topic Geep proposed: Then Stgatilov's answer: But I think applying subtitles in different languages shouldn't be too hard I would think, but I don't know how the current translation system works. The engine should apply the correct subtitles based on the applied language setting, this doesn't need a whole new language system I think. Not sure who's going to write those subtitles though. I can only do Dutch and English and nobody needs Dutch I think. I suggest further discussion of this to take place in topic https://forums.thedarkmod.com/index.php?/topic/21741-subtitles-possibilities-beyond-211/

It isn't that difficult, but it looks a little ugly code-wise. In the latest version from @stgatilov found in this post just replace: #define SUBTITLE_BASE_Y (379 - 52 * SUBTITLE_IDX) with: EDIT - Removed because it was wrong. Check this post. Mind you! this again is a quick hack with no guarantees. Code must be properly assessed if we go for it.

Yeah it would be cool to see some more detailed statistics and it’s a shame they aren’t really captured. Since we are talking about fan mission platforms, where players also make the content for the game, I feel like the best thing we’ve got is you can look at the number of content releases for the games. Keep in mind the graph counts campaigns as single missions - so for example NHAT and TBP both count as 1 mission. A good year for TDM has has approaching maybe 50% - mostly we’re 25-30%. https://www.ttlg.com/forums/showthread.php?t=152494 You could also look at the number of ratings thief missions get on https://www.thiefguild.com/ vs TDM ones, but that is pretty iffy in that you could chalk that up to more awareness of the site in the thief community than TDM Out of curiosity is there a reason a thief player can’t be a new player? I kind of think a player is a player and new players would be ones who are playing the dark mod who weren't? Is there disagreement the base of players most likely to pick up the game are fans of the thief games? They are certainly the most fruitful place to find feedback on the game beyond the sphere of this forum that I have seen. When we were trying to finish up SLL there was a lot of discussion on the forums about how long it had been since there was a release for the game. I am thankful that the stats show at least some stability over the years in terms of releases for TDM, but the trend for all of the games is decline. Not doing anything is a valid response if that’s what the devs want to do - it is not possible to provide evidence that any effort will slow that inertia. As a player and content maker I would just prefer trying to find feedback where it is offered from players who were willing to try the game but ultimately could not engage with it and see if there is anything that can be done within reason to ease them into the game. The game has a lot to offer imo. All those players are potential contributors - contributions in turn attract players - it’d be nice to see the cycle go on as long as it can.

I didn't research The Black Mage, but presumably the speech of the guy in red is being delivered by a method where the source location could not be located. This might be because it was tagged as by narrator or by player. Or maybe triggered by a script somehow, directly or via a speaker. Not sure about that last thing, because a speaker does have a location (whether it's the "right" one from the story point of view is another matter.) Might warrant further investigation within the source code.

Thank you. Here is an updated version of "Outlined Yellow" based in your latest code. The image of the ring is no longer fully transparent and it comes with an outline now for improved clarity. Base colors of the image are now shades of grey and the color of the widget is now changed by making use of the matcolor property so that colors of both the widget and the text could change simultaneously via user input. z_Subs_212_Outlined_Yellow_20240108.pk4

Keep in mind that different Linux distros use different display architectures, some of which use GPU compositing. Some of the compositing based desktops hard-code vsync on regardless of driver setting. Conversely, some X11 based distros have notorious problems with vsync that can only be fixed by changing the default Window system or some other workaround.

What I found is that changing the color of the text by using the escape character [^] is a feature of the Doom 3 engine and not something created for the subs in TDM. What is happening in your "extremely bolted" example is that when using a color other than the default we are also rendering all eight "shadows" in that other color, hence the bold appearance. The above solution doesn't solve a thing and I cannot think of anything other than having the source code deliver a copy of the subtitles stripped from color escape characters. In any case, imagine for a second you are watching a TV series and each episode comes with subs in different colors...

Replaced in svn rev 16896. The 20 pixel padding was introduce conservatively before the font was changed. Merely applying the 16:9 vs 4:3 correction allows to reduce it to 15. But also the font is significantly smaller now. I tried to edit text in order to see maximum overflow. It seems that capital W is the widest letter in this font, and I can't get a significant overflow (see image below). So I have reduced padding from 20 to 10. Also I shifted everything to the right, so that now subtitle ring and text field are centered horizontally (instead of the background box being centered). This looks much better with frobhelper activated, because previously frobhelper and location ring center we not at the same X position. Finally, I have increased step between subtitles from 50 to 55 to avoid next subtitle box overlapping with previous subtitle location ring. These tweaks can still be changed, since they don't change anything regarding the text layout. Here is how it looks now (blue background shows the text box): My stance on this is still the same: if large empty boxes look ugly, then we can make several possible background boxes and make engine select the best one that text fits into. This way the decision of which box is OK can be made with the very same code that actually renders this text, instead of some external independent computation. There is no reason why smaller background box should be applied depending on verbosity, except that "it looks all non-story subtitles are small enough now". One exception is enough to break this idea. Alternatively, it is quite possible that we switch from background boxes to black outline around text. Both approaches works rather well, and without background we can forget about tweaking the background box. tdm_subtitles_message.gui

In your code you have a duplicated "visible" line. The last line needs to be removed. Excuse if I didn't make myself clear.

I have been quite careful to ensure that making the subtitles narrower for barks (but not story verbosity) is not potentially breaking. Examples of this treatment have been included in all my more recent testSubtitles... releases. Yes, this is "crucial" for me. Regarding the padding issue, to restate: TDM 2.11 and on through the 2.12 released beta version use a subtitle right text padding of 20 px. While some padding is necessary, this does a poor job of centering the text visually in the backing field. This is obvious with a short bark. My redo of this, with padding of 7.5px on both sides, fixes it, while I believe not causing any problems for word wrap of subtitles with the given compressed font & scale. I'm provided several versions above of this fix (code hidden as Spoiler). Most recently, this was with snatcher's suggested tabbed location ring and vertically-tighter backing field, here This version will also be incorporated into testSubtitlesDrunk, to be released tomorrow just released. I would urge you to incorporate this code (or a close variant) into the next beta release.

Download the "White" or "Geep" version from this post. Latest code by Geep can be found in this post (the second "visible" parameter from SubtitlesLocationBacking must be removed). Unless we are talking different things text must be rendered with 8 shifts, otherwise it doesn't look as good: top-left, top, top-right, right, bottom-right, bottom, bottom-left, left.

Very well done, Geep! Remove the second "visible" parameter from SubtitlesLocationBacking and we have a RC1 (Release Candidate 1). What do you think of the result so far? You mentioned your version of the code didn't make into the beta for whatever reason. @stgatilov should run a sanity check now. It was intentionally off from the beginning to support the 3D illusion, along with the thickness on lower half of the ellipse. I don't mind it one way or the other.

How about we proceed next with something like this? If done right the widget can have its own background, and blocks will naturally stand out from one another. Please note the above pic comes from a quick an dirty hack to illustrate the idea so I won't share any code. Backgrounds can eventually be replaced with images with round corners or whatever.

Particle collisions cannot be computed in realtime, particles are purely graphical effect which cannot interact with collisions. So the collisions have to be precomputed beforehand, just like dmap precomputes triangulations of brushes. Most of the nuances grow from here. It was possible in theory to run it automatically during dmap (just like e.g. you never have to run aas tool directly, because dmap calls it automatically), but I'm afraid it would annoy everyone because it may take quite a lot of time depending on settings. Now that some people have some practice with this, should we change it? Most importantly, collisions are precomputed statically. If you move the emitter, the collision information becomes wrong. All objects which seem dynamic are automatically excluded from precomputation, so the particles will still go straight through all the guards and moveables. What do you mean by "default" behavior? Default behavior of what? particles? Like make all particle emitters stop on collisions automatically? What about cases when mapper wanted particles to pierce walls? What about moving particle emitters? The goal was to reduce amount of work actually. As soon as you are able to set one huge particle emitter over the whole map, I think you don't have to mess with it any more, just remember to execute runParticle occasionally when you want up-to-date collisions. Before that, mapper had to split the rain patch into many patches and manually tweak every patch so that it stops at proper height. As far as I understand, it was very time-consuming and painful. As for areaLock, it does not restrict particles to single area. It only disables the whole system if renderer proves player does not see the specified area. As long as the door is open, you should still see rain falling indoors, no? Yeah, this is a tough question. Texture layout: Only works properly if particle evolves exactly the same way if emitted from the same location. Interacts with texturing: requires you to set non-overlapping texcoords in 0..1 range on the emitting surface. The only option in TDM 2.08. Ok for straight-falling rain, but snow is out of question. Linear layout: Only works for a periodic system, i.e. the whole system exactly repeats itself after some time. Precomputation might take a lot of time, especially if you insist on a large period. [problem for maintainers like me] If particle code is changed in TDM engine, the collisions must be recomputed. Was added in TDM 2.09. Supports pretty much any kind of particles, although snow was the main goal.

Creating a new thread for this as it was being discussed in an old beta-testing thread starting here: https://forums.thedarkmod.com/index.php?/topic/21822-beta-testing-high-expectations/&do=findComment&comment=490751 I suppose the main questions are: when should this spawnarg be used, if at all? why was it introduced in the first place? Can we get it documented properly on the Wiki so misuse isn't propagated? @stgatilov @Dragofer

The widget needs a background or a shadow or outline otherwise it cannot be seen in some situations. I am not sure how to deal with this. At this point, I think you are leaning to: The existing background and background color (but from your code that includes a narrower background for barks) Original white text color Newest widget in white color closer to the text it belongs to, similar to the original More centered text

And here is v4 "Geep", based on your code from four posts above. Background enabled Text centered New graphic White color (let me know if you want to test other colors) Choose between any v3 or v4. We will take your choice to @stgatilov for a sanity check afterwards. EDIT: Download removed. Check this post for the latest version.

I will take a look this coming week. In my heart of hearts, I'd rather make "background or not" a user choice. The simple version of that wouldn't be too hard: just a CVar settng the backing field visibility. The more sophisticated version, where no-background implies fake-drop-shadows, requires more thought to make it live with the backing field code.

Thank you very much, Geep. Not in my samples but mind you: I consider this a visual exercise to evaluate what looks best and decide what works and what doesn't. No guarantees in the code. Gui values must be properly reviewed once you settle on something. Find attached to this post v3 "Yellorange". Text is centered and the font color is a yellow leaning to orange, that looks like yellow in the game but it actually is more orange than yellow (for me anyway). EDIT: Download removed. Check this post for the latest version.

There's the inner box to constrain the text, and trigger word wrap, and the outer box to show the backing field. These are identical in size and location except the latter is a bit wider, by 20 px. A comment in the .gui code says: // #5914: engine allows overflowing textbox size by one character // maximum character width is 17 at textscale 0.25, so leave horizontal padding 20 on the right So the motivation is to keep the text from never visually exceeding the backing field. However, that extra padding can not be considered when the engine decides the point about which to center text in the inner box Probably a padding of 20 is excessive, even more so now that a width-compressed font is used. That said, there may be something else dominating the anomaly. And the sound location widget is also off-center.