Search the Community

============== -= IRIS =- ============== WELLINGTONCRAB TDM v 2.11 REQ Ver. 1.3 *For Maureen* -=- "Carry the light of the Builder, Brother. Unto its end." -Valediction of the Devoted "What year is this? Am I dreaming?" -Plea of the Thief Dear Iris, I am old and broken. When we were young it felt like the words came easily. Now I find the ink has long dried on the pen and I'm as wanting for words as coin in my purse. I can tell we are nearing the end of the tale; time enough for one more job before the curtain call... ============== -Installation- Requires minimum version of TDM 2.13 -Iris does not support mods or the Unofficial Patch- Download and place the following .pk4 into you FMs directory: Iris Download ============== Russian Language Translations by @kalinovka Mirror #1: yandex.ru Mirror #2: Google Drive ============== *Thank you for playing. Iris is a large mission which can either take as quickly or as long as you are compelled to play. I hope someone out there enjoys it and this initial release is not completely busted - I tried the best I could!* *Iris both is and isn't what it seems. If commenting please use spoiler tags where appropriate. If you are not certain if it would be appropriate a good assumption would be to use a spoiler tag* *Support TDM by rating missions on Thief Guild: https://www.thiefguild.com/* ============== WITH LASTING GRATITUDE: OBSTORTTE - Whose gameplay scripts from his thread laid the foundation which made the mission seem like something I could even pull off at all. Also fantastic tutorial videos! DRAGOFER - Who built upon that foundation and made it shine even brighter! And whom also provided immeasurable quantities of help and encouragement the past couple years on the TDM discord. ORBWEAVER & GIGAGOOGA - For generously offering their ambient music up for use. EPIFIRE - Who lent me his fine trash and trash receptacle models. AMADEUS - Who was the first person who wasn't me to play the damn thing and provided his excellent editorial services to improving the readers experience playing TESTERS AND TROUBLESHOOTERS: AMADEUS * DATISWOUS * SPOOKS * ALUMINUMHASTE * JAXA * JACKFARMER * WESP5 * ATE0ATE * MADTAFFER * STGATILOV * DRAGOFER * KINGSAL * KLATREMUS - What can I possibly say? Playing this thing over and over again could not have been easy. Deepest thanks and all apologies. -=THANKS TO ALL ON THE TDM DISCORD AND FORUM=- ==SEE README.TXT FOR ADDITIONAL ATTRIBUTIONS & INFORMATION== HONORABLE MENTION: GOLDWELL - If I hadn't by chance stumbled into Northdale back in 2018/2019 I would probably still be trying to get this thing to work in TDS, which means it probably would not exist - though more details on that in readme. ============== Boring Technical Information: *Iris is a performance intensive mission and I recommend a GTX 1060 or equivalent. I find the performance similar to other demanding TDM missions on my machine, but mileage may vary and my apologies if this prevents anyone from enjoying the mission.* *Iris heavily modifies the behavior of AI in the game, how they relate/respond to each other and the player. So they may act even stranger than they do typically in TDM. Feedback on this is useful - as it can potentially be improved and expanded upon in future patches.* -=- This is my first release and it has been a long time coming! If I forgot anything please let me know! God Speed. 2.10 Features Used:

So it's clear there are a lot of possibilities, each with strengths and weaknesses. It doesn't seem like anything replicates Discord completely right now. By my own experience, we mainly need Discord for 1) mappers as a place to bounce ideas, exchange files and work together in private channels, and 2) users as an easily accessible place to meet and chat about TDM. Right now we have the forum for anything that needs to be persistent and findable in the future, but discipline is not perfect in this regard, so sometimes important chats take place in Discord and get forgotten. Also, forum latency between messages is too long for easy chatting or co-mapping. I would place our priorities as follows: Must-haves: No requirement to prove identity. Multi-user text chat. Easy to partition into subchannels, either public or private. Easy to join and use. A lot of people can't or don't even want to install a VPN client, so it should not be much harder than signing up for Instagram. Made by programmers, not vibe-coders, and steadily developed. This ties into how secure and well-functioning the software is likely to be. Everyone uses AI these days to code, the question for me is what the skill level of the ones wielding it is. Nice to have (as a tiebreaker): Mature. We can expect projects to become more mature after initial teething problems. Similar UX to Discord. Has a mobile app for iOS and Android Easy to maintain for hosters Can be selfhosted. If we choose a public hosted service, we should check how likely it is for the makers to join the identity verification movement. Completely free. Paid products with a free tier tend to progress in a bad direction eventually because of greed, putting us in a similar situation again. However, the reality seems to be that this narrows our choices a lot and will require compromises elsewhere. Not important: Voice chat, video streaming, webhooks, bots. Not my impression these are commonly used features. We use youtube/twitch for streaming and sharing playthroughs. Federation. This would allow users to join other interesting communities with the same app/login, but narrows our choices down a lot for a relatively minor gain imo. End-to-end encryption. This causes operational complexity to manage, i.e. new users joining encrypted channels in Matrix couldn't see old messages. Also, the question is what our threat model is. I think what this mainly achieves is being able to hide messages from server admins and hackers, which isn't a feature we have had in Discord. Most of our messages are public. A risk of not having E2E could be a hacker leaking private chats and community members finding them (probably only if actively looking for them). I think we could reframe it not only as a Discord alternative, but also as a Microsoft Teams alternative given our collaboration needs for mappers. Could also be an idea to use forum software that has inbuilt chat rooms, which Discourse seems to be, but that would be a pretty big migration (AI helps, but can we replicate all the forum features we want and/or need?) and a big change from what we are used to. I have my doubts whether our forums need to be replaced. Also, most of the examples I found look a bit bare and like long scratchpads, especially if you don't figure out that you need to filter by category (examples, an example). If we can work around that, we would win 1) chat and forum being in one place and 2) currently free. From what I see so far, Zulip seems to be a good match for the priorities I put up, except for TaffingTaffer's objection that it is getting slop-heavy. Alternatively, we could migrate the whole forum to Discourse and use its inbuilt chatroom feature, hopefully without the new forum feeling unfamiliar or old content getting broken. But it could be a good idea to intentionally keep forums and chat separate so we can still communicate if one of them has a problem.

This is an experimental GUI app for managing and packing Dark Mod missions. It's a successor to FM Packer but with a GUI, that I've been working on for some time. It's now at a stage where I feel somewhat comfortable sharing. Having a GUI unlocks potential for more in depth management of fms, which I intend to explore in the future. You can download the binaries here: https://github.com/Skaruts/tdm_packer_2/releases Currently: it can pack your selected mission into the pk4 at a click of a button you can specify which files to exclude from the pk4, by editing the .pkignore file (Package -> Pack) you can edit the mission's files with syntax highlighting (xdata, scripts, skins, definitions, etc) you can view both the included and excluded files in a handy tree list (you can Shift+LMB to fully expand/contract branches) it can launch TDM or DarkRadiant for the selected mission, or run a second installation of TDM to test your pk4 in isolation (see the menu Settings->Paths) it automatically puts your map sequence into the appropriate file all maps, except the ones in the map sequence, are auto excluded from the pk4 Important: This is still an experimental alpha version, so backup your missions before using it. Note: For now I provided binaries for Windows and Linux. I don't have a Linux system to test the binaries yet, though, so they may or may not work properly. As a last resort, one can still run this app from the source code by running the Godot Engine itself from the terminal with the "--path path/to/project" argument. (Godot itself is just a simple executable and requires no installation.)

I'm making this thread to pick up on JackFarmer's recent status update asking where to go after letting Discord go. For those who might not be aware yet, Discord has the intention to roll out age verification (read: identity verification) for its users through uploading government identification or face scans to vendors like Persona, which is backed by Peter Thiel who can be described as "post-democratic" (PCGamer article from February, Wikipedia on Thiel). The public backlash appears to have delayed their plans for now, but it would appear wise for anyone who would not accept such a policy to make plans in good time for when Discord eventually does follow through. Back in February a small group of mappers and I looked into Discord alternatives and tried out Matrix on a public server. We ran into some technical & user experience issues with Matrix, and ultimately are still mostly on Discord after they walked back their plans and our acute need to migrate went away. I can only imagine that the landscape has improved since then and will continue to do so, and we can make our choice again. Personally I've gotten into selfhosting a couple years ago, so I have a strong bias to something that is open source and can be hosted on a rented virtual server, since I think that's a solution we can trust and control. I run various self-hosted services internally on various Linux devices with a focus on security and networking, and will eventually take over system admin of the TDM server from taaaki, so I think I would be a in a good position to step up to offering our own chat service. The big "if" I see in this plan, however, is the risk of an EU-wide law coming into force that forces all public chat services to verify age, but in that case we could try to see whether we can select a more benign method (like hand gestures) or whether we can shift responsibility to someone outside of EU jurisdiction. A publicly hosted service would also be an attractive option since it could have significant advantages when it comes to availability, performance, cost, bus factor, handling legal requirements etc. But then we are reliant on what that entity does, and the question is whether we can actually find such a public service. Let's start discussing here. Suggestions for, recent releases or significant updates of alternatives to Discord, which route to take, etc.

I'm surprised I could find any thread here for chat-GPT. Version 4 is outstanding from all reports I saw and I can't wait to get my hands on. It's not just a chat-bot (though it can discuss anything with you in great depth.) It can grasp the MEANING of sentences and write its own. In future games, you'll be able to talk to NPC's like you would any human. Search for video: Unbelievable AI Breakthrough Interactive AI Characters in a Videogame for the First Time! This demo is outstanding. GPT will be WRITING games! It can write meaningful stories. It can fill in your tax form, prepare your business/wedding speech and discuss its merits with you, and organise your professional work rapidly It can understand humour It can teach! Efficently! Sensibly! Find the Khan Academy video. It can write code/script good enough to frighten a senior programmer who can see it already is as good as junior coders and some seniors. He's afraid because it is certain to take over HIS job in due time, possibly only months away. An AI bomb has been dropped with GPT-4 and many do not yet realise how life-changing it will be - greater even than the advent of the internet. I give it 5 years to change the efficiency of almost everything tenfold, a hundredfold.

I think it is actually quite weird that we don't have a thread on graphics technology, yet. So, I would like to encourage you to share awesome new demos, talks, articles or papers about graphics technology here. I recently came accross this brilliant analysis of the rendering pipeline of "Rise of the Tomb Raider". I would love to see something like that for Doom Eternal, but so far, I could only find this rather superficial (but nevertheless interesting) review by Digital Foundry. Epic revealed Unreal Engine 5 today, which looks absolutely stunning. That Nanite-Technology will probably save game developers quite a bit of time. I do wonder, 'though, how the actually do it? Do they dynamically generate LOD-models? Also, does their Lumen technology require RTX?

Hello, everyone! In this multi-part, comprehensive tutorial I will introduce you to a new light type that has been available in The Dark Mod since version 2.06, what it does, why you would want to use it and how to implement it in your Fan Missions. This tutorial is aimed at the intermediate mapper. Explanations of how to use DarkRadiant, write material files, etc. are outside of its scope. I will, however, aim to be thorough and explain the relevant concepts comprehensively. Let us begin by delineating the sections of the tutorial: Part 1 will walk you through four, distinct ways to add ambient light to a scene, the last way using irradiance environment maps (or IEMs). Lighting a scene with an IEM is considered image-based lighting. Explaining this concept is not in the scope of this tutorial; rather, we will compare and contrast our currently available methods with this new one. If you already understand the benefits IBL confers, you may consider this introductory section superfluous. Part 2 will review the current state of cubemap lights in TDM, brief you on capturing an environment cubemap inside TDM and note limitations you may run into. Three cubemap filtering applications will be introduced and reviewed. Part 3 will go into further detail of the types of inputs and outputs required by each program and give a walkthrough of the simplest way to get an irradiance map working in-game. Part 4 will guide you through two additional, different workflows of how to convert your cubemap to an irradiance map and unstitch it back to the six separate image files that the engine needs. Part 5 will conclude the tutorial with some considerations as to the scalability of the methods hitherto explained and will enumerate some good practices in creating IEMs. Typical scenes will be considered. Essential links and resources will be posted here and a succinct list of the steps and tools needed for each workflow will be summarized, for quick reference. Without further ado, let us begin. Part 1 Imagine the scene. You’ve just made a great environment for your map, you’ve got your geometry exactly how you want it… but there’s a problem. Nobody can appreciate your efforts if they can’t see anything! [Fig. 1] This will be the test scene for the rest of our tutorial — I would tell you to “get acquainted with it” but it’s rather hard to, at the moment. The Dark Mod is a game where the interplay between light and shadow is of great importance. Placing lights is designing gameplay. In this example scene, a corridor with two windows, I have decided to place 3 lights for the player to stealth his way around. Two lights from the windows streak down across the floor and a third, placeholder light for a fixture later to be added, is shining behind me, at one end of the corridor. Strictly speaking, this is sufficient for gameplay in my case. It is plainly obvious, however, that the scene looks bad, incomplete. “Gameplay” lights aside, the rest of the environment is pitch black. This is undesirable for two reasons. It looks wrong. In real life, lights bounce off surfaces and diffuse in all directions. This diffused, omni-directional lighting is called ambient lighting and its emitment can be termed irradiance. You may contrast this with directional lighting radiating from a point, which is called point lighting and its emitment — radiance. One can argue that ambient lighting sells the realism of a scene. Be that as it may, suppose we disregard scary, real-life optics and set concerns of “realism” aside… It’s bad gameplay. Being in darkness is a positive for the player avatar, but looking at darkness is a negative for the player, themselves. They need to differentiate obstacles and objects in the environment to move their avatar. Our current light level makes the scene illegible. The eye strain involved in reading the environment in these light conditions may well give your player a headache, figurative and literal, and greatly distract them from enjoying your level. This tutorial assumes you use DarkRadiant or are at least aware of idtech4’s light types. From my earlier explanation, you can see the parallels between the real life point/ambient light dichotomy and the aptly named “point” and “ambient” light types that you can use in the editor. For further review, you can consult our wiki. Seeing as how there is a danger in confusing the terms here, I will hereafter refer to real life ambient light as “irradiant light”, to differentiate it from the TDM ambient lights, which are our engine’s practical implementation of the optical phenomenon. A similar distinction between “radiant light” and point lights will be made for the same reason. Back to our problem. Knowing, now, that most all your scenes should have irradiant light in addition to radiant light, let’s try (and fail, instructionally) to fix up our gloomy corridor. [Fig. 2] The easiest and ugliest solution: ambient lights. Atdm:ambient_world is a game entity that is basically an ambient light with no falloff, modifiable by the location system. One of the first things we all do when starting a new map is putting an ambient_world in it. In the above image, the darkness problem is solved by raising the ambient light level using ambient_world (or via an info_location entity). Practically every Dark Mod mission solves its darkness problem1 like this. Entirely relying on the global ambient light, however, is far from ideal and I argue that it solves neither of our two, aforementioned problems. Ambient_world provides irradiant light and you may further modulate its color and brightness per location. However, said color and brightness are constant across the entire scene. This is neither realistic, nor does it reduce eye strain. It only makes the scene marginally more legible. Let’s abandon this uniform lighting approach and try a different solution that’s more scene-specific. [Fig. 3] Non-uniform, but has unintended consequences. Our global ambient now down to a negligible level, the next logical approach would be hand-placed ambient lights with falloff, like ambient_biground. Two are placed here, supplementing our window point lights. Combining ambient and point lights may not be standard TDM practice, but multiple idtech4 tutorials extol the virtues of this method. I, myself, have used it in King of Diamonds. For instance, in the Parkins residence, the red room with the fireplace has ambient lights coupled to both the electric light and the fire flame. They color the shadows and enrich the scene, and they get toggled alongside their parent (point) lights, whenever they change state (extinguished/relit). This is markedly better than before, but to be honest anything is, and you may notice some unintended side-effects. The AI I’ve placed in the middle of the ambient light’s volume gets omnidirectionally illuminated far more than any of the walls, by virtue of how light projection in the engine works. Moving the ambient lights’ centers closer to the windows would alleviate this, but would introduce another issue — the wall would get lit on the other side as well. Ambient lights don’t cast shadows, meaning they go through walls. You could solve this by creating custom ambient light projection textures, but at this point we are three ad hocs in and this is getting needlessly complicated. I concede that this method has limited use cases but illuminating big spaces that AI can move through, like our corridor, isn’t one of them. Let’s move on. [Fig. 4] More directional, but looks off. I have personally been using this method in my WIP maps a lot. For development (vs. release), I even recommend it. A point light instead of an ambient light is used here. The texture is either “biground1” or “defaultpointlight” (the latter here). The light does not cast shadows, and its light origin is set at one side of the corridor, illuminating it at an angle. This solves the problem of omnidirectional illumination for props or AI in the middle of the light volume, you can now see that the AI is lit from the back rather than from all sides. In addition, the point light provides that which the ambient one cannot, namely specular and normal interaction, two very important features that help our players read the environment better. This is about as good as you can get but there are still some niggling problems. The scene still looks too monochromatic and dark. From experience, I can tell you that this method looks good in certain scenes, but this is clearly not one of them. Sure, we can use two, non-shadowcasting point lights instead of one, aligned to our windows like in the previous example, we can even artfully combine local and global ambient lights to furnish the scene further, but by this point we will have multiple light entities placed, which is unwieldy to work with and possibly detrimental to performance. Another problem is that a point light’s movable light origin helps combat ambient omnidirectionality, but its projection texture still illuminates things the strongest in the middle of its volume. I have made multiple experiments with editing the Z-projection falloff texture of these lights and the results have all left me unsatisfied. It just does not look right. A final, more intellectual criticism against this method is that this does not, in a technical sense, supply irradiant light. Nothing here is diffuse, this is just radiant light pretending the best it can. [Fig. 5] The irradiance map method provides the best looking solution to imbuing your scene with an ambient glow. This is the corridor lit with irradiance map lights, a new lighting method introduced in The Dark Mod 2.06. Note the subtle gradients on the left wall and the bounced, orange light on the right column. Note the agreeable light on the AI. Comparing the previous methods and this, it is plainly obvious that an irradiance environment map looks the most realistic and defines the environment far better than any of the other solutions. Why exactly does this image look better than the others? You can inform yourself on image-based lighting and the nature of diffuse irradiance, but images speak louder than words. As you can see, the fact of the matter is that the effect, subtle as it may be, substantially improves the realism of the scene, at least compared to the methods previously available to us. Procuring irradiance environment maps for use in lighting your level will hereafter be the chief subject of this tutorial. The next part will review environment cubemap capture in TDM, the makeIrradiance keyword and three external applications that you can use to convert a TDM cubemap into an irradiance map. 1 “ Note that the color buffer is cleared to black: Doom3 world is naturally pitch black since there is no "ambient" light: In order to be visible a surface/polygon must interact. with a light. This explains why Doom3 was so dark ! “ [source] Part 2 Cubemaps are not new to The Dark Mod. The skybox materials in some of our prefabs are cubemaps, some glass and polished tile materials use cubemaps to fake reflections for cheap. Cubemap lights, however, are comparatively new. The wiki page linked earlier describes these two, new light types that were added in TDM 2.05. cubicLight is a shadow-casting light with true spherical falloff. An example of such a light can be found in the core files, “lights/cubic/tdm_lampshade_cubic”. ambientCubicLight is the light type we will be focusing on. Prior to TDM 2.06, it acted as a movable, on-demand reflection dispenser, making surfaces in its radius reflect a pre-set cubemap, much like glass. After 2.06, the old behavior was discarded and ambientCubicLight was converted to accept industry standard irradiance environment maps. Irradiance environment maps (IEMs) are what we want to make, so perhaps the first thing to make clear is that they aren’t really “handmade”. An IEM is the output of a filtering process (convolution) which requires an input in the form of a regular environment cubemap. In other words, if we want to make an IEM, we need a regular cubemap, ideally one depicting our environment — in this case, the corridor. I say a snapshot of the environment is ideal for lighting it because this emulates how irradiant light in the real world works. All radiating surfaces are recorded in our cubemap, our ambient optic array as it were, then blurred, or convoluted, to approximate light scatter and diffusion, then the in-game light “shines” this approximation of irradiant light back to the surfaces. There is a bit of a “chicken and the egg” situation here, if your scene is dark to begin with, wouldn’t you just get a dark irradiance map and accomplish nothing? In the captured cubemap faces in Fig. 6, you may notice that the environment looks different than what I’ve shown so far. I used two ambient lights to brighten up the windows for a better final irradiance result. I’ve “primed the pump”, so to speak. You can ignore this conundrum for the moment, ways to set up your scenes for better results, or priming the pump correctly, will be discussed at the end of the tutorial. Capturing the Environment The wiki has a tutorial on capturing cubemaps by angua, but it is woefully out of date. Let me run you through the process for 2.07 really briefly. To start with, I fly to approx. the center of the corridor with noclip. I then type “envshot t 256” in the console. This outputs six .tga images in the <root>/env folder, simply named “t”, sized 256x256 px and constituting the six sides of a cube and depicting the entire environment. This is how they look in the folder: [Fig. 6] The six cube faces in the folder. Of note here is that I do not need to switch to a 640x480 resolution, neither do I need to rename these files, they can already be used in an ambientCubicLight. Setting Up the Lights For brevity’s sake, I’ll skip explaining material definitions, if you’ve ever added a custom texture to your map, you know how to do this. Suffice it to say, it is much the same with custom lights. In your <root>/materials/my_cool_cubemaps.mtr file, you should have something like this: lights/ambientcube/my_test_IEM_light { ambientCubicLight { forceHighQuality //cameraCubeMap makeIrradiance(env/t) cameraCubeMap env/t colored zeroClamp } } We’ll play with the commented out line in just a bit. Firstly, let’s place the actual light in DarkRadiant. It’s as simple as creating a new light or two and setting them up in much the same way you would a regular ambient light. I select the appropriate light texture from the list, “my_test_IEM_light” in the “ambientcube” subfolder and I leave the light colored pure white. [Fig. 7] The corridor in DR, top view, with the ambient cubic lights highlighted. I can place one that fills the volume or two that stagger the effect somewhat. Remember that these lights still have a spherical falloff. Preference and experimentation will prove what looks best to you. Please note that what the material we defined does is load a cubemap while we established that ambientCubicLights only work with irradiance maps. Let’s see if this causes any problems in-game. I save the map and run it in game to see the results. If I already have TDM running, I type “reloadDecls” in the console to reload my material files and “reloadImages” to reload the .tga images in the /env folder. [Fig. 8] Well this looks completely wrong, big surprise. Wouldn’t you know it, putting a cubemap in the place of an irradiance map doesn’t quite work. Everything in the scene, especially the AI, looks to be bathed in slick oil. Even if a material doesn’t have a specular map, it won’t matter, the ambientCubicLight will produce specular reflections like this. Let’s compare how our cubemap .tga files compares with the IEM .tgas we’ll have by the end of the tutorial: [Fig. 9] t_back.tga is the back face of the environment cubemap, tIEM_back.tga is the back face of the irradiance map derived from it. As you can see, the IEM image looks very different. If I were to use “env/tIEM” instead of “env/t” in the material definition above, I would get the proper result, as seen in the last screenshot of part 1. So it is that we need a properly filtered IEM for our lights to work correctly. Speaking of that mtr def though, let’s not invoke an irradiance map we haven’t learned to convert yet. Let’s try an automatic, in-engine way to convert cubemaps to IEMs, namely the makeIrradiance material keyword. makeIrradiance and Its Limitations Let’s uncomment the sixth line in that definition and comment out the seventh. cameraCubeMap makeIrradiance(env/t) //cameraCubeMap env/t Here is a picture of how a cubemap ran through the makeIrradiance keyword looks like: [Fig. 10] Say ‘Hi’ to our friend in the back, the normalmap test cylinder. It’s a custom texture I’ve made to demonstrate cubemap interactions in a clean way. Hey now, this looks pretty nice! The scene is a bit greener than before, but you may even argue it looks more pleasing to the eyes. Unfortunately, the devil is in the details. Let’s compare the makeIrradiance keyword’s output with the custom made irradiance map setup seen at the end of part 1. [Fig. 11, 12] A closer look at the brick texture reveals that the undesired specular highlighting is still present. The normal map test cylinder confirms that the reason for this is the noisy output of the makeIrradiance keyword. The in-engine conversion is algorithmic, more specifically, it doesn't allow us to directly compare .tga files like we did above. Were we able to, however, I'm sure the makeIrradiance IEM would look grainy and rough compared to the smooth gradient of the IEM you’ll have by the end of this tutorial. The makeIrradiance keyword is good for quick testing but it won’t allow you fine control over your irradiance map. If we want the light to look proper, we need a dedicated cubemap filtering software. A Review of Cubemap Filtering Software Here I’ll introduce three programs you can produce an irradiance map with. In the coming parts, I will present you with a guide for working with each one of them. I should also note that installing all of these is trivial, so I’ll skip that instructional step when describing their workflows. I will not relay you any ad copy, as you can already read it on these programs’ websites. I’ll just list the advantages and disadvantages that concern us. Lys https://www.knaldtech.com/lys/ Advantages: Good UI, rich image manipulation options, working radiance/specular map filtering with multiple convolution algorithms. Disadvantages: $50 price tag, limited import/export options, only available on Windows 64-bit systems. cmftStudio https://github.com/dariomanesku/cmftStudio Advantages: Available on Windows, OSX and Linux, free, open source software, command line interface available. Disadvantages: Somewhat confusing UI, limited import options, missing features (radiance/specular map filtering is broken, fullscreen doesn’t work), 32-bit binaries need to be built from source (I will provide a 32-bit Windows executable at the end of the tutorial). Modified CubeMapGen https://seblagarde.wordpress.com/2012/06/10/amd-cubemapgen-for-physically-based-rendering/ Advantages: Free software, quickest to work with (clarified later). Disadvantages: Bad UI, only Windows binaries available, subpar IEM export due to bad image adjustment options. Let’s take a break at this point and come back to these programs in part 3. A lot of caveats need to be expounded on as to which of these three is the “best” software for making an irradiance map for our purposes. Neither of these programs has a discreet workflow; rather, the workflow will include or exclude certain additional programs and steps depending on which app you choose to work with. It will dovetail and be similar in all cases. Part 3 The aim of this tutorial is twofold. First, it aims to provide the most hands-free and time-efficient method of converting an envshot, environment cubemap to an IEM and getting it working in-game. The second is using as few applications as possible and keeping them all free software that is available for download, much like TDM itself. The tutorial was originally going to only cover IEM production through Lys, as that was the app I used to test the whole process with. I soon realized that it would be inconsiderate of me to suggest you buy a fifty dollar product for a single step in a process that adds comparatively little to the value of a FM, if we’re being honest (if you asked me, the community would benefit far more from a level design tutorial than a technical one like this, but hey, maybe later, I’m filling a niche right now that nobody else has filled). This led me to seek out open-source alternatives to Lys, such as Cubemapgen, which I knew of and cmftStudio, which I did not. I will preempt my own explanations and tell you right away that, in my opinion, cmftStudio is the program you should use for IEM creation. This comes with one big caveat, however, which I’m about to get into. Six Faces on a Cross and The Photoshop Problem Let’s review. Taking an envshot in-game gives you six separate images that are game-ready. Meaning, you get six, split cubemap faces as an output, you need six, split irradiance map faces as an input. This is a problem, because neither Lys nor cmftStudio accept a sequence of images as such. They need to be stitched together in a cube cross, a single image of the unwrapped cube, like this: [Fig. 13] From Lys. Our cubemap has been stitched into a cross and the “Debug Cube Map Face Position” option has been checked, showing the orientations of each face. In Lys only panoramas, sphere maps and cube maps can be loaded into the program. The first two do not concern us, the third specifically refers to a single image file. Therefore, to import a TDM envshot into Lys you need to stitch your cubemap into a cross. Furthermore, Lys’ export also outputs a cubemap cross, therefore you also need to unstitch the cubemap into its faces afterwards if you want to use it in TDM. In cmftStudio you can import single map faces! Well… no, you can’t. The readme on GitHub boasts “Input and output types: cubemap, cube cross, latlong, face list, horizontal and vertical strip.” but this is false. The UI will not allow you to select multiple files on import, rendering the “face list” input type impossible.2 Therefore, to import a TDM envshot into cmftStudio you need to stitch your cubemap into a cross. Fortunately, the “face list” export type does work! Therefore, you don’t need to unstitch the cubemap manually, cmftStudio will export individual faces for you. In both of these cases, then, you need a cubemap cross. For this tutorial I will use Adobe Photoshop, a commercial piece of software, to stitch our faces into a cubemap in an automated fashion (using Photoshop’s Actions). This is the big caveat to using cmftStudio, even if you do not want to buy Lys, PS is still a prerequisite for working with both programs. There are, of course, open source alternatives to Photoshop, such as GIMP, but it is specifically Photoshop’s Action functionality that will power these workflows. GIMP has its own Actions in the form of Macros, but they are written with python. GIMP is not a software suite that I use, neither is python a language I am proficient with. Out of deference for those who don’t have, or like working with, Photoshop, I will later go through the steps I take inside the image editor in some detail, in order for the studious reader to reconstruct them, if they so desire, in their image editing software of choice. At any rate, and at the risk of sounding a little presumptuous, I take it that, as creative types, most of you already have Photoshop on your computers. 2 An asterisk regarding the “impossibility” of this. cmftStudio is a GUI for cmft, a command line interface that does the same stuff but inside a command prompt. I need to stress that I am certain multiple faces can be inputted in the command line, but messing with unwieldy prompts or writing batch files is neither time-saving nor user-friendly. This tutorial is aimed at the average mapper, but a coder might find the versatility offered in cmft interesting. The Cubemapgen Workflow You will have noticed that I purposefully omitted Cubemapgen from the previous discussion. This is because working with Cubemapgen, wonderfully, does not need Photoshop to be involved! Cubemapgen both accepts individual cubemap faces as input and exports individual irradiance map faces as output. Why, then, did I even waste your time with all the talk of Lys, cmftStudio and Photoshop? Well, woefully, Cubemapgen’s irradiance maps look poor at worst and inconsistent at best. Comparing IEMs exported from Lys and cmftStudio, you will see that both look practically the same, which is good! An IEM exported from Cubemapgen, by default, is far too desaturated and the confusing UI does not help in bringing it to parity with the other two programs. If you work solely with Cubemapgen, you won’t even know what ‘parity’ is, since you won’t have a standard to compare to. [Fig. 14] A comparison between the same irradiance map face, exported with the different apps at their respective, default settings. Brightened and enlarged for legibility. This may not bother you and I concede that it is a small price to pay for those not interested in working with Photoshop. The Cubemapgen workflow is so easy to describe that I will in fact do just that, now. After I do so, however, I will argue that it flies in the face of one of the aims of this tutorial, namely: efficiency. Step 1: Load the cubemap faces into Cubemapgen. Returning to specifics, you will remember that we have, at the moment, six .tga cubemap faces in a folder that we want to convert to six irradiance map faces. With Cubemapgen open, direct your attention to these buttons: [Fig. 15] You can load a cubemap face by pressing the corresponding button or using the hotkey ‘F’. To ensure the image faces the correct way, you must load it in the corresponding “slot”, from the Select Cubemap Face dropdown menu above, or by pressing the 1-6 number keys on your keyboard. Here is a helpful list: X+ Face <1> corresponds to *_right X- Face <2> corresponds to *_left Y+ Face <3> corresponds to *_up Y- Face <4> corresponds to *_down Z+ Face <5> corresponds to *_forward Z- Face <6> corresponds to *_back ...with the asterisk representing the name of your cubemap. With enough practice, you can get quite proficient in loading cubemap faces using keyboard shortcuts. Note that the ‘Skybox’ option in the blue panel is checked, I recommend you use it. Step 2: Generate the Irradiance Map [Fig. 16] The corridor environment cubemap loaded in and filtered to an irradiance map. The options on the right are my attempt to get the IEM to look right, though they are by no means prescriptive. Generating an IEM with Modified CubeMapGen 1.66 is as easy as checking the ‘Irradiance cubemap’ checkbox and hitting ‘Filter Cubemap’ in the red panel. There are numerous other options there, but most will have no effect with the checkbox on. For more information, consult the Sébastien Lagarde blog post that you got the app from. I leave it to you to experiment with the input and output gamma sliders, you really have no set standard on how your irradiance map is supposed to look, so unfortunately you’ll have to eyeball it and rely on trial and error. Two things are important to note. The ‘Output Cube Size’ box in the red panel is the resolution that you want your IEM to export to. In the yellow panel, make sure you set the output as RGB rather than RGBA! We don’t need alpha channels in our images. Step 3: Export Irradiance Map Faces Back in the green panel, click the ‘Save CubeMap to Images’ button. Save the images as .tga with a descriptive name. [Fig. 17] The exported irradiance map faces in the folder. These files still need to be renamed with appropriate suffixes in order to constitute a readable cubemap for the engine. The nomenclature is the same as the table above: “c00” is the X+ Face, to be renamed “right”, “c01” is the X- Face and so on. Right left, up down, forward and back. That’s the order! This is all there is to this workflow. A “cameraCubeMap env/testshot” in the light material will give us a result that will look, at the very least, better than the inbuilt makeIrradiance material keyword. [Fig. 17] The map ended up being a little bright. Feel free to open Fig. 4 and this in seperate tabs and compare the Lys/cmft export with the cubemapgen one. A Review of the Workflow Time for the promised criticism to this workflow. I already stated my distaste for the lack of a standardised set of filtering values with this method. The lack of any kind of preset system for saving the values you like makes working with Cubemapgen even more slipshod. Additionally, in part 2, I said that Cubemapgen is the fastest to work with, but this needs to be qualified. What we just did was convert one cubemap to an irradiance map, but a typical game level ought to use more than a single IEM. Premeditation and capturing fake, “generic” environment cubemaps (e.g. setting up a “blue light on the right, orange on the left” room or a “bright skylight above, brown floor” room, then capturing them with envshot) might allow for some judicious reuse and keep your distinct IEM light definition count down to single digits, but you can only go so far with that. I am not arguing here for an ambient cubic light in every scene either, certainly only those that you deem need the extra attention, or those for which the regular lighting methods enumerated in Part 1 do not quite work. I do tentatively assume, though, that for an average level you would use between one and two dozen distinct IEMs. Keep in mind that commercial games, with their automated probe systems for capturing environment shots, use many, many more than that. With about 20 cubemaps to be converted and 6 faces each to load into Cubemapgen, you’ll be going through the same motions 120 whole times (saving and renaming not included). If you decide to do this in one sitting (and you should, as Cubemapgen, to reiterate, does not keep settings between sessions), you are in for a very tedious process that, while effective, is not very efficient. The simple fact is that loading six things one by one is just slower than loading a single thing once! The “single thing” I’m referring to is, of course, the single, stitched cubemap cross texture. In the next part, I will go into detail regarding how to make a cubemap cross in Photoshop in preparation for cmftStudio and Lys. It will initially seem a far more time-consuming process to you than the Cubemapgen workflow, but through the magic of automation and the Actions feature, you will be able to accomplish the cubemap stitch process in as little as a drag-and-drop into PS and a single click. The best thing is that after we go through the steps, you won’t have to recreate them yourself, as I will provide you with a custom Actions .atn file and save you the effort. I advise you not to skip the explanations, however. The keen-eyed among you may have noticed that you can also load a cube cross in Cubemapgen. If you want to use both Cubemapgen and Photoshop together to automate your Cubemapgen workflow, be aware that Cubemap gen takes crosses that have a different orientation than the ones Lys and cmftStudio use. My macros (actions) are designed for the latter, so if you want to adjust them for Cubemapgen you would do well to study my steps and modify them appropriately. For the moment, you’ve been given the barebones essentials needed to capture an envshot, convert it to an irradiance map and put it in your level at an appropriate location, all without needing a single piece of proprietary software. You can stop here and start cranking out irradiance maps to your heart’s content, but if you’re in the mood for some more serious automation, consider the next section.

ok gemrb works pretty ok now though the enhanced edition support is still experimental. it does not load movies unless you copy them to lang\<your locale>\movies. some addons like bggo and bubbs spell menu work. the HD pack for baldurs gate does not work due to it relying on an extension dll for the EEex addon to load the 4k scaled textures (so do not use that!). the UI does not like internal resolutions above a certain point, these are the biggest that will work for 16:9 # Screen width Width=1336 # Screen height Height=768 anything higher breaks the UI. also does not matter since it scales to the screen anyway, it is mostly set for correct aspect ratio. for baldurs gate 2 change this in the cfg -> GameType=bg2ee and for baldurs gate 1 GameType=bgee if using the enhanced editions. gemrb needs the path to the gamedirs set in cfg but it can use relative paths like ..\gamedir\ mine looks like this GamePath=..\Baldur's Gate II - Enhanced Edition\ for baldurs gate 2. you can use multiple different cfg files for several games i currently use 2 named bgee.cfg and bg2ee.cfg and to load the correct one make a shortcut to the gemrb executable like this <D:\Spil\gemrb\gemrb.exe -c bg2ee.cfg> or D:\Spil\gemrb\gemrb.exe -c bgee.cfg. this loads up the game pointed to in the cfg files with the settings you have selected. try it out but be aware that there are a few bugs still with the enhanced editions.

I am working on improvements I can make to all.lang. The potential scope of work is overwhelmning, so I'm focusing at this time on the Main Menu, particularly Settings. I'd appreciate your review of the workplan, which has 3 main components - 1) commenting-out #str phrases no longer useful 2) adding #str to replace phrases hard-coded in English, in the relevant GUI files. a) in [English] b) in other languages (using AI) 3) For existing Settings #str in the GUI files, that were translated for some languages: do the remaining languages (using AI). I'm excluding this - - strings in *.cpp files - translations into Dutch and Swedish, where almost all strings are untranslated. Each of these is a project in itself, and I'm not up to it currently. Reviewers... My base is the 2.14 all.lang. If you know of 2.15 changes that could affect individual #str, please mention it here Details I have a revised all.lang WIP with the following changes done so far: - Group (1) work in both [English] and all other sections, as summarized and itemized here... - Group (2a), only in [English] so far, as summarized and itemized here... Workplan for Group 3 is WIP.

I kind of miss our old status-bar on the right, where you could casually share what's on your mind or what is happening in your life right now. So, I figured, let's just start a thread for that. Let's get this started...

actually did quite a workover on the old digital mars compiler and updated STLPort to the latest version while i also did some changes internally to it's runtimes so that it would work with it. there was one pitfall though and it was quite nasty... the compiler runtimes use the NT 386 masm assembler (and good luck finding it ) you cannot use the DOS masm.exe assembler or the visual studio 5 or 6 ml.exe assembler it needs the masm386.exe assembler. this is due to how microsoft at that time ported DOS for use with the 16 bit VDM and since symantec C++ was from that time it uses the same assembler... luckily i still had it with my old MSN discs so i could rebuild the runtime after a few changes, but damn... the masm386 assembler is a bit non standard in that it supports both DOS and NT switches at the same time. the new stlport works great for XP but some of the older NT sources in examples are not to happy with it due to increased strictness . digital mars also introduced an updated main compiler executable named dmc.exe which is partly written in D. compared to the older symantec sc.exe it supports linking to both COFF and OMF libraries where sc.exe only supports OMF. it is also compatible with much newer sdk's than the standard NT sdk but setting it up to work with those can be a bit hairraising. D is walter brights brainchild and can be used as a replacement for C++. there are some differences to C++ though. one it uses garbadge collection for nearly everything, two the syntax is a bit of a mix between pascal and C++ so it does take some getting used to.

Crouched Player Hands Mod (TDM 2.14) @jivo, the original creator of the Visible Player Hands Mod, is currently absent. A year ago Jivo announced plans to further improve the mod but we haven't heard from him since. TDM 2.14 was released and his mod hasn't been updated. One of the planned features was to have the option to show only the hands (no items). This is what I think works best, at least as the starting point, and this is what my fork is about: Show at least one hand when crouching Remove the crouch indicator from the HUD DOWNLOAD (Windows) https://www.mediafire.com/file/oboazn4ohfby7e4/Crouched_Player_Hands_2.14-Win.zip/file Please note the download includes a modded TDM 2.14 Windows executable. The executable has been compiled by me using official code sources and Microsoft Visual Studio Community 2022. The download also includes a copy of the changes made in the source code, which can be found inside the pk4. The zip includes: TheDarkModx64.exe z_crouched_player_hands_214.pk4 INSTALL Make a manual backup or rename your TheDarkModx64.exe (ie: TheDarkModx64.exe.original) Drop the modded TheDarkModx64.exe and the file z_crouched_player_hands_214.pk4 into your TDM root folder UNINSTALL Delete the modded TheDarkModx64.exe and the file z_crouched_player_hands_214.pk4 from your TDM root folder Restore the original TheDarkModx64.exe DOWNLOAD (Linux) I don't have the knowledge to provide a build for Linux. ---------------------------- Should Jivo be back and resume work on his mod I will ask Forum Moderators to delete this whole topic. In the meantime, I hope you have fun with this fork for TDM 2.14. THANKS JIVO FOR YOUR WONDERFUL WORK! PLEASE BE BACK SOON!

Good thing to have for FMs that haven't already been translated. (I once started a similar effort to convert the Perl extraction script to C++. Abandoned as too much work, tho partial code was successfully recycled to help my other utility projects.)

This is just an imagination thread. Taff. I've been having some thoughts on why this setting captures my imagination. I think it's that, as parallel worlds go, it feels really intensely like it's in a "lost corner." Between seeming like it's the post-post-apocalypse, or some moment of deep amnesia in a historical period that has been unable to change virtually for eternity, the seemingly endless underground layers, the wildly overbuilt urban infrastructure, monstrously tall townhouses and skyways. Supposedly Bridgeport has colonies, but if Bridgeport has colonies, Bridgeport is an empire. But from everything we know of history, if Bridgeport is an empire, then it has changed recently and will change soon. There's contrast there between parts of the civilization that seem stagnant and parts that have been ripped up and will be ripped up soon if not in the process already. The technology (wireless power) is something we haven't achieved at an urban scale in contemporary times. The most we have is like an electromagnet that charges your toothbrush or your phone virtually at point blank. What accounts for these scientific wonders in a world that is otherwise much more primitive? Archaeological rediscovery of lost scientific advances? Or perhaps the more occultic forces that sometimes make an appearance? Is it possible that the streetlamps are powered by irrational forces like anxiety and terror? Or is there something deep under the earth, something we don't understand, beneath Bridgeport, that the city is able to tap into? Is it local to Bridgeport, or is it worldwide? If it's not worldwide, does Bridgeport's monopoly on it sustain its empire? I have my personal answers to these questions, but mainly, I want to invite you to appreciate the sense that something is wrong with Bridgeport, something is off. It's a lost corner. And it's a mistake, and the people there sometimes feel it, but seemingly the full story of why is either lost or never known.

might want to limit yourself to XP if trying out the visual studio 5.0 compilers. later versions of windows got increasingly quirky with the old microsoft compilers. version 6.0 can run even on windows 10 but you had to disable allmost half of the features due to incompatibilities. .NET 2003 compilers run even on windows 11 though even they still got some compatibility problems (the ide must be set to run as admin and disable desktop composition and DPI scaling otherwise the search feature breaks). running the compilers from the command line works well enough though. also both msvc 5.0 and 6.0 barely had a working Standard library with both relying on stlport or other standard library enhancers for more advanced stuff. so C++ was quite a bit more annoying to work with . other compilers like symantec C++ and borland made full use of stlport because they did not come with they're own STL at all. digital mars which is actually the symantec compiler even works today with the only problem being the IDE which needs to have some compatibility flags set so that it shows correctly. digital mars can even build stuff that relies on microsofts MFC library but it is mostly intended for work on older code. supports building DOS WIN16 and WIN32 stuff.

I think there's something here that isn't being mentioned about using forum instead of chat which is when someone wants to ask a simple question or just something random that doesn't need its own thread and cluttering the forum with duplicated questions and stuff like that. I know this could be done by creating a thread called random that one could post anything in it but still. This is why i don't see harm in creating a chat server that can be used side by side with this forum. First you could try XMPP public server instead of creating your own to test how it will work. If things turn out alright then you could go ahead to create your own. I'm pretty sure some of them offer a way to create your own group.

Ooh how did this thread turn into a retrocomputing thread i dont know why i am so obsessed with pentium D lol The AMD Athlon 64 X2 was released in the same year tho The onky advantage of the Pentium D sticker currently on my PC is that it prevents Altman from asking how much RAM I have and what my RAM utilization is. it's become a worldwide meme now Netburst was memorable , let's commemorate its long staged pipeline + pipeline stall , bad branch prediction, high l1d latency and so on older pentium like pentium pro ? i like how tomasulo algorithm was included in pentium pro or p6 architecture https://stackoverflow.com/a/58370390 found nice writeup and core 2 duo review from very old anandtech article : AnandTech | Intel's Core 2 Extreme & Core 2 Duo: The Empire Strikes Back - Print View (2006) you can see the the evolution from pentium d to core 2 series got some interesting nuggets of info and keyword from there : the first is "Memory Latency: No Integrated Memory Controller Necessary" , L2 shared cache , "wider front end, aggresive prefetcher " Intel wide dynamic execution on core 2 is the main benefit in the fight against AMD at that time " Rather than 3 execution pipes, core CPU's have 4. This allows the Core Architecture to process 4 simultaneous instructions per clock cycle. This reduces the amount of clock cycles needed to execute a program, reducing power consumption as the CPU is at load for less time. With Wide Dynamic Execution comes another feature built into the pipeline called "Macro Fusion". When the instructions are loaded into the decoder, if a common pair of instructions are found in the decode buffer, Macro combines the 2 and sends them down to the Execution stage in a single packet. This doubles the data that is sent allowing 2 instructions to be sent simultaneously. Increasing the amount of data processed per clock cycle." (source from tweaktown). IIRC, did amd only have 3 instruction ? Another fascinating story is that when many DEC Alpha engineers joined AMD to work on Athlon, AMD adopted the EV6 front-side bus protocol, which was directly inspired by DEC. If you look more closely at its structure, it features a separate memory link, peripheral interface, and interconnect between cores. However, this front-side bus seems to have become a point of contention among the cores. It's limited by its speed, and this may affect the maximum throughput. The DEC Alpha 21264 DNA obviously was there HyperTransport and QPI (if I’m not mistaken, Intel hired the engineer who created HyperTransport) emerged later.

@jivo basically cloned the weapon entity and named it "visible_hands". The original weapon entity remains unaltered and the new "visible_hands" weapon is always enabled or active. Changes required must be applied to: game\Player.cpp game\Player.h game\Weapon.cpp game\Weapon.h These changes on their own don't do nor break anything: script\tdm_weapon_unarmed.script must be edited to work with the changes. Here attached the changes needed based on 2.15 dev17610-11364. It is in your hands now 215_dev17610-11364_Visible_Hands.zip

How you can help depends a lot on what skills you have. I can Record Video Recording "Let's Play" videos or simple walkthroughs of existing missions and posting them to Youtube is great exposure for the mod (see example .) Be sure to let us know so we can link to them. If you have some editing ability, Video tutorials, where you explain how the mod works, or how to use specific tools, would also be great. Video trailers, showcasing interesting places and features, are also great for publicity. An example is . I can Write Writing reviews for missions are always nice, especially if they include good screenshots. Not only does it give us something to post on other forums, but it makes mappers feel good when their mission gets attention (especially if it's positive). We have a collective thread to post reviews in: http://forums.thedar...s-walkthroughs/ Writing reviews of the mod as a whole, targetted an an audience that doesn't know much about TDM, is also very useful. You could also try offering your services to mappers to create interesting readables, or to proofread for their mission. I can Act and Record Audio We are always on the lookout for good quality audio recordings for vocal sets. If interested, you can pick a few different lines from this script: http://wiki.thedarkm...t:_Average_Jack and send the recordings to Springheel, who then writes a script based on the type of voice you have. I can Translate We could always use translations of our menu/hud into more languages. Also, only a few FMs are aavailable in more than one language, so there is a lot of work there, see the I18N Translator's Guide in the Wiki. I can Model Great! Take a look at the model request thread:http://forums.thedar...-requests-here/ and pick something that interests you. Or just post a, "Hey, anybody want a model?" thread in this forum and I'm sure mappers will get back to you. I can Animate Fantastic. We can always use more good animations. Our current character rigs use a Maya skeleton. PM Springheel for more info. I know C++ Have a look at our coding section in the wiki, pick an issue or feature from the bugtracker of the mod or the leveleditor, download the recent sourcecode release (or better ask for an SVN checkout) and get cracking. Make sure nobody is already working on that specific issue and feel free to ask questions. I can Edit Images We can always use completely new textures and/or improved versions of older textures. How to get started and how to import them into the mod. I can Take Photos Good quality photos of useful textures (medieval-ish building facades, dirt, rocks, wood, etc) are always welcome. The fewer directional shadows and higher resolution, the better. I don't have any skills Even if you can't do any of the above, you can still help out. Talk about TDM in other forums; share your (preferably positive) experiences with other gamers you know. Last, but not least, compliment people when you like their work. Saying "thanks", to a developer or, "I really enjoyed your mission" to a mapper will make their day. -------------------- I'll update this further as more things occur to me.

I think that a forum is always better for communication and interaction in is random access structure, not possible this way in social networks wit sequencial structure, where it is easy to loose the theme and you have to scroll up kms to find it. Yes, its mainly for socializing. Forums are dying, despite it is way better and feature rich than a chat, but it was killed by smartphones. In a smartphone the handling of a forum is a toothache, there a chat or social network is easier and more direct. But for an tech support, there exist nthing better than a forum. Respect Markdown, which I like a lot, would be nice to have instead of the BBcode. But here is needed to maintan the automatic insetion of YT videos, because In Markdown it don't exist like in the BBcode.

Agibot A3, 2 versions, this one for security tasks and a second one for services and work.

ThiefGuild has some tags: https://www.thiefguild.com/fanmissions/?advanced_search=&series=&collection=&table=&page=&works=&work_lists=&sort_by=newest&search=&games=5&released_from=all&released_to=all&genre=all&original_games=fms Not sure how complete or accurate those are, after all either the author or users add the tags to the missions.

If like me you scour the web looking for inspiration for your next TDM mission then look no further.. Now... talking of images have you guys seen the latest from the master that is DrK from his Rocksbourg4 campaign. We need more dirty texture in TDM me thinks...

Interesting. I'd be up for a Matrix "server" (what do they call it instead, spaces/rooms?) I was introduced to Matrix (and Element as its client) from some people in the OpenXcom modding community. It works reasonably well, but yeah you have to be patient especially with first use of it. It's not uncommon at all to miss out on a lot of older messages because they get locked behind encryption and never decrypt. It's still a problem even today, but so long as you get it working and use it somewhat frequently, things work fairly smoothly.