Search the Community

So I finally did it Started learning C++ / Qt5 and made my first app - Doom 3 BFG mod launcher. It lets you prep Doom 3 BFG to be mod friendly with a click of a button. No more messing with scripts and console! I also authored a few mods for Doom 3 and now you can run them with Doom 3 BFG (these mods don't have SDK code, scripts/assets mods). Some run well, some not so much. Either way, feel free to give it a spin: http://www.kot-in-action.com/forum/viewforum.php?f=28

Above 3 items are released now, on the "Barks" thread: https://forums.thedarkmod.com/index.php?/topic/21740-english-subtitles-for-ai-barks/&do=findComment&comment=483331

Perhaps you have a infinite loop in one of your scrips? Infinite loops can cause freezes. But I also thought the script parser was able to caught those? Btw I don't remember ever having, Doom 3 in this case, freeze because of changing a def file (or even a script?), the worse it could happen is crash the game or cause ingame bugs but I'm not absolutely sure on this.

Hmm... Is Uncapped FPS enabled ? The standard Doom 3 FPS cap ( com_fixedTic 0 ) is known to steal a ton of performance in the latest drivers. How does the Dhewm3 Doom 3 port perform ?

Instead of that, you could, in that time period, start learning your own missions and in doing so become more active on the forums, learning from others. It's also great to understand how things work in the engine, when you play. It might spoil some immersion though.. Or learn to build games with other engines, like Godot for example.

As far as the file syntax is concerned, there's no difference between a Doom 3 .map and a Doom 3 .pfb. When DR is saving a .pfb file, no corresponding .darkradiant file is going to be created, i.e. all map meta data like layer and group info is lost. There's no difference in the XML structure of the mapx or pfbx file contents. No .darkradiant file will be created for neither of them since it's not necessary. Layer and group information is saved in the mapx/pfbx file itself. A .pfb file is using the decl-style syntax of Doom 3 maps, while .pfbx is an XML file. The XML file is taking up more space on disk than the decl-based one, if anybody likes to care about that. Yes, these two commands are different, as expected: Export selected as Map will create a regular map file without adding any additional stuff like those sealing brushes, or moving player start around, it's just for saving the selected part of the map - it's really just what the name says. The region feature has the goal of making a part (the regioned one) pass beyond the dmap flood fill phase, hence the wall brushes.

There is no SS3, how can they do a remake? And thank god they got rid of unity, that engine is total trash garbage on anything over 60 fps. Just spend 5 minutes on steam forums for Unity project games, and there's just thousands of people complaining about poor performance, stuttering etc.

Made 2.09b the default version. I hope at least a few people have installed and played it I'll finish the release process tomorrow (tags, source, pdb, etc.)

@Dragofer, I'm wondering what template tags to give to this page, besides the usual "Editing". I'm tempted to add "Physics", but are force fields really considered part of the physics engine?

Sounds pretty good, and I'm looking forward to it. Looks like a taffing good time, tbh. Might I suggest a name change, though? DOOM 3 was DOOM³. The Dark Mod is no longer a mod, so how about The Dark³ (TD³)?

Something about Doom 3's FPS cap method is incompatible with modern drivers and accelerated desktop render techniques. Capping FPS should make GPU resources available for the next frame so it should make things smoother when you are near or slightly above 60 FPS. Instead, it can steal as much as half the FPS performance even in pretty light scenes. Setting uncapped FPS increases performance even if you use the "new" Max FPS cap that TDM uses and set it to 60. We should probably default to uncapped FPS with max fps set to 60 and leave the old Doom 3 cap method as a developer cvar.

Thank you for the details and test map! I will try to get testing done tonight but I see that our engine still has support for the "noportalfog" global material keyword. There may already be a noportalfog light material in our repo that we can test ( converted from Doom 3 ). Too bad it's not an entity spawnarg but I think I can add that too.

Sorry if this has been posted before, I know some of you are already aware of this but I couldn't see a thread dedicated to it. I've only just come across this project called Thievious thanks to a post by clearing at TTLG. Although I was doubtful at first (inspired by TDS??) I was suitably impressed at the in-game videos and the potential that this could have, although the title of the mod sounds a little silly so I've suggested 'Thieves' would make a better name for a co-op Thief game. Now, I know that the TDM team aren't considering any multiplayer development, and most TDM fans (myself included) are primarily interested in a single player experience, but co-op would be a worthwhile addition to TDM gameplay since thieves would often (in the real world and in this universe) collaborate and are not always the lone wolf characters that most of us associate with Thief. I would hate to see this co-op project fail to progress because it's just a one man tech demo at the moment with no real support, and at the same time, it would be disappointing if it were to be completed, only to have one or two playable maps. My question then is, does the team agree that it would be mutually beneficial for Thievious and TDM if this project were taken under your wing, so to speak, so that if it were eventually completed it could benefit from being able to play TDM missions (some of which would presumably need to be modified for co-op support)? Ideally, what would be great is if at some point in the future, you could launch TDM missions from within the launcher in co-op mode, which would use the multiplayer work demonstrated in the Thievious project videos. More than anything, the reason I suggest this is that I hate seeing resources duplicated in different projects, when sharing those resources could speed up the development of both. I imagine that if Nightblade had been undertaken in Doom III it might still be around because they could have shared some of the resource and development work that went into TDM.

Probably the .script file that's needed, but unfortunately can't be included with a prefab. Maybe there's a comment somewhere in the prefab (or in the wiki or forums) that says what script it needs and where to find it. (The similar combination setup I used earlier doesn't involve "slot", so clearly uses a different script that I what I have.)

Oh! I didn't knew that! Thanks for the correction. Is what happens when I take knowhow from the original Doom 3 engine (and Dewm 3 engine) as a starting point. :S

Since it already has been mentioned in the forums, I'd like to announce a small project of mine. A few weeks ago I was playing Legend of Grimrock and it struck me that their level design is extremely simple and modular, and yet, the player can spend quite a lot of time in the game. And it looks pretty, too! So I wondered if it wouldn't be possible to create a modern "Dungeon Crawler" (solve puzzles, fight monsters, collect loot, progress your character, upgrade your equipment) type of game inside the TDM engine. The engine already supports a lot of things one needs for this, and the overal structure and assets work, too. And with prefabs, one might get the level layout done quickly. However, building a few test prefabs in DR is easy, but creating a full mission out of them is quite painful. Not only needs it a lot of planning, but you can also spend a lot of time "upgrading" things later on. For instance if you later want to add a grime decal to the walls, you have to revisit the entire map. Even worse is if you find out later that your block size must be bigger or smaller. So the idea was born to create a sort of framework that can assemble missions from prefabs. Preferable while getting the description of the mission from a text file. So far, this has been a lot easier than I thought. Here is what I got working so far: Overview: You can describe your mission in a (Unicode) text file. This contains overall options, different locations (each location can have its own ambient light, music,name, fog), and the connections between the locations. Each location can have multiple "floor levels", these are stacked on top of each other. The config file also specifies which symbol means "use this prefab". It is also possible to specify links (per location), which means you can say "this lever with the symbol A opens the door with the symbol D". The framework reads the prefabs, and then positiones them in the map. It also glues all the locations together, adds location_info entities, a player start, an exit, and an objective to reach the exit. The resulting map is then enhanced with script objects (all nec. assets are bundled together), and automatically dmapped via TDM. Everything then is packaged together into a working .PK4 file. My demo map takes about 20 seconds, where 15 are dmap. In addition to the "basic" stuff I also managed to get a few things working, like a pressure plate, portcullies, and also made some puzzles. Oh, and per location fog (fading from location to location). Different difficulty levels are also supported, one can specify "this prefab appears only on easy" etc. You can find more info and screenshots and demo here: http://bloodgate.com/swift/ There is also a developer diary where I will be posting interesting entries from time to time. Here is an DR shot of a sample level, consisting of small modular prefabs and one large (the large hall on the lower left): The next steps will be to add more randomness (either static at map generation, or at runtime, so the map is slightly different each time you replay it). Also, while it is already possible to "overlay" prefabs (e.g. "for this location, look first here before falling back to the default"), it is not yet possible to "reskin" prefabs. This would be something which is impossible in DR (you cannot really reskin worldspawn brushes, unless you live with the fact that it is all manual For now I'm quite excited!

I'm trying to fix the warnings on my end, but remodelling the models is out of my league, so you're going to have to fix the stairs model on your end: "WARNING:ConvertLWOToModelSurfaces: model 'models/darkmod/architecture/stairs/set01_stairs.lwo' has 17/8108 nontriangular polygons. Make sure you triplet it down" Edit Also there's this model, which is probably a modelling issue as well: "WARNING:ConvertLWOToModelSurfaces: model 'models/darkmod/misc/clipmodels/pickaxe_cm.lwo' has bad or missing uv data" I still have hopes for script-hotfixing the following warnings: "WARNING:Couldn't load image: tdm_tongue [map entity: atdm_ai_townsfolk_female_1] [decl: atdm:ai_head_female02_base_brunette in def/tdm_ai_heads_springheel.def] [decl: female_head02 in def/tdm_ai_heads_springheel.def] [model: models/md5/chars/heads/npcs/female_head02.md5mesh] [decl: tdm_tongue in <implicit file>] [image: tdm_tongue]” (Edit: I hotfixed this issue and attached the hotfix in the tech support forums. The "tdm_tongue" shader should simply be renamed to "tdm_character_tongue".) “WARNING:Couldn't load image: models/darkmod/wood/boards/wood_brown_dull01 [map entity: func_static_53] [decl: old_plaster in skins/tdm_models_architecture_modules.skin] [decl: models/darkmod/wood/boards/wood_brown_dull01 in <implicit file>] [image: models/darkmod/wood/boards/wood_brown_dull01]" (Edit: I hotfixed this issue as well - see the tech support forums - but I think you should still go over this file, because there are a lot of other suspect textures in there as well.)