Search the Community

It could be from the physically based rendered materials having less details on the texture itself and having more of the detail being born from shaders and model geometry but I see that kind of pastel look beyond 3d rendered things like in music videos and recent movies, and even in some Linux ui custom "rices" it all kind of reminds me of 60s era art, maybe a little saturated than the colors from then, and of course more detail oriented.

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/

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

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

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.

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.

Yes that is an issue - for the game to draw any material it must defined in a .def file. It is the material def which points at the texture maps, and then the model is pointed at the material def via the names of it's material. For yours it could be quite simple for the time being: textures/gobmdl/ksword_rusty { metal diffusemap textures/gobmdl/ksword_rusty }

Good news is that is appears to me to export fine (and seems like it will be a cool dishonored style model): Bad news would be what the heck is going wrong. Here is a picture of the modifier stack: And the ase export settings: What does your material def for the texture look like? Maybe there is an issue there.

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.

hmm yeah a new more powerfull chip would be better if they intend it to compete with the top shelf cards from nvidia. the new chip does well for its intended price segment (which we havent seen any sign of here in denmark though, the card is still listed at 1000$ for the cheapest model sigh). some of the price is tax etc which here in denmark is and has allways been 25% of the real price. so 750$ for real which is still well above the promised msrp. it is actually the fastest card for alan wake 2 beating even the 5090 which is kinda weird as this is the only game it actually beats nvidias top card in (might be better optimized for mesh shaders else im blank ???). perfomance wise it is a good deal faster than the 3090 ti but that card is also two generations old so not really ground shaking performance wise but still ok.

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