Jump to content
The Dark Mod Forums


  • Posts

  • Joined

  • Last visited

  • Days Won


Spooks last won the day on January 5 2021

Spooks had the most liked content!


724 Legendary


Contact Methods

  • Website URL

Recent Profile Visitors

2715 profile views
  1. In addition to this, can anyone testing compare the RAM usage between an old version of DR and this one? If there is still something like 3 to 4 GB of discrepancy, I'd say it's still cause for concern.
  2. Turns out the problem with the loot purse had to do with the entity, weirdly enough. atdm:loot_spilt_purse doesn't work, but atdm:moveable_loot_purse_belt with the other entity's model on top does work. Hell. I don't know. I had an inkling though and it's good I checked, that's some headache saved. This one works just fine, thanks a bunch!
  3. I'm still on Windows 7 per my mantis bug reports. I'm also using the portable versions to test, if that helps any. I opened Down by the Riverside's river.map ("from Project") to test out the new lighting preview mode with DR 3 earlier in the week. It also lagged like hell but mainly due to zooming out the orthoview, not so much flying around. I thought that might be normal, not my map, right, so I ignored it then. DR does die pretty quickly when I'm zooming out in King of Diamonds' kod.map and there I'd definitely know if something is out of the ordinary.
  4. I'd definitely appreciate it if the light diamonds weren't opaque. Back to wireframe or if translucency can be worked into it that'd be fine, too. Really annoying as they are with regards to candles and small objects like that, you can't do clutter with those things getting in your way. Something a bit more important than that, though. 3.0.0 either has some crazy lack of optimization in the new render code or there is a memory leak somewhere in there. I opened a heavy map (any finished map basically, my map has 14k brushes and ~5.5k entities for example). I kept the windows task manager on top to track the RAM usage and the more I moved in the 3D view the higher the "Working Set (Memory)" went. It didn't matter what render mode I was in, looking around was faster than previous DR versions but moving with the freelook caused heavy stuttering. Worse yet, zooming out the orthoview stuttered like hell and the RAM usage quickly spiked up to the max 6 GB my system has. Bam, computer freezes, have to push the reset button with a paperclip. It's replicable, I made it happen twice. First time with the original release and now with pre2. For comparison, the copy of 2.11.0 I keep tops at 1.35 GB of memory usage on the same map and does not increase in this way at all.
  5. Okay, @Geep , I did a quick test and I've remembered it wrong, it seems to work for what it was supposed to do. It must be that DR's grouping was just sort of "good enough" for me and I forgot about these. I also re-read what I had written in the thread and I remember that my "100 groups" comment was clearly meant not as a wedge for instancing but as an aid in modular building. Because models don't seal geometry func_groups can be a good way to make brush-based kit pieces or at the very least standardized sets of caulking and monster-clipping brushes. If you have a good idea of what the scale of your map is going to be, you can copy-paste func_groups and conceivably greybox more efficiently, too. The one thing I figure you can add in the wiki page is mentioning that you can use func_groups to set a permanent rotation origin point on a bunch of brushes and do more advanced rotation that way. The bit about the entity filtering is also true but all the while I do still have, from back in the day, a custom filter that only shows func_groups. "Entity class .* hide", "entity class func_group show". Don't remember how useful it was, but it may also be worth mentioning that a user can just have a custom filter that shows only them and worldspawn (effectively "Filter All Entities Except func_group") - you only need to add a third rule that says "entity class worldspawn show".
  6. I may see about it in a day or two but right off the bat I am pretty sure func_group never got around to being implemented. SteveL stopped posting on the forums altogether about a year after that post and I've not heard hide nor hair from the feature. I remember testing it, though after five years it's difficult to recall whether it was in 2.03 or 2.04. It "worked" in a very gimped way and I've not touched it or used it in my mapping since. The whole functionality of it has largely been superseded by Dark Radiant's grouping feature, though of course my hope was that this was going to be a wedge for the possible implementation of instanced map regions/map section nesting, like Valve's Hammer editor had (and there's been discussions of that very thing in the forums, recently too I think). The wiki article might simply be useless but you or I could give the func_group thing a whirl in-game and actually check to what extent it works. This week's busy though so unless there are any brave experimenters it will take me to the weekend to get to it.
  7. Two questions: I have a golden skull with some rubies in its eye sockets. How can I make it so that the rubies drop down if the player steals the skull before they steal the rubies? I have a lootable coin purse that has hide 1 and a script activates it (thru activateTargets) so it gets unhidden. The problem is that then the player can't loot it, it's unfrobable. I've tried to set the activator not to $player1 but that hasn't fixed it. Any idea what I can do here?
  8. The TDM script reference on the wiki page seems to be pasted twice over. It's already a long enough page as it is... 🥵

    1. Show previous comments  1 more
    2. nbohr1more


      It looks like someone tried to make it "easier" by having all the commands listed sorted by spawn class. If that is needed, it should probably be on it's own wiki page. Do you have wiki editing rights?

    3. Spooks


      I don't but then again that double listing has been around forever iirc (subsection 1.1 v 1.2). There was a whole section 2 that was basically a repeat of 1. It's good that stgatilov regenerated it though, not only did it make that go away but the last update was from Dec. 2021.

    4. datiswous


      Styling of that page is quite minimal. I added some styling myself (with Stylus plugin), to make it better readable:

      h2 {
          font-size: 180%;
          margin: 2em 0;
      h3 {
          color: blue;
          margin-bottom: 0.5em;
      h4 {
          margin: 2em 0 0.5em 1em;
      dl {
          margin: 0 0 1em 0.5em;




      This does make the page much longer.

  9. I've tested several now and it seems only the jd_hand GUIs give me trouble. (When I said "take any of the books or scrolls" I should've been read as meaning "any of this particular one that struck me as wrong ") The double sided book one skips two lines at the end and the paper one skips a single line. I have not tested every single common-use GUI with its font thoroughly, to see if I catch another mismatch between the editor and in-game, but I'll provide the little test map here in a pk4 (the jd_hand ones have been set up to exhibit the bug, they are on a table in front of the player spawn). For testing, one can just go down the list in the readable editor, hit save, and reload xdata in-game to see if the number of lines matches. wysiwyg.pk4
  10. OK, so this is bothersome. Take any of the books or scrolls GUIs and the DarkRadiant readables editor will either show that they can fit text that is a line over or under what actually shows in-game. As an example, "guis/readables/books/book_hand_jd_hand.gui" will fit, in the preview, an extra line at the bottom that won't show up when I test inside the map. Now what I've noticed is that the GUIs in the preview and those in-game have a different aspect ratio. I play on a 16:10 resolution. Is it that the GUIs get stretched rather than centered, could that be the cause? So, in the end, is it really a problem on DR's side or on TDM's? This kind of mismatch is dangerous because you can type out text lines in-editor and have them get cut short for players even if you see them yourself (provided resolution stretching really is the issue). Imagine it's some mission critical information that's in the readable and you have yourself a soft-lock.
  11. Hey, did someone manage to make a version of the forge builder that uses weapons ie is not a civilian? I remember somebody struggling with this but I searched this thread and got no results.
  12. Yep, pretty much only the wood trellis and the wallpaper are custom textures in that, too, the rest is stock assets. OT I do quite like the new menu style. The original background concept drawings, by Springheel I believe, are very nice but the whole grainy and fuzzy aesthetic that the paper parchment menus have only gets older as time moves on. Not that we should be jumping to super-sleek, geometric stuff, but at the very least a resolution increase is sorely needed. UI ought to serve rather than impress, after all.
  13. The 'Attaching Props to AI' wiki page refers to this post and the follow-up by Obsttorte to state that "You cannot directly vary the presence of a def_attached item by Difficulty Level. A work-around is to clone your AI, then make them differ in their diff_n_nospawn spawnargs and their attached items." The very next reply in the thread after Obsttorte, to my amusement, was me also being unhelpful. Just about 6 years later (!) I'm in a better position to answer this question. You can use spawnargs to handle the case of props on AI without having to resort to cloning said AI, so if someone wants to edit the wiki with my info I'd appreciate it. The way to do it is with diff_x_arg_y and diff_x_change_y rather than diff_x_nospawn. You set up the key (or whatever else) to spawn on the AI conditionally per difficulty setting rather than not spawn conditionally after it has already spawned. Here is a visual example of the kind of spawnargs you need to put on your AI. This, for instance, will spawn a named, grey key on the belt of the AI only on the easiest difficulty. Do not give any 'default' values to these spawnargs, leave them undefined and only define them like this. The other way around — pre-defining these spawnargs (ie setting them as usual) and then "blanking" them through diff_x_change/arg_y — that doesn't work.
  14. Speaking of this actually, this is something I'd already fixed in my mission's upcoming patch but I suppose I stupidly didn't bother mentioning here. I had several moveables with hide_distance and no lod model to replace them (so they'd just not show) on a shelf (and the shelf itself was hide_distanced in that way, too), and on 2.10, when you got to them, they had fallen through the shelf. Obviously not the case in 2.09. I tested around and found out it was the hide_distance was the thing causing it (and that probably on the shelf rather than the moveables) but since I didn't want to disable their hiding I just set nodrop to 1 as an alternative fix. I guess if there were LOD fixes that might be one consequence?
  15. The volumetric rays will go through stuff like walls while the light itself will be stopped by them, ie it will cast shadows. If you have something like a street light in the middle of an empty street there is no downside besides possibly particles being a more FPS friendly solution.
  • Create New...