MirceaKitsune

What's the entity type for having a model that sways back and forth? I've seen swinging signs above taverns in some FM's but couldn't find the entity for making my own. I believe for constant rotation it's func_rotating but not sure for bobbing.

That's necessary, I want the spinning in this case: The AI sits on a chair in front of a desk, they can't normally walk in between them so it needs to sit from the right side of the chair then rotate in place. The issue is that the AI doesn't spin back when standing up, but does so when playing the book flip animation which is too early.

Thanks. I looked but can't quite understand which spawnargs I need to change on my light to use the cube maps for the default skyboxes. It offers an example for a material... are the default materials broken, or no longer meant to be used directly and I need to redefine the skybox cube lights per FM? I went with what I remember doing last time, which was adding a light entity covering the map and giving it the texture spawnarg "lights/ambientCube/skybox_mountain_sunset_cube" for example, however this no longer works and the light is absent. Update: The default definitions are indeed broken. In tdm_textures_base01.pk4 the definitions in materials/tdm_cubeLights.mtr still use ambientCubicLight which that bug report says was replaced. So those need to be redone, I'll look more into it and mention this there since they were likely forgotten. Still wish we could use the active skybox as a light. Then we wouldn't need to manually match a skybox background as the light texture to get that realistic environment lighting on the specular channels of surfaces.

The latest TDM dev version (dev16650-10157) appears to contain broken definitions for ambient cube lights, breaking lighting on any FM that uses them (I have several in progress). I noticed the path got renamed from "ambientcube" to "ambientCube" (c became a capital C). Even if picking the new path however, DarkRadiant shows a "shader not found" error, whereas in-world the light is no longer visible and functional. Can this be fixed for the next dev snapshot please?

Managed to solve part of the problem but not quite. Even the AI Sitting Behavior doc doesn't quite explain it it. The problem is if the AI sits at an angle. For instance you set "sit_down_angle 90" on your path_sit: The AI spins in place after sitting, but if you trigger a path_wait or path_anim after that, he instantly spins back before playing the animation. Apparently path_sit treats any path following it as the AI having finished sitting, the angle only sticks if you set "wait" and "wait_max" directly on the path_sit.... if you do that however you can't have your custom idle animation. Does path_sit allow you to override the anim directly? As a workaround which will work as intended, you can set a couple of spawnargs on the AI itself, exemplified by the beggar prefab... problem then is the AI will play the page turning animation wherever it sits rather than just at the desk, I don't have him sitting elsewhere but this still feels wrong. idle_animations_interval 2555 idle_animations_sitting idle_sit_turnpage replace_anim_idle_sit idle_sit_turnpage

Thanks. My mistake was setting both sitting and sleeping, only sleeping must be turned on... then of course "sleep_location 2" also has to be set. No paths needed this way if you don't want the AI to wake up at times. Stuck on another one now: How do you make a walking AI occasionally sit at a desk and write? I've seen it done in several FM's but never had to do it till now.

Yes, that solves it. I get a slightly smaller 3D viewport but it's not that bad. Hope this can be solved with a scrollbar like other menus. It's easier to have such windows pinned to the new Properties viewport so I prefer that now. Customized the keybinds a bit and got the camera working with WASD, much better! Please bring back the ability to set shift / rotation / scale on an entire brush or multiple selected faces if possible though.

It's a super early stage thing with nothing significant in it so that's fine, just one building where I practiced learning the model modules. If you suspect the FM could be at fault, here are the map and darkradiant files: test.maptest.darkradiant Can anyone reproduce it and confirm it's not just me? I'll need to go for a bit again so I'll put up a bug report later.

I'll look into those bindings a bit later, thanks! I wanted to keep them default but I wish to change view switching from Control + Tab to just Tab anyway so I'll look into what else to modify. And yeah I'm not seeing it. Could be the new interface that was just added? Actually now that I look closely I can see a a Flip: Label below Align: but no buttons for it! I tried scrolling with the mouse wheel and nothing happens so I assumed there's just nothing there, but it's likely an interface bug and no scrollbar being added to the Surface Inspector when docked.

What is the correct way to make an AI that starts sleeping on a chair? I enabled both "sitting" and "sleeping" on the entity, but that only causes the character to be sitting without also being asleep.

Latest Darkradiant Git introduces an issue on Linux (Manjaro / KDE Plasma) with the amdgpu driver. To reproduce I simply use "Filters - Func_static entities" to hide all map models, then click on it once more to show them again: Most of the time every model is glitched out and has its polygons stretched all over the screen once it reappears. Fortunately this doesn't trigger a crash and simply reloading the map works... sometimes entities will instead leave a visual copy of their model when you drag then, that does cause DR to crash soon after.

There are two things I'd like to add here please. First is the return of two features that seem to have been removed from the Surface Inspector in recent DR updates: Could you bring back the Natural button? It was used to reset a surface to its default texture mapping, in case you fit an image then changed it back to a tiling texture and want to revert to the default mapping. Now you seemingly need to select each face and manually clear any offset / rotation then set the size back to 0.25. When selecting multiple faces, most fields (Shift, Rotation, Scale) become grayed out. Old behavior allowed you to input a value which would be overridden on all selected faces. This was very useful as you could scale multiple faces at once regardless of texture. Is there a reason why this is no longer allowed? There's another little change I'd really love: When you right-click the 3D camera view to grab it and go in mouselook, can we have an option to make the WASD keys move the view? Normally those letters do other things which is fine, but while the camera is grabbed it would be great if they were overridden to act as the arrows. We're used to relying on them for walking and it's annoying to put your left hand on the arrows at the bottom-right of the keyboard to move the view.

Cheers! I only run DR from Git as there's no appimage for Linux and flatpak requires configuring an external repository over a simple "download and run" approach, I should however be on the Git commit of the 3.7.0 release. I only noticed one obvious issue: When trying to add new windows to the new interface, DR will often crash and close on itself. Going to Windows and trying to open the Light Inspector for instance always crashes for me. Same as View - New XY view / New camera view, instant crash if I touch those. I like the new window setup otherwise! For example it's easier to permanently put the Surface Inspector on the Properties bar instead of having a new window pop up when you press S then having to close it. I got used to having all 3 2D views open at once, but using just one with Control + Tab to switch is actually better... though considering how often we have to do that I'd consider making the default shortcut just Tab if possible.

I agree with your observation in the main post, and admit it's a sin even I understandably commit: The DarkRadiant GUI didn't make it clear which models have a LOD, you'd have to check and find out for yourself... even then you aren't encouraged to do so right away as it requires going through the trouble of setting LOD spawnargs manually. My suggestion: Maybe don't combine the models and entities menus, they seem better as separate things and mixing them might clutter everything and make it harder to browse. But the model screen could hide LOD models from the browser, and instead automatically set LOD spawnargs to models that have them when inserted on the map. We could leave it func_static but add the "model_lod_*" and "lod_*_distance" arguments... I'd even consider a default "hide_distance" for all models based on their bounding box size. Those should be settings you can disable like "Surround with monsterclip brush" which is currently the only option in the model chooser, we could maybe offer a multiplier offsetting how aggressive the LOD settings are based on the model scale. If not the simple and perhaps ideal solution is having a default entity for every model that has a LOD: Some trees for instance have them, a few other items too... not everything does though. I checked out the new "Related entity classes" menu and that seems good enough to me; I'd add a checkbox to automatically insert the first entry if one is detected, the menu might be lost on some mappers in all the GUI detail. But to be useful I think more models should be given entities.

I saw that feature but admittedly never used it myself nor see myself needing it. If it's not bloating the code or getting in the way of anything, I'd say try keeping it still: I can see it being useful if for instance someone adds a top-down view of a city (Google maps?) and can more easily sketch buildings from above.

Thank you for this beautiful and much needed change! One of the biggest limitations in DR was that you couldn't edit items in a group without first ungrouping everything, and since you want things like prefabs to stay grouped having to group it all back after making changes was the other part of the pain. Now we finally no longer need to ungroup / change / regroup and the feature also allows preventing changes to other areas you aren't working on Gave it a quick test in latest Git and it seems to be working great. Only thing I'd change is adding a toolbar icon for this: I'll likely be using the Control + F shortcut exclusively but that's good to have in case we ever forget it.

Got it, tested and it works! For anyone else looking to use this trick, these are the full arguments you need to pass to your shortcut and add after darkradiant.exe, obviously for your respective FM and OS: /home/mircea/Games/Quake/TheDarkMod/darkmod/fms/testing/maps/test.map fs_game=fms/testing Note that for thedarkmod.exe you need a different format for some reason, it's "+set var val" instead of "var=val". +set fs_currentfm testing But you can't use the Recent Files list to jump between editing FM's and have it automatically work: If my suggestion is possible as an option I hope you can keep it in mind. For now I'll add those shortcuts to every FM I'm editing which helps!

Is there also a parameter to load the map in cause? For single-map FM's this would also make the shortcut open exactly the map you need so you don't have to look for it and open separately.

Thanks for the explanation. My only remaining curiosity then: Would it make sense to offer it as an option still (off by default) for those who don't find a performance an issue? I haven't noticed much additional reload time when changing the active FM in DarkRadiant so I could likely use it well. But I can understand why this change might not be possible. And I'd love to know what that command line parameter for DarkRadiant is! I use Linux but presume they're named the same way as the Windows exe. I already use a custom shortcut to launch TDM for testing my FM without changing the selected FM, via the super helpful "+set fs_currentfm my_fm_name" argument: I take it for DR it's something similar?

Ooooh! Thanks! I must have missed that hint, and that's not something I'd have thought about on my own, very clever. I'll do that tonight when I get back to playing

Figured I'd ask about this here before posting on the bug tracker, there might be a reason why it hasn't been done yet. Let me explain my reasoning first: When creators are working on multiple FM's at once, each one will obviously be located in its own directory. Most FM's contain custom assets and definitions, when working with maps in DarkRadiant you need to select their data folder for additional defs. This is done by going to File - Game / Project Setup - Mission and selecting it there. The issue: Let's say you want to take a break from one FM and work on another. Each time you load a map from a different FM, you also need to go to that menu and select it from there, otherwise custom assets won't be detected and appear as missing in DR. This is quite a bit of an annoyance. Suggestion: Is it not possible to detect and automatically select the active mission from the path the map is located in? We know every map should be located in "darkmod/fms/name/maps", so why not automatically extract the maps directory and set that to "darkmod/fms/name"? If there's an issue with getting such detection right, we can at worst simply store this information in the map.darkradiant file, so even if the player needs to first select it manually the choice is remembered per map and automatically reverted when you load it. We could technically do this with the other settings in that menu, such as Game Type and Darkmod Path. Not sure how much we need it for those unless someone is working with multiple installs and wants the convenience. Sounds good if doable but the important one is the mission directory as that must always be changed with the map you're editing.

A truly amazing FM and another among the top best. Love the city design, so detailed and cozy... complex and full of secret areas too. Normally I post after finishing a FM but this is one I've been stuck on for several days. Speaking of bugs another one I should point out before I forget:

So that's not exactly it and a few changes are still needed. I know it needs to work such that light doesn't affect (only) the brightness but the alpha channel in the same way. The material can otherwise be fully bright or still responsive to standard lighting, ideally the filter would only affect transparency without changing how light is otherwise received. I've subscribed to the thread you mentioned though it hasn't been active since 2019, glad everything's documented there. I don't fully understand the issue though: When the surface is fully invisible (0% alpha) it becomes black, but once it has any value above zero (1% alpha) it works well? Is it difficult to solve whatever is happening the right way?

Interesting, thanks! Didn't think it might since I haven't seen it done before nor any material flags that stood out, despite how appealing the idea is which is why I was surprised not seeing it in any FM. We could probably use some default lamps and decals to encourage mappers... can make any defs myself if anyone ever wishes or needs them. The material flag is listed on id.sdk so it's even part of core idTech4. But in DarkRadiant I don't see a spectrum spawnarg for light entities: Is it simply not documented, or does the light also need a texture who's material has that spectrum?

Was playing the first FM that makes use of X-ray glasses... seeing them in action inspired me to write about an addition to their idea. This is likely a feature suggestion, I've played most FM's and never saw it done nor found any script / material features that would allow this result, but presume it's possible with a tweak in materials or the renderer. I'm thinking of ultraviolet lamps that can uncover hidden decals or items: The object is invisible if not lit by a specific lamp, only when the light of an UV source touches them they start to show up. A blue-light can be offered to the player as an inventory item or replacement to the standard lantern, a lantern you can pick up and move only in the world, even come in the form of a candle since why not? The player or the environment must move specific objects and / or light sources to the correct positions to uncover secrets such as codes. Some examples: Next to an UV lantern you find a note hinting there's a secret code in a particular room... you must pick up the lantern carry it to that room then place it on a support, illuminating the number-wheel combination or hint on the secret entrance you must go to. We can even reverse the process and have a static UV lamp on a wall, the player picks up an inventory item and must drop it under the lamp to see what's written on it... we can even have a hidden symbol on an AI which will shine when they walk under that one streetlight. They could also reveal frobable objects which can't be touched unless illuminated... maybe a hidden lock to open a door which becomes available when lit, or a readable note which normally appears blank but can be read or contains additional text if there's an UV lantern next to it. So many fun ideas we could do with this given our usual theme and ideas for secrets! At a technical level, the logical way seems like separating the lightmap of light sources marked with the UV spawnarg, then multiplying with its intensity the alpha channels of all material components marked with the UV material flag. This might mean UV lights have to be rendered to a separate pass which could break some performance optimizations? Would be great if an index was possible instead of one flag, that way different secrets can be revealed by different lamps... even an universal UV lamp / material set would do though.