OrbWeaver

I just checked the tarball which can be downloaded from my GitLab repository (https://gitlab.com/orbweaver/DarkRadiant/-/tree/maint/3.1.0) and .gitattributes is not appearing in the resulting archive, so it looks like GitLab at least is honouring the export-ignore attribute.

If a box is easier to implement than a cone, then no problem. The shape probably doesn't matter too much, what's important it is that it is a volume not just a single line. I don't think the volume itself should handle obstructions, since it would be tricky to work out if an obstruction is actually blocking the blackjack or just an irrelevant intrusion into the edge of the volume. Quite possibly you would need a ray trace in addition to the volume: i.e. the volume is used for AI head positioning, whereas a ray trace is used to check if there is a window or something between you and the AI head. I'll gladly test it out if and when it makes it into SVN and can be tested easily (e.g. with a cvar).

The only person who can answer that question is the person who is actually offering to do the work. None of us can answer in the abstract because there isn't a standard rate for "modders for hire", and the scope and complexity of the task is not well-defined. First you will need to find this hypothetical programmer (or team) who is able and willing to produce the game you want. Then they will tell you how much it would cost and you can decide whether you're willing to pay.

In my opinion it shouldn't be a box or a point trace — that is far too sensitive to aiming direction, as some of the feedback comments are already pointing out. If at any point the instructions involve things like "You are better off aiming at the shoulder blades because they are broader", the implementation is going in the wrong direction. It should be a forward-facing cone (like one of those dog collars to prevent scratching) centered on the player position, and extending forwards. The angle and length of the cone will need to be determined via testing, for example it could be a 90 degree angle extending for 1.5 metres or something like that. If the AI's head is anywhere within this cone, there isn't a wall or other surface in the way, and all of the other alertness conditions are met, the knockout should succeed.

My default position is that pure editor state changes should not be considered part of the undo stack — in other words, if a particular operation would make no difference to the map file on disk if you saved immediately afterwards, then that operation would not be part of the undo stack. Under this criteria, selection changes would not be undoable. The advantage of the above approach is that the "map changed" status can be tied to the undo stack: if (and only if) the stack is empty, the map is unchanged. Although this is an implementation detail that is of little interest to end users. However, there clearly is a case for having selection undoable if certain selection operations are tedious or time-consuming to perform, as has been mentioned with patch vertices. The fact that Blender is making selection undoable indicates there must be a significant demand for it.

Oh, I must have been thinking of 3.1 then, which being an "unstable" release wouldn't be expected to make it into Ubuntu repositories. 2D views, such as the preview image on the Media tab and the main part of the Textures tab, used to show completely white until resized. I haven't actually tested since my Ubuntu upgrade though so not sure if it's still a problem.

Do you still get the render issues in the texture preview window (i.e. the view is entirely white until you resize or force a render in some way, after which it works correctly)? This was always a problem with the 3.0 wxWidgets packaged with Ubuntu. I've been thinking about wxWidgets version recently because I upgraded to Ubuntu 22.04 last week and they are still packaging wxWidgets 3.0, even though 3.2 has been out for a long time. I'm wondering if we need a way to build using a local newer version of wxWidgets that we can include without needing to rely on the distro packages (e.g. with an optional Git submodule). Although if you're getting crashes with 3.2 it sounds like the upgrade might not be as simple as I would have hoped.

I've set the export-ignore attribute on .gitattributes itself, so I guess we'll see if this makes any difference to what GitHub produces. Another possible source for the tarball would be the one attached to the Ubuntu package, which is effectively a "pristine upstream" tarball since I am generating that package myself without any Ubuntu-specific patches. It would also be (indirectly) signed as part of the PPA publishing process. However I don't know if you or Debian would have a problem with basing a Debian package off an Ubuntu package source, since it's usually the other way around.

Yeah, the anaglyph stereo effect is fun for looking at a few 3D objects in picture books, but I wouldn't want to play a whole game using it. The weird inconsistent eye colour really detracts from the image quality.

I don't think the preferred solution would be to remove .gitattributes from source control — even if its contents aren't strictly required now (which I haven't investigated), a permanent requirement to never have a .gitattributes would be somewhat restrictive since we might need its functionality at some point. The problem is that the file is appearing in the tarball, which is unnecessary and undesirable. The first thing to do would be to set the export-ignore attribute on .gitattributes itself, which should cause it to be excluded from any git archive command. I have no idea whether this will affect the automatic tarball published by GitHub, but if it doesn't, presumably it would be feasible for either us (upstream) or coldtobi to create a tarball explicitly using the git archive command from the repository.

I think people are getting hung up on the question of whether the nation of France existed, which is actually irrelevant to this discussion because in the TDM world, none of the real-world nations actually exist with their real names and political histories. Nor does it matter whether "Britain" existed, because Bridgeport is never described as being in "Britain". The question is whether the geography and climate of (what we now call) southern France match the areas which are presented in game. It seems to me that Bridgeport is modelled more on a port city of medieval England (which certainly did exist geographically, regardless of what the country was called or who ruled it at the time). But I guess you don't really perceive temperature in-game, and most missions take place at night in a small area of the city, so it could be pretty much anywhere in (what we now call) Europe.

I actually had no idea that the in-game world was supposed to map onto the shape of real-world continents. I always imagined it was a pure fantasy world like Westeros or Middle-Earth.

I agree. The Hammer interface looks like a much better way of presenting this functionality. Blender also does a good job here — in fact they recently got rid of their "Layers" functionality altogether and merged it into the Outliner/Collections window.

Yes, that was it. I never even realised there was something to pick up in the vault after the "fade to black" sequence.

Yeah, having a completely independent timer seems like a recipe for desychronisation problems. Probably what I'd do is: If the display frame rate is less than or equal to the cap value, just enable vsync and don't do any manual synchronisation — it's not adding any value beyond what vsync does naturally. If the display frame rate is greater than the cap: After a frame is actually displayed (i.e. vsync is completed and the buffer swap has happened), store the current time in a variable. When the next frame is ready to be shown, compare the current time with the value stored in the previous step. If not enough time has elapsed, pause for the required number of milliseconds (or slightly less) before displaying the next frame. Of course this assumes that there are suitable platform-specific methods to obtain the actual display frame rate. I can imagine this might be problematic on Linux given there are two different display servers and several desktop compositors in use. Perhaps the quick and dirty solution on Linux is just to enable vsync by default, then disable the frame rate cap by default (since vsync will take care of it)?

I seem to remember having this issue too. It's strange but the built-in FPS cap doesn't seem to work well on Linux. Perhaps there is some low-level problem determining the correct FPS from the X window system (or Wayland if you're using it).

I'm not sure I fully understand the problem, but yes, materials are written into the map file (that's how the engine knows what texture to put on the side of a brush, after all). Regarding dmap not noticing material changes — that sounds odd, as far as I know dmap does not do any kind of "change tracking" and should just compile the map however it finds it, regardless of what has changed since the last time you dmapped. Note however that dmap is part of the game engine not DarkRadiant, so I can't really be much help with this side of things.

I enjoyed this mission, but fell at the last hurdle: I can't figure out how to "Leave with the loot"! I tried going back to the starting point, but nothing happened. All of the windows have bars, and I can't find any doors out of the bank. I also had to consult the forums to find out how to empty the teller safe. That key hiding place is very non-obvious (at least from a Thief perspective — I guess it makes perfect sense in real life).

Not a problem. This is still useful feedback. If you were confused where to drag, it's a safe bet other people are too, which means there is scope for UI improvement.

It's been like that for as long as I can remember, and I never really considered it a problem as such. This is a 3D game with constant mouselook — I expect it to grab the mouse while it is in the foreground. With in_grabMouse 1 I get a permanently grabbed mouse, as if I were playing the game exclusively. Bringing down the console releases the mouse, as does Alt+Tab or Super+Tab to another application. With in_grabMouse 0 the normal cursor displays on top of the window, in addition to the TDM cursor (if on a menu screen). If the cursor is moved outside of the window, the game stops receiving mouse events, which means there is a limit to how far you can rotate the player camera. This is probably useful for testing GUIs and menus but doesn't seem that useful for actual player navigation.

Windowed mode + console is the only way I can get the mouse back on Linux. I think it's unavoidable: the game is capturing the mouse for freelook and does not give it back until you do something which interrupts the game, e.g. bringing down the console.

Linux builds don't product .obj files. The equivalent on Unix is .o

It doesn't, which is a major oversight in my opinion and the reason I always encourage new sound contributors to provide uncompressed versions as well. As a result of the initial failure to retain uncompressed versions of the original sounds, any editing or cleanup of those sounds (as another forum member did recently) has to rely on decompressing and recompressing Ogg Vorbis files, which is sub-optimal from a quality perspective.

Those guidelines sound a bit outdated to me — like they were conjured up the era of dial-up modems. Ogg Vorbis files are not generally encoded with a specific bitrate, but with a quality factor which goes from -1 to 10. Quality of around 4 - 5 should be more or less transparent to most people, so I'd aim for this. The output bitrate will probably end up somewhere near the values given in those guidelines, but they won't match exactly, and that's fine. The important thing is the constant quality factor, which ensures that the music/SFX sounds good no matter how "complex" it is. Ambient background music should definitely be stereo. Mono music sounds like it comes from the middle of your head whereas stereo can sound like it is all around you (i.e. "ambient"). Of course this depends on the content of the music and how it is mixed, but there is absolutely nothing to be gained by mixing down to mono in this day and age. And if you do submit some sounds, please submit uncompressed (FLAC/WAV) versions as well as Oggs if possible. This allows the sounds to be remixed later (or used to create entirely new sounds) without introducing generation loss due to repeated compression.

I don't understand the seven years ago obsession either. Maybe there is a good argument for allowing oil lamps to be blown out, and maybe there isn't. I'd be fine with it, but perhaps some mappers wouldn't. But the fact that it was discussed seven years ago is of no practical relevance that I can see.