OrbWeaver

I don't recommend changing the volume of ambient music in a specific mission, because this is something that is supposed to be under the player's control (as chosen by the volume slider in preferences). If you change the volume in the map itself, all it means is that the player will adjust their own volume slider to compensate, so you're just annoying the player without really obtaining any "artistic freedom" for the effort. Ideally all ambients would have a carefully matched volume level, so players would know exactly how loud the music is going to be based on their volume control setting. However we are a long way from that ideal. It is very easy to add a custom ambient and make it far too loud, particularly if it's music you like and/or your own in-game ambient volume is set to a lower level than default.

Support for FullName is implemented for the LWO exporter. It is not yet implemented for ASE export or either of the importers.

Yes. Copyright infringement comes from using the copyrighted code, it has nothing to do with what you use it for. Even if you copy that code into an Android alarm clock app, you have committed copyright infringement. Nope. Copyright applies in full to the engine and the basic code. It does not apply to the generic "idea", although it can apply to the idea at a more specific level (so you can't make another game called "Duke Nukem", but you can make another FPS featuring a musclebound dudebro protagonist). If they are using the same engine then they have licensed that engine. They are not using stolen code. If they did, they would be sued into oblivion. Again, you are confusing "ideas" with code. Anyone can make a generic shooter, RPG or platform game without infringing copyright, as long as it's not called "Super Mario Brothers". The basic idea might be the same. That has nothing to do with the code. You don't need to steal code to implement a game which has similar ideas. Claiming that software which does similar things must be using stolen code is the sort of thing Darl McBride came up with in the SCO vs IBM lawsuit. It failed spectacularly because his assumption was wrong. There was never any stolen code. Correct. Not correct. Copyright law applies to large companies just as it applies to individuals, and since they are prominent companies with deep pockets, they are much more likely to get sued. That's why they have a legal department to make sure they are using all IP correctly. They do not steal code. I suppose if you're talking about some fly-by-night Chinese rip-off company, then they might be stealing code (since enforcing IP against companies in China is notoriously difficult). But if we're talking about AAA game companies in the US or Europe, using stolen engine code is not normal behaviour, although there may be occasional instances where it happens.

It's also copyright infringement by anyone who uses that code in their own game. Copyright doesn't magically vanish the moment the first person who leaked the code is caught and punished. Copyright follows the code/image/text/movie wherever it goes, and if you use that content in your own work without permission, you have made a derived work which is copyright infringing. You're saying that most games are based on illegally leaked code? I don't know what you're smoking, but I suggest you cut down on it. Making a work which is "similar" has nothing to do with it. Copyright applies to specific texts: code, images, movies, blog posts etc. It does not apply to generic "ideas", which is why anyone can make a first person shooter, or an anime series about heroes saving the world, or a story about a teenage wizard (as long as he's not called Harry Potter). If the company doesn't exist anymore and the rights to the IP were not sold or passed on to anyone else, then you have an "orphan work" which (depending on legal jurisdiction) may be covered by special rules. But in game development this is a rare situation, because if the studio who made the game is shut down, the rights to the game will pass to the publisher, or whoever else buys the original studio's assets. Companies don't usually disappear into thin air, they get bought out by someone else, or their assets sold off in bankruptcy proceedings. So it would be very unwise to assume that a particular leaked codebase is an orphaned work just because the original company which made the game doesn't exist anymore.

I remember when the Blender limit was 19 characters. At least the developers of Blender have generously allowed us a whole 63 characters to play with, although why the hell anyone thinks it is acceptable to have hard-coded name length limits in 2022 is anyone's guess. The aforementioned "skin trick" was something I came up with as well: each model had a material name like "sk/my_model" which then used a skin to map the model surfaces onto the real textures. But this is only useful for models which have their own custom texture; it is not so convenient if you want the model to use a regular, arbitrary Dark Mod texture. I'll have to check the state of the import/export scripts. The custom property approach should certainly solve the problem and I'm sure it has been discussed before, but I don't recall if it actually made it into the code. Perhaps if it hasn't already been implemented, the time to do so is now, given that the 63-character limit is clearly causing problems for some people.

Why?

As @Zerg Rushsays, "good" and "free" are not a happy combination for VPNs. I used ProtonVPN Free for a while, but it took months to get off the waiting list and given an account, the performance was terrible, and any kind of file sharing (e.g. BitTorrent) was completely blocked. I now have the basic package for $5/month, which I consider extremely good value even though I don't use it all that frequently. You have a big choice of servers with good performance, and some of those servers support BitTorrent (I use the ones in Iceland). Be aware that most VPNs don't support IPv6, so if you have an IPv6-enabled ISP, your IP address can "leak" even while the VPN is active. Some VPN software (including ProtonVPN) will therefore include an IPv6 "kill switch" to prevent this from happening, but you should always check it's working by going to a "What's my IP address" site and ensure that no IPv6 address is visible.

Not just a cosmetic issue in fact — it would be better gameplay for a guard to stop and enter a "Huh?" state for a couple of seconds, giving the player a cue that he had been spotted and giving time to run away, rather than have the guard act as if nothing was wrong and then suddenly enter a combat state. Perhaps this could be solved fairly straightforwardly by setting different delays for the various levels of state transitions. I.e. transition from 0 (unalerted) to 1 (huh?) could be instant, but the further transition from 1 to 2 or more (actual attack) could be significantly longer.

There are things I like about UEFI. Being able to install Windows after Linux and not completely trash the bootloader is nice (the two OS's just add their own entries to the system partition and appear in the list alongside each other). GPT was also a big step forward over the horrible 1980s primary/extended partitions (although I think you might be able to use GPT without using UEFI). Also for some reason Ubuntu loads so much faster in UEFI mode. I have no idea why. When I was using BIOS it took something like 2.5 minutes before I saw a login screen.

There is not currently any such feature. It probably wouldn't be a huge amount of work to implement, but to me it seems very much a stop-gap measure of limited utility. The objective of the lighting mode render is to look as similar to the game as possible by rendering objects in the same way; if you want a more visible but less accurate view, the unlit render mode is designed for this purpose. When the lighting mode does not look the same as the game, this can be considered a bug in the DR renderer which should eventually be fixed (and Greebo has been doing some amazing work in DR 3.0 closing the gap between game and editor rendering). I don't think that manually creating "editor-only skins", simply to fake the correct rendered appearance, is a good use of either mapper time or developer time. Mappers should create content the way they want it to look in the game, and DR should do the best job it can to render that content in an accurate way.

Confirmed. All tests are now passing on Linux. ~BufferObject() { - glDeleteBuffers(1, &_buffer); + if (_buffer != 0) + { + glDeleteBuffers(1, &_buffer); + } + _buffer = 0; } D'oh. I actually saw that _buffer was 0 in the debugger, but thought it wasn't important. Although the docs say that glDeleteBuffers should silently ignore 0, so I don't know if it's actually related to the crash.

Oh yes, sound radii definitely should not be opaque, since these are typically much larger than the relatively small light center points.

I actually like them opaque. It makes them easier to see and less likely to be confused with other wireframe objects (such as the light boundaries).

Sure, I'll create a bug for it. I did try turning the _geometryStore member into a unique_ptr and explicitly resetting it in shutdownModule(), but this did not solve the problem. However it's possible I did not do it in the correct order with respect to other members which need to be cleaned up. I also noticed that there is a potential race condition during the shutdownModule calls themselves, because we don't actually take dependencies or initialisation order into account during shutdown — we just shut down modules in the order they appear in the _initialisedModules map (which I guess is alphabetical). This was causing my HeadlessOpenGLModule to be shutdown before the OpenGLShaderSystem which I was convinced was the cause of the problem... but even fixing this did not help.

The Linux segfault is definitely not merge related, since I can reproduce it in your branch prior to the merge commit. It looks like a problem with OpenGL being called during shutdown (maybe after the context has been destroyed or invalidated?). Here is the stacktrace: The actual line which crashes is: -> 31 glDeleteBuffers(1, &_buffer); which then jumps to address 0x0000, which I think can only mean that the glDeleteBuffers function pointer itself has been set to null. My first thought was that headless OpenGL simply won't work on Linux, but this doesn't really make sense as an explanation because the crash happens in an OpenGL call during shutdown, which must have been preceded by several other calls (which did not crash) during initialisation and running the tests. Also there is a HeadlessOpenGLContextModule which has been used by tests for 18 months without crashing, so it can't be the case that no OpenGL commands work in tests. I'm guessing this must be something related to the order of destruction of some of the new rendering-related objects (as commented within the OpenGLRenderSystem destructor), but I'm not sufficiently up to speed on how the new objects fit together to identify an obvious root cause.