OrbWeaver

I don't think anyone is suggesting that music recordings don't have copyright. This is a thread for "Dark Mod inspiration", not freely reusable assets.

That's a test build of a release that is half a year out of date by now. I suggest you install the latest 2.12.0 release instead. If there are problems with key or mouse bindings, you might need to clear out your local preferences.

Of course I'll defer to what the experienced mappers want, but in terms of specific integration features, my suggestions would be similar to what a modern IDE would show, e.g.: An indication of the latest checked-out revision, its commit date and author (possibly in the status bar). A log view that allows you to view the latest changes, and quickly revert to an earlier version. In editor display of your local changes with respect to the last commit, as well as being able to view changes between revisions in the log view. Obviously it's the last one which is the most difficult, because unlike with IDEs, a simple context text diff of a map file would be useless to mappers. For the diff to be in any way useful it would need to be parsed and displayed graphically, e.g. If the change is to an entity spawnarg, show the entity name and the new/old spawnarg values in the diff view. If the change moves an entity, show the old and new positions in the 2D/3D views (e.g. old position in red, new position in green, maybe an arrow pointing from start to finish). If the change adjusts brush geometry, show the old and new brush sizes/positions with a similar mechanism (red lines for deleted geometry, green lines for added geometry). But I'm aware that this would require a huge amount of diff parsing and intelligence in the algorithm — perhaps it might even be completely impractical to interpret the Git map diffs to this extent.

Like what? You "commit", you "push", you "pull", you "merge", you "switch" branches (if you use branches, which most mappers probably won't be doing). These terms are pretty much identical between Git and Hg, and provided you are using a decent GUI the workflow is basically the same. Honestly I think the "Git is hard to use" meme dates from about 2006 (when the only way you could use Git was via a bunch of non-obviously-named shell scripts on Linux) and hasn't been updated since. Not that I've got anything against Mercurial, it is a decent user-friendly VCS which I would be happy to use if it had become the market leader. But the disadvantage is that relatively few public sites offer support for it, since everybody is using GitLab and GitHub these days. I always used to think this, but recently @stgatilov actually found that SVN sucks for large binaries too, because of the limited window it uses while diffing. So I don't think there's any VCS that is actually good for binaries. SVN does have the advantage that you don't need to clone the entire history when you checkout the latest version, which might make it slightly better for absolutely HUGE projects. I never really understand this argument either. "Spending 30 seconds to click the Commit button and enter a brief log message is too complex, therefore I'm going to manually make ZIPs of my map and copy them to another directory because that will be much quicker!" It's actually more work to do the thing which is "not overkill" than to do the thing which is "overkill". I suppose if you're using something like Dropbox already and you just put your WIP map directory inside your Dropbox folder, that is going to be easier than using any kind of VCS since it's all automatic.

Thanks for raising this. I think this is a very important topic, and could save mappers a lot of frustration. Reading about mappers occasionally losing all of their work always made me confused, since it ought to be an easily avoided problem, but I guess non-programmers don't naturally gravitate towards version control systems in the way that we do. Even if VCS features don't become part of DarkRadiant itself, a basic how-to guide on the wiki might be a helpful starting point.

I interpret "no archiving 'as is'" to mean that Grayman was not going to provide unfinished beta versions to be released after his death — not that he wanted to retroactively remove the already-released missions.

Yes, it's source code so you need to rebuild. The code doesn't end up in the installation directory because it gets compiled into machine code and written into the "darkradiant" binary executable and its shared libraries.

The effect is generated in your brain because the two eyes focus on different parts of the image which are similar enough (at the random dot level) for the brain to "match them up" and resolve into an apparent 3D image. Simply putting two parts of the stereogram on top of each other would not produce anything other than a meaningless fuzzy image. In any case, "simulating" 3D in a game by processing random dot stereograms wouldn't make any sense, because the stereograms are themselves generated from a 3D model, which the game could just render directly using OpenGL.

https://gitlab.com/orbweaver/DarkRadiant/-/commit/66b3c0780c16268985b4b1f6929780ffbb297db2

It turns out we were doing exactly this. I have removed all forced colour setting in the Entity Inspector, and instead show the inherited properties in italic text. I think this makes the distinction clear (along with the lack of property type icons) without compromising visibility in either light or dark themes.

Wouldn't the leaf plane shadows look wrong in any case, because they would just be the shadows of various squares and rectangles, with no visible leaf pattern?

I can have a look at the code and see if there is something specific we're doing that would override automatic text colour changes (perhaps we are forcing black rather than setting just the default colour for non-inherited properties).

So it turns out Blender has no concept of a "two sided face", but during rendering it assumes everything is two-sided by default unless the "Backface Culling" option is set in the Material properties. It seems therefore that the only way to handle these duplicated faces during import is to discard them, and if the user really wanted to export with duplicated geometry in this way, an option would be needed in the export script. However, I think that there is actually no need for such duplicated faces in the LWO files, because (like Blender) "twosided" is a property of the material shader, not the geometry. Provided the hedge materials contain the twosided material keyword where necessary, the models could be exported without duplicate faces and this might give some performance benefit.

No there isn't. We don't have any support whatsoever for dark themes.

I think it's a problem with the current incarnation of the script. These are some faces created out of vertex IDs in model hedge01_square_long.lwo: Face: [5288, 5286, 5289] Face: [5287, 5286, 5288] Face: [5288, 5289, 5286] Face: [5287, 5288, 5286] So although it's using the same three vertices to create two faces, the vertices are specified in a different order which is clearly intended to create two-sided faces. The problem is that when I try to create such faces in Blender it throws an exception (Face already exists), and does not seem to care about the vertex ordering. I'll need to research what is the correct way to handle this in Blender, perhaps there is a two-sided property that can be set on the face rather than trying to create it a second time.

No. There is zero performance benefit in doing this, and creating complex shapes with brushes is more likely to result in map leaks or bad geometry generated (e.g. missing triangles). The result will also look bad because the level of detail you can create with large flat surfaces is low, and there is no smoothing applied, so the results will look more like Thief 2 than a modern game. Not as far as I know. You can copy textures from different surfaces using various combinations of mouse button and modifier key, which might help in some situations, but I've never seen any way to project textures based on the camera position. I suppose this would be useful if you wanted to create a flat but non-rectangular shape (like a trapezoid door) and you wanted the texture to align to the edges of the patch. If the flat patches are rectangular I don't see how this would be any better than just putting the texture on the brush itself. Of course for non-flat surfaces, patches (with caulk brushes behind if needed) are definitely the way to go if you can't or don't want to use a 3D modelling tool.

I noticed something weird when using my WIP import script to load the hedge models: there are loads of duplicate faces (the same three vertices are used to generate a face more than once). This resulted in about 2400 extra polygons for one of the models. However I need to do more investigation to work out if this is a problem with the model or just a bug in the script — perhaps duplicate faces are how the LWO model represents twosided faces which can be viewed from both directions.

Scaling only increases the size of existing faces, it does not create any new ones. But because the texture will be scaled along with the model, the hedge leaves will probably look huge.

The Real WTF is that a model which looks barely any different from a slightly misshapen brush manages to waste 9600 polygons. I can only assume it was generated with some procedural method which produces a very high number of randomised internal polygons which in all likelihood you cannot actually see from the outside. Out of curiosity I started updating the LWO import script for Blender. Currently it imports edges and faces but is not yet handling materials and UVs, so it's a long way from "round trip safe" in terms of loading and editing existing models.

If we have control over the error text, shouldn't it be something more informative than just "Too few"? It would be more useful if it said something like "Too few combined texture units (need 48, found 32)".

That's not exactly what I mean — I am referring to the fact the the whole mansion interior seems to be lit at a fairly constant level, even without any visible light sources. The line about "I need to get the lights on" falls a little flat when I can already see perfectly fine with the lights off. Maybe I'm just playing with a much higher brightness/gamma than expected, although I haven't noticed this appearance in other missions. I wonder if it would be creepier if the interior was almost pitch-black, except around windows? Perhaps those weird noises would be even weirder if you can barely see anything outside the radius of your own hooded lantern (which in turn makes you visible and vulnerable). There would then be a more significant difference (and sense of relief) when you finally get the lights on. Of course this would be a dramatic change from the mission as it currently is, but might be worth experimenting with.

Well good luck to you, but don't underestimate how much programming time will be required, and how much this is likely to cost. A competent programmer working alone might be able to produce a reasonably decent game in six months. Based on average programmer salaries in the UK, this would cost in the region of £20,000. You could try a site like Freelancer.com and find some delusional guy in Delhi who hasn't actually read the brief telling you he can do it for $150, but that's not going to work out well for you.

A few misconceptions here: Neither MD5 nor PROC are binary formats. Even if they were binary formats, this would not affect licensing. Intellectual property does not generally make a distinction between "binary" and "text" formats, which are technical not legal terms (and not particularly well-defined even in the technical world). Being "specific to a particular engine" is also not relevant, particularly when that engine is itself open source. There are several open source MD5 exporter plugins available, and PROC files are generated by the id Tech 4 map compiler which is also open source. So even if formats could be proprietary, it is difficult to see how these would qualify, being entirely producable by open source tools. As stgatilov says: Even Microsoft under Steve Ballmer could not prevent open source tools from loading and saving .DOC files, which is considered a "proprietary format" because it is not publically documented, not because it is actually illegal to read or write it. You can't in general "own" a way of organising data in a file, although you could: keep the specification secret (e.g. DOC files) apply a restrictive license to the documentation or SDK required to read and write it, forcing open source developers to use reverse engineering to create their own, possibly non-compliant implementations (e.g. FBX, VST plugins) in certain jurisdictions, take out patents covering particular aspects of the algorithm (e.g. most recent video codecs, MP3 until fairly recently). require a valid file to contain a large block of trademarked or copyrighted content (such as your company logo), making it legally impossible for third parties to create files which your own software would accept. I believe some of the consoles have used this to prohibit third party games.

You're mixing up a few different things here. DarkRadiant is just the editor. Its source code is fully GPL, but if you're just using it as an editor to create maps, the license doesn't matter — you can release those maps under whatever license you want. DarkRadiant isn't in itself a game engine, so you can't really make a game out of it, although you could use it as your preferred editor for producing maps with your own game. The Dark Mod source code is the game engine, and it is GPL. It is not unlawful to try to sell a game based off it, but it would be commercially rather difficult — why would people pay for your game when they can just download the source (which you are required to publicise, according to the terms of the GPL) and build it themselves for free? The Dark Mod assets include all of the textures, sounds, models etc used in the Dark Mod, and the majority of these are released under a non-commercial Creative Commons license. This means that it would be unlawful to use these assets in a game that you wish to sell commercially. What you could do is use the Dark Mod GPL code as your game engine, then release a commercial game using 100% original assets that you create yourselves, and require people to pay for the game which includes your assets (while they could still download the engine source code under the terms of the GPL). This is essentially what ID Software did when they made Doom 3 open source: you can download the game engine code for free but you still need to buy Doom 3 if you want the full game including all of the content.

Age ratings are a joke. Every time I go to the Elder Scrolls Online website (or its store page on Steam) I have to enter my age into a combo box. It's not a horror game, there's no porn involved, but some Think Of The Children bureaucrat has nevertheless decided that a standard fantasy MMO is somehow too dangerous for the children, and further decided that children are too stupid to enter a fake age on a website, so we all have to jump through this ridiculous hoop just to read some patch notes. The developers of Elite Dangerous, on the other hand, don't even respect their customers enough to offer an opt-out from the kid-friendly censorship. Ship names are silently censored (visible only to other people — you have no idea if your own ship name has been changed), starring out not only obvious swear words but even foreign language words that appear in the middle of other words, as well as totally harmless words like "hell" which are only considered offensive by Bible-thumping rednecks. Presumably this embarrassingly broken automated censorship is imposed to comply with some age ratings agency, because I'm pretty sure not a single player has asked for it.