Jump to content
The Dark Mod Forums


Active Developer
  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by OrbWeaver

  1. 1 hour ago, Kerry000 said:

    @OrbWeaverGetting the following error when installing your .ase export script (the other two import scripts installed okay). This is in Blender v2.80 and using the correct version (for 2.80) from the page you linked...


    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.

  2. 1 hour ago, Kerry000 said:

    Got you. Thanks again for the help. Have just decided to use ASE model, rather than .lwo, in order to simplify the whole process.

    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.

  3. 3 hours ago, Kerry000 said:

    @OrbWeaver, does the material name in the modeling application need to include the folder path, or just the name itself? (ie. redbrick_with_mortar versus textures/darkmod/stone/brick/redbrick_with_mortar)

    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.

  4. 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:

    1. Create a material file to construct the texture out of individual images (diffuse map, bump map etc).
    2. 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.
  5. 14 hours ago, peter_spy said:

    I doubt such dismissive attitude towards mappers or content creators will help with anything.

    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.

  6. 13 minutes ago, peter_spy said:

    We're talking about dismissing one of the most popular model hosting / selling platforms out there.

    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.

    13 minutes ago, peter_spy said:

    Having closed packages adheres to the terms, there's no requirement on security measures being on par with those used in banks or military.

    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.

  7. 1 hour ago, cabalistic said:

    I may have to see such a license to understand what is truly required, because from a technical perspective, an "unopenable package" is clearly nonsense. The game would have to be able to open it, and with the game being open source, that would immediately tell anyone who is interested how to do it.

    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.

  8. 2 hours ago, peter_spy said:

    Second thing is a bit more controversial I guess, but IMO exporting model geometry should be disabled. This way you can use DR to e.g. export .ase to .obj and modify otherwise unchangeable models (ase can be exported, but not imported into any modeling software). Artists have no control over how their assets can be used, and this way they can be spliced, hacked, and bashed by mappers. Even if you copyright or otherwise restrict the usage, you'll have hard time tracking down those who don't give a crap about modellers.

    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.


    There are many free models that are not entirely CC0, but they're free / allow derivative works, but on a condition of, e.g.: "you may not use the asset in a way that allows others to use or access the asset as a stand-alone".

    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.


    So having DR as an .ase -> .obj exporter makes such terms impossible to follow.

    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.

    • Like 2
    • Thanks 1
  9. 6 hours ago, greebo said:

    Nice you could track that down, there's not much missing now, is there?

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

    • Like 1
  10. 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.

  11. 15 hours ago, greebo said:

    Oh man. I could give it a shot by compiling against the wx3.1 sources in Linux to see if it's as broken there.

    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.


    The dev cycles of new stable releases are almost painfully long in wxWidgets, the 3.1 branch has a few wxGTK bugs less and has been there for years. Users are even "encouraged to use this release, including in production", but it's still not available in a single Linux distro.

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

  12. 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).

    • Sad 1
  13. 5 hours ago, greebo said:

    Great, I like this a lot! Let's hope the docks support some kind of saving/restoring, then I'm all for replacing the 4 existing layouts with AUI-based ones.

    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.

    • Like 2
  14. 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.

    • Like 2
  15. 5 hours ago, greebo said:

    I don't mind adding another screen layout, if it really helps productivity.

    It would be interesting to see if the wxWidgets AUI functionality is suitable


    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.

  16. 5 hours ago, Springheel said:

    in the worst cases actually moved you from the shadow to the light, resulting in detections that otherwise wouldn't happen.

    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?

  17. 22 hours ago, Zerg Rush said:

    Only OpenSource apps or licensed paid apps are used for development for public use, but not freeware apps.

    That is not correct. You are mixing up different concepts which are not in fact the same thing.

    Whether an app is proprietary or open source is dependent on the license. This has nothing to do with price. There is no difference in legal terms between "freeware" and "licensed paid apps". Both are proprietary apps, with the only difference being whether the copyright owner demands money for a license (licensed paid app) or offers a license for no cost (freeware).

    Whether an app allows the distribution of files it creates, and under what terms, depends again on the license, and has nothing to do with cost. There is no general legal principle that dictates that freeware must not allow public distribution of its files, while a paid proprietary app must allow it. I could write a freeware modelling tool which allows full distribution of its files, or I could write a paid commercial modelling tool which sells for $1000000 per coppy which generates proprietary documents whose license forbids all distribution.

    It may be the case that large companies tend to release freeware versions of their major apps which have additional limitations, such as "personal or educational use only" or "no public distribution of files", but these are just business choices. They have nothing to do with the concepts of freeware vs paid apps. There are plenty of proprietary freeware tools which do not impose any limitations on the documents they produce, and as LDAsh correctly points out, no such restrictions can be retroactively applied to already-released versions of the software (or its files) no matter what happens in the owning company.

    Your general point about the advantages of open source is correct in many cases, and I certainly prefer to use tools which will remain open forever rather than being subject to the future whims of an owning copyright holder. You are also correct that people should definitely read the license before committing to a proprietary tool, to make sure there aren't any legal restrictions that will come back and bite them later. But assuming that you've done this and confirmed that no such restrictions exist, there is no reason why you shouldn't use a decent freeware tool if it meets your needs.

  18. 2 hours ago, STiFU said:

    Thief 2014 started out quite exciting, with that big hub-area, but after some time, you notice its problems and so it gets boring quickly.

    • Inability to return to previous level sections (that's a big "no no" for games that revolve around finding loot)

    That was one of my biggest annoyances too. There is literally no reason why those one-way valves needed to exist in the middle of a level, they contribute nothing to gameplay, and they interfere with the loot objectives as you say.

    I also took issue with the pointless "console waggling" to traverse piles of debris, and the parts of the game where you are forced into the open or placed in the middle of already-alerted enemies.

    But I agree with chakkman that the game wasn't crap. It was beautiful to look at and very atmospheric, with just a few gameplay flaws which got in the way (and it was way better than the unfinished bug-ridden shite that was Deadly Shadows).

  19. 2 hours ago, greebo said:

    my first measure would be to remove the Instance() stuff and make it a regular dialog that is instantiated each time it's shown. The problem will most likely go away with it, and we don't need to monitor the GlobalMainFrame to get rid of the instance on time during shutdown.

    It turns out your intuition was right. Removing the static instance fixes the problem with the empty dialog appearing on the second showing, but there is still a problem with the search box. No matter what I type in the search box (even just a single letter), the tree immediately empties of all content, and nothing returns the tree to its previous state even if I delete the search box contents entirely. Fortunately since it is no longer static, I can at least close the dialog and open another one which shows the expected content.

    I'll go ahead and commit this partial fix in any case since it downgrades the issue from major (dialog is useless after first showing) to a minor (search feature doesn't work).


  20. 1 hour ago, greebo said:

    The fact that the EntityClassChooser is a singleton doesn't really help. Population is threaded and working very fast, so my first measure would be to remove the Instance() stuff and make it a regular dialog that is instantiated each time it's shown. The problem will most likely go away with it, and we don't need to monitor the GlobalMainFrame to get rid of the instance on time during shutdown.

    I agree with this general approach. I'm already running into sporadic "Debug/Breakpoint trap" dialogs on shutdown because of some weirdness with the singleton ModelChooser's destruction (something to do with wxWidgets and DecRef() but the problem happens deep within wx/GTK code so it's basically impossible to debug), so getting rid of these static singletons sounds like a step in the right direction.

    In cases where there is still a performance concern with population, we could probably cache just the data rather than the whole widget and get a performance boost without having to worry about wx/GTK destruction issues.

  21. 7 minutes ago, greebo said:

    Oh crap. Are you already investigating it, or should I have a look?

    All I've done so far is confirm that the bug appears in the released 2.11 build rather than just something local to my working copy. If you're set up to reproduce it I imagine you will make faster progress since you're more familiar with that part of the code (especially the search system), but I'm happy to investigate it if it's awkward for you to reproduce a GTK-specific issue.

  22. Unfortunately I have discovered a serious bug in the Linux version which affects the released 2.11 build — the second time you use the Create Entity function, regardless of what (if anything) you created the first time, the tree view is completely empty. I assume this doesn't happen on Windows because loads of people would be complaining about it already. Probably some interaction between the search function and the GTK implementation of wxWidgets tree controls which needs investigation.

  23. 17 hours ago, totallytubular said:

    I'm pretty sure when calculations are done in a loop call, the compiler is smart enough to calculate something once. (So, I'm pretty sure a C-compiler is smart enough to do that, too).

    IE: the TILE_SIZE / 2 in the "for" statements will get calculated once, not each time the loops loop and the statement is evaluated.

    But, in the body of the code after the 2nd "for", the TILE_SIZE/2 is calculated 2 more times on the byte out. So, pre-calc once for the first "for" to use over and over. Another time (?) for the next "for" to use over and over, then 2 more times in the body each time the 2nd for loop runs.

    Your misconception here is that there is something special about loops which means that the compiler will optimise constant expressions used within the loop, but it will only perform this optimisation for the first usage of the expression within the loop body.

    This is not how C or C++ compilers work. There is nothing special about loops, and no limit on the number of compile time optimisations that can be made. If you have a numeric expression which can be evaluated at compile time, e.g.

    int x = 4 / 2;

    then that compile time calculation will be performed every single time. So you can happily write constant expressions like "TILE_SIZE * 4" as many times as you like and the compiler will substitute the constant value result each and every time (provided that TILE_SIZE is indeed a constant, not a variable which can be modified elsewhere).

  • Create New...