OrbWeaver

There isn't anything exactly equivalent to a last modification time, but you can listen for modifications to entity key values by constructing an Entity::Observer and attaching it to an Entity with Entity::attachObserver(). However, this will only give you changes to key values on a single entity. While you could theoretically attach an observer to every entity in the map, this would be an O(n) quantity of observers and callbacks and would probably cause performance problems in large maps. If you're not looking for a notification mechanism but just a way to determine what has changed (effectively a "diff" operation on the entire map's entities), I can't immediately think of a way to do that efficiently in the current codebase, since it's not a problem DarkRadiant has ever needed to solve before.

That would be ideal I think. A toggle setting for "DR camera follows player position" plus a one-shot button for synchronisation in the other direction. That certainly makes sense. There's not much point in you spending hours tweaking wxWidgets layouts in DarkRadiant, when your skills are more needed elsewhere in the mod. Ah OK, I didn't realise the implementation was still in progress. I'll wait for the eventual pull request rather than trying to preemptively integrate things now.

That actually looks very cool. I was originally assuming you were just going to add an extra button along the lines of "Reload this map in the game", but you've gone all the way to full bidirectional camera synchronisation in real-time which could be extremely useful (and help get around the drawbacks of DR's very limited rendering). I think there could be some improvements to the UI but that's something we can handle on the DR side. I would be interested in testing your changes, but I'm not sure how to integrate them with just the new files attached to the forum post (or is it literally just a case of adding them to the build and everything happens automatically?). If changes outside of those files are needed, would you be able to produce a patch using git-format-patch which should cover everything and is very easy for other Git users to apply?

I completed it! 4645 loot and about 2:14 completion time, all optionals completed (on Easy). I really liked the "old hidden area"; very atmospheric with some great lighting and architecture. I didn't quite understand the ending though, it seemed to be

Symbols like Matrix4 are in the math library, which you can add to your link options. However, GlobalCameraManager is only available within the radiant binary, so your initial assessment is correct — this part is not available for plugins. Historically there has not been any use of external plugins that interface tightly within the main UI (as opposed to adding new dialogs which plugins like Objectives and Stim/Response already do), which is why the CameraManager is not exposed in this way, although it is already a module with a defined interface so it could be refactored if necessary. For now though, it might be simpler just to write your prototype code as part of the main radiant binary rather than as a separate DLL. It could always be separated out later if there was a need.

With regard to 1), I suppose it would be possible to track the number of requests to the mission server from the in-game menu (without logging IP addresses or other personal information of course), and use this as crude measure of current player activity. It wouldn't be possible to derive actual numbers of unique players, just overall trends, but it might be interesting to see how the player activity varies over time (e.g. are there big spikes after a major release, has there been more activity during lockdown, etc).

The LWO export script has now been updated to support Autosmooth settings. A new option is present in the export dialog, allowing you to choose No Smoothing, Full Smoothing (looks the same as ASE), and Use Autosmooth settings. If you choose Use Autosmooth settings, the settings of Autosmooth in Blender will be exported into the LWO file, allowing you to use both smoothing and flat shading on the same model without needing to manually split vertices.

A spent a good few hours playing this mission and although I eventually got stuck and did not complete it, I still thought it was a very good mission and will provide my feedback now rather than waiting until I eventually get around to finishing it. The architecture was excellent. I particularly liked the fact that everything was realistic and believable. The walls looked like walls, the stairs looked like stairs; there were no unsupported flagstone textures on the ceiling threatening to fall on my head, and no awkward-looking half-courses of bricks on stair risers and above doorways. You certainly hit the jackpot with the "non-linear" aspect. The whole mansion was like a rabbit warren, with multiple routes everywhere. On the downside this did make things somewhat confusing, although the maps did help. Most guards were blackjackable and there were no forced-ghost objectives, so thanks for that. You even provided some extra ammo and resources in the armory, although I had explored most of the map before I noticed it was there. I feel that having both a "church" and a "chapel" in the same map is rather confusing, and might be even more so when translated. Judging from some earlier posts in this thread, it seems that other players did get the two mixed up. A minor audio nitpick, but I felt that some of the ambient sounds were both too loud and too small in radius (e.g. the bubbling pot on the stove in the kitchen, the wall clock in the kitchen, and the dripping around the well). You wouldn't hear them at all from a couple of meters away, but when you got up close it was suddenly the only thing you could hear. I suggest leaning in the other direction for more realism: wider radii but lower volumes, so the sounds fade in and out more naturally. I do want to have another go at this and get to the end because from some of the other posts it seems like there is an interesting ending.

Interesting, I didn't realise that. I'd better check my recent changes, because I might have inadvertently added new minor usages of Boost without realising that the headers wouldn't be available on Windows.

There is no safe way to knock someone out in real life. Not with a bump on the head, not with choking. Even using a poison dart dipped in some anaesthetic would not be safe, because anaesthetics need to be carefully matched to the patient's body weight. We all know this. It doesn't matter. The Dark Mod is not a reality simulation. The blackjack exists because the aim of this game is to deliver an improved version of the Thief gameplay experience, in which blackjacking was an important mechanic. That's all there is to it.

I guess you're talking about Boost libraries here? I think we are still using quite a few of the header-only Boost facilities, although it's mostly just simple things like the string comparison algorithms. As you say, most of the stuff we originally used Boost for can be replaced with modern C++ (std::function, std::shared_ptr etc). Agreed. The library dependencies are cumbersome even on Linux, so I definitely would vote for restricting ourselves to only those elements of Boost which are header-only (and only then if there is no standard library equivalent).

In DarkRadiant we heavily use Boost, so Boost.ASIO is a solid choice, although if you're not using Boost in the game itself I don't know how easy it would be to "manually construct" the other end of a Boost.ASIO channel. I guess you can just use Boost to connect to a pure TCP socket however. ZeroMQ is also a very good toolkit. I have used it in a commercial project and it was very easy to use. Since it is header-only and doesn't require pulling in Boost.System, Boost.DateTime etc it might be easier to use ZMQ on the TDM side, which in turn means that you can use the same library for both ends of the connection.

That is very similar to my suggestion for a separate command-line tool to run dmap. Essentially it would be the TDM binary but compiled in a mode which only ran dmap on a map specified as a command-line argument, and would not include any of the higher-level gameplay or rendering code. Running it as a command-line tool on demand (which then exits) would be much easier to manage than having a persistent process which accepted commands over IPC.

Right, so a library-based dmap is probably a non-starter unless large parts of idLib were integrated into DR, which would be a huge task. A command-line tool ought to be possible though. Instead of building the main game, you'd use different compiler settings to produce an executable which only ran dmap on a command-line argument (it would be quite a fat binary of course, but I doubt people care much about executable sizes these days). I seem to recall the open-source Quake 3 did something like this, and they provide a q3map2 binary along with the game engine. I don't think that would be a problem — the map compilation process is pretty much the same across all D3-based games, isn't it? Or have we made a load of compilation changes specific to the Dark Mod? You're right, it probably is of limited benefit. Being able to pass dmap arguments directly from DarkRadiant and read the log output would be nice, but this can be achieved with the socket approach just as easily (or just parsing a log file that dmap writes out to disk).

For dmap specifically, I wonder if this would be a good candidate to move out of the game altogether, and into DR, either by splitting out the code into a command-line tool that DR can run, or as a library that DR can call into? Map compilation seems like something that might be better off in the editor (for improved user feedback etc) rather than in the game itself. The other suggestions (like hot reload) are clearly things which need the IPC-based automation mechanism. Do you really need persistent, event-based Python scripts for those tasks though? It seems that most of them are "push functionality" which happen in response to clearly-defined DR user actions (such as saving the map), rather than ongoing synchronisation. Maybe bidirectional camera synchronisation — moving the DR camera in response to player movement in game — could benefit from event handling, but would you really want this functionality to be "always on" rather than moving the DR camera when the user specifically chooses to update it by clicking a button? I would have thought that the DR camera jumping around in response to another application could become very confusing and annoying. Yes, they can do all those things. "Plugins" in DR are really more like Linux kernel modules: there is no binary API, plugins have full access to all DR structures, and must be built at the same time. The decision whether to put some code in the core binary or a plugin is somewhat arbitrary, and the only use of plugins currently is to make it possible to build two packages on Linux, so that users can install core without the Dark Mod plugins. On Windows there's only a single installer so you always get the Dark Mod plugins anyway (although you could delete them from disk if you really wanted and DR would run fine).

Silhouette-based visibility gets brought up fairly frequently, but unfortunately it's a complete non-starter from a game design point of view. The current system based on incident light depends only on the player position. Silhouettes depend on both player position and the views of individual guards, who each have a different view of the player silhouette. There is no practical way for the lightgem to show both incident light plus an arbitrary number of silhouettes based on the number and position of guards in the scene, and even if you could find a way to represent this, requiring the player to mentally keep track of their possible silhouette as seen by every (moving!) guard in an area would make effective stealth almost impossible. As for degrading stealth based on the amount of collected loot, this is an even worse idea than degrading player performance based on lost hitpoints (which has also been suggested). At least you can avoid losing hitpoints and/or consume healing potions, but you cannot avoid collecting loot since it is the purpose of the game. Making the game harder and more frustrating over time, for no other reason than "muh immersion!", effectively punishing players for doing what the game requires them to do — that's an excellent way to piss off the player base and encourage them to go do something else.

I recently upgraded my AMD graphics drivers and in the latest version of their configuration app, they are listing a couple of my installed games (which I have been happily playing for years) as "Minimum system requirements not met". System "requirements" that aren't actually requirements, just guesses as to what sort of hardware would give best performance, are pretty much useless in my opinion. The only things which should be listed as requirements are actual hard requirements, like a GPU which supports OpenGL 3.0, a CPU which supports the AMD64 instruction set etc. I've never seen a game which would refuse to run if you didn't have enough CPU cores or a high enough clock speed.

The V-2 rocket was both the first object to be propelled into space and the first major usage of a liquid-fueled rocket engine, so there is a direct lineage from this weapon to the liquid-fueled rockets of today. This is the only connection between Nazis and space rockets and you're right, it's completely irrelevant at this point in time. If the Nazis hadn't invented this rocket, somebody else would have. But that's exactly the point. We don't demand that space rockets be uninvented and memory-holed because of this historical connection to the Nazis. So why are people demanding that this guilt-by-association approach be applied to other cultural artifacts?

That's fine. You're talking about personally choosing to avoid a company because of the way that company behaves towards their employees, or because you think the product is low quality. This is something people do all the time, for their own personal reasons. Some people don't like to buy from Amazon because of reports of how they treat their staff, or because they put smaller vendors out of business. I don't choose to read clickbait garbage articles by the woke media for the same reason: I am not interested in putting (ad) money in these people's pockets, and their content has no value to me. But this is a completely different issue to what I was talking about, which is the demand to ban content because of the personal views or behaviour of individual content creators, based on a silly superstitious idea that viewing content somehow spreads political views like a virus. Guilt by association is a fallacy, and media effects theory has been repeatedly debunked (although is still sadly believed by many people it seems). No, but that was never my point. It's not about being a hypocrite, it's about the complete impossibility of operating a "all content creators must have clean political opinions" policy, given the vast number of content creators who contribute to modern culture and the impracticality of trying to keep track of all of their personal views.

Woke Myth number 1: depicting something is the same as endorsing it The card is literally called "Invoke Prejudice". Prejudice is a bad thing. It is not called "Nice people with hoods doing good things that we support". The card is a reference to something bad, and the accompanying artwork is intended to depict that bad thing. There are also cards called Murder and Public Execution but I've never heard anyone suggest that these should be removed because they somehow endorse murders and public executions. For some reason, however, when it comes to prejudice and racism the rules are different, so that simply describing, explaining or depicting it in media is somehow considered tacit approval which needs to be censored and apologised for. Woke Myth number 2: the moral behaviour of creators somehow infects their creations (and might infect the audience too) This is the idea that we need to ban films by Roman Polanski because he might have been a child abuser, or that we should stop using space rockets because they were invented by the Nazis. Aside from being ridiculous in itself — problematic political views are not viruses that infect artwork and spread to viewers of that artwork — it is also a completely unsustainable in practice. Here's a trivial example: do you use an Android or an Apple smartphone? How many programmers and graphics designers do you think have contributed code and artwork to the functionality of that phone? Probably thousands, if not tens of thousands. Are you going to track down every one of those people and interrogate them about their political views, then insist that their contributions are removed if they fail to say the correct things about various woke causes? Once you decide to go down this "fruit of the poisoned tree" rabbit hole you will soon find that you have to ban pretty much everything.

There's no need to feel bad about that. We all have different energy levels and amounts of available free time. I find it helpful to set realistic targets, rather than taking on a massive project and then giving up because it seems so overwhelming. For example, I aim to spend one or two evenings a week working on something mod-related, even if it's just adding a small section to the DR manual, doing some minor C++ refactoring that hopefully moves towards fixing a bug, or cleaning up one of the Blender export scripts. You'd be surprised how quickly a small thing each week adds up to something more meaningful over time, and is infinitely better than doing nothing at all. Likewise, as a mapper you might be able to contribute small regular tasks like helping to design a prefab or model for someone else's map, rather than taking on a large mapping project from scratch by yourself.

Let's not go overboard. It's nice if the mod gets a mention in the gaming press, but that isn't a reason to bow down and kiss the feet of the media. That sort of thing is likely to alienate some of the potential playerbase (they will perceive it as "media whoring", "selling out" etc). Of course there's nothing wrong with engaging with their community in a friendly (and non-spammy way), helping people with installation issues or particular missions. But I wouldn't vote for blatant marketing-related things like putting commercial banners in the game.

Presumably this part is the problem? If the lighting interaction shader cannot be compiled, a black screen is likely to result.

Not nitpicking at all. Correctly adjusting volume levels is important but often neglected, even in commercial games (in Dungeons and Dragons Online there are certain quests with background music which is deafening and renders the game sounds inaudible, making me wonder if the developers ever actually test their own game). It's very easy to introduce a cool new sound or piece of music but make it too loud, because subjectively "loud sounds better" to most listeners. Waveform normalisation doesn't solve this problem, because many sounds need to play at different volumes, and peak amplitude doesn't entirely determine subjective loudness in any case. If background music plays at the same RMS power as guard shouts, then the music will sound too loud and the player will struggle to hear the guard shouts at all. I don't think new cvars are needed, just some sensible tweaks to the volume offsets in the sound data files. If particular sounds are too loud, this can be tweaked by adding small volume reductions (e.g. steps of -2 dB) in the sound shader until the subjective volume levels seem more similar. One thing I learned in music production is how much you can progressively lower the volume of a sound while it still remains completely audible (because human hearing is non-linear), but it fits so much better in the mix once it's reduced to a similar level as surrounding sounds.

It wasn't released in the last few weeks, but Left 4 Dead 2 was criticised as "racist" because a few of the zombies were black (despite the story being that the whole population had been infected, which obviously would include people of all races). The "last few weeks" thing refers to the frenzy of censorship and corporate virtue-signalling that has occurred across various types of media since the start of the BLM protests, including the removal of Magic cards, the renaming of Git branches, and the deletion of decades-old TV series. I don't know if it has yet affected video games, but given that it is affecting all kinds of other media I doubt that video games are somehow going to be immune.