MirceaKitsune

That gives me the full picture, thanks @Dragofer for the detailed clarification! Only one more thing I should probably know on that: Do worldspawn patch meshes count to the pathfinding algorithm or just brushes? Asking since I use patch terrain... of course I have a normal brush right under it so it should work regardless but it doesn't hurt to know. As for RIT that sounds like what I've been doing all along so I didn't miss out. I do it by having paths target multiple paths which results in random actions, often times the AI going to different rooms or looking at different things in each room. I don't feel like placing paths for some decorative AI that only need to wonder around however, could still use an alternative to animal patrol mode for random movements (without the running around like crazy).

I know AI can't walk on entities, but was under the impression they can walk on top of func_static models. Granted they aren't overly complex in shape, that seems to be what's causing most issues. So should I assume anything func_static is not navigable, only brushes are? As for random interesting things, I think I already use that: I target many path_corner's to multiple path_corner's, which has a random possibility of going to one or the other.

What does RIT refer to in this context?

Thanks @Dragofer for that info! Which brings up one thing I should correct then: I drew monsterclip brushes to encompass the model and not up to the ceiling, might be best to bring it all the way up then. Still curious which models will generally require it, and which meshes are safe for AI... for instance I don't seem to need to MC handrails or door / window frames. The real issue I have though is with complex meshes the AI is meant to navigate... namely stairs, and namely the large mansion stairs model at that (models/darkmod/architecture/stairs/mansion_stairs_01b.lwo). I tried placing paths on it once but the AI got stuck under the stair instead, can't go up or down those. At the moment I monsterclipped the whole thing which solves that, but if an AI tries to chase the player across floors it would become obvious they cannot. Onto another little question too: I was wondering how you can make a human AI wonder around randomly without any path nodes, to give a bit of detail to civilians and other decorative AI's who don't need a predefined path. I tried the "animal patrol mode" setting which is the only one I'm aware of, but it has a very wrong pattern: The AI randomly walks and runs into all sorts of directions... it doesn't look like they're idly walking around but more like they're having a psychosis attack. Is there an additional option or an equivalent to animal_patrol but without the running and more suited for idle human characters?

Here's one I recently found very worth asking: During testing my maps, I find that a lot of func_static models will cause the AI to get teleported on top or bend in weird ways when touching the model or even break pathfinding. At the same time many func_statics will not cause any bad interaction with an AI. Is there a standard way or guidebook to knowing which do? I mainly ask so I can easily know what I need to draw a monsterclip brush around. For instance I found I need to monsterclip several stairways and pillars and all other sorts of architecture, yet railings and some furniture are fine. I can't draw a brush around every single map model I place, so it would help to have a more standard prediction of what AI will have issues touching.

There is a little issue I keep running into every now and then: It seems that if you move the mouse too suddenly while looking around, the view will sometimes snap to a different angle and you find yourself facing the other way around. I assume it's the mouse cursor getting reset when an edge is touched too quickly, or something among those lines? If any Linux user on KDE / Plasma can try out the dev build please help to confirm: If you keep moving the mouse rapidly and erratically across long distances, you should notice your view occasionally gets teleported the other way around.

Another one I forgot about: Is it possible to set an objective to become visible once another objective is failed or completed? I see that till now I had to trigger an atdm:target_setobjective_visibility to make new objectives appear after I complete existing ones, but it feels like this shouldn't have to be needed for inter-objective dependencies.

Don't think I'm gonna write a script just for testing, it's not that urgent only if it was simple to do. This would be a nice feature for map testing, might suggest it on the bug tracker sometime.

As I might be needing this to do some testing I figured I'd ask: Is there by chance a console command that can be used to trigger an entity on the map? So if for example I type "thetriggercommand trigger_relay_1" that relay fires as if triggered by a trigger_multiple entity for instance. Never heard of one but the team is intuitive so I imagine it might be there! It would be useful to test some effects before I have their proper triggers in place.

Found a little bug worth bringing up: Whenever I highlight a door its doorhandle will also flash the outline for a split second. The effect only lasts for one or a few frames after which only the door is highlighted as is proper, but it's noticeable enough to see the handle blinking when you first look at the door.

5.12.9-1-MANJARO

I was thinking of creating a horizontal portal covering the entire area who's face touches against the top of the bottom-most brush, then portaling multiple small areas against the sides of the same brush: This way the top half would be one portal while lower zones would be divided. I might be able to find a better way though... if not I'll just limit the detail I have outside in a worst case scenario.

That's good to know. It might be in that case: Linux has an issue with my microphone which starts acting up the moment I open Audacity, but with sound output I never had any problems. Sounds like I might need to start messing with the OpenAL settings again to see if anything there fixes it. I didn't get this issue in Manjaro over a month ago when I switched to it (from openSUSE Tumbleweed) and I already had the 2.09 TDM release, so it's likely some driver update that introduced it recently. Let me know if any setting I should try tweaking comes to mind.

Thanks. As for why I might need this, let's just say it's part of the struggle to find smart ways to portal large outdoor areas for decent performance when the geometry doesn't make it easy to do so.

Playing with mapping again so a question for something I may need: Does the engine allow portals to rest against one another? As in can you form a T shape with two portal surfaces, if one is perfectly touching the center of another?

Since installing the latest versions of my system packages, I hear a loud and annoying static noise crackling in TDM audio. This seems to be different from my stuttering sound issue which was caused by a bad period size setting in OpenAL: Normal sound plays fine without interruptions or lag, but I also hear this annoying popping noise in my headphones all the time. I get it in both the latest release (2.09) as well as latest dev snapshot (dev16269-9407), where the later seems to be producing the noise even more intensely. It's independent of EFX and HRTF, I tried turning both off and restarting but the issue persists. No issues in any other games (eg: 0ad, Red Eclipse, Xonotic) only TDM does this. Persists after restarting my system so it's a permanent issue. My OS is Manjaro Linux on KDE / Plasma. Any other Linux users getting this and know what might be the cause?

I fixed the mouse capturing issue and am back on latest dev, thanks again cabalistic for the help! Testing with "r_frobIgnoreDepth 0" I can indeed see the annoyances: Doors as well as drawers only have their outline showing on some sides, it becomes hidden when they perfectly touch the frame and its edges cover the item. Further more they flicker in and out of existence as you move around and change angles which looks very wrong. What would most likely work is customizing it per item: No depth test for the outlines of doors and drawers and other entities integrated in world geometry, yes for buttons and movable objects and other geometry independent actors. This could be set via spawnarg on the root entities... an arg to customize the color was already desirable. An entity could have the options "frob_color 1 1 1 0.5" to change the color / alpha of its highlight, plus now "frob_depth 1" to decide if it shows in front of everything or represents an object meant to be hidden by surfaces. It should offer the best results.

Thank you, it fully fixes that problem! I'd lose a lot of settings so I prefer keeping the old config, but every now and then options like this need to be reset. The new window and input manager seems to be working perfectly now: Need to play for longer and do more testing but so far this seems like another great success I'd note only one little thing I just noticed: When alt-tab switching, the TDM window is properly minimized this time. But I noticed that if I leave the game running instead of pressing esc to go to the main menu, my GPU is still heating up, meaning the game is still rendering. If possible I'd disable the renderer while the window is minimized by the system.

Thanks. I had to revert to latest TDM release due to other issues, might try this again later once the latest dev snapshot starts working right on my OS. I'm tempted to cast a vote for disabling r_frobIgnoreDepth by default... if the performance cost is significant and it can end up looking worse, I must at least test it more before having a definitive opinion on that.

Thanks for clarifying. Temporal AA might be unneeded then, I've never seen movement artifacts. I only use AA to get rid of jagged edges in both still and moving frames. Considering all this then, I'd honestly be very happy if FXAA and / or SMAA could be implemented for the time being please. I know it's just a targeted blur filter which might seem useless from a developer's perspective, yet what it achieves makes it worth it: It gets the job done for most edges, is very fast at it, popular in many engines, easy to implement as it requires no special passes, and on top of that it also fixes sharp edges in alpha textures not just geometry which is a bonus the others don't offer. It doesn't need to be on by default as far as I'm concerned. If you're uncertain about it, I'm fine with adding it as just a hidden cvar for now... if it helps I can test it before we decide if it should be in the menu at all; I'd even be happy with it as a hidden setting one can enable from the console. I'm hoping to maximize performance on my 144 Hz screen this way (run at >= 144 FPS) which would help a lot on top of all the new optimizations. Hope you can consider it till other options become easier to implement.

Finally gave the latest dev snapshot a try and decided to look at this. I honestly love what I'm seeing! Also I'm on board with the default white color... I'd decrease the intensity / alpha just a little, keep it color neutral otherwise. I have only one problem with the effect: It shows in front of other objects and there's no occlusion. This can look weird... for instance light switches show through their socket and you can see the outline of the normally hidden bottom of the lever. Is it possible to make it render on top of the model being highlighted, but still occluded by other geometry?

I switched to the latest dev snapshot via the installer now that this should be included. Noticed a new issue straight off the bat: The system pointer shows over the game pointer in the main menu. The issue is even worse in-game, where the pointer not only shows and moves over the screen but you can no longer look around when it reaches a screen edge, apparently it's not auto-centered any more. Will have to revert to latest stable until this is resolved. If it's important I'm on Manjaro / KDE Plasma.

So far the consensus seems to be that SMAA and TAA would be the better options. They're both popular implementations and the screenshots I'm finding suggest they're pretty good. From what I'm seeing SMAA appears to look best, but this could mean it's also slower as some articles indicate, so TAA may be the ideal middle option. Is the engine presently in a position to make at least SMAA easier to attempt implementing so far, or any of the other options available to us? Based on how our available render passes and shaders and other core components are set up to work, in hopes that major changes aren't necessary to support either of them.

Is it also as fast? Also, regarding FXAA, on what Cabalistic mentioned earlier and in the initial chat: FXAA is supported by the video driver, however it's not an option you enable at runtime, I looked for a system parameter and couldn't find a way. The engine probably needs a flag to call OpenGL with this feature. If that's the case and I understood correctly, supporting it would be a matter of just implementing a menu option linked to a renderer initialization call. Don't know for certain if that's the case, just what I'm gathering so far.

I'm down with TAA or any option. I think the decision should be based on three criteria: How much it reduces aliasing and thus looks as good as MSAA, how much performance it gains us compared to it, and how easy it is for the developers to integrate into the engine so this improvement can hopefully catch the next release. On FXAA I can only say I noticed a few FOSS games started using it recently, which means it's probably the most popular alternative. The latest version of 0ad has it as a menu option, Red Eclipse I already mentioned, and I recently noticed that even Xonotic (darkplaces engine) implemented it as a hidden setting which I now enabled.