Search the Community

As usual this is mainly intended as a discussion and to hear opinions: It's not an expectation that the feature will happen soon or at all. Especially as this would be complicated to achieve, but if it could be done I think it may be a fun capability to consider. The idTech engine had several features that got removed since we aren't using them like multiplayer. One used to be the ability to record a demo of your matches, which makes sense in multiplayer DeathMatch games. Yet recently I started to wonder: How would it be like to have a demo capability designed for TDM? Imagine being able to record your playthroughs or share your recordings for others to watch, for when you'd like to relax watching a FM like a film instead of playing it like a game. You could fly as a detached camera, observing yourself wonder around the map and watching the things you did... or stay in 1st person and see the game play itself like in a Youtube video. The coolest thing would be the ability to see through the eyes of any NPC: Imagine being able to click on a guard in floating camera mode to embody them, seeing through their eyes as they patrol the area and at some point notice the player hiding in a corner through that guard's eyes (even if the AI didn't notice you). The biggest challenge would be a way to record store and reproduce every input from the player, with every AI decision and other entity actions just as they occurred, which includes preserving object physics to represent the exact movements of all entities: Parts of the demo system from Quake would likely need to be reimplemented, wonder how much it knows to handle on its own. Saves and loads would be another tricky one: Each demo should erase what you did after last loading to produce a seamless run... alternatively it could record that as an action and include reloading in the playback. There's probably other challenges but if it's within the realm of possibility, would anyone else use this and think it's worth thinking of?

I realized a fun change we could consider for the lightgem, which should also be fairly easy to implement if agreed upon. We know how aside from the amount of light shining on the player, some FM's increase the lightgem based on movement and crouching, you become more visible while walking and especially when running. I'd like to ask if anyone thinks we should additionally support a slight increase to the lightgem based on mouse movement. Explaining how the idea came to mind is the best way to illustrate why I feel it would make the experience more fun. The player often hides in a dark corner waiting for a hostile AI to pass right by as they patrol: In any real scenario you'd be holding your breath as to not make any sound or the slightest movement, even breathing would stand out slightly and could get you spotted. Thus from a perspective of realism, it feels out of place that I can zoom the mouse all over without any consequence... merely turning your head would draw a bit of attention, let alone looking behind which implies the player turning their whole body around. Meanwhile from a gameplay perspective, it could be a welcome challenge having to not move the mouse when a guard is right next to you, keeping your mouse steady similar to how you'd hold your breath as you wait till the danger passes to look away... this would feel more exciting and add a new form of tension, especially as many players complained the AI feels too easy even on the highest difficulty settings. Obviously the increase should be minuscule, possibly just 1 lightgem point: We don't want players feeling they can't look around while hiding, just not doing it too much when an enemy is right in your face. The best way seems like making it based on the movement speed: Moving the mouse very slowly could have no penalty, whereas jerking it suddenly could increase the lightgem by a few points so even in total darkness the AI sees something and may even catch you if you keep looking around rapidly while next to them. Another debate is whether this should be a spawnarg new missions have to configure, similar to some existing visibility properties and lightgem offsets. Personally I'm in favor of defaulting it to a low value, just 1 lightgem point increase if it's fixed or something like 3 if it's speed based. Alternatively we could tie it to the difficulty setting... if it's controversial maybe just implement it as a hidden cvar we can try out? Very curious what you think so let me know your thoughts, I'd definitely like to at least see the concept tested!

Currently mappers can't edit the objective screen gui. 1. But let's say you create a mission where you don't want any difference in difficulty, or set it in a different way, then I think you should be able to remove the 3 difficulty selections from the objective/dificulty screen. (Edit: Not possible yet, but objectives could be set in mission briefing and then difficulty selection screen can be skipped, See below.) 2. Also, maybe you don't want to list the objectives on an objective screen before mission start. Maybe you want to have a mission briefing, start the mission and after that give the objectives somewhere during the mission. Or maybe you want players to select difficulty inside the mission in some way. In this case there's no need for the objectives screen and you might as well skip this screen. (Edit: Already possible with #define ENABLE_MAINMENU_DIFF_SELECT 0 in mainmenu_custom_defs.gui )

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?

Last night we chatted on Discord about Vulkan support and PBR, bringing up a system for adding proper reflections once more. I suggested screenspace reflections but it was argued reflection probes would still be better than SSR in our case, a ticket for that is already open but I'm uncertain whether it's the best way: A manual approach would need new entities to be placed by the mapper... this requires extra effort and would exclude old FM's that are no longer updated, while the result will also be inaccurate and static meaning you won't see an AI reflected as they walk on a shiny metal plate for instance. If PBR with realistic graphics can be a hope for 2.12 or later, we'll definitely want to do it right rather than using a limited / limiting system. A technique came to mind that might just work for our engine and setup. I wanted to share it here before I forget the specifics; This might already be a common practice and even have a definition, for the purpose of this thread I'll just describe it as I originally imagined it and feel this would work for our engine. The idea is we'd use reflection probes but in an automated fashion: A probe is automatically spawned in every valid area (within bounds) in the player's view, at a given grid unit size. For example: If the grid scale is 16, a probe may exist at position '0 -48 16' another at ''0 -48 32' and so on. Every point projects its result on all surfaces in its radius which contain a specular channel masking it, the best alternative presently available till we were to convert all textures for PBR support. The cool thing is the same cubemap can also be projected as a light source, allow for global illumination in addition to just reflections! This would be similar to how the Irradiance Volume works in Blender / Eevee except each dot renders a little cubemap from its perspective. I already know what everyone is rightfully thinking: This is going to kill performance! After all each probe needs to produce a render from its perspective, and being a 360* panorama it will open portals in all directions. Normally that would be insane, but I thought of various ways in which the impact could be greatly minimized to very bearable amounts. The frame buffer of each probe will be at a very small resolution by default since much detail shouldn't be needed. Even 64x64 per cube face might do. Each probe only needs a draw distance double its grid size, given it only has to see as much as is necessary to fill the gaps between it and its neighbors. So if the grid size is set to 64, each probe would only have a draw distance of 128 to cover the space in between its neighbors, nothing beyond that would exist to it. Only probes the player can see would ever be spawned and calculated; If the view frustum doesn't overlap the virtual cube who's corners touch that probe's neighbors, the probe is dropped from memory. Probes are also only spawned in a valid visible space, never out of bounds including rooms culled by portals. A draw distance after which probes are removed or not spawned can also be included. This would further help by making any probe further than X distance be ignored, slowly fading away as to not noticeably pop in and out of existence. Reflections / GI are a discrete effect you'll only see up close. Similar to lights and shadows, the result of a probe should be cached and not calculated unless necessary. This means that unless something moves within radius of that probe its cubemap won't be rendered again. Probes would only be updated either when they first come into the player's view, or if something touching their cube has moved. Note that particles and lights with animated textures would have to count as you may see them in a detailed reflection, candles and torches would force constant updates per-frame for probes they intersect. If with all that performance is still affected, frame skipping is also a solution: Reflection probes can update at a lower frame rate to further decrease their impact. If you have a 60 Hz monitor and are running TDM at 60 FPS max, reflections could run at 30 / 20 / 10 FPS without looking out of place. They could in fact be defined as a fraction of your average framerate, so for the FPS you get you can decide whether it's going to be 1/2 or 1/4 or so on of that... this would have the added advantage of exponentially gaining back FPS the lower your FPS goes. There are several reasons why I believe this would be better than mappers manually placing new probe entities: Extra work is required for the mapper, who needs to figure out how to cover each area in probe lights. Every piece of the map would need to be encompassed in a reflection / GI probe otherwise you won't get shiny surfaces or bounce lighting which will look out of place. Most existing FM's will never be updated to use this: Only maps created or updated after the feature is introduced would benefit, anyone playing old missions will get boring visuals without reflections / GI which will be inconsistent to new ones. I strongly believe this should be done as an universal effect like SSAO. Single large probes will produce inaccurate results; The larger a cubemap is, the more drift and a fake results you get with distance from its center. This can be mitigated by using parallax corrected cubemaps which should be used for automated cubemaps too... none the less you get a single point of vision for a large room which makes the result inaccurate the further you go... with an automated approach you could have many probes in a dense grid (if your hardware allows it) for a much more accurate result at any position and angle. What are your thoughts on this solution, do you think it's realistic and can work out? I do believe it should be either this or screenspace reflections the way they're done in Godot or Blender / Eevee. If SSR isn't the right choice for our engine, reflections and global illumination alike could be captured using a global grid of capture points shining within their respective areas.

Okay, I'd like to throw in one idea. Open the spoilers for several disclaimers. Imagine 1. a real-time, online Multiplayer for Dark Mod (or similar 3D-first-person-medieval-theft-style game inspired by thief) 2. every real person has an account with a virtual money balance as acquired by playing the game 3 however, if one's virtual character dies, so does the account, and then the money is gone. One can decide to start fresh with a new account though. 4. top players and their accounts are listed somewhere on the games central website, bla bla bla, so there is motivation to have a long-lived character with a lot of money So far so good (?). Now for some gameplay specifics: 5. there are maps, of course. Everyone is free to design Maps. (since availability of maps is certainly one of the bigger bottlenecks, the initiative for someone to submit a map should be rewarded, or at least not made difficult). 6. There is an official entrance for the map, where the guards enter. And then there is a (or several?) inoffical entrance(s). There thieves might enter. The map creator is responsible for making sure both types of entrances (official and inoffical) exist. (As with single-player maps, the map creator should make sure there are official and inofficial routes throughout - in other words, an interesting, explorable, thief-style map). 7. The map creator is also responsible for making some riddles, which potential thiefs must solve in order to get into the map. Riddles should be hard (only solvable with a "hacker-mentality" - think of the cognitive tasks thieves face when trying to get entrance to a complicated system) (or, metaphorically speaking - the thieves play out their own version of a cutscene before a heist - of course only in their mind, not with a video ) 8. The goal of the guards is to, well, guard a specific object (or keep thieves from achieving a certain objective) for a certain amount of time. If they succeed, they will be paid accordingly (or rather the player's accounts)). 9. Per map, there is a maximum number of guards. This number is defined by the map creator. Also, the map creator equips each guard. Before a map starts, each guard position must be filled. If more people are interested than open positions exist, there will be a competitive selection procedure (maybe one-on-one fights in a "sandbox" mode against contestants? Or a quiz how well they are familiar with the map they want to guard?) 10. Importantly, the map creator CANNOT specify routes of guards. This is up to the players playing the guards. 11. Even more importantly - the group of guards do not know when of even if thieves will appear. This should encourage patrolling-style behaviors automatically. 12. The entrance riddle of thieves should be difficult. This is the main trade-off for the lucrative prize, together with the high guards:thieves ratio. 13. Within the map, there is no chat. People (guards and thieves) should only be allowed to cooperate via game-play elements. Therefore, guards writing letters should be possible, but thieves might steal this information within the map. (maybe talking is also possible, but this should be audible in a realistic way - thieves should be careful to not raise their voices and were they want to speak) 14. When the set time for a map is done, the players may decide each time if they want to play for the guards or the thieves next time. All in all, I believe this gameplay style would offer trade-offs for each party (guards, thieves) to make it difficult for both but balanced. Going back to the disclaimer: I'm aware that the online, real-time nature of my suggestion is difficult to implement at best, impossible at worst. But then, why these specific ideas? I believe such an approach could circumvent several dangers Dark Mod is facing: - rather unrealistic/easy AI --> not an issue here, because there is no AI, only natural human intelligence. - small ratio between map playing time : map creation time (not so much an issue as maps may be reused, but the feel for the mission is kinda new each time) - this might inspire some opening up of the community to new players, or encourage people to hand in maps, with the prospect that they might be used in a real-time, MP, higher-stakes scenario. So! I think I'm ready now being torn apart by you guys

I was thinking about how I've been a bit of a pessimist whenever I post stuff in the off-topic section of The Dark Mod Forums, and whilst I do stand by the fact that it's healthy to face unhappy realities of the world in order to provide discussion so that people will spread that discussion and the problems are eventually gained notice of and fixed, I also realize that it's kind of depressing, talking about war and strife. So, I decided to talk about a topic of how we can make the lives of people who are sick and dying happier, and help them experience things they wouldn't be able to otherwise due to their conditions, such as elderly in retirement homes or cancer patient children undergoing chemotherapy or other people who can't go out and travel much. I was thinking about how I haven't gone to the Zoo, Aquarium, or Museum for over a decade, and how I haven't gone to an amusement park, water park, or the beach in summer since covid started. Then I thinks to myself, at least you've done that in your life, some people aren't as lucky or well-off as you've been in life; some people never got around to doing that sort of stuff in their life and now they're stuck in a nursing home, or some are still young but stuck sick in the hospital, and may not live long enough to do that stuff. So I got to thinking, I've seen people on The Dark Mod Forums who've discussed making a VR version of The Dark Mod. And I wonder to myself, hey, you don't know how to program any of this for the less fortunate, but you like to suggest stuff to people, plant seeds in their ears like, so I decided to suggest this to you guys: What about making VIrtual Reality Experiences for the less fortunate? Zoos, Aquariums, Amusement Parks, Carnivals, Circuses, Fairs of the normal and medieval variety, Museums, that sort of thing. And they don't just have to be based on reality, with V.R. you could create a zoo full of unicorns, dragons, zombie animals, aliens, demons, and other fantastical beasts, or make Amusement Park rides that aren't feasibly safe with modern technology, like a roller coaster that reaches up into outer space and through an asteroid belt! I know this comes out of nowhere, but the idea hit me and I'd feel guilty if I didn't share it.

I realized when I played it that The Abomination, a giant gray monster composed of the fused forms of multiple zombies that attacks with tentacles and travels by digging tunnels underground, is obviously a ripoff of Subterranean Boss Infected Dolagius from Silent Fear, one of the first custom level mods for Left 4 Dead and the first one to have a custom boss I'm pretty sure of.

Below, I'll be describing what I see as a problem, in the form of a draft bug report. But perhaps there is some compelling reason to keep the existing behavior? So comment. --- Feature request: Prevent stealth retexturing. When you select a surface with Ctrl-Shift-LMB, you give it a blue dot. If you then paste or apply a new texture (e.g., from the Texture Browser), that new texture appears where expected. But you may have, without realizing it, retextured all other surfaces of any objects you had left selected. Typical problem cases: The blue-dot surface belongs to an object that you left selected. So all surfaces are retextured. If it’s a wall, you may not immediately realize that the far side and edges have changed. The blue-dot surface belong to a primitive component of a multi-part entity, and some other primitive component, perhaps out of sight, is still selected. So you change both the blue-dot surface and all surfaces of that other component. Discussion: I would like this to work, at paste time, just like Ctrl-MMB does. Namely, given a particular surface designated, ignore any object selection, and just paste to that surface. More specifically, if a blue-dot surface exists, paste/apply just to that. If it doesn’t, and an object selection exists, paste to all its surfaces.

Fire Arrows and Water arrows are a thing. So, what about Electricity arrows that activate machinery and can activate or deactivate robotic enemies like Steambeasts?

This isn't a feature I personally plan on using as I like to work alone. However I wanted to bring this up as I believe it would help with mission creation and more FM's being developed faster, particularly for people working on FM's in teams rather than alone. I'm imagining a relatively simple system, albeit it may require bigger code changes. Think of it as multiplayer with a server list but for the map editor: DR instances would have the ability to connect to other DR instances (or different server software) over the internet. Upon connecting the map in cause is cloned locally and loaded. The maps are synced between actively connected instances and any change made on any of the connected DR's is mirrored to the others in realtime, with the local map file being updated on each end as this happens. When an user selects or moves a brush or entity on one instance, it's highlighted and repositioned on all others as fast as the network allows... if done right a DR user should see map components moving on their own in the viewports as they would if being dragged by the local user. I'm imagining that such an ability could bring FM creation to a new level; Creators of a FM can connect to a central server storing that FM, ideally up for connectivity 24/7... each author can then make changes whenever they feel like working on a given part of the map, with everyone else seeing those changes in realtime (if connected) or when they connect to the project later. We could have larger and more complex FM's as a result! What do you think, and would this be possible without too much development effort? Trivia: This idea was inspired by the map editor in the Cube / Tesseract engine which is what the popular FPS Red Eclipse uses. It's not just integrated in-game requiring no separate editor at all, but people can start an ordinary multiplayer match to create a map instead of playing Deathmatch. This got me thinking about the possibilities of realtime collaborative map editing, especially for something more complex as TDM FM's where this could accelerate things quite a bit.

Obviously, the main way to contribute to TDM is to contribute work and expertise. FMs, tech improvements, every little helps... I've been thinking about whether, besides general TDM trailers, previews, FM briefings, wallpapers, promo images, and so on and so forth, we could drum up a little amount of extra publicity for TDM via more physically tangible, but financially permissible promotional materials. As I note in the title of this thread, how about using a few select paper models, each with a The Dark Mod theme (and the associated stylistics), as something of a fan keepsake new or old fans of our freeware game could build and keep ? I'm under no illussions it would be amazing or anything. However, as a bit of a feelie, done in free time as simple promotion by some members of what is essentially a hobbyist freeware dev team, I think it would be an aptly humble, but still original bit of extra promotion. Everyone expects wallpapers, screenshots, promo videos, and so on, but some papercraft promo could help add a little bit of different flair to that more conventional promotion we already have covered. You might think "Okay, a few people will build those paper models, but how effective could this promo be, anyway ?". Well, as much as I don't have any illussions... Imagine if someone puts a building from Bridgeport paper model on their desk, next to their computer, at their own apartment/house or at their dorm room, and someone eventually asks: "Nice ! Is that a real building ? What's that from ?". The owner, who also plays TDM in their free time and is already a fan, can say: "Well, it's from this and that stealth game with this and that style setting. Want to see it ?" Then he can show the curious guy or gal this site, a trailer or two, start up the game and show some gameplay from a mission or two, the training mission... Who knows, maybe he'll get that other person interested, maybe even hooked. And it all starts with a simple paper model of some building from the TDM world. Now, playing the game in front of them could achieve a similar result. Having a TDM wallpaper as the background on the screen, or being caught watching a trailer video or Let's Play video of TDM could achieve similar results too. In the end, though, those things are wholly digital. They're not as immediate and tangible in the same manner as a paper model can be. Yes, at the end of the day, it's just card paper with textured surfaces printed on one side, skillfully cut out, assembled and glued together. But it's still a physical object, giving you more of a 3D feel than just a 2D screen (and not necessitating any VR equipment for greater immersion, beyond the limitations of that on-screen imagery). Now, concerning what the paper models would encompass, how they'd be constructed and look, I think we have to be realistic about it: Most people can bother with a paper model of a simple enough building or object, but they won't be assembling detailed paper models of, e.g. a City Watch guard. Ergo, the TDM promotional paper models we could have should focus on two areas: 1.) architecture from the setting, primarily that of The City and other urban environments (clocktower, medieval townhouses, some castle or manor house, etc., you name it); 2.) gadgets and items carried by the player character thieves in the game (a paper model of a mine or even a flashbomb, a paper model of a potion bottle or of the small hooded lantern, etc.). The surface and details should be based on textures we assign to their models directly in the game. This is obvious in the case of the gadgets and items. In the case of buildings, they could either recreate an iconic building from some FM's scenery, or they could just as easily depict a generic building, but with the same combination of building textures as you see on buildings in TDM missions. The same stone textures on the outer walls, the typical late-medieval/early modern style windows, with their metal grills and glass panes, etc. Having the paper models designed and textured in such a way that they'd reflect TDM's predominantly night time setting (including dimly lit windows on buildings) would be a pretty cool move, IMHO. It would also be accurate to the atmosphere of the game. Distribution method... Could be available for download among the promo materials section on the site, either in .pdf format or some image format (.jpg or .png). Should I take a stab at designing some basic model concepts in my free time, if I'm ever bored ? Just as a test whether we could create TDM paper models in the first place. I think there is some merit to using paper models as an inexpensive and entirely ancilliary, but still useful promotional item. Especially for a freeware labour of love like this one, tirelessly being worked on for over 16 years. Sixteen years of this much patient fan devotion is nothing to sneeze at.

Not so long ago I found what could make a pretty good profile picture and decided to try it out on these new forums. But I couldn't find a button anywhere that would let me change it. I asked on Discord and it seems Spooks also couldn't find anything anywhere. So I logged into an old alternative account and, lo and behold, that account has a button. This is on the first screen I get when I: 1) click on my account name in the top-right of the browser -> 2) click on 'profile'. Compared to my actual account: Are you also missing this button on your account? It'd be very much appreciated if that functionality could be restored to any of the affected accounts.

I remember that a few years ago, someone pointed out a rather obvious limitation in the AI: A foe will only become alert if it sees the player directly, but not if it sees the shadow cast by the player. This means that if you're hiding behind a wall through which an enemy can't see you, however a light in front of you casts a shadow on the wall behind you which the foe would be able to see, that foe won't be alerted by your shadow. For the sake of having an intelligent and even more realistic AI, this always seemed a nice idea to consider. It was mentioned that it's difficult to find a good implementation for this mechanic. Earlier today I was thinking about TDM and remembered this subject. I thought about how such a system could be implemented in a way that doesn't decrease performance, and at the same time is accurate enough to be considered usable. Although I don't code any TDM scripts, I wanted to contribute the solution I came up with; It's an estimation so it won't give the most accurate results, but should be cheap and provide just enough realism for this purpose. This is how it would work step by step: We begin by looping through all lights that cast shadows on the map. For each light, we scan whether there's any entity that is a player or AI within the radius / box of that light. If the light is touching a player or AI, we proceed with the following points for each one. If a valid entity was detected at point 2, we trace a line from the origin of the light toward the center of the player / AI bounding box. At this stage we do some boundary and collision checks: If the line reaches a solid surface before it reaches the player's center, that means a wall is likely in the way and we proceed no further. Also if the line passes the player's center but exceeds the radius of the light without hitting anything, the shadow is likely not going to reach the surface behind them so we stop. If the line does pass the player's center then touches a solid surface without existing the light's radius, we take note of the origin at which this line touched this surface. A solid surface should be considered any shader who's alpha >= 0.5, as shadows are typically not visible on materials like glass or water. Next we spawn a virtual box at the origin of this point, which will usually be a floor or wall or ceiling. The size of this box depends on the distance between the light, the player's center, and the point in which the box is spawned: The closer the player is to the light source the bigger it should be, and the further the player is from the traced point the bigger it should once more get... this is to better estimate how large the shadow should be thus how likely to attract attention. At this stage we have a problem: If the cube is passing through a solid wall, it will cause AI in other rooms to inexplicably become alert. So before proceeding, our invisible cube must be cropped (scaled and positioned) so that it aligns with the surface of all walls it touches from the direction in which the line was cast. This might be a little tricky for diagonal walls. Now the cube entity can act as a visual alert for AI: If an enemy is seeing it, it's as if they are seeing the player. The alert should have a watered down effect, so that the AI's alert level rises much slower compared to seeing a foe directly: The AI should be surprised at the shadow but not immediately figure out that it's a person who shouldn't be there. That should be it from a technical standpoint! This method might fail to produce accurate results at times, namely if the path to the center of the player's box is obstructed by a solid although parts of the player are still visible to it... for a simple AI alert it should do however. It would be nice to see someone playing with this idea, maybe record a demo of how such a box projects to see if it's accurate enough. I attached a little schematic exemplifying how this would look like in 2D for easy visualization.

Hi, I need to know what the code is to use Spoiler Tags. I am using my tablet and I don't have the options to use anything, like spoiler tags, quote tags, text changes etc. Thanks

I discovered for myself some great html5 features of our webbrowsers, like viewing 3d generated environments with google maps and running old dosgames. (see other topics in offtopic forum) For the ones who doesnt know it, Its also possible to run Doom 3 in your browser: project page: http://www.continuation-labs.com/projects/d3wasm/ Sourcecode: https://github.com/gabrielcuvillier/d3wasm Demo: https://wasm.continuation-labs.com/d3demo/ (pro-tip: run the demo in google chrome/chromium) For a easy demonstration of our beloved game on cross platforms, how about running TDM in the webbrowser? (and stream the data files from a tdm mirror server)