Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Spooks

  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.
  16. Something is screwy with decal rendering again. Example: "textures/darkmod/decals/dirt/scattered_dirt01" in the model "models/darkmod/junk/scattered_papers01_leaning.lwo" disappears from view when you look at it at a right angle ie. when you stand over the papers. I noticed a similar thing while beta testing Iris but I don't know if that's the same decal. Another decal to complain about is "textures/darkmod/decals/dirt/scorch_flatbottom", that simply doesn't show from either side even when placed in the middle of a room. This decal has "sort 1" and the former has "decal_macro" in the defs, to shortcut you some info if you need it. I'm on Nvidia drivers.
  17. What AluminumHaste said, but also more practically, just type r_frobOutline and hit tab and you'll see all the relevant cvars. There's ColorA (for alpha), ColorR, ColorG and ColorB. The blur passes set up how wide it is.
  18. After a couple of weeks I've found myself not wanting to move away from preset 3, the image-based one. It's probably got the worst clipping errors of the bunch, yes, but it somehow feels the most unintrusive. I like Deus Ex as much as the next guy but the other presets make it feel a little too much like I'm playing that and not TDM. The only personal change I've made is lower the alpha and change the bright white outline to a bluish-purple. I tried orange, to go with the principle Dark Mod color, but blue is the lowest in luminance, so it is better on the eyes. Tinge it purple and you have a nice thiefy color. No screenshots but, well, I will post some regardless. I think people need to be aware that they can fully customize the hue and transparency of the outline to suit their needs, at least through the console.
  19. Nope, haven't done that, forgot to mention.
  20. Sorry, I don't have it in Darkmod.cfg! I don't have autoexec/commands cfgs either. I've kept a darkmod.cfg backup from 2.09 but it's not there either. Stgatilov may just be right, because I saw this mentioned at some point on the forums and played around with it, a couple of years ago. I have a second, fresh install of 2.03, let me update it to 2.09 then and see if there's the command in there... Well okay, that's weird. In both 2.09b and 2.10 beta4 r_newfog doesn't show up in the main menu but it does show up once you have loaded and are inside a map. Whatever that means, I don't know, but there it is.
  21. I've been too busy mapping so I could knock out two birds with one stone here, get back to general 2.10 testing and help you out with the FM beta test. Count me in, I'm below the "minimum spec" so if I can help any with general performance improvements I'll be glad to.
  22. r_newFog was in 2.09 and it persists in 2.10 beta 4. It comes up in the console when I search for it. I find it weird that you don't have it, AluminumHaste, but regardless that looks like a material problem from looking at the screenshot more closely. They're rendering in front of the fog for sure, maybe if you posted the material def it would be of help.
  23. You should try Obsttorte's fog script for a foglight in only one location. You would need to location-separate your cellar in such a way to ensure the fog fades in and out in not such an obvious way, that's about the only concern with it. A little antechamber usually does the trick. If you don't want fog anywhere else on the map, I believe you can just set the fog coefficient for the other locations to a really low value (or even to just the ones adjoining the cellar, so they clear the fog). I've used the script on a very old WIP and it still works great.
  24. I'll admit that the old frob, through material stages, looks a teensy bit better than the shader version. The new frob tends to bleach out the shadows on the highlighted object. All the same, I see there are some graphical glitches now. This is the female guard from Sotha's Deadeye. This is with r_newFrob 1, it looks normal. This is with r_newFrob 0, the current default. The pants become a solid color on highlight and her face becomes glossy purple. Maybe some material definitions that made the old frob work properly were already deleted? Or not restored? My opinion above nonwithstanding, I think the new frob (outline included) looks just fine, and I voted as such in the poll thread, but it's a democracy and all that jazz.
  25. Because I need to? Mapping vs playtesting purposes. Anyway, after further testing today the ambient lights thing is just due to an old .cfg. I have no idea which cvar makes it happen, I did a .cfg comparison and didn't see anything obvious, but I guess it doesn't matter if deleting the file fixes it. The graphics breaking is specifically a 2.08 -> 2.09 bug and I've reported it HERE. There is another 2.08 -> 2.09 bug that I found regarding material stages that I've also reported HERE. There is a 2.10 hitch with the loading screens in King of Diamonds, but I'll take that to the appropriate thread or message stgatilov directly about it. I've ran through Cole Hurst so far and I plan on playing at least a couple more FMs, so far so good as far as beta testing goes. Bug hunting is fun.
  • Create New...