OrbWeaver

Compatibility profiles are an aspect of standard OpenGL initialisation. They are not related specifically to AMD or enabling support for particular games. In a Core profile, certain deprecated features (like immediate mode, glBegin/glEnd etc) are removed, whereas in Compatibility profiles they remain available to support legacy applications. The driver is allowed to offer different GL versions for each profile, for example on macOS if you request a Compatibility profile you will never get anything more recent than 2.1. Neither the Core not the Compatibility profile should vary its be

Some mouse buttons emit keyboard events automatically. I have a Logitech G600 MMO mouse and all of the buttons on the side are just aliases for the number keys ("1"-"0", "-" then "="). So if your friend can use a mouse like that he can just bind those number keys as he wishes, without needing to worry about handling them as special mouse buttons.

Help with what? This is a thread about the proposed DarkRadiant material editor. I'm not sure how online 3D asset libraries are relevant.

I guess that's the disadvantage of splitting the interface into Basic and Advanced — everybody has slightly different ideas of what features need to be in the Basic mode. That's my understanding too, but how many mappers are creating custom transparent materials? I can't imagine they would have more than one or two in a mission, whereas they might have hundreds of custom brick or stone textures. Using one stage to write to particular channels which then control the behaviour of a subsequent stage definitely feels like "advanced" functionality to me. It's also useful for ti

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/

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 (

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 y

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

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

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 rel

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 al

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 t

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 fo

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) whic

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 othe