Search the Community

Not sure if this is a bug or my computer doesn't have enough memory. When I try to extinguish one of those blue fire elementals, the game ends and goes to main menu without showing anything. I checked the console and here is an error I found that might be related to this: Error:idafentity_base::setmodel: model imp_explosion_blue.prt is not modelDef

Double topic. See also topic: https://forums.thedarkmod.com/index.php?/topic/22754-thief-vr-legacy-of-shadow-announcement/

i am having a hard time searching for specific keyword in bug tracker so i decided to wade into google search and found similar thread with similar issue : https://forums.thedarkmod.com/index.php?/topic/13723-key-drop-melee-animation-glitch/

no it was actually even lower just checked. the max texture size is 2048*2048 so 2gb. the engine needs a power of two so the max texture resolution can only be 2048 or 4096 or 8192 etc. textures above that size limit gets scaled down despite not setting the scaledown cvar so as to not crash the engine. but upping the value also ups the limit for when the scaling occurs so it would crash cards with insufficient vram.

not sure though i seem to remember that the texture resolution limit in doom3 was about 4gb so unless that was upped in TDM then it would still hold ?. the devs should know . it could probably be upped to 16 gb max with current cards though i remember some older cards (4gb or less) did not like when the value got upped and would outright crash with some of the HD texture packs for doom3, so my guess is that some of the textures may have been bigger than say a 4gb card could handle without the limit.

Just to complicate your life, there are 3 additional aspects to consider about the circa-2014 Mason files, and subsequent circa-2017 improvements to the 'english' version perhaps applicable to your work. (These issues are covered in the wiki "Mason Font" article, with a bit more in my "Analysis of 2.12 TDM Fonts", https://forums.thedarkmod.com/index.php?/topic/22427-analysis-of-212-tdm-fonts/. The 2017 changes can be seen in the *current* 2.13 TDM English Mason files.) 1) Need for custom DAT-scaling on certain Mason characters The source TTF had upper-case and lower-case characters that were early-on considered too similar to size. So (before 2014) in the DAT, selective per-character scaling was used to differentiate them. See https://wiki.thedarkmod.com/index.php?title=Font_Metrics_%26_DAT_File_Format#Per-Character_Font_Scaling for details. As you add new characters, you should do likewise (relatively easy with refont). 2) Creating the "glow" of mason_glow How Tels created the glow (for 'english' carleton & mason) is discussed in reasonable detail here: https://forums.thedarkmod.com/index.php?/topic/12863-translating-the-tdm-gui/page/5/#findComment-262661 That could be done for Russian too, which I recall currently fakes a glow, and possibly would require a minor GUI or engine code change to use. Note: To best accommodate glow and retain GIMP-visualization-alignment between base and glow characters, Tels moved some base characters within their bitmap, to keep their glyphs 2-3 pixels away from any bitmap edge. You should consider this when placing new base glyphs. Note: For the 3 mason bitmaps doubled in size circa-2017 as discussed next, the mason_glow bitmaps were also doubled. 3) Extensive bitmap editing to solve main menu character jaggedness. On Oct. 5, 2017, @Springheel in https://forums.thedarkmod.com/index.php?/topic/19129-menu-update/#findComment-412921 said: "Looking at the Mason fonts, it looks like they were super low res to begin with, and were then just resized [presumably referring to per-character scaling], making them even worse. I'll see what I can do." [Further on, referring to fonts in the TDM menu system:] "It appears that resizing the dds file to make it higher res is possible, so I'll proceed." Later, on Oct 13, 2017, he concluded within a "More detailed list of changes: "Updated the menu fonts, which were surprisingly bad before" Unfortunately, I couldn't find details on how this work was actually done. I assume the bitmap editing was all done in GIMP. It started with doubling the size of certain bitmaps from 256x256 to 512x512. This was done for the first 3 bitmaps (i.e., those with ASCII, some Latin-1). Then characters were made more crisp and smooth-edged. How? Dunno. Also, some odd but harmless artifacts happened within GIMP (noted in https://forums.thedarkmod.com/index.php?/topic/22427-analysis-of-212-tdm-fonts/page/3/#findComment-499660)

Or, just get in contact with the owners of the IP and ask them since just because an IP lawyer in one jurisdiction says it would be okay, doesn't mean it would be okay globally. There are several packs out there of scripts/definition files which are licenced under free licences (CC0 and WTFPL mostly) and claim their freedom by recreating them using "clean-room way". In fact, I used them in getting TDM running with mostly free licenced files by selectively choosing which had clearly been written from scratch albeit with reference to the originals, and which were just direct copy and paste with claimed free licences (I didn't use them). Then it was a case of finding/replacing the core engine textures, sounds, etc. the engine required to launch with free alternatives (again checking the packs since some were just copied direct from the game files and claiming to be free). In the end, the only non-free licenced files that were still required were those from TDM itself. The result of this TDM version is the screenshot I posted some posts ago here: https://forums.thedarkmod.com/index.php?/topic/22346-libre-version-of-tdm/page/3/#findComment-500642 However, you will notice the giant cursor on the screen in the screenshot, why? because the only reference to hiding the cursor is within the UI files which come under the game eula, so I didn't add in the command to hide it in game. In the case of the script/def files, this "clean-room" approach has stood up in a court of law when I looked online, however you wouldn't really want to end up being in the position of ending up in court defending yourself in the first place. The flaw in the def/scripts that were recreated are that they all wrote their files using the originals as reference. So if the originals are under the game eula, and if the information contained is in some way protected, then all these "clean-room" files revert to the original game eula, as the authors didn't have the right to change the licence. I believe (with a pinch of salt )that if the core scripts/files were made GPL by idSoftware/Microsoft then as files based off of or using them as parents (basically all TDM scripts/defs as far as I can make out) then all of the TDM scripts and def files would automatically become GPL as their authors could also not claim their work was NC-BY since it was then based on GPL work.

Regarding the existing Russian version of TDM's MasonAlternative font, this had a different origin than those Russian fonts processed by Riff_Keeper. Tels created this in 2012. He started from bitmaps of an ASCII Mason font, then used his Perl patch program to copy selected ASCII glyphs (that resemble in some way Cyrillic) to new font "MasonAlternative". See https://forums.thedarkmod.com/index.php?/topic/12863-translating-the-tdm-gui/page/15/#findComment-274617 In GIMP, he flipped or otherwise hand-edited to make them Cyrillic. He said, "There are still a few dozen missing, but this is enough to render the two headlines we have (New Mission and Setting)" https://forums.thedarkmod.com/index.php?/topic/12863-translating-the-tdm-gui/page/15/#findComment-274623 This accounts for the incomplete coverage. Speculatively, he took this approach because it couldn't find a Mason-style TTF font with both Russian characters and an acceptable license (e.g., public domain, or at the least freely redistributable for non-commercial use). @kalinovka,I wonder what the licensing is for your masonchronicles3.ttf.

Evidently a significant portion of the Cyrillic work was done by Keeper_Riff (in conjunction with Tels) back in 2011. These folks are not active in TDM these days. Keeper_Riff outlined a workflow, starting with FontLab to edit TTF files... https://forums.thedarkmod.com/index.php?/topic/12863-translating-the-tdm-gui/page/12/#findComment-271548 Specifically Carleton: https://forums.thedarkmod.com/index.php?/topic/12863-translating-the-tdm-gui/page/4/#findComment-262135

ah well the 9070 xt is about twice the speed of my current card so i doubt the 9060 xt will beat it by a large margin. the extra ram will be nice though but to ice the cake it would have to be atleast 30% faster otherwise theres not much point other than being able to play titles like indiana jones with texture resolutions higher than minimum. my 2080 ti does ok in indiana jones speedwise but sucks a bit in alan wake 2, the 9070 xt really shines in that game though and is actually one of the few cards that can handle it with everything maxed in 4k. i can live with a little less so will be interresting to see the numbers.

Made Daraan's texture pack, (books, plaster & misc), TDM ready, I would welcome testing - - Linked removed for now, verifying CC compliance of plaster textures, because in typical ttlg style, its not clear.

Last time I checked, new/used prices for RX 7000 series aren't fantastic in the U.S. because production has ended and stock has dried up. RX 9070 XT and 9070 above MSRP is not the best idea since they will probably drop after the supply stabilizes. Grabbing a 9060 XT 16 GB at $350 MSRP in June could be a good option since you would be getting the VRAM u want, with rasterization performance exceeding a 6700 XT, 7600 XT, and potentially matching the 7700 XT. Raytracing will go beyond that, perhaps at playable frame rates if you lean on FSR4/Redstone crutches. I think it's likely that some form of FSR4 will come to RDNA 3/3.5 simply because it's possible with some tweaks and that is what AMD is shipping in mobile for the next year. I would not count on Redstone coming to older GPUs though. SSDs can easily saturate every new PCIe (x4) standard... not that most people should pay a premium for PCIe 5 drives when PCIe 4 drives are cheaper and cooler. There are (crappy) cards that suffer from PCIe downgrades. Notably, the 6500 XT (4 GB) on PCIe 3 x4. Recently, I believe the 5060 Ti 8 GB took hits from going to PCIe 4 x8. If that's true, PCIe x16 on the 9060 XT 8 GB could help it alleviate the effects of the low VRAM when PCIe 4/3 is used. Yup, here: NVIDIA GeForce RTX 5060 Ti with 8GB memory sees up to 10% performance loss when switching to PCIe 4.0 TechPowerUp may also do this testing, but I don't think they've posted it yet. For the 16 GB model, you lose 1-2% at PCIe 4.0 x8, and 4-5% at PCIe 3.0 x8. NVIDIA GeForce RTX 5060 Ti PCI-Express x8 Scaling - Conclusion NVIDIA GeForce RTX 5060 Ti 8 GB Review - So Many Compromises

Made Skackys T2 texture pack, TDM ready, I would welcome testing - https://drive.google.com/file/d/1JWZ9fQYnMpEAB6pEnpiTPmqbFZHQOn5-/view?usp=sharing

Released DOOM - The Dark Ages Min Sys Specs for low quality 1080p Processor: AMD Zen 2 or Intel 10th Generation CPU @3.2Ghz with 8 cores / 16 threads or better (examples: AMD Ryzen 7 3700X or better, or Intel Core i7 10700K or better) Memory: 16 GB RAM Graphics: NVIDIA or AMD hardware Raytracing-capable GPU with 8GB dedicated VRAM or better (examples: NVIDIA RTX 2060 SUPER or better, AMD RX 6600 or better) Storage: 100 GB free NVME SSD storage required https://store.steampowered.com/app/3017860/DOOM_The_Dark_Ages/ Nothing for my poor Laptop

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

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?

Hi all, Thanks for the replies. I'm not sure if it's just my setup, but it should be quite apparent if you load up any original Doom 3 map in DarkRadiant (unless it's only me having issues ofc). The mod folder doesn't seem to make a difference, but I do currently run the dhewm3 source port, so I should maybe run a clean installation on the side just to make sure and rule that out. Here are two screenshots, one from darkradiant and one from d3-editor from the same location on a map. The model appears green when it is connected with a light. I believe default keys are shift + k in D3 Edit to achieve it. And just to explain, the light on the right is essentially just brushwork and then a light sitting below it (not visible in the screenshots), while the left one is a light with the model property assigned, and the model can just be a func_static but that just doesn't seem to work in DarkRadiant for me. Caverns2 shows this off in the first room below the elevator pretty well.

So I came back to revisit this, and managed to port 95% of the Volta 3 breakable crates to my current project. It looks like I'm missing a material definition for the flinder bits the crate leaves behind after exploding, but according to the .ase that texture is "textures/darkmod/wood/boards/tdm_crate04" which... sure seems like a tdm builtin? I'm not sure how the breakables can't find it. Attached a picture for reference (the FM is quite dark on purpose but those black squares shouldn't be pitch black like that). Other than this minor hiccup, this seems like the coolest solution that is the closest to what I want - but the downside is that now my project folder has a ton of extra junk and new volta-specific folder structures, entity definitions, and whatnot in it that I blindly copied and pasted. I'm gonna try to remove the volta specific stuff as much as I can and replace with some tdm defaults and see how it goes!

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.

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?

Oh never knew Doom 3 editor lacked prefab ability, one reason DR got so popular then, prefabs are awesome. I never used inhouse Doom3 editor, besides trying it for a few minutes but DR felt better to me, so I used that. Custom DR prefabs, do work in Doom 3, obviously TDM ones will not. I did used prefabs in Doom 3 for some things, like wall lamps and such, where I connected a model, a light and a particle effect for example. Never looked at the DR source code, but behind the scenes I bet the entities are just being bound to each other and that Doom 3 supports fine. About the topic, I would love to help the person but like i said, I never used inhouse Doom3 editor, so I can't really compare behaviors between the editors. And what you said sounds totally reasonable.

Prefabs don't exist in the original Doom 3 or D3Edit as far as I know. But I don't understand what is the issue being reported. As far as I can see, creating a light entity and setting a "model" key works as expected, with the model becoming visible in the 2D and 3D views in addition to the light bounding box. I'm not sure what else is meant by "having a specified model for the lights". Perhaps vanilla D3 does this in some other way than by setting a "model" key.

Are you talking about the prefabs? If yes, afaik DR supports prefabs well, so if you are getting issues with that, could be because you are importing the model/entity not the prefab itself? To use prefabs (pre-fabricated complex group of entities) you need to right click on a 2D view and click on "insert prefab". If you are already doing that and it still doesn't work, then is probably some prefab that got outdated/broken, if so, please do a bug report for it. https://bugs.thedarkmod.com/my_view_page.php

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.