Search the Community

Investigating further on that issue turned out that the self-occlusion (or its absence) isn't the issue here. The actual problem comes from the animation. The ai is leaning forward while at the same time slightly moving its torso to one side. If you replicate this irl you will notice that you are indeed able to see behind you in that case. I see two possible solutions: Avoid any animations like that as idle animations Introduce an additional check to explicitely exclude the possibility of the ai to see anything behind itself (behind in respective to its bodies orientation). I favor the second one as it means less work for anyone working with animations. I mean, nobody expect that to happen anyway.

Hi Frank Cotton, please do what you want, but if you don't mind, I have some suggestions for you to consider, If perchance along modeling, you know how to animate, personally and I mean personally, I would love if someone would make more animations for the werewolf character, specially a better run animation and a cool roar one for when he detects the player. Also again IMO, if instead of rework existing ones (that imo are fine for the time being), a totally new character would be cool, for example, like we have the small spider like guard bot, to me would be cool, to have a relative big, biped steampunk robot, with animations, at lest walk and search animations, why, because based on Doom 3, imo is sad to me that the engine has AI AAS support (ability to navigate in a level) for big monsters but TDM has none to take advantage of that. I can imagine some missions where the player goes to some inventor guild place and has to go around a massive robot to reach some high value thing. Something like where the head is a search spot light that goes around and he makes steam boat sounds when he detects the player. I know this second one is very probably way harder to make than the one above and TDM already has a automaton character but imo is to much a obvious reskin of the builder guard. A better automaton would be cool, one that is more or less the representation of a human guard but still very different, something not like but akin to the following, world be cool Where his eyes are red and cast a spot light mood example Of course all of this new characters without animations, will be almost useless only used has static props, so again if you can't animate, reworking a existent character is obviously better. Just my two cents.

The *DOOM3* shaders are ARB2 ('cause of old GeForce support) carmack plan + arb2 - OpenGL / OpenGL: Advanced Coding - Khronos Forums

id Studio did a poor job in defining its categorization of variable nomenclature, so in subsequent documentation and discussions there are divergent views (or just slop). In my series, I had to choose something, and went with what I thought would be clearest for the GUI programmer: Properties, which are either Registers (like true variables) Non-registers (like tags) User Variables (also true variables) I see that your view is more along these lines (which perhaps reflects C++ internals?): Flags (like my non-registers) Properties, which are either Built-in (like my registers) Custom (like user Variables) Also, elsewhere, you refer to "registers" as temporaries. I am willing to consider that there could be temporary registers during expression evaluation, but by my interpretation those would be in addition to named property registers. I'm not sure where to go next with this particular aspect, but at least can state it.

Several days ago I was thrilled to hear that TDM 2.08 contains several new characters along with other fantastic improvements. Seeing how much work had been done on this release gave me a motivational boost to try contributing something myself, especially having worked on porting human(oid) characters to TDM in the past... this time I wanted to submit something that can hopefully be included in vanilla TDM perhaps with 2.09. As I was testing the new release I remembered an old submission on Blendswap called BGE Dragon, featuring a polished quality dragon for the now defunct Blender Game Engine, notable for the fact that it comes with animations for walking / running which makes working with it easier as you don't have to make those yourself. I always felt dragons would fit the theme of TDM wonderfully and allow for some amazing missions, to be fair suggesting them had long been on my mind... remembering how easy it was to work with this one, I figured I'd do the groundwork and instead submit a blend that contains everything needed to port it to The Dark Mod. I'm happy to announce I now have such a blend available! The first thing was the polygon count; The original mesh is pretty high poly, clocking at about 30,000 polys which may be too much for TDM on most people's devices. I played with mesh decimation then did some manual corrections, managing to retain acceptable quality while generating models with okay polygon counts: lod0 = 9.306, lod1 = 6.009, lod2 = 3.218, shadow = 2.265. The original quality mesh is still included in the blend file, so if we need to re-generate any LOD version this can be easily done at any time. Next I worked on separating the armature into two objects, based on the example for the human model I built my previous characters upon: The real armature that deforms the model and is used to export animations, with a control armature driving its bones that's only used to design said animations inside Blender. As the control armature uses a complex IK setup for bones this took some toying with, but in the end I could generate a simple armature which will hopefully work in exporting the md5anim set. Speaking of animations I made sure those are also covered. For the endlessly looping walk and run animations I added markers that identify the frames between which they must be exported to get a seamless loop. I next turned the idle animation into a randomly occurring gesture, then proceeded to animate everything else from scratch to obtain: Walk Run Idle (with two random gestures, stretching / pacing and looking around) Sit (with "lay down", "stand up", "idle" animations) (seamlessly connects to "idle") Sleep (with "lay down", "stand up", "idle" animations) (seamlessly connects to "idle") Attack (two types, bite and slash) (seamlessly connects to "idle") Die (brief animation at the end of which the ragdoll system is supposed to take over) An example gif of the idle gesture from the Blendswap submission, converted to and intended as a random occurrence in-game: From here on I need your help and am calling on the artists who helped create the new monsters (eg: Manbeast) to aid in making this come true as well! I've done most of the work as far as the model goes, putting aside any tweaks that might be needed (eg: model scale and animation length). I'm also going to work on the texture next to produce the proper maps... my target is to have 4 different skins / colors in total. I also believe I can produce the sounds having already found promising submissions to start from on OpenGameArt. But before putting more work into this, I wish to be sure someone can help with the remaining steps so we can get the model in the game. What I need from fellow developers should be: A new AI type for the dragon. Note that it's not intended to fly, especially not in its initial implementation; Later on we may add a fly animation and data to the AI for knowing how to use it... for now I only care to have it work like the spider, wandering around and attacking if it sees a hostile entity. This should thus be easy if we can copy another monster's code. Exporting the assets from Blender to TDM, particularly the model and animations. As I don't have an AI nor a test case handy nor ever worked with exporting TDM animations or models for non-human characters, I need someone else to generate and test the mesh files. First the md5 mesh for each LOD, everything is included in the blend even the low-poly shadow mesh... afterward the armature actions for it need to be exported to md5anim files. Lastly the defs need to be written, along with any other step I may have missed to make the character actually work. I should be able to do the material based on my previous examples once I finish the textures, so don't worry about that part... please just make sure the materials in the exported md5mesh have the same name as the material names in Blender. Download blend version 0.5 I look forward to hearing your thoughts! If any developers or experienced contributors confirm they can take care of the integration, I can get started on the remaining assets soon

This might not be too important in terms of gameplay, and it probably has already been addressed, but the player has no shadow. More than that, he has no animations at all. Whenever I step into light and don't see any shadow, it's a little interesting. Try it yourself. Whenever you look into a mirror, the player's body is frozen. He hovers an inch off the ground and floats to wherever he wants to go. I understand this is nitpicking and can easily be ignored, but it feels weird sometimes, floating around, having no shadow. Also, it might just make the game more interesting, where the AI might go off their path and turn the corner to see if it is their friend, or a thief that is giving the shadow. Happy New Year everybody!

Thanks, I can also recommend gog galaxy. The idea of the custom tags is really nice, I'll have to try this out too!

Keep in mind also that mission size, and complexity have increased dramatically since the beginning. For a lot of veteran mappers, it can take over a year to get a map made and released. The last dozen missions have for the most part been pretty massive, with new textures, sounds, scripts, models etc. We seem to be long past the point of people loading up the tools, and banging out a mission in a few weeks that's very barebones. We still do see some of those, but I noticed in the beta mapper forums and on Discord, that mappers seem to make these maps, but don't release them, and instead use the knowledge gained to make something even better. Could just be bias on my part scrolling through the forums and discord server though.

YOU TAFFERS! Happy new year! Deadeye is a small/tiny assassination mission recommended for TDM newcomers and veterans alike. Briefing: Download link: https://drive.google.com/file/d/1JWslTAC3Ai9kkl1VCvJb14ZlVxWMmkUj/view?usp=sharing Enjoy! EDIT: I promised to someone to write something about the design of the map. This is in spoiler tags below. Possibly useful to new mappers or players interested in developer commentary.

Seems to confirm: https://bugs.thedarkmod.com/view.php?id=5718 does it happen in the latest dev build: https://forums.thedarkmod.com/index.php?/topic/20824-public-access-to-development-versions/

I know oil flasks are not highly regarded in T3, as they introduce slapstick animations for AI, but this kind of access denial means could add interesting challenge if you can slip from some ledges and pipes. https://www.youtube.com/watch?v=b7D_X7CTlm8 Slippery surface is already available, but probably used only in frozen areas. Using special slippery paint make it easy for colour coding, like in e.g. Mirrors Edge, but red colour in this case should be repelling. Also it will raise suspicion with otherwise neutral guards if you are literally marked as a trespasser - reminds me of a police paintball ammo with hard to wash ink, so they can catch hooligans or cars later.

I hope I'm not proposing some unfeasible idea that was already imagined before, this stuff is fun to discuss so no loss still. Riding the wave of recent optimizations, I keep thinking what more could be done to reach a round 144 FPS compatible with today's monitors. An intriguing optimization came to mind which I felt I have to share: Could we gain something if we had distance-based LOD for entity updates, encompassing everything visual from models to lights? How it would work: New settings allow you to set a start distance, end distance, and minimum rate. The further an entity gets the lower its individual update rate, slowly decreasing from updating each frame (start distance and closer) to updating at the minimum rate (end distance and further). This means any visual change is preformed with frame skips on any entity: For models such as characters animations are updated at the lower rate, for lights it means shadows are recalculated less often... even changes in the position and rotation of an entity may follow it for consistency, this would especially benefit lights with a moving origin like fireplaces or torches held by guards which recalculate per-frame. Reasoning: Light recalculation even animated models or individual particles can be significant contributors to performance drain. We know the further something is from the camera the less detail it requires, this is why we have a level-of-detail system with lower-polygon LOD models for characters and even mapmodels. Thus we can go even further and extend the concept to visual updates; Similar to how you don't care if a far away guard has a low-poly helmet you won't notice, you won't care if that guard is being animated at 30 FPS out of your maximum of 60, nor if the shadow of a small distant light is being updated at 15 FPS when an AI passes in front of it. This is especially useful if you own a 144 Hz monitor and expect 144 FPS: I want to see a character in front of me move at 144 FPS, but may not even notice if a guard far away is animating at 60 FPS... I want the shadows of the light from the nearby torch to animate smoothly, but can care less if a lamp meters away updates its shadows at 30 FPS instead. The question is if this is easy to implement in a way that offers the full benefit. If we use GPU skinning for instance, the graphics card should be told to animate the model at a lower FPS in order to actually preserve cycles... does OpenGL (and in the future Vulkan) let us do this per individual model? I know the engine has control over light recalculations which would probably yield the biggest benefit. Might add more points later as to not make the post too big, for now what are your thoughts?

A few additions and observations: We may get even better results using not just distance but also the entity's size, given the rate should probably depend on how much the entity is covering your view at that moment. As this shouldn't need much accuracy we can just throw in the average bounding-box size as an offset to distance to estimate the entity's total screen space. A small candle can decrease its update rate even closer to the camera, while a larger torch will retain a slightly higher rate for longer. To prevent noticeable sudden changes, the way LOD models can be seen snapping between states in their case, the effect can be applied gradually without artificial steps given it's just a number and may take any value. It might be best to have a multiplier acting on top of the player's maximum or average FPS: If your top is 60 FPS, the lowest update rate beyond the maximum distance would be 30 FPS for a 0.5 minimum setting... along the way one entity may be 0.9 meaning it ticks at 54 FPS, a further one 0.75 meaning 45 FPS, etc. Internally there should probably be different settings for model animations and lights: A low FPS may be obvious on AI or moving objects so you probably don't want to go lower than half the max (eg: 30 FPS for 60 Hz)... for lights the effect can be more aggressive on soft shadows without noticeable ugliness (eg: 15 FPS for 60 Hz). In the menu this can probably be tied to the existing LOD option which can control both model and frameskip LOD's.

Cannons actually EXIST in TDM; they show up in about 3 missions. One I recall actually gets FIRED - as part of the objectives. (nothing animated, blast-a-hole-in-a-wall gimmick) More obviously MINES too... so B.P. (or something LIKE it ) exists in-world. So either the Empire has banned all civilian firearms, or more likely: Nobody cared to create one as its not part of classic Thief/1,2,3... series game-play or Worse; I don't think any modders here even possess the knowledge to model, animate, script, code, texture, sound-engineer, script-more and create all the associated kinematic animations as well...need a real Doom3 expert for that. Also; Everyone forgets old Air Guns exist: https://en.wikipedia.org/wiki/Girardoni_air_rifle The early ones even LOOK 100% steam-punk, with weird iron & brass spheres for pressure - fancy nickle-iron skeletal frames galore.

TTLG? That's Through the Looking Glass Forums. A looking glass fan community. Has been around for a long, long time. https://www.ttlg.com/forums/

I just read@motorsep Discovered that you are able to create a brush, then select it and right click "create light". Now you have a light that ha the radius of the former brush. Just read it on discord and thought it may be of use for some people in the forums here too.

TDM was never meant to be fully realistic, it would become impossibly difficult were that the case. None the less I still find myself wishing more could be done to make AI feel less like AI, especially when handling hostile encounters (usually the player). While like most aspects this could never be truly perfect, one area feels like it could be noticeably improved: Giving AI some form of long term memory, rather than just one alert level which goes back to zero after a short time. Here is the reason why I'm saying this: Walk inside your average heavily guarded mansion and step into the bright lights, making all the guards clearly see you and chase after you to attack. Once you've had enough fun repeating the process, hide somewhere and give everyone enough time to cool down. At the end of it all, hide somewhere in the shadows where you can barely be seen and let a guard walk past you: The guard will just say "is there something over there", at best waiting a few seconds and saying "probably just the shadows" before walking away... the same man that may have chased after you for 30 minutes and should by any logic know an intruder is still in the house, I mean come on Now I'm aware we have a basic persistence system: If I remember correctly an AI that's encountered the player and was alerted enough to draw their sword will have its acuity permanently increased by a slight amount. This however makes no noticeable difference as the AI behaves mostly the same. They'll keep telling fellow AI an intruder is in the area, this definitely helps but it's only a dialogue change not accompanied by noticeable modifications in behavior as you'd expect. Obviously massive modifications might be hard to do now without upsetting existing players since it would make everything harder. As such any such attempt would likely be an experiment and, if successful, a new menu option for the difficulty settings. Still I felt like suggesting my imagined solution just in case there's a point in considering tackling this. My idea: Replace the one-time bump in acuity with a paranoia level independent from the alert level... think of the existing alert system as short-term alert and the new one as long-term alert. The standard alert level of guards is slowly added to their paranoia level, thus the more time a guard spends being alert and the higher that alert is the more fear increases. Paranoia level may be allowed to decrease over time but at a far slower rate than the alert level: If an alert guard will typically take 3 minutes to fully calm down after losing track of the player, the paranoia level should take at least 30 if not 60 (real life) minutes to fully go down to minimum... even then it shouldn't drop below a certain degree after that point was reached, for instance just 50% of the maximum paranoia. This long-term fear level would have several effects on an AI as they patrol on their normal route... the ones I've thought about are: Increased acuity as they'll be more alert. This system would replace the existing simple bump we have in that regard, with a more fluid effect and also stronger effect. Increased playing of voices and idle animations: Due to being afraid the guard may talk to themselves or others a lot more frequently and babble excessively. Walking could be replaced by running for a while, even on path nodes that don't have the run flag. The AI would still patrol that same route just at a faster pace. As a map feature set by FM's: Some path nodes can be filtered by fear level, may already be possible with the simple system but I never tried it. An AI paranoid the player is still around but having resumed their normal patrol route may choose to patrol a more sensitive area it normally wasn't going to, which would be a fair way of punishing the player for being seen by having that AI start guarding a sensitive location from then on. If the paranoia level is allowed to slowly decrease, the guard may decide to go back on this decision... the player could then do something else for 15 minutes around the map till the guard abandons the paranoid patrol route. Here's an idea I like: AI randomly getting scared for no reason, thinking they see the player in every shadow even when there's nothing there. A scared guard normally walking on their patrol route would randomly become alert for no reason, typically when walking through a dark area, causing them to draw their sword or randomly run around for a second. The problem here is this effect would be random: Imagine you're hiding accordingly but a guard randomly freaks out and bumps into you, most players would find this unfair.

https://github.com/HansKristian-Work/vkd3d-proton/tags <- directx 12 wrapper for dxvk https://github.com/doitsujin/dxvk/tags <- directx to vulkan wrappers D3D 9 to 11 eg. dxvk if you want to try it with horizon zero dawn you need to copy out dxcompiler.dll from Tools\ShaderCompiler\PC\1.0.2595\x64 and bink2w64.dll from Tools\bin and place them next to HorizonZeroDawn.exe. then copy over dxgi.dll from dxvk and d3d12.dll from vkd3d and place them next to it to. now fire up the game and let the shaders recompile -> profit.

I think the reason the dev forums exist is to provide a place where the implementation of features can be discussed without getting mixed up with other debates when someone believes what the devs are doing is wrong. We often post public discussion threads for features with subjective elements like the frob outline, because community feedback is very important. But there will always be vocal defenders with strong views for or against certain features, or how exactly it should be implemented in their opinion. At some point a decision has to be made and be carried through, which is what the dev forums are for. Almost all of the threads are very technical, basically explaining and discussing recent or potential code changes with other devs. Its hard to say. Its a hobby the devs do in their spare time, so people come and go when they're in the mood and when they have the time. The team page is mostly accurate except for some relatively newer additions like myself.

Definitely no KO immunity per say, don't think that would even make sense here. The idea is for guards who have seen you to show signs of persistent awareness, behaving in a different way from how they normally act before knowing there's an intruder. Some could be mechanical and difficulty altering changes, like guards drawing their sword and searching over circumstances that would have initially made them mumble and move on... others could be cosmetic behaviors that don't much affect gameplay but add more realism, like making paranoid guards use different animations or look around constantly or randomly interrupt their walk cycle to show nervousness and confusion, which would also help the player gauge their long-term alert and know when to avoid a guard that knows what's up. Also my idea may not require a separate alert field after all. Alert levels are floats: I believe guards still patrol normally until alert reaches 1 which is "AI stops and looks around", we could activate such behaviors at say (alert < 1.0 && alert >= 0.5) then make the alert level taper off more slowly at low values (decreases fast from 5 back to 1 but very slowly from 1 toward 0).