Jump to content
The Dark Mod Forums

Spooks

Member
  • Posts

    612
  • Joined

  • Last visited

  • Days Won

    38

Posts posted by Spooks

  1. On 4/10/2022 at 11:53 AM, greebo said:

    Can somebody confirm / try doing the same? Open DR pre2 with the project setup pointing to "river" or "kingofdiamonds". Then File > Open Map from Project... and pick the kod.map or the river.map, respectively. When moving around 3D view it stutters a bit as new things come into view, RAM is increasing, but as soon as DR has "seen" everything, memory consumption should stay constant at about 5-6 GB (at least for me).

    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.

    On 4/5/2022 at 8:46 PM, JackFarmer said:

    This one works just with responses:

    https://streamable.com/qck043

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

    • Thanks 1
  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. 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

     

     

    • Thanks 1
  9. 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.

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

    • Like 1
  11. On 4/1/2016 at 8:40 PM, VanishedOne said:

    Am I doing something wrong, or does 'set <spawnarg> on <prop>' just not work to stop the prop spawning on a given difficulty level (meaning I'll have either to place a key in DR and bind it instead, or to do something to remove the entity after map load)?

    "def_attach6" "atdm:prop_key_simple_steel"
    "pos_attach6" "belt_back_right"
    "name_attach6" "perimeter_key"
    "set name on perimeter_key" "perimeter_key"
    "set inv_name on perimeter_key" "the exterior door key"
    "set diff_1_nospawn on perimeter_key" "1"
    "set diff_2_nospawn on perimeter_key" "1"

    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.

    image.png.2bbe0dfe0512738cd764e29772dd4af1.png

     

    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.

    • Like 1
    • Thanks 3
  12. On 2/4/2022 at 2:56 PM, Dragofer said:

    That's probably the result of LOD for lights being fixed in 2.10. Kyyrma probably attempted to apply LOD to these lights, found it didnt work, and left the spawnargs on them.

    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?

  13.   

    16 minutes ago, joebarnin said:

    A question about volumetric lights. If I specify volumetric_light=1 on a light, and take the defaults for the other values, then the dust is visible only if the Shadows Implementation is set to Maps. If it is set to Stencil, the dust doesn't show up. This has been discussed in this and other threads.

    However, if I add volumetric_noshadows=-1 (or 1), the dust is visible in both Maps and Stencil mode. And, the light still casts shadows (as least, as far as my limited testing has shown).

    It looks like if I set volumetric_noshadows=-1, I can get volumetric dust in my lights for both Maps and Stencil. If that's the case, is there a downside? What am I not understanding?

     

    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.

    • Thanks 1
  14. 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.

    • Like 1
  15. 4 hours ago, Abusimplea said:

    What actually are the commands for setting hue, saturation, luminance and glow-width?

    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.

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

    kingofdiamonds_newpatch_2022-01-18_01.09.23.jpg

    kingofdiamonds_newpatch_2022-01-18_01.07.22.jpg

    kingofdiamonds_newpatch_2022-01-18_01.04.41.jpg

    • Like 1
  17. 21 hours ago, AluminumHaste said:

    So try this. Remove "seta r_newFog" "1" from your Darkmod.cfg. Then go back in the game and see if you can still find it in the console.

    Also, check to see if it's present in autocomands.cfg or autoexec.cfg files if you have them.

    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.

     

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

    • Thanks 1
  19. 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.

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

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

    deadeye_2022-01-01_20_36_03.thumb.jpg.0b00b5fda35bc6f5db8e76f165c1e720.jpg

     

    This is with r_newFrob 0, the current default. The pants become a solid color on highlight and her face becomes glossy purple.deadeye_2022-01-01_20_36_12.thumb.jpg.ca01a097e28b5482941997d96fc22b4c.jpg

     

    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.

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

  23. vid_restart seems to break ambient light, or at least ambient_world. a lot of the world is pitch black after it. That might be on 2.10. I'm having to do vid_restart because every time I alt+enter to change from windowed to fullscreen, the game graphics break. I think that's just something getting broken from the side of Nvidia's drivers though, I used not to get it in 2.09 but then it started happening there, too... If anyone has that problem, shout out but, well, point being, vid_restart kind of fixed it but now that's useless.

×
×
  • Create New...