Search the Community

Well, leaving aside the snark of the last post, note that nobody has to install wesp5's patch, so, nobody is forced to be fine with the changes to the ingame maps he made. I agree though that it's a different universe, thus "France" isn't full of Frenchies.

From what I could tell, ai_should_not_handle prevents the AI from ever trying to open the door and prevents it from considering the area behind it traversible, so long as the door remains closed. If it's ever opened (by the player) they are then able to pathfind through it. Monsterclip would be a permanent invisible wall for them, even if the door were opened. Based on my last round of tests, even when alerted they couldn't open the door or go through it. There was some odd behaviour where they milled around in front of the door as though they wanted to go through it, but they never actually tried.

Alright, I've done it. And then probably went overboard. I was able to disconnect all of the volta-named bits from the entities and rename or repoint everything to assets that ship with TDM. The results don't look quite as cool, but I still was able to make a destructable crate with flindery bits, particle effects, and smashing sounds. Hooray! I then discovered that changing the model required whatever new model I chose to also have a clip model. So there was no way to get around making clip models in darkRadiant for whatever things I wanted to be smashable. I went ahead and made really basic (cubes or 6-sided prism) clip models for all the junky broken down wooden objects I could find in the TDM assets, most of which were missing, and used those to create breakable versions of those models. Funny enough, this approach worked for everything except the original door that I wanted to make breakable in the first screenshot of this post! There is something funny about the collision geometry of models/darkmod/architecture/doors/oversized/old_door_02.lwo . If I used it as an entity model, the map complained about not having a collision model. But if I added a simple box as a collision model, the box didn't get used! I was able to shoot arrows and walk straight through this broken down "door". So my original chain-of-random-entities solution that doesn't make flinders is probably as good as we'll be able to get from the door. I also used this solution to try to recreate breakable banners from TG and T2, and they work pretty well. They should probably have a "torn" version that hangs from the banner rod instead of the whole banner and rod disappearing entirely, but they will serve the gameplay purpose of being able to hide safes/secret passages behind banners well enough for me. Coming back to flinderable entities, I realized I could probably tweak the entity definition to also make breakable ceramic pots, so I made some of those too. I ended up with ~25 prefab objects that you can smash with the sword or detonate with fire arrows - some are small enough to be picked up, but the bigger ones can only be pushed or are completely stationary. I tried to pick reasonable health values for them based on their size and apparent sturdiness. All of these can be used as obstacles to block doors or secrets. I've uploaded a .pk4 that contains a simple test map, the entity definitions, and the prefabs. Feel free to download, rip 'em out, and use 'em! If there are any good candidates for smashable-looking crap that I missed or any feedback on how I could make these better, let me know. If @kingsalis cool with it (...because I basically copied his homework for the scripting), I would also support making these entity definitions, collision models, and prefabs part of TDM's core, and would be willing to make whatever tweaks we think are good to help make that happen. breakable_prefabs.pk4

It kinda depends on original D3 object/inheritance structure vs. what is in TDM. If I remember correctly, TDM got this structure kinda backwards. In other engines it was usually Light > Light type (e.g. spotlight) > light with model attached. I tried this in DR long time ago, and the light was visible and editable as any other light. In TDM it's Model > Model with light attached, with light being not editable. I remember there were some fixes planned to address that, and maybe that broke something?

I see a light leak through this shelf in the Objects And Handling section, but only when using stencil shadows: When using shadow maps instead, the light doesn't leak through the shelf anymore: Also notice the odd lighting under the bed on the left. It seems the wooden frame is the only part of these beds that casts shadows, so light goes right through the blankets, mattresses, and pillows. ALSO also, the keys in the Keys And Lockpicks section have funny collision when I "drop" them from my inventory and hold them. If I jump while holding one of those keys below me I can hover and fly around on them. This doesn't happen with the Guard Post Key found in the Stealth And Shadows section, so it seems some but not all of the keys in the mission have this physics issue. I'm running TDM 2.13 on Windows 10. Nitpicks aside, I very much appreciate the new equipment tutorials and lighting effects from the recent update, well done!

MLID is teasing that there may be something impressive coming at the top of the stack but I can't imagine what it could be other than what I mentioned. I will post the video when it's out. As for me, I'm more interested to see what happens at the low-end with a potential 9050, 9040, etc. There's also renewed talk of a 7300/7400: https://videocardz.com/pixel/aida64-adds-support-for-radeon-rx-7300-rdna3-gpu With AMD's lowest-end dies having 32 CUs, it would be easy to make a budget card that is more impressive than the RX 6400 and RX 6500 XT (Navi 24 had 16 CUs). The Radeon Pro W7500 proves that they can make a good ≤75W card with 8 GB as well.

A Critical Look at MCP - Raz Blog i'm dropping one post related to AI here..

That is very surprising, idDebris imo was a very useful entity, not only for projectiles, thou this "flinder" class apart from the physics seems to be the same thing, thou I was unfamiliar with that word. Also probably idDebrie add code that couldn't be transferred to standalone TDM or something. I would love to give better help because I do think more destructibility for TDM objects would be cool, but unfortunately I did that stuff so long ago that I totally forgot how I disabled the physics. I went to look at the Doom 3 idDebris c++ code and saw nothing directly that says "disable physics" but I did saw something in Entity.cpp, a function called RunPhysics() that is also called by idDebrie class, and on there, I saw a particular entity flag, one called "fl.solidForTeam", that sounds like it controls physics for entities in the same "team" and that is probably what I used. So I imagine that there's a way to negate this flag through scripting? try writing a entity spawnarg "solidForTeam 0" on the flinder objects in the editor.

Thanks! I thought they were pretty fun. I haven't looked at those powder kegs in a long time, but it might be worth re making them someday. I remember them being fun to light with the flint and then tossing them on bad guys heads. @chumbucket91The powderkegs in volta 2 also use the flinder system but I think its a very different set up from the crates in volta 3. Might be useful in your search though.

@JackFarmer Here some more screenshots of things I encountered that could be improved: See this post for the previous ones. I also noticed a lot of console errors including a bunch about incorrect efx range.

Thank you. If you want, you can also share your post in this music resource thread I started a while back. I think it would fit nicely.

I might still have to add one for radio_static.ogg (the numbers). Edit: Are these the correct numbers? Edit 2: I think after finishing, this isn't important info for the mission, right? I'm still playing the mission, so I will post them after. Nice!

Moved to this thread. There are lots of complaints about UE5 performance. Oblivion Remastered may be a worse example than usual (there is another title that did a UE5 on top of other engine approach, but I forgot what it is), but it's only the latest. Budget PC gamers have benefited from industry hardware/software stagnation (PS4 era games became trivial to run). We are still a far cry from the fast-paced 90s when your shiny new 3D accelerator could be completely obsolete within a year or two, but things are picking up a little. What we're learning is that we tend to need moar than 8 GB of VRAM, with 16 GB presumably having no issues given that current-gen consoles are locked in at 16 GB GDDR6 max. We can blame lazy developers for this if we are being uncharitable. Aside from that, you can't count on being able to do 4K or ray tracing (on low-end like 7600 XT 16 GB), but if you have little interest in newer games, that's probably fine. AMD is bringing some heat with several 16 GB options, but hasn't bothered with a 192-bit die, and won't be able to do some of the exotic memory configurations Nvidia can using 3 GB GDDR7 modules (GDDR6 is limited to 2 GB). Intel's 10-12 GB Battlemage cards are a no-show. AMD's 9060 XT 16 GB could be impacted by tariffs. We'll be lucky to see it under $350. I think next-gen could be more interesting with hopefully better market conditions, Nvidia using a new node (Blackwell 4nm = Lovelace 4nm), and all competitors using GDDR7, allowing 12 GB on 128-bit, 18 GB on 192-bit, etc. APUs are becoming a good option, giving you "unlimited VRAM" and decent performance. AMD only has Phoenix APUs on the desktop socket but might launch Strix Point by the end of the year. These should be generally sufficient for 1080p. Mobile-on-desktop soldered products are looking good and coming out long before the desktop APUs. AMD's Strix Halo is theoretically interesting, but in practice it's expensive and positioned more for AI than gaming. It just doesn't matter to the budget-conscious right now. If you don't care about the latest games, you're good to go. I've hardly played anything other than Thief and TDM lately. I do want to push TDM to higher resolutions though, and perhaps see ray tracing land in the engine in the future.

Look right above your post.

idTech4 engine has used on Doom 3 already had a destructible entity system for the destructible barrels, was that removed? In Doom3 you can create debris entities and they become physics entities, never heard of this "flinder" stuff so I assume is a new TDM entity type. Don't know if this is useful for TDM, if not ignore, but who knows could give some hints. This was how I created a simple destructible wood barrel in Doom 3 engine. First I defined the broken debris peace's: (yes they are individual entities and models) entityDef debris_woodbarrel_1 { "spawnclass" "idDebris" "mins" "-3 -3 -3" "maxs" "3 3 3" "model" "models/maps/temple/mapobj/pipo broken/pipo_debri_1.lwo" //"skin" "skins/exp_barrel_red" "health" "0" // amount of damage projectile can take if damaged (0 means it can't be destroyed) "velocity" "1 1 450" // how fast the projectile leaves the gun (or distance if fuse is 0) "random_velocity" "1" "angular_velocity" "105 215 10" // how the projectile is rotating when it leaves the gun "thrust" "0" // the rate of acceleration (always in the direction of the projectiles model) "thrust_start" "0" // when to start accelerating "thrust_end" "0" // when to stop accelerating "linear_friction" "1.0" // "air" friction "angular_friction" "0.1" "contact_friction" "0.9" "bounce" "0.1" // how much speed a projectile retains when it bounces off of objects (coefficient of restitution). 0 means no bounce. "mass" "50" "gravity" "1066" // how much gravity affects the trajectory. gravity direction is same as the entity that fired it. "fuse" "10" // how long before the projectile is removed or self-detonates. Use 0 for beam weapons (velocity == distance). "detonate_on_fuse" "1" // whether projectile should detonate when it's fuse runs out "detonate_on_death" "0" // whether projectile should detonate when it's "killed" (health runs out) "detonate_on_world" "0" // whether projectile should detonate when it hits an obstacle "detonate_on_actor" "0" // whether projectile should detonate when it hits a character in the game "smoke_fly" "debristrail.prt" // particle effect while in the air "snd_bounce" "tray_impact" // parametric particles -- temp "model_detonate" "" "smoke_detonate" "" // particle effect when detonates "smoke_fuse" "" "smoke_bounce" "" } entityDef debris_woodbarrel_2 { ... } etc, then I define the main entity: entityDef moveable_woodbarrel { "editor_color" "0 .5 .8" "editor_mins" "-16 -16 0" "editor_maxs" "16 16 48" "editor_rotatable" "1" "editor_usage" "Moveable woodbarrel. Works just like a func_moveable. However the barrel" "editor_usage1" "has special handling to make it appear more round. This version also explodes when damaged enough." "editor_usage2" "Only add model, model_detonate or model_burn or health to override defaults" "editor_var burn" "number of seconds to burn before exploding." "editor_model model_damage" "model to leave as damaged base" "editor_model model_detonate" "ips model to switch to for explosion." "editor_model model_burn" "ips model to show when on fire." "editor_var def_debris" "add as many as you like, debris1, debris2, etc.. " "editor_var health" "how much health the barrel has, default is 5. If burn is set to 1, the health is effectively doubled so you have to kill it twice to get the explosion" "editor_var respawn" "if non zero the number of seconds to respawn after killed" "editor_var respawn_range" "no player in distance range to actually respawn - default 256" "editor_var respawn_again" "try again in seconds if player in range - default 10" "editor_var triggerTargets" "if set to 1 will trigger targets after being killed" "editor_mat mtr_lightExplode" "light shader to use for explosion" "editor_mat mtr_lightBurn" "light shader to use for burning" "spawnclass" "idExplodingBarrel" "density" "0.02" "friction" "0.2" "bouncyness" "0.4" "def_splash_damage" "damage_moverCrush" "ignore_player" "1" "model" "models/maps/temple/mapobj/pipo.lwo" "def_debris" "debris_woodbarrel_1" "def_debris1" "debris_woodbarrel_2" "def_debris2" "debris_woodbarrel_3" "def_debris3" "debris_woodbarrel_4" "def_debris4" "debris_woodbarrel_5" "def_debris5" "debris_woodbarrel_6" "def_debris6" "debris_woodbarrel_7" "def_debris7" "debris_woodbarrel_8" "def_debris8" "debris_woodbarrel_9" "health" "35" "snd_explode" "wood_barrel_breaking" "snd_bounce" "woodimpact" } This was the effect: https://drive.google.com/file/d/1lsXwNssxp-QO3MZKOmUiBd1DWhd0V7HY/view?usp=sharing Hope this helps.

At long last there is also an accompanying Wiki article here: https://wiki.thedarkmod.com/index.php?title=Turret, complementing the info that was found in spawnarg tooltips and entity and prefab descriptions.

I have a working setup of a destroyable 3D objects in the form of the camgoyle, security cameras and the turret. I've extended the flinderize system for these entity types, but the basic components that should work on any static entity type are: A health spawnarg, so that the entity knows when to break. By default it'll be vulnerable to sword attacks, broadheads, fire arrows and fast-moving moveables. A "broken" spawnarg, which defines the model to switch to when the entity is broken. The flinder spawnargs shown above. The damage detection on a func_static is simple. For example, a fire arrow's splash damage is always 30 as long as the entity was within the splash radius, and you can't disable certain damage types. I don't recall a general-purpose entity type that offers better control atm, but technically you could turn your door into a disabled security camera if you wanted to make use of all of the damage spawnargs described on this wiki page, but you'd need to assign a simple collision mesh to the door.

I've always wondered: who are these people who record all these noises/sounds for freesound.org? And now one of them is here, thus, thank you for contributing there as well! If you need help when it comes to mission building with Dark Radiant, you can post your question(s) here.

I listened to Palingenesis, and it definitely sounds like a track you would hear in a TDM mission. Well done. Clicked on "On The Edge Of Dawn" and it sent me straight to the second track, "Dawn Fades". It's good but may be a bit busy/loud by TDM standards. YMMV. I'd like to use this thread to point out that T1/T2 made use of short ambient loops, repeated, mixed up, and layered. This was probably due to technical limitations, but it can contribute to the hypnotic feel of the soundtrack, and isn't often replicated by the usual completed tracks we hear now. I don't know if any TDM mappers have taken this approach, but boiling down ambients to their smallest components might be a good idea from a creative standpoint. For example, I downloaded Thief 2 to this computer. Ambients are in RES/snd.crf/SFX. You can open it with 7zip, sort by size or name, and start loading them in your media player without extracting. One iconic mission, Framed, uses these: m04ring (36s) S0400 (24s) m04lo (23s) s0401 through s0407end in snd.crd/MiscVOs/english Some areas in missions are only/primarily playing a short loop in the background, such as: voicel1 (13s) SUBSON1 (4s) m01drone (~1s) Lhouse (4s) L7baseM (4s) L2_base1 (6s) voxloop2 (4s) brassL (6s) Some sounds may be played randomly (not sure), such as FB1 through fb10. The largest file, swells2.wav, is used in Shipping and Receiving and another mission, and it's still only 44 seconds long. Another fun thing are the "twangs", "openers" or whatever you would call them, that only play at the very beginning of the mission. There are two main ones in Thief 2: ambstart.wav (6s) BELLTHMP (6s) I think there's a third variation, might only be in Dark Project My point in bringing all this up is that to get that Dark Project/Metal Age feel, maybe we need to go back to the basics.

After doing a bit more homework and poking around, I've discovered that the answers to (2) and (3) are "make your own prefab", and a prerequisite for doing that is "make a proper project folder for your map, in which you can place a prefabs/ subfolder", which is a thing that I should have done anyways before I spent several hours making a wooden shack for players to break into, and also a long winding forest path up to said shack. So the only real question I have now is (1) - is there any sort of entity multi-spawner for chunks of physics objects that I can use for wooden flinder.

And some info can be found on this forum topics and wiki. Wiki article: https://wiki.thedarkmod.com/index.php?title=Parallax_mapping Topic: https://forums.thedarkmod.com/index.php?/topic/22574-experimental-support-of-parallax-mapping-in-213/

Are you using an old version of the fm, or the newest version? If you use the newest version, you should not get a crash (in Linux). I just post this to make sure that you didn't miss that nbohr1more just fixed the mission and uploaded it to the database.

Changelog of 2.14 development: dev17330-10984 * Tonemapping is now applied to game frame only, HUD and menu are not affected. Includes major & breaking changes in X-ray implementation (6606). * Now engine defines macros TDM_VERSION/TDM_REVISION/TDM_VERSION_FULL in game scripts and GUI. * Added all missing mipmaps in DDS textures (post). * Fixed crash from having many localization packs (6611). * Fixed comments parsing and automatic collision model for OBJ models (6610). * Ported some fixes from dhewm3 repo: save/load, snprintf, bad memset, some RenderSystem shutdown fixes. * Fixed number = 1 in inventory GUI on non-stackable items (thread). * More fixes in fonts (post). * Added cvar r_ssao_insubview which enables SSAO inside subviews. * Split oversized tdm_modelsXX.pk4 packages into more pieces. dev17332-10999 * Fixed Linux crash when material with custom shader is loaded during gameplay (6510). * Completely disabled old light estimate system (6546). * Now it is possible to use larger mesh models... at least static ones. * Ported some more fixes from dhewm3 repo: mostly warnings and uninitialized memory use.