Search the Community

This is an intereting discussion. So, could one of the mods please move this to a separate thread as to not derail the beta testing thread. As a developer, you spend about 80% of your time just reading code. So, optimizing for readability is very important. The more information you can gather just by reading without cluttering up the code (by needless comments) the better. Hungarian notation helps immensely to quickly prase the displayed code in your brain. Yes, your IDE will show the desired information as well, but a mechanical interaction with the code is required to show it (mouse over or similar). Also, often you are tasked to do code review on webpages that don't offer these nice crossreferencing features of your IDE. Some things are objectively bad, 'though, so the respective rules preventing those things should universally be followed. For instance, much legacy code is nested extremely because at some point in time, it must have been a rule that you only have one return-point in your function (probably a c-residual). Such code is exhausting to read ("what was the else-if-condition some 1000 lines ago leading to this else-case again?") and very likely contains tons of code duplication. Today, we have the rule to only use little nesting and short if-else-clauses, to make the code easy to read and debug. If I come accross such a nested legacy function, I refactor the shit out of that function while trying to understand it, just so the next person after me doesn't have to deal with that horrible mess again.

Alright, so, I'm a Texture Artist myself for more than 20 years, which means I know what I'm talking about, but my word isn't law at all, remember that. I've worked (mostly as mods, I am a professional but I much prefer being a freelance) with old DX8 games up to DX12. When it comes to Detail Textures, for my workflow, I never ever use it except rarely when it's actually good (which, I emphasize on "rarely"). This is one reason I thought mentioning that I worked with DX8 was logical. One of the few times it's good is when you make a game that can't have textures higher than what would be average today, such as, World Textures at 1024x1024. Making detail textures for ANY (World, Model) textures that are lower than 128x128 is generally appealable. Another is when the game has no other, much better options for texturing, such as Normal Maps and Parallax Mapping. Personally, I think having Detail Textures for The Dark Mod is arguably pointless. I know TDM never had a model and texture update since 2010 or so, but most textures do seem to at least be 1024x1024, if there's any world texture that's lower than 256x256, I might understand the need of Detail Textures. Now, if this was a game meant to be made in 2024 with 2020+ standards, I would say that we should not care about the "strain" high resolution textures add, however, I do have a better proposition: Mipmaps. There are many games, mostly old than new ones, that use mipmaps not just for its general purpose but also to act as a "downscaler". With that in mind, you boys can add a "Texture Resolution" option that goes from Low to High, or even Lowest to Highest. As an example, we can add a 2048x2048 (or even 4096x4096) world texture that, if set to Lowest, it would use the smallest Mipmap the texture was made with, which depends on how the artist did it, could be a multiplication of 1x1 or 4x4. One problem with this is that, while it will help in the game with people who have less VRAM than usual these days, it won't help with the size. 4096x4096 is 4096x4096, that's about 32mb compressed with DXT1 (which is not something TDM can use, DXT is for DirectX, sadly I do not know how OpenGL compresses its textures). I would much rather prefer the option to have better, baked Normal Maps as well as Parallax Mapping for the World Textures. I'm still okay with Detail Textures, I doubt this will add anything negative to the game or engine, very sure the code will also be simple enough it will probably only add 0.001ms for the loading times, or even none at all. But I would also like it as an option, just like how Half-Life has it, so I'm glad you mentioned that. But yet again, I much prefer better Normal Maps and Parallax Mapping than any Detail Textures. On another note...Wasn't Doom 3, also, one of the first games that started using Baked Normal Maps?

I've seen fun workarounds like that in other game modding as well. Years ago, maybe even a decade, some fella who was making a mod for Mount & Blade over at the Taleworlds forums revealed that he put invisible human NPCs on the backs of regular horse NPCs, then put the horse NPCs inside a horse corral he built for one of his mod's locations/scenes and then did some minor scripting, so the horses with invisible riders would wander around the corral. The end result was that it looked they're doing this of their own will, rather than an NPC rider being scripted to ride around the corral slowly. Necessity is the mother of invention. I don't know about the newest Mount & Blade game, but the first generation ones (2008-2022) apparently had some sort of hardcoded issue back in the earlier years, where if you left a horse NPC without a rider in its saddle, the horses would just stand around and wait and you couldn't get them to move around. Placing an invisible rider in their saddles suddenly made it viable again, at least for background scenes, of riderless horses wandering around, for added atmosphere. First generation M&B presumed you'd mostly be seeing horses in movement with riders, and the only horses-wandering-loosely animations and scripting were done for situations when the rider was knocked off their horse or dismounted in the middle of a battle. Hence the really odd workarounds. So, an invisible NPC trick might not be out of the question in TDM, even though you could probably still bump into it, despite its invisibility.

Here's my first FM. A small and easy mission, inspired by Thief's Den and The Bakery Job, where you must find and steal a cook's recipe book in order to save a friend from going out of business. Download: Mediafire (sk_cooks.pk4) TDM Website's Mission Page The in-game mission downloader Thanks to: The people who helped me get this far, both in the forums and on Discord. The beta testers: MirceaKitsune, Mat99, Baal, wesp5, Cambridge Spy, jaxa, grodenglaive, Acolytesix ( Per the author in the beta testing thread. ) Skaruts has given permission to the TDM Team to add Subtitles or Localization Strings to this mission. (No EFX Reverb.) If anyone from the Community or TDM team wishes to create these we will gladly test them and update the mission database.

Might be worth a try. I browsed the source code yesterday a little, but I had no idea where to even start looking for it. I've been building a sort of starter-project for it, but it's not public yet. But my support for DR is not ready for production or anything. Everything seems to work fine, except I'm having issues with textures, and tbh I'm not sure I'm gonna make it. I am about to make my repo public regardless of that, though, but I still need to get a lot of stuff in order. Meanwhile, if you'd like to move forward without DR, you could try NetRadiantCustom or TrenchBroom. Personally I recommend NRC (although TB might be a bit easier to start with). The plugin I'm using is FuncGodot (formerly known as Qodot). It's currently the most recommendable. Patches and NURBS aren't supported by any plugins yet, btw.

I can certainly help to locate and identify the relevant code, but I didn't write it myself and I'm not really a maths guy so the help I can provide with respect to its logic might be limited.

Actually I think I found what's causing issues with my textures: DR changes the texture's Horizontal and Vertical Shift when a face gets slanted. E.g., my test door is facing -Y and sitting flat on the ground, which is at 0 in Z, so the v-shift is 0. When I move the bottom vertices of the door 8 units forward, and then re-fit the texture, the v-shift turns to 4 (3.97241). If I do the same but backward, the v-shift turns to 90.7035. But these values depends on the distance the face is from the world origin, and sometimes if I move the top vertices instead, the values don't change. I can't make sense of it... The other editors don't do this, so the plugin's import code doesn't account for it. Do you think you could help me understand the logic behind this? If I could understand it, maybe I could get the plugin working with it.

Inn Business It's business, at an inn, over three nights. Development screenshots: Download: https://drive.google...dit?usp=sharing Update 1.48 uploaded March 8th, 2014, one change: patches key rarely not being frobable in one of its possible spots Big thanks to my beta testers: Airship Ballet, Kyyrma and AluminumHaste! Development supporters of note: Sotha, Springheel and Obsttorte. Also thanks Sotha, for urinating in my mission. ;-) And thanks Kyyrma for the title screen! My appreciation to all forum/wiki contributors, without whom, this wouldn't exist. Thanks to positive commenters on my previous mission too, extra motivation helps! :-) Note this uses campaign features, what you use the first night, impacts subsequent nights. And to quote a tester, "...the level is maybe best experienced in more than one sitting". If you do pause between nights, please be sure to save, you can't begin partway through effectively. (If you accidentally start a night you already completed, just fail the kill objective to switch to another night.) If your frame rates are too low facing the cemetery, please reduce your "Object Details LOD" setting. It was designed with "AI Vision" set to "Forgiving", to be able to sneak through with minimal reactions, if you want more/less, adjust your settings accordingly. There are several random, conditional aspects, and ways of going about things, so others might have slightly different experiences. Post here if you discover hidden objectives for extra points! My condolences to loot completionists, I made a bit on the third night hard, you've got your challenge cut out for you! Speaking of which, there's a TDM bug that mission complete totals too high, here are the real amounts per night: 2026/970/202. Oh, there is something that in the U.S. would be rated PG, in case you play with kids in earshot. I hope you enjoy playing it, feel free to let me know you did, and I'm glad to respond to inquiries (like how stuff was done, nothing was scripted). (Note which night you are referring to if it's something specific.) (Please remember spoiler tags to not expose things meant to be discovered by playing.) Like so: [spoiler]secrets[/spoiler] Developed for TDM 2.01. PS: Thiefette, good news, no spiders! Springheel, if you find an optional objective you can skip...you might find it immersion breaking. Others, no undead! There are a couple other interactive critters though. :-) Edit note: Some posts below were from users of an unreleased version of TDM 2.02 which broke several things, they do not reflect regular game-play.

Your skins don't have a model specified in the skin code. How do you think it works that way? Edit: The reason this happens (I think) is that the skin name cannot start with a number. skin one_brick_teal_blue { model models/title_models/walls/wooden_frame/straight_frame/straight_frame_wall_128_x_128.ase textures/darkmod/plaster/plaster_01 textures/darkmod/stone/brick/blocks_tealblue_dark }

Alright, new problem with making these skins (or should I make a new thread about this?) Why are my skinned models coming up black? Here is my updated code for a simple skin. And here is the model in the skin editor, changed to its creamy, plaster version. Yet for some reason, all of my skins are pure black. The wiki says this is caused by the editor not finding the skin definition, and that there are spelling errors somewhere. I am not sure what this means, though, since all of my directory paths are spelled right (otherwise, how would the skin editor display them perfectly fine?) Does the name of the file have to match the declared skin name?

The TDM Unofficial Patch is a personal project of mine to modify some small details that annoyed me in the core game. It wouldn't be possible without many others, so thanks to the whole TDM community for discussions and help, but especially to friendly modders who directly contributed code for it, like Obsttorte, Dragofer, Kingsal, Goldwell, Destined, and snatcher! You can find it under the link below and while over the years there was little progress, in recent times many things have been improved that I never even thought of when I started and some might be worth to be included in the core game. https://www.moddb.com/mods/the-dark-mod/addons/the-dark-mod-unofficial-patch Version Changelog: ------------------ v1.7 20.08.2022 ---- Made loot icon change right back to last tool icon, thanks snatcher. Added new whistle player skill to distract NPCs, thanks to snatcher. Made more lights extinguishable and added info for 4 beta missions. Corrected container bottom fix messing up drawers, thanks Dragofer. Improved unlit behaviour of moveable light sources, thanks snatcher. Corrected lit lamps set to extinguished in maps, thanks to Dragofer. Changed western empire maps so the location of Bridgeport is vague. Added several major city names to the small map, thanks to Kukutoo. Fixed frobing animation not working with bound and carried entities. v1.6 23.07.2022 ---- Improved extinguishing oil lamps, thanks to Dragofer and Obsttorte. Added frobing animation, thanks to Obsttorte, Goldwell and snatcher. Fixed container bottoms and training mission chest, thanks Dragofer. Made doors open faster when running, thanks Obsttorte and snatcher. Added more player tools to training mission and improved text there. Fixed Holy Water doing no damage and Hazard Pay not starting at all. Made all five oil lamps in Sotha's "The Bakery Job" extinguishable. Added blow player skill to snuff out small flames, thanks snatcher. Changed Unarmed icon to make clear that the player always has a bow. v1.5 02.07.2022 ---- Created Invisibility Potion out of cut Speed Potion, thanks Kingsal. Increased arrow head shot damage to both living and undead enemies. Replaced slow matches with easier to handle flints, thanks Kingsal. v1.4 10.03.2022 ---- Replaced Frob Helper with dark Frob Outline and updated to TDM 2.10. Made electric mine stun elite guards too and improved mission names. Renamed mission installation/selection UI mishmash to "activation". v1.3 21.02.2021 ---- Changed flashmine to stunning electric mine and updated to TDM 2.09. Edited more mission names and made threefold candles extinguishable. v1.2 26.08.2020 ---- Updated to TDM 2.08 and fixed custom holywater script compatibility. Added Numbers Scroll showing stealth and loot info, thanks Dragofer. Edited more mission names to avoid truncated descriptions in menus. Added default keys info to training mission and repaired cut lines. v1.1 03.02.2019 ---- Moveable candles can be extinguished directly by frobing the candle. More blackjack immune enemies and inextinguishable candles modified. The key frob distance has been decreased to be that of lockpicking. Holy Water bottles must be thrown directly, but they do more damage. The controls settings menu additions have been updated for TDM 2.07. New mission names have been fixed to fix format and spacing issues. Added looking up and looking down controls for people without mouse. Pointed bad prefabs container open/close sounds to existing effects. Added version info to starting screen and edited some new missions. v1.0 06.05.2018 ---- Many enemies will not become immune to blackjacking when alerted. Oil lamps can be snuffed by frobing, thanks Destined and Obsttorte. The controls settings menu lists that "use" can work on held items. Mission names were syncronized between download and online lists. The controls settings menu lists that "frob" can get or drop items. Astericks were added to official missions to move them to list top. Minor text and format bugs have been fixed in some mission infos.

I notice that what Blender does is not lock or hide the mouse cursor, but allows it to move, then snaps it back to the other side of the window so you can drag infinitely in one direction. I.e. if you are dragging to the left, when the cursor reaches the left-hand window edge, it immediately re-appears at the right-hand window edge and continues moving to the left. I wonder if re-writing the code to use the Blender approach would solve the problem? Perhaps the back-end code can handle instantaneously changing the mouse pointer position more reliably than trying to lock it in place.

Complaint From Players The player must pick up candles before extinguishing them, and then the player must remember to drop the candle. The player must drag a body before shouldering it (picking it up), and the player must remember to frob again to stop dragging the body. The player finds this annoying or easy to make mistakes. For players who ghost, some of them have the goal of returning objects back to their original positions. With the current "pick up, use item, and drop" system, the item might not return easily or at all to its original position. For example, a candlestick might bounce off its holder. (See player quotes at the bottom.) Bug Tracker https://bugs.thedarkmod.com/view.php?id=6316 Problems to Solve How can the "pick up" step be eliminated so that the player can directly use or interact with the item where it is in the game world? How can so much key pressing and mouse clicking be eliminated when the player wants to directly use an item? How can candles be extinguished and lanterns toggled off/on without first picking them up? How can bodies be shouldered without first dragging them? Solution Design Goals Make TDM easier for new players while also improving it for longtime players. Reduce tedious steps for common frob interactions. Make it intuitive so that menu settings are unnecessary. Do not introduce bugs or break the game. Terms frob -- the frob button action happens instantly. hold frob -- the frob button is held for 200ms before the action happens. (This can be changed via cvar: 200ms by default.) Proposed Solution Note: Some issues have been struckthrough to show changes since the patch has been updated. Change how frobbing works for bodies, candles, and lanterns. For bodies: Frob to shoulder (pick up) a body. Second frob to drop shouldered body, while allowing frob on doors, switches, etc. Hold frob (key down) to start drag, continue to hold frob (key down) to drag body, and then release frob (key up) to stop dragging body. Also, a body can be dragged immediately by holding frob and moving the mouse. For candles/lanterns: Frob to extinguish candles and toggle off/on lanterns. Hold frob to pick it up, and then frob again to drop. Frob to pick it up, and then frob again to drop. Hold frob to extinguish candles and toggle off/on lanterns. For food: Frob to pick it up, and then frob again to drop. Hold frob to eat food. For other items: No change. New cvar "tdm_frobhold_delay", default:"200" The frob hold delay (in ms) before drag or extinguish. Set to 0 for TDM v2.11 (and prior) behavior. Solution Benefits Bodies: New players will have less to learn to get started moving knocked out guards. With TDM v2.11 and earlier, some players have played several missions before realizing that they could shoulder a body instead of dragging it long distances. Frob to shoulder body matches Thief, so longtime Thief players will find it familiar. Second frob drops a shouldered body. Players still have the ability to both shoulder and drag bodies. Compatible with the new auto-search bodies feature. Dragging feels more natural -- just grab, hold, and drop with a single button press. There is no longer the need to press the button twice. Also, it's no longer possible to walk away from a body while unintentionally dragging it. Set "tdm_frobhold_delay" cvar to delay of 0 to restore TDM v2.11 (and prior) behavior. Candles: New players will have less to learn to get started extinguishing candles. With TDM v2.11 and earlier, some players didn't know they could extinguish candles by picking them up and using them. Instead, they resorted to throwing them to extinguish them or hiding them. Hold frob to extinguish a candle feels like "pinching" it out. Once a candle is picked up, players still have the ability to manipulate and use them the same way they are used to in TDM v2.11 and earlier. For players who ghost and have the goal of putting objects back to their original positions, they'll have an easier time and not have to deal with candles popping off their holders when trying to place them back carefully. Set "tdm_frobhold_delay" cvar to delay of 0 to restore TDM v2.11 (and prior) behavior. Solution Issues Bodies: Frob does not drop a shouldered body, so that might be unexpected for new players. This is also different than Thief where a second frob will drop a body. "Use Inv. Item" or "Drop Inv. Item" drops the body. This is the same as TDM v2.11 and earlier. This is the price to pay for being able to frob (open/close) doors while shouldering a body. Patch was updated to drop body on second frob, while allowing frob on doors, switches, etc. Candles: Picking up a candle or lantern requires a slight delay, because the player must hold the frob button. The player might unintentionally extinguish a candle while moving it if they hold down frob. The player will need to learn that holding frob will extinguish the candle. The player can change the delay period via the "tdm_frobhold_delay" cvar. Also, when the cvar is set to a delay of 0, the behavior matches TDM v2.11 and earlier, meaning the player would have to first "Frob/Interact" to pick up the candle and then press "Use Inv. Item" to extinguish it. Some players might unintentionally extinguish a candle when they are trying to move it or pick it up. They need to make sure to hold frob to initiate moving the candle. When a candle is unlit, it will highlight but do nothing on frob. That might confuse players. However, the player will likely learn after extinguishing several candles that an unlit candle still highlights. It makes sense that an already-extinguished candle cannot be extinguished on frob. The official "Training Mission" might need to have its instructions updated to correctly guide the player through candle manipulation training. Updating the training mission to include the hold frob to extinguish would probably be helpful. Similar Solutions In Fallout 4, frob uses an item and long-press frob picks it up. Goldwell's mission, "Accountant 2: New In Town", has candles that extinguish on frob without the need of picking them up first. Snatcher's TDM Modpack includes a "Blow / Ignite" item that allows the player to blow out candles Wesp5's Unofficial Patch provides a way to directly extinguish movable candles by frobbing. Demonstration Videos Note: The last two videos don't quite demonstrate the latest patch anymore. But the gist is the same. This feature proposal is best experienced in game, but some demonstration videos are better than nothing. The following videos show either a clear improvement or that the player is not slowed down with the change in controls. For example, "long-press" sounds long, but it really isn't. Video: Body Shouldering and Dragging The purpose of this video is to show that frob to shoulder a body is fast and long-press frob to drag a body is fast enough and accurate. Video: Long-Press Frob to Pick Up Candle The purpose of this video is to show how the long-press frob to pick up a candle isn't really much slower than regular frob. Video: Frob to Extinguish The purpose of this video -- if a bit contrived -- is to show the efficiency and precision of this proposed feature. The task in the video was for the player to as quickly and accurately as possible extinguish candles and put them back in their original positions. On the left, TDM v2.11 is shown. The player has to highlight each candle, press "Frob/Interact" to pick up, press "Use Inv. Item" to extinguish, make sure the candle is back in place, and finally press "Frob/Interact" to drop the candle. The result shows mistakes and candles getting misplaced. On the right, the proposed feature is shown. The player frobs to extinguish the candles. The result shows no mistakes and candles are kept in their original positions. Special Thanks @Wellingtoncrab was instrumental in improving this feature during its early stages. We had many discussions covering varying scenarios, pros, and cons, and how it would affect the gameplay and player experience. Originally, I had a completely different solution that added a special "use modifier" keybinding. He suggested the frob to use and long-press frob to pick up mechanics. I coded it up, gave it a try, and found it to be too good. Without his feedback and patience, this feature wouldn't be as good as it is. Thank you, @Wellingtoncrab! And, of note, @Wellingtoncrab hasn't been able to try it in game yet, because I'm using Linux and can't compile a Windows build for him. So, if this feature isn't good, that's my fault. Code Patch I'll post the code patch in another post below this one so that folks who compile TDM themselves can give this proposal a try in game. And, if you do, I look forward to your feedback! Player Complaints TTLG (2023-01-10) Player 1: TDM Forums (2021-03-13) Player 2: Player 3: TDM Forums (2023-06-17) Player 4: TDM Discord (2021-05-18) Player 5: TDM Discord (2023-02-14) Player 6: Player 7: Player 8:

Why does it not crash on Windows though? Or is that code different there?

Ah, pity I wasn't reading the forums back in February. I'm fond of that game, along with Bugbear's other early title, Rally Trophy. I was never too good at FlatOut, but it was always a hoot to play.

Looking at the backtrace and the code, I think the culprit is here: https://github.com/codereader/DarkRadiant/blob/fa4c266a6776516b59740f78f57b849097d97618/radiant/ui/skin/SkinEditorTreeView.cpp#L44 The ThreadedDeclarationTreePopulator is created on the stack and thus deallocated at the end of the function. The EnsureStopped() function is called on deletion (https://github.com/codereader/DarkRadiant/blob/master/libs/wxutil/dataview/ThreadedResourceTreePopulator.cpp#L108) but this doesn't appear to actually wait for the deletion to finish. By the time the deletion request is processed, the object itself is no longer valid. Other usages I see put the object in a shared pointer instead of on the stack. I'll have a chance to look at this properly on Sunday and figure out the best way to fix it.

After some amount of work I'm happy to be able to share my Christmas gift for TDM! Or at least half of it, considering the other half is still only in design phase. I created an addon that implements detailed player functionality, inspired by the first DeusEx game (The Conspiracy). It's NOT a mission script but an addon, meaning you place the pk4 in your TDM directory to enable the system and it will automatically work in each and every FM. Note that due to using tdm_user_addons.script / user_addon_init() it may disable or get disabled by other addons you have installed... this is a design limitation which can hopefully be lifted at some point in the future. This plugin will be included in my cyberpunk total conversion The Dark Module and automatically active with it, but first I shall design it and make it available as a small independent addon for vanilla TDM. In the current initial release it implements just per-limb damage; The upcoming plan is to add a skill / augmentation system, allowing the player to use loot as skill points to enhance various body parts and gain new or improved abilities. Due to the scripting system being very limited in what it lets me modify, I'm still gathering documentation on how to implement those skills and which I can have. So until then detailed body damage with penalties remains the only part that's theoretically finished so far (further improvements are required here too)... including a HUD component above the lightgem showing the status of each body part: Green = full health, yellow = half health, red = (close to) no health, black = no health left. The individual limbs available: Head, Torso, Left Arm, Right Arm, Left Leg, Right Leg... arms and legs work in unity however. They each take damage with the player as well as healing together with them. The more damaged a group is, the more a respective penalty is applied to the player. Groups and penalties include: Head: When the head is damaged, the player begins to get dizzy and has their vision impaired. Currently the only effect replicates the flashbomb, causing white dots to appear around the player and disrupt their view until the head is healed. As the player can't live without a head, reaching 0 will cause instant death. More effects are possible and pending. Torso: Damage to the torso translates to damage to the cloak, increasing the player's lightgem and rendering them more visible even in dark spots. As the player can't live without a torso, reaching 0 will cause instant death. Given script limitations I'm unable to simulate lung damage and decrease / limit the amount of air the player has. Arms: Arm damage makes it difficult for the player to hold items: In-world objects being held will probabilistically get dropped, more often the worse your arms are hurt. When both arms reach 0 health, the player can no longer pick up anything in the world without instantly dropping it... you also become unable to use any weapons. Due to limitations in the scripting system, I'm unable to decrease the speed or accuracy of the blackjack / sword / bow as was desired. Legs: As expected leg damage will make the player walk more slowly. It was desired that when one leg is lost the player can no longer jump, whereas when both legs are gone you remain stuck in crouch mode until healed... due to limitations in the scripting system this part is also not possible at the moment. A crude limitation is the fact that limb damage is primarily based on the direction the player is walking toward... for example, increased likelihood of suffering damage to your right arm and leg if strafing right the moment you take the damage. The script system doesn't let you extract the vector direction of the last damage event, thus I can't use the real direction the hit came from when calculating which body part should absorb the most health loss. This means that even if an arrow comes from above and hits the player's head area, the player will only take damage to the legs if they're falling downward the moment they got hit... for the time being this provides a bare minimum amount of realism but is a very bitter implementation. For this reason it would be greatly appreciated if any of the code developers could join this discussion and verify if they can help with adding the necessary hooks to external scripts: With 2.09 getting periodic beta releases at this point in time, it would be a great opportunity to make changes to the builtin player script that allow an external function to modify more player variables. This includes the efficiency of weapons, if the player is allowed to jump or forced to always crouch, and I'd also really appreciate a hook to manipulate the breath so air can be lowered as if the player is underwater. I understand other priorities exist or if the work may be considered too much, however this would help in being able to finish this mod with the proper functionality and planned skill set. In the meantime let me know what you think of this idea and how I went about it! So far no new assets are included except the GUI graphics: Everything is done with less than 250 lines of script which I'd say is a good achievement I've attached the pk4 and since it's so lightweight I'll also add the main script straight in this post. player_damage_1.0.pk4 #define DAMAGE_WAIT 0.0166667 #define EXPOSURE_ARM_LEFT 2 #define EXPOSURE_ARM_RIGHT 2 #define EXPOSURE_LEG_LEFT 2 #define EXPOSURE_LEG_RIGHT 2 #define EXPOSURE_HEAD 3 #define EXPOSURE_TORSO 1 #define PENALTY_TORSO_LIGHTGEM 4 player self; float damage_gui; boolean dizzy; entity dizzy_particles; float bound(float val, float min, float max) { if(val < min) return min; if(val > max) return max; return val; } // Range based probability: Calculates a probability per frame independent of wait time (0 - 1 range at 1 chance per second) boolean prob(float x) { return sys.random(1) > x && sys.random(1) < DAMAGE_WAIT; } // Directional exposure calculator float dex(vector dir, float ex_front, float ex_back, float ex_right, float ex_left, float ex_up, float ex_down) { float maxvel = 100; float dir_front = bound(dir_x / maxvel, 0, 1) * ex_front; float dir_back = bound(-dir_x / maxvel, 0, 1) * ex_back; float dir_right = bound(dir_y / maxvel, 0, 1) * ex_right; float dir_left = bound(-dir_y / maxvel, 0, 1) * ex_left; float dir_up = bound(dir_z / maxvel, 0, 1) * ex_up; float dir_down = bound(-dir_z / maxvel, 0, 1) * ex_down; return dir_front + dir_back + dir_right + dir_left + dir_up + dir_down; } void player_damage_update_arm(float dmg_l, float dmg_r) { float hl_l = self.getFloatKey("health_arm_left"); float hl_r = self.getFloatKey("health_arm_right"); float hl = (hl_l + hl_r) / 2; if(dmg_l != 0 || dmg_r != 0) { hl_l = bound(hl_l - dmg_l, 0, 1); hl_r = bound(hl_r - dmg_r, 0, 1); hl = (hl_l + hl_r) / 2; self.setKey("health_arm_left", hl_l); self.setKey("health_arm_right", hl_r); self.setGuiFloat(damage_gui, "PlayerDamage_ItemArmLeft", hl_l); self.setGuiFloat(damage_gui, "PlayerDamage_ItemArmRight", hl_r); // Penalty #1: Disable the weapon once the arm are damaged to minimum health if(hl == 0) { self.selectWeapon(WEAPON_UNARMED); self.disableWeapon(); } else { self.enableWeapon(); } } // Penalty #2: Probabilistically drop held items based on arm damage if(hl == 0 || prob(hl)) if(self.heldEntity() != $null_entity) self.holdEntity($null_entity); } void player_damage_update_leg(float dmg_l, float dmg_r) { float hl_l = self.getFloatKey("health_leg_left"); float hl_r = self.getFloatKey("health_leg_right"); float hl = (hl_l + hl_r) / 2; if(dmg_l != 0 || dmg_r != 0) { hl_l = bound(hl_l - dmg_l, 0, 1); hl_r = bound(hl_r - dmg_r, 0, 1); hl = (hl_l + hl_r) / 2; self.setKey("health_leg_left", hl_l); self.setKey("health_leg_right", hl_r); self.setGuiFloat(damage_gui, "PlayerDamage_ItemLegLeft", hl_l); self.setGuiFloat(damage_gui, "PlayerDamage_ItemLegRight", hl_r); // #Penalty #1: Make movement slower self.setHinderance("health", 0.25 + hl * 0.75, 1); } } void player_damage_update_head(float dmg) { float hl = self.getFloatKey("health_head"); float time_current = sys.getTime(); if(dmg != 0) { hl = bound(hl - dmg, 0, 1); self.setKey("health_head", hl); self.setGuiFloat(damage_gui, "PlayerDamage_ItemHead", hl); // Penalty #1: Without a head the player dies if(hl == 0) self.damage(self, self, self.getOrigin(), "damage_suicide", 1); // Penalty #2: Simulate dizzyness starting at half health if(hl <= 0.5) { if(!dizzy) { dizzy_particles = sys.spawn("func_emitter"); dizzy_particles.setModel("flashbomb.prt"); dizzy_particles.setOrigin(self.getEyePos()); dizzy_particles.bind(self); dizzy = true; } } else { if(dizzy) { dizzy_particles.remove(); dizzy = false; } } } } void player_damage_update_torso(float dmg) { float hl = self.getFloatKey("health_torso"); if(dmg != 0) { hl = bound(hl - dmg, 0, 1); self.setKey("health_torso", hl); self.setGuiFloat(damage_gui, "PlayerDamage_ItemTorso", hl); // Penalty #1: Without a torso the player dies if(hl == 0) self.damage(self, self, self.getOrigin(), "damage_suicide", 1); // Penalty #2: Torso damage negatively affects the lightgem self.setLightgemModifier("damage", (1 - hl) * PENALTY_TORSO_LIGHTGEM); } } void player_damage() { sys.waitFrame(); self = $player1; damage_gui = self.createOverlay("guis/player_damage.gui", 1); float health_old = 100; // Init by sending a heal event filling the limbs to full health player_damage_update_arm(-1, -1); player_damage_update_leg(-1, -1); player_damage_update_head(-1); player_damage_update_torso(-1); while(1) { // sys.waitFrame(); sys.wait(DAMAGE_WAIT); float health_current = self.getHealth(); float dmg = (health_old - health_current) / 100; float dmg_arm_left = dmg * EXPOSURE_ARM_LEFT; float dmg_arm_right = dmg * EXPOSURE_ARM_RIGHT; float dmg_leg_left = dmg * EXPOSURE_LEG_LEFT; float dmg_leg_right = dmg * EXPOSURE_LEG_RIGHT; float dmg_head = dmg * EXPOSURE_HEAD; float dmg_torso = dmg * EXPOSURE_TORSO; // If this is damage and not healing, apply directional damage to each limb if(dmg > 0) { // Currently we estimate damage direction based on the player's velocity, we should fetch the real direction of a damage event when this becomes possible vector dir = self.getMove(); vector ang = self.getViewAngles(); // Protections based on the player's position and relation to the environment // protection_look: 1 when looking up, 0 when looking down // protection_low: Higher as the lower part of the body is exposed float protection_look = 1 - (90 + ang_x) / 180; float protection_low = 1; if(self.AI_CROUCH) protection_low = 0; else if(self.AI_ONGROUND) protection_low = 0.75; // Use the dex function to calculate directional exposure patterns, direction order: Front, back, right, left, up, down // Arms: Somewhat likely to be hit, no added protection // Legs: Somewhat likely to be hit, added protection when the player is crouching // Head: Unlikely to be hit, added protection when the player is looking down // Torso: Likely to be hit, no added protection float exposure_arm_left = bound(sys.random(0.375) + dex(dir, 0.5, 0.25, 0.0, 1.0, 0.0, 0.25), 0, 1); float exposure_arm_right = bound(sys.random(0.375) + dex(dir, 0.5, 0.25, 1.0, 0.0, 0.0, 0.25), 0, 1); float exposure_leg_left = bound(sys.random(0.375) + dex(dir, 0.75, 0.5, 0.0, 0.5, 0.0, 1.0) * protection_low, 0, 1); float exposure_leg_right = bound(sys.random(0.375) + dex(dir, 0.75, 0.5, 0.5, 0.0, 0.0, 1.0) * protection_low, 0, 1); float exposure_head = bound(sys.random(0.25) + dex(dir, 0.25, 0.75, 0.5, 0.5, 1.0, 0.0) * protection_look, 0, 1); float exposure_torso = bound(sys.random(0.5) + dex(dir, 0.75, 1.0, 0.0, 0.0, 0.0, 0.0), 0, 1); // Apply the exposure to damage, multiplied to simulate the sensitivity / resistance of each limb dmg_arm_left = exposure_arm_left * dmg * EXPOSURE_ARM_LEFT; dmg_arm_right = exposure_arm_right * dmg * EXPOSURE_ARM_RIGHT; dmg_leg_left = exposure_leg_left * dmg * EXPOSURE_LEG_LEFT; dmg_leg_right = exposure_leg_right * dmg * EXPOSURE_LEG_RIGHT; dmg_head = exposure_head * dmg * EXPOSURE_HEAD; dmg_torso = exposure_torso * dmg * EXPOSURE_TORSO; } player_damage_update_arm(dmg_arm_left, dmg_arm_right); player_damage_update_leg(dmg_leg_left, dmg_leg_right); player_damage_update_head(dmg_head); player_damage_update_torso(dmg_torso); health_old = health_current; } }

When talking about a possible libre version of TDM (https://forums.thedarkmod.com/index.php?/topic/22346-libre-version-of-tdm/) it seems we believe all media/gamedata included in TDM is licensed CC-BY-NC-SA. I am not familiar with how the process of adding new media/gamedata works today; I have seen files uploaded to the bugtracker which developers then commit to SVN, but I don't know if there are other ways. It may be a good idea to implement a process that when new components (media/gamedata included in TDM) are added, the contributor is asked to be explicit about the license (a choice which may defaults to their previous preference, for usability). It won't fix the past, but it may help in the future. This will make it easy for contributors to add future data under a more permissive license if they choose. Libre media can be added and its license can be tracked, rather than assumed to be CC-BY-NC-SA. I suggest looking at how Wikimedia Commons has implemented this: the contributor state the source and license at the time the data is uploaded. This can be done either by providing urls or by saying "It's my work and I choose this licsense". The first step could be to add a way to keep track of each filepath in SVN, author, license, sources. Start by setting the value for each file's license to "(default/legacy CC-BY-NC-SA)". Possible implementations for a user interface for new additions are: * Use our own wiki, which runs Mediawiki (same as Wikimedia Commons). I see several benefits of this, but we also need a way to accept uploads of batches, not just single files. * Look at how other open source projects have solved this. There may be more appropriate solutions available. ... but I'll leave the implementation open. Suggestions are very welcome! If the author of each file already in SVN can be tracked, then it may be possible that the author is willing to give a blanket permission for all their past files in one statement, and all their files in SVN can be updated in one commit. A productive contributor willing to release some of their work under a more permissive license could make a big change. If Dark Radiant would support letting mappers search media/gamedata by license (does it already?), it would make it easier for mappers to create a completely libre mission, which would help facilitate a TDM-libre release. If I understand things correctly. This post does not address all details and it may contain misunderstandings or assumptions, but it's a start. Also relevant: * Is there a compiled and maintained list of recommended or deprecated resources for mappers to use? * https://forums.thedarkmod.com/index.php?/topic/20311-external-art-assets-licensing/

All speakers are defined as spheres, with a customisable inner and outer radius. There is no way to change them into any other shape. Implementing support for rectangular speakers would need changes to the core game code.

Cheers! I've been wondering for some time now if it would be possible to compile the source code of TDM to the Raspberry Pi, especially the models 3 and 4. I've seen some videos online of people running Doom3 on it, so how hard would it be to compile the source of TDM for the raspberry pi? Would it need a major rewrite of some parts of the code? I've been "tinkering" with the source for some days, and as I was expecting, all the configuration files are made for x86 architectures (Linux and Windows). I've been searching online for some info about the toolchains needed to even start compiling the source for these arm machines, but the information has been quite lackluster and outdated. I've managed to track down a toolchain to compile c++ code for the raspberry pi, made by the pi foundation but I'm not quite sure how to use it and I guess the support for it has been dropped for quite some time now. Anyway, I figured that instead of wasting more of my time, it would be best to ask here what you guys think. Is it possible to even think about this, or does TDM use some kind of libraries or other external code which makes it impossible to compile for the pi? Is there anything related to the game that makes almost impossible or too much of a hassle to try to port the game for the raspberry pi? Performance isn't an issue for me. I just want to know if it can be run in that machine. If it is possible to do this without a major code rewrite of the game, where should I start? I have no experience on compiling anything for arm, only some experience in x86, so this might be a fool's errand, but I would like to give it a try nonetheless. If it is possible to do this and if some of you could help me in any way, that would be appreciated. On the other hand, if you think this is a really hard thing to even try to do, please feel free to tell me so I don't waste more of my time. Thanks in advance

No I mean you licence (for money) those modules for others to use in their game. But they don't own it. What fits the genre best is if someone would steal your code. Bad for you but good for thief.

Haha good try, i am glad people cant figure it out. I dont want my code to be sold to other people. I want to profit from it big time. That means if i dont find a solution for this project, it will go under forever. Ofc i will take the award as best thief clone anyways. Thats the reality of this genre.

There's a cool trick that is making what you have on your "hand", very small, or at lest smaller enough to not get out of the player collision mesh, so it can never reach a wall, the player collider prevents it. And then move the object very near the camera "lens" and it will look big and normal despite the small size, is a nice trick that I learned a few fps games use. But I don't think is the one idTech 4 uses... Unfortunately I don't recall what that trick/hack is anymore, I just remember something about the engine code having what idSoftware called "weapon hack", probably just looking at the engine code and searching for weapon hack, will give some results, thou like I said, right now, I don't recall how it is used.

As far as I see in the code, minDistance/maxDistance specify the range in meters where volume falloff happens. Let's introduce F(d) as piecewise linear function. Then: F(0) = F(minDistance) = 1 F(maxDistance) = F(+infinity) = 0 F(d) changes linearly from minDistance to maxDistance The sound gain is multiplied by F(d)^2 (i.e. falloff is turned quadratic). If we talk about real physics, the falloff from point sound should linear without any caps. The gain should be multiplied by (1 / d). However, real sound sources are never perfectly concentrated at a point. If a sound source has size S, then the volume at distances up to O(S) will look like constant. I suppose default minDistance is nonzero to replicate this effect. The existence of maxDistance is harder to justify physically. Perhaps it is here for optimization reasons (don't process sounds farther than this). As for quadratic falloff instead of linear, I think the simply wanted the sound to fade away to zero smoothly.