Search the Community

Hmm quite a bit of choices but yah nvidias bungle with gamers nexus was a mess. I doubt they will score many points even if the 5060 cards do deliver. Whats up with them going bananas on pcie speed ?, in less than 5 years we went from pcie 3 to pcie 5 it is kinda weird when you think about it cause the difference from pcie 3 to pcie 4 ment about 1 fps difference and the same from pcie 2 to pcie 3. Did gpus suddenly develop the need for such drastic bus speeds ?. Tbh i use a pcie 4 card in one of my older pcie 3 boards and it actually does better in it than any pcie 4 boards i could get measurements of . I also had a hunch that a modern card like the 5000 series might not do to well on a core 2 , sure it can run windows 10 and some core 2 models were pretty fast back in the day, but support for many more modern simd features would hold back any card newer than say a geforce 970 and even that might be a stretch.

This is not true. Headshots normally only have a damage multiplier which sometimes is not enough, so I increased it in my Unofficial Patch. Points 1-3 would require new models and animations and thus are not worth the effort. I believe 4 and 6 is being worked on and I don't even know what you mean by 7. You don't want to know when new missions are available for download or you don't want to know about new mission objectives?

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

You might be missing the skin file. yourfm/skins/volta_containers.skin Yeah that's the downside of objects like this that have a lot of associated files. Those crates have: -volta_breakable_crate.def -volta_breakable_crate.script -volta_crate_break.prt (this is the particle that spawns) volta_fx.mtr -----> textures/darkmod/volta/crate_debris01 dds\textures\darkmod\volta_fx\ crate_debris01.dds - volta_containers.skin -All the flinders in \models\volta\crate - volta_containers.mtr models/darkmod/props/textures/crate01_d_breakable models/darkmod/props/textures/crate01_local models/darkmod/props/textures/crate01_s_breakable I think that's it. Hope this helps.

Yes, that's just a func_static with a "model" key set to the entity name, which means it's brushwork converted to a func_static (so DR just renders the brushes). My guess is that DoomEdit does something specific when you "connect" a model and a light, which we're not doing in the same way. I thought that all that "connect" did was set a target key to point to another entity. Maybe it's supposed to have special handling for models and lights.

At a first glance, the model field points to a model name, while it should be a model path, e.g. models/etc/modelName.lwo Edit: oh, that could be a brush converted to a model, that's why it has model name in both fields. Maybe that's the issue?

I can confirm the material and image file are present in core. Material: textures/darkmod/wood/boards/tdm_crate04 { wood diffusemap models/darkmod/props/textures/crate04 // bumpmap models/darkmod/props/textures/crate04_local } I wonder why the bumpmap is editted out though.

Correct. And I agree that the D3 way was much more intuitive, and allows the light to remain easily editable even after it has had a model attached. I never really understood the idea behind the TDM approach of starting with the model then attaching the light entities at runtime. I suppose it makes it possible to have more than one light source for a given model, but that would be a pretty bad idea from a performance perspective. We do now have the ability to preview the light entities (in the 3D renderer), which is a big improvement over having them appear as completely unlit models. Actually editing them, unfortunately, still requires a very clunky manual "set light_color on <attached>" approach, which is probably close to unusable without dedicated UI support.

I thought this could happen when you have not specified your mod folder correctly and you use custom models inside your fm instead what exists in the core game. I mean it sounds like this situation from the description.

Hi, This is just me being a bit curious. I've grown quite fond of DarkRadiant, so I tend to use it over the built-in d3-editor when mapping for Doom as well. However, there is one thing that doesn't work well, and It's when you have a specified model for the lights. So if you open up any map, you'll see the box with a question-mark instead. This is usually when there is special things going on like breakable lights etc. Is that just functionality that was never needed for the Darkmod/DarkRadiant or is there something else going on ? I tend to use d3-editor just for those special cases.

Hmm could be an updated chip based on the 7900 series ?, the 7900 xt and xtx models are still faster than the 9070 xt in raster performance at least. So something similar with the new and better rt cores could lead to a pretty impresive card.

I went ahead and tried triangulating and changing my export options to no avail, I did switch from lwo to ase but that didn't change either, I tried doing the obj export thing but for some reason objs werent showing up in dark radiant and I didnt find much info on objs on the wiki so I did the only other trouble shooting method I could think of and imported in the utah teapot model from the university of stanford's computer graphics website and its see through aswell, not sure what this would imply though other than the source of the issue not being the models themselves maybe the way I have my exporter setup is wrong?

This almost has to do with the normal facings of the model which I can see you are aware as you are posting a picture of the blue normal direction in blender. The catch would be even when the normals are facing the correct direction in blender - it unfortunately doesn't always mean they will be handled correctly by the model exporter. Check a few things: Have you triangulated the model? Quads and ngons will not render correctly in the game. The export tools have a triangulate check box - but I prefer to use the triangulate modifier in blender as that gives you a bit more control and you can actually see the result. Do you have "recalculate normals" selected on export? *Normally* that is fine (get it?), but if the exporter is messing up the normal facings of the model you can try disabling it. Then are you using lwo? *Personally* I have had a lot of issue when importing and exporting lwos in general - and that includes circumstances where the normal direction of the models just would not export correctly - and I actually had to invert the normals in blender (ie all red outward faces) to get them to export correctly into the game. For that reason I currently like using ase over lwo or the newer obj export as it is the most reliably “what you see is what you get “option when working with TDM formats and blender, but that is just my opinion.

imported a model, its see through and it isn't obvious to me why it is that way (model has been cut up for better visualization of the problem) it likely isn't vertex normal related since all of the outside is blue and the model looks fine in dark radiant, I can provide more information about the models and things if it is needed

Given the slow updates I switched my DarkRadiant Git clone from Codereader to the Orbweaver origin. Everything seems to be working well except for an immediate breaking issue: In the 3D viewport entities without models no longer display the little box you click on to select them, just the arrows showing their angle. Meanwhile in the 2D viewport, I'm seeing lines that seem to stretch infinitely to the right. Here's a shot of the issue on a FM I'm trying to finish, letting @OrbWeaver know hoping the issue is easy to replicate and fix (Linux / KDE / Wayland).

I like Clair Obscur quite a bit, but it crashes fairly often for me. Also, in Act 2, some of the models look really broken, as if an LOD-model was loaded in rather than the high-poly model. It is weird, because I know that the game uses Nanite. Did they actually intentionally include such low-poly models or is this bugged?

atm amd cards seem the best solution vram wise, the 9070 xt is really good but nowhere near msrp (performs better than an rtx 3090 ti). with some luck you can get a 7900 xt for a good price (good deal faster than the 9070 xt). the older 6800 xt is also a good card if raster performance is all you need as raytracing performance is kinda abysmal with the pre 7xxx series. some lower cost amd models are also worth considering like the 7600 xt.

Coming in late in this discussion, but I've made some breakable crates for Volta 3 that work pretty well. It is a real pain to get the flinders to spawn at the right place since they need to spawn a few units away from each other or their clip models will get stuck and they'll float in the air. If its helpful, you can check them out in volta_breakable_crate.def. Breakable doors would be pretty cool, I wonder how AI will react to them?

This is the kind of thing I'm talking about with "Mobile-on-desktop", except that it isn't an APU and still needs a graphics card to get acceptable performance. We have seen a rumor that AMD's standard desktop RDNA2 2 CUs could be increased to RDNA4 8 CUs with some Zen 6 desktop CPUs, in which case that would probably have legitimate performance at 1080p. But it's just a rumor from one leaker, and if AMD includes that many CUs, I would expect some models to only be partially enabled (e.g. 6 out of 8 CUs on a Ryzen 5). Also, if you didn't notice, you can now finally buy 64 GB DDR5 DIMMs and SO-DIMMs, up from 48 GB.

20 gb vram confirmed by a 4090 user on max so ya it eats up vram like its christmas . while the requirements arent as steep as posted for indiana jones it does require lots of vram as one can see for themself when the 3060 16 gb model is faster than the 8gb 4060 by quite a margin. my 2080 ti can handle medium but i have to lower some settings to keep vram usage in check. even so it is damn close to putting a plug in the old 11gb card, a shared memory model might help the low vram gfx card models a bit but since motherboard memory is usually quite a bit slower than vram i would expect it to be quite choppy.

It's an AI image generator, but the latest version is more sophisticated and can work from starting images. It's very much an AI generated image that resembles the original, with added things from a prompt. It also allows for continuous iteration. Like, usually these models start from random values and denoise it slowly using a transformer until it looks like a thing. And the only way to adjust small things is to start from scratch. But this model actually allows for adjustments midway. (EDIT: so I could say, after that generation, "make the shadows a bit darker" and it would continue from this image instead of starting anew) I'm just giving you the basic idea I read somewhere though. I'm not an expert on this thing.

It seems that this isn't as much of the case as one would hope, unless I'm still doing something else wrong. I added the broken and hideModelOnBreak spawnargs to my current setup, but the model isn't hidden on destruction and the flinders still don't spawn. I then took a slightly different track and tried to rig the security camera to actually be a door. This approach seems like the correct-er one, although the sound effect when striking it with a sword seems a bit off. Like its repeating every frame that the sword is in contact with the model, maybe? Also, setting the clipmodel correctly is giving me trouble, so you have to swing at some air on the left side of the door to destroy it - I'd like TDM to derive the clip from whatever is set in the model arg, but setting a clipmodel to 0 or "" or some other obviously invalid value doesn't seem to trigger that behavior like the documentation strings claim it does - instead, it throws an error when I attempt to map (dmap completes just fine either way). In case it helps, I've attached a sample .map with a player start, an inventory full of smashing gear, a light, and my two breakable-ish doors. The one on the left is the doorified-camera, which sounds weird and clips weird (and crashes the game when I try to correct the latter by setting the clipmodel spawnarg to ""), and the one on the right is my model-turned-damageable and doesn't flinder or disappear. I'd be happy if I could get the left one to clip like its visual model (I would like to reuse this as a prefab, and swap out different models like half-broken crates or barrels - so just creating my own clipmodel isn't great (although it looks like a ~30s task based on https://wiki.thedarkmod.com/index.php?title=Moveables so maybe thats the way to go)), or the right one to flinderize and disappear. Is there something I'm still missing or misunderstanding about either setup? EDIT: Making sure I've uploaded the right version of the testmap I've made breakable_door_flinder.map

You could use the spawnarg hideModelOnBreak 1 to hide the entity completely. You may still need to set the broken spawnarg, even if its the same as the model spawnarg. A suitable broken model if it were still visible could be something that just has the hinges and one board left, but probably not that easy to tweak models when youre still new to mapping.

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.

I think here is some info about flinders: https://wiki.thedarkmod.com/index.php?title=Breakable_objects#What_happens_when_an_entity_dies? So I think you replace the door model with different door pieces that fall to the ground. Maybe it's possible to make a custom one for wood pieces. Also maybe it's good to add a quick smoke particle or something that happens when it breaks so (maybe) you can hide the transition. I wonder if you could set: "def_flinder" "models/darkmod/junk/door01_broken_piece.lwo" "flinder_offset" "0 0 -5" "def_flinder1" "models/darkmod/junk/door01_broken_piece1.lwo" "flinder_offset" "0 0 5" "def_flinder2" "models/darkmod/junk/door01_broken_piece2.lwo" "flinder_offset" "0 5 -5" "def_flinder3" "models/darkmod/junk/door01_broken_piece3.lwo" "flinder_offset" "0 -5 0" Because I think"flinder_count1" probably makes copies and maybe you don't want same looking door pieces. At least that's my idea currently. But I never tried any of this.