Jump to content
The Dark Mod Forums

OrbWeaver

Active Developer
  • Content Count

    7988
  • Joined

  • Last visited

  • Days Won

    35

Everything posted by OrbWeaver

  1. 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. 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.
  3. 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.
  4. 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.
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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).
  11. 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
  12. 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
  13. 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 compl
  14. 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.
  15. 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.
  16. 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.
  17. 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?
  18. 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 noth
  19. 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
  20. Well that seems pretty conclusive. The documentation clearly specified a behaviour which the library code wasn't actually implementing. Perhaps the fact that it was fixed in a more recent version of wxWidgets means that the defect didn't affect as many users as I first assumed.
  21. 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
  22. 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 abo
  23. 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.
  24. 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.
  25. 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 c
×
×
  • Create New...