OrbWeaver

I agree entirely, but I think ID already did that by using "blend blend", "blend add" and "blend filter" for the most common operations. Trying to make up a name for every other possible combination is a lot of work, and doesn't really add much value. As you correctly point out, those custom modes are for advanced users who know exactly what operation they want to specify, although they could still be made slightly more friendly by dropping the explicit OpenGL API names (i.e. "Source alpha" rather than "gl_src_alpha"). Right, it's just a question of whether it's worth having the Basic/Advanced distinction go as far as removing items from dropdown lists. If the switch between Basic and Advanced only controls the visibility of entire widgets (via tabs, or some other method), then the blend mode dropdown is going to be visible in both modes including its "Custom" entry (at which point you've got to have the src/dest blend mode widgets visible as well, although obviously they should be disabled if "Custom" isn't the chosen blend mode).

I would leave the blend modes in the Basic section because you've already got a dropdown for the common blend modes (diffuse/specular/bump) so you might as well have them all in there rather than having two separate dropdowns. However I would sort them by order of usage, e.g. [Diffuse, Bump, Specular, Add, Filter, ..., Custom] so the most useful selections would be near the top. I'd also have all of the colour options in the Basic interface (rgb, colored, vertexColor) etc, along with probably alphaTest. I think the masks, depth hack, private polygon offset can go in the advanced section (although maybe mappers are using these more than I assume). That's not easy to accomplish. You'd have to make up a name not just for each keyword but for each pair of keywords (I count 36 combinations in total), and it might be far from obvious what name to use for many of the combinations (especially considering not everyone is a native English speaker). I think at the point where people are choosing the Custom blend option, they probably know exactly what operation they want and obscuring the technical details with vague terms like "Soft light" would just confuse things.

Regarding having every option available to avoid losing data when an existing material is passed through the editor: I think that is an important feature, but it also leads to two conflicting design goals. On the one hand, you need to save everything so no data is lost, on the other hand, many of those settings are pretty arcane and probably never used by ordinary users, so having them in the UI makes it seem overly complicated. Would it be possible to decouple the UI and the data storage, so that while all settings would be stored internally when you load a material (and preserved when you save it out), you could still pick and choose what was actually exposed in the UI?

You shouldn't need anything specifically from TDM, all of the light stuff should be in the original id Tech game assets which it sounds like your game is based off. Do the light entities appear as light volumes, i.e. with rectangular radii and light_center points etc? If so this means that the entityDef is located correctly and DarkRadiant is using it to construct lights, so the problem is specific to rendering. If the lights appear only as generic entities and do not have visible and resizeable light volumes, then there is something wrong with the entity def — you might just need to set the "editor_light" spawnarg to get DR to recognise it as a light. If the light volumes themselves appear correctly but do not render anything in the lighting preview mode, my guess is that it is something to do with light textures. If you use the light inspector to change the light shader, does it make any difference? If you examine the MTR file for the light shader you have chosen, it will point to one or two falloff textures (e.g. "lights/biground1a.tga"): do these textures exist in the specified location and have appropriate contents?

As Greebo says, the renderer does not care (or even know) about the specific type of game, but the correct rendering of lights will depend on the presence of a working "light" entityDef along with the falloff textures that are applied to the light. If your game is set up in a way whose light setup differs considerably from Doom 3 or TDM, it is possible that the assumptions made by DarkRadiant no longer hold and the lights will not work, but we'd need to see more details of the game assets in order to fully diagnose the issue.

I'd say if the photo is one he's already shared publicly it's fine, otherwise I would treat it like a photo of any other living person and not put it on the internet unless you know for sure that the person wouldn't mind.

I have the same issue but I always assumed it was because of poorly-performing AMD drivers. Interesting to hear that it affects nVidia too.

Oops, that's an error on my part. I was messing around with the ID names but discovered that using a full address like that didn't work and thought I reverted the change, but I must have only reverted it in one script and not the other. You can work around it by searching for the string "com.thedarkmod.export.ase" and changing it to "export.ase", which is what it was originally.

Which Blender ASE exporter are you using? I just did a search for "WHO" in the one I maintain and didn't find anything, so you might give it a try if you are having problems with a different exporter.

Nothing wrong with that, if you find ASE easier to work with. However for ASE the requirements are rather similar: the *BITMAP line needs to contain the full TDM material path. The advantage of ASE is that you can edit the file after export in a text editor, whereas with LWO you have to get it right in the original modelling tool.

It needs to be the full material name, including any parent "folders". Note that material names are actually just arbitrary strings, which do not need to correspond to on-disk paths, and the "folders" are only used for organisation in DarkRadiant. It is not a requirement that they start with "textures" or "models", or even have any folders at all. You could use "Material.001" as your material name, or "/my/really/weird/path", and it would work fine as long as it was correctly matched by the model file's material name.

You don't need an entity def for a static model. Defs are only required for entities which "do things", e.g. a candle which spawns a flame and a flickering light. To import a textured LWO model you need to do two things: Create a material file to construct the texture out of individual images (diffuse map, bump map etc). Set the name of your material (e.g. textures/darkmod/stone/brick/redbrick_with_mortar from the linked page) as the object's material name in your modelling application. If you have problems I suggest breaking this down: Define your material and apply it to a simple brush in DR, then view it in game. This proves your material definition is correct. Set your model's material name to a known-good material from the core mod, e.g. one of the brick or stone textures, then import the model and confirm that the model appears with the chosen material. This proves that your model is exported correctly and you have set the material name in the correct place.

I'm commenting on the technical uselessness and impossibility of the "closed packages" idea, which is a mathematical fact, and has nothing do with my "attitude" towards mappers or content creators. If you choose to believe that such protection really is possible, if only the developers care enough about mappers to get off their lazy asses and implement it, you go ahead and believe it. I can't force you to change your mind. Perhaps you can actually find some developer somewhere who is actually interested in implementing such encryption just for the lolz, and you could work with them to release a fork of TDM which would include this feature. But if you're relying on such a trivially-defeated level of protection to allow you to comply with a license which says "nobody must be able to access these models", you're on very legally risky ground. Regarding textures which appear to be taken from other games, of course I agree entirely that such textures are being used unlawfully and should be removed from the mod immediately.

Too bad. This is an open source project based on free licenses (GPL and Creative Commons). The team is not obliged to implement utterly worthless and trivially-defeatable DRM systems just so a few mappers can more easily use assets with non-free licenses. You're not getting it. There are no such things as "closed packages" which can be opened by open-source software. The "security measures" you propose are not simply weak, they are non-existent. Anyone who knew basic C++ would be able to remove the "protection" within an hour, and release the DRM-free version of the mod on GitHub so all the "script kiddies" could simply use their version without needing to do anything themselves. Or just release a command line tool which would convert a "closed package" into an open PK4 in a single step. The likely outcome of trying to force such DRM into the mod is that the development team would split, between developers who wanted to maintain the DRM (if there are any) and those who only wanted to work on a DRM-free version. Based on past experience (Oracle buying Sun, XFree86 vs X.org, etc), when open-source projects start trying to close stuff down, pretty much everybody jumps ship to the open version. I'm not sure this would be a great outcome for the mod or its player base.

Thank you. I can't believe this thread is now two pages long and nobody until now has noticed that you cannot have DRM in an open source project. This has nothing to do with ideology, people "believing everything must be shared" or anything else. It is literally impossible. Yes, you could encrypt the PK4s if you like, but in order to play them, the game has to decrypt them, which means the decryption key has to be accessible from within the game source, which means that everyone who has access to the game source (which is everybody in the world, because it's GPL) is also able to decrypt those packages. So your encryption has achieved absolutely nothing except waste developer time and CPU time on the player's system. DRM doesn't work particularly well even in closed source software, but it cannot work at all in open-source software. This is why there will never be an officially-licensed open-source DVD or Blu-ray player for Linux (the players that exist have to bypass or crack the DRM), and why viewing DRM-encrypted video streams in open-source browsers requires you to download closed-source components like Widevine. The only way to implement such DRM in the mod would be to make it entirely closed source with a decryption key carefully hidden in the binary so that it is very difficult to extract without step-by-step assembler debugging, then constantly update that key if and when people do manage to extract it (which means you need a revocation mechanism, a way to update existing missions with new keys, and all other key management headaches). But none of this is an option, because you can't legally take GPL code and turn it into a closed-source project. By all means continue to discuss the benefits and drawbacks of DRM, the impact on the community, the social contract and implications regarding user trust, and everything else. But in my opinion such discussions are a waste of time when the underlying technical proposal is so completely infeasible that it can never happen even if the entire community were 100% agreed that it would be a good thing. You might as well be discussing whether we should build a football stadium on the surface of the Sun.

Ugh, no. DarkRadiant is a mapping tool, not a DRM enforcement system. Disabling or removing features because someone, somewhere might use them to violate someone's copyright is the sort of rubbish we saw when the late-twentieth-century RIAA and MPAA wanted to ban MP3 players and CD writers because people might use them to copy commercial music. Then those models are not compatible with the CC license used by the Dark Mod can cannot be used as part of the mod, full stop. Our CC license requires sharing alike and restricts commercial use, but no more. There are no restrictions on formats or storage mechanisms, and any license which imposed such additional restrictions would be CC-incompatible and therefore unlawful to distribute as part of a CC-licensed work. You seem to be under the misconception that there is something magic about the ASE format which means it can't be loaded into anything else. This is incorrect. It is a text format like any other, and it is easy to write an import script for it just as you can write an import script for OBJ, LWO or any other format. There is even an ASE import script for Blender 2.49, which according to your interpretation would make it impossible to follow the license of certain models until Blender is deleted from the internet. If a license is interpreted such that following the license is only possible as long as some other piece of software does not exist, there is something very broken about that license and I would suggest not touching any assets which use such a license.

No, it's definitely ready to go in at least as an additional layout option. I'll create a suitable bugtracker ticket. Of course we'll want to be sure that it works well on a range of systems before using it as the basis for all the existing layouts, but it's looking promising so far (I withdraw my comment that it is "useless", but I still feel it is somewhat confusing and could be made more robust).

Well I managed to get the persistence working at last. The clue was in the fact that calling _auiMgr.LoadPerspective(_auiMgr.SavePerspective()) worked fine, indicating that the saving and loading code wasn't fundamentally broken, but something was wrong when the saved perspective from one session was loaded into the next session. Following the clues in this thread, it turns out that if you don't give the panels deterministic internal names (which is not the same as their user-visible caption), wxWidgets auto-generates a named based on some internal data (maybe pointer addresses) which do not match between sessions, resulting in failure to load the persisted data. I still consider it a bug that the result of this failed operation is all the panels disappearing; after all if wxWidgets cannot match layout data to panel names, it should just leave the panels in their default state, not set them to invisible.

Sure, by all means have a go if you like. Most changes are committed into my master branch, although late last night I finally worked out how to default the panel sizes (it's a horrible hack, requiring you to set initial minimum sizes of half the main window size, add the panels, then set the minimum sizes back to 128x128 so the user can shrink the panels again) and this isn't committed yet. EDIT: This is now committed. I think at this point its functional enough to remain in the software as an optional new layout, but without the persistence it cannot be a replacement for all of the other layouts. One thing I haven't checked yet is whether the persistence does work but all the panels are just hidden by default for some reason. There are options to hide and show panels which I haven't used but perhaps their default value is changing. I'm beginning to wonder if we should just skip whatever version of wxWidgets Linux distros install, and instead have a Git submodule pointing directly to wxWidgets source which we compile ourselves. I think they are using CMake as well so integration probably wouldn't be that difficult, and it is consistent with the direction software seems to be moving in (Snaps, FlatPak, AppImages etc which always bundle the complete set of libraries, including GTK and the like, so you never have to worry about what is available on the distro).

Well it was worth a shot, but it turns out wxAUI is useless, unmaintained junk that simply doesn't work as advertised. In particular: The saving and loading is absolutely broken. Even if I pass back the exact string that it dumped out to the console, copied into a hard-coded string in code, all that happens is every single panel disappears, making it worse than no persistence at all. There is no way to fix the size issues with the panels. The only thing which works is setting a minimum size, which means the user can no longer shrink the panels down. The "best size" value is completely ignored by the initial layout; it only applies if you float the panels and then re-dock them with the mouse. These two factors combined effectively make it impossible to layout the panels to mimic the embedded layout, taking up the entire window. The panels can only be initialised as two small strips along the left and right edges (determined by the minimum size) with a large grey space in the center. Similar problems have been reported by other users years ago but nothing is ever fixed, just a few comments from developers insisting there isn't actually a problem. Of course it's possible that the behaviour is very different between Windows and GTK backends, and maybe between wxWidgets versions (we already know there are a fair number of bugs with the 3.0.x series on Linux).

They do. There are SavePerspective() and LoadPerspective() methods on the AUI manager which can import/export the configuration to strings, which can then be saved in the registry. I haven't got it to work yet, but I assume it's just something I'm doing wrong and needs more debugging. If this can be made to work well I'm definitely in favour of getting rid of the old-style hard-coded layouts as well as the wonky position/size-saving code which has always been unreliable on my Linux system.

I added an experimental AUI-based layout. The API seems promising; the dock panels can be moved around as you wish, and can be floated as separate windows, meaning that the layout @peter_spy wants (with just the properties panel floating) could be achieved very easily. The major annoyance at the moment is that the dock panels start out really small at the left and right edges of the window, almost like toolbars, and have to be manually dragged to fill the window. I guess there is something weird going on with size hints.

It would be interesting to see if the wxWidgets AUI functionality is suitable https://wiki.wxwidgets.org/WxAUI Apparently it is supposed to provide the sort of customisable dock-based interfaces that you get in certain modern applications, but I haven't done any testing to see if it is suitable or would work with DR.

Oh yeah, I forgot about that. It was awful. Rather than just raising your blackjack, you'd actually dive forward out of your hiding spot, right into the light where the guard was standing, and then stand there through a 3-second "muffle the guard's mouth and lower the body" animation. At which point every other guard in the area was coming straight for you. Do I remember correctly that some of the "blackjack" animations actually involved kicking the guard in the balls, or am I just imagining the game to be even more cheesy than it was?