Search the Community

There's now an editable fan mission list on the wiki, for the sake of tracking missions made for The Dark Mod. Please read and follow the guidelines, and help keep the list up to date! Direct link, but also accessible from the wiki title page: http://wiki.thedarkmod.com/index.php?title=Fan_Missions_for_The_Dark_Mod Discussion of changes (format, policies, entries, etc.) can take place in this thread. --------------------------------------- There is also now a wiki page to track upcoming fan missions: http://wiki.thedarkmod.com/index.php?title=Upcoming_Fan_Missions Submissions, progress, and any discussion for missions under construction can take place here: http://forums.thedarkmod.com/topic/11639-upcoming-fan-missions/

About ways to share a patch. If you have SVN working copy, you can simply create SVN patch and attach it to forums post. Better mention which SVN revision your patch is based on. If you don't have SVN working copy (e.g. downloaded source code archive), then I guess you have to use some diff tool between directories. To be honest, I don't remember doing it myself. WinMerge is good for directory diff, but I don't know if it can actually save the changes as some patch... I'm currently travelling and don't have access to TDM development, so I'll trust the decision of "how should it work in various situations" and testing to the other members of TDM team. But I'd be happy to read a source code patch anyway.

They're in a dilemma. People expect super high definition graphics and AAA tech even from games with a small budget, when they come from a bigger publisher. I really see only one way for projects with ideas which stray from the mainstream: Go Indie and crowdfunding. Some nice games are done that way. But, even if you do that, people have totally overblown expectations. See the System Shock remake. I hold my head in shame every time I visit the Steam forums for that game. Gazillions of "When is this being released pleeeease... " threads. Well... it will be released when it's done. I guess. Not to mention they had to start all over again, of course, because people didn't like what they saw, and they had to change everything to make it closer to the original. Well... I guess crowdfunding has its very bad sides as well. Again due to expectations though.

Select the text, and use the Special BBCode button. Specify the "Spoiler" BBcode. That wraps the text in spoiler tags. Or you can do it manually, by adding [ spoiler] at the start of the text, and [ /spoiler] at the end (except, don't add the space after the open bracket; I did that so that you could see it in the message).

1- Zoom the 2D views toward the mouse location. I couldn't find any option for this in the settings, so I'm assuming this isn't in DR at all. This would make zooming in and out much easier. 2- A search feature on model/skins/texture/etc browsers. I noticed that in some cases if you press Space a text field appears, and it seems like that's some form of search thingy, but doesn't seem to work very reliably. This would make things much easier to find, regardless of how they are organized in the folders. You could always just search for it. Find "by name" might be enough for most purposes, and would be golden in itself, as far as I'm concerned. Although if more could be suggested about this, I'd say it would be something like how Hammer categorizes things with tags that allow for search filters (can also use material keywords for filtering textures). 3- Simplified wireframe on models (optionally just a bounding box). So that models wouldn't turn the 2D views into incomprehensible messes so quickly, but it would also help more easily seeing where model boundaries are exactly, for positioning/alignment purposes and such. Also one more, that I forgot: 4- Add an acceleration factor to the camera movement speed. Since there's no quick way to change it back and forth between fast and slow (have to press P, click camera, change speed, click ok, every time) this would make it easier to do small adjustments to camera position while still keeping the speed high enough to taste, and so that if you kept the movement key pressed you still quickly fly away to that far place you want. This is how it works in Hammer. I think its acceleration factor must be pretty high, so that small taps barely move the camera, but a continuous press almost instantly accelerates you to max speed.

Oh, right, spoiler tags. Here is the content of mylog.txt after I start TDM with the start argument:

Thanks for the logs. (please keep this topic clean, by placing the content of the logs between spoiler-tags.) like this. Cant see any error messages in the logs, thats with the problem to do with it. So, whats the content of mylog.txt, after you start tdm with the following startargument? +gfxinfo +condump mylog.txt +quit

Thanks for testing. This help us too, to help other players in the future on their first-run. Some on the internet say, to also install the vcrun2015 component. Please install it and check it reaction. A black screen with sound is a video problem. You can solve this by change things in the tdm config file or run tdm with start-arguments. Run TDM windowed mode and low screen resolution: make a backup of the file "darkmod.cfg" (by make a copy of it) Then open the file with a texteditor, change the following values and save the file. r_customHeight 600 r_customWidth 800 r_fullscreen 0 If this works on your system, then you can change the video settings from the tdm main menu. If not, we need some logs. Create in playonmac a shortcut to the tdm executable and fill in some start arguments. (Configure button > select dark mod container > General tab > "Make a shortcut from this virtual drive" button)", select the dark mod exe inside the darkmod folder) After you created the shortcut in playonmac, hit the configure button again, select the darkmod container, then the darkmod exe shortcut and select tab "general" and where you can enter arguments in the "Arguments" input. we need to see how tdm loads. please create a log for us. using the start arguments: +gfxinfo +condump mylog.txt +quitThis generates a textfile inside the tdm folder and automaticly close tdm. We want to see the content of that file. (in spoiler-forum tags, please) If changeing the values for low resolution and windowed moded in the darkmod doesnt work Then use start arguments: +set r_customHeight 600 +set r_customWidth 800 +set r_fullscreen 0(or change these values in the darkmod.cfg file,) If this works on your system, then you can change the video settings from the tdm main menu. Folow the following tdm wiki article: http://wiki.thedarkmod.com/index.php?title=Debugging_TDM_systemerrors

@Acolytesixthe party's over here! https://forums.thedarkmod.com/index.php?/topic/21384-beta-test-for-eastbound/ You can take a look now, or wait and be a fresh set of eyes on Beta 2 sometime next week.

The beta thread is up, head on over there for a download link: https://forums.thedarkmod.com/index.php?/topic/21384-beta-test-for-eastbound/ Looking forward to hearing feedback from my alpha testers on the adjustments I made as well as more fresh perspectives!

So, you've been working for weeks or months and finally have a fan mission that you're happy with. Now what do you do? 1. Playtest (in private) You've obviously been testing things yourself as you build, but it's important to get a few fresh perspectives before releasing your mission. Other players will try things that you never thought of, and will help you decide if your mission is too easy or difficult. They can also spot texture misalignments, floating objects, and other mapping pitfalls that we all fall into from time to time. Don't just post a link to your mission in the public forums, however. Lots of people are bound to download it and play it without realizing it is still in the playtest phase, and then complain about any bugs. We recommend you post a message asking for beta-testers, and then email them a link to your mission. It's probably also best to handle feedback through private messages; even with spoiler tags, things inevitably slip out. 2. Test the Release version It's very easy to make a last-minute, minor tweak to your mission, and then upload it, only to find out that you forgot to dmap, and now your aas is out of date. Oops! If you change anything, it needs to go through a couple of testers. This does slow down the release process, right at the moment where you're most excited. But you don't want to be in a position of dozens of people trying your mission with a last minute bug that slipped through. 3. Submit your mission .pk4 for hosting Where should you host your pk4? Good question. There are several public sites that will host small pk4 files. Mediafire darklurker 4. Post a Release Announcement Post a new message in the Fan Mission forum with the following title: "Fan Mission: [mission title] by [author] ([release date in yyyy/mm/dd format])" The first post should include a short synopsis of your mission, perhaps with a couple screenshots, as well as download links. 5. Add your FM to the Fan Mission List. Other Considerations A few other miscellaneous details... External Material: If you use external material (textures, sounds, models, etc) that isn't part of the mod repository, and you didn't make it yourself, get permission. We won't host or link to any missions that use copyrighted material, and it's not a good way to make a name for yourself. Credit: Be sure to give credit for anything you use that you didn't make (other than the stuff in the main mod itself). That's just good form. If someone helped you write your readables or made a loading image for you, credit them too. The TDM Website: Don't post asking why your FM has not been added to the official FM page on the Dark Mod website the day it is released. As the number of TDM FMs grows, it will take longer to ensure that new missions are copyright-issue-free, so it may take some time for new missions to appear.

Headbobbing definitely seems like something for the player rather than the mapper to control. In fact, the headbobbing in TDM is a criticism I often saw on the TTLG forums, so it would be good to at least allow them to disable or reduce it.

DarkRadiant 2.8.0 is ready for download. Next to a considerable number of bugfixes and improvements, a nice amount of new editing features made it into this build. There's a new way to select items by filter, it's possible to retain grouping information when copy-pasting between DarkRadiant sessions, a new "Select Parent Entities" command has been added, and more. A new DarkRadiant User Guide is being worked on and available on the website https://www.darkradiant.net/userguide (also accessible through the About > User Guide menu option). Windows and Mac Downloads are available on github: https://github.com/codereader/DarkRadiant/releases/tag/2.8.0 and of course linked from the website https://www.darkradiant.net Thanks go out to all who helped testing this release! Please report any bugs or feature requests here in these forums, following these guidelines: Bugs (including steps for reproduction) can go directly on the tracker. When unsure about a bug/issue, feel free to ask. If you run into a crash, please record a crashdump: Crashdump Instructions Feature requests should be suggested (and possibly discussed) here in these forums before they may be added to the tracker. Changes since 2.7.0 Feature: Selection by Filter Feature: Preserve grouping information when copy-pasting between multiple open instances of DR Feature: Add Portable Map Format storing map and additional data in one single file Feature: Preserve grouping information in prefabs Feature: Model chooser now lists .md3 models Feature: The Dark Mod: Let DR look for either 32-bit or 64-bit TDM .exe's Feature: The Dark Mod: Added ability to edit difficulty names Feature: The Dark Mod: Add Move up/down buttons to Conversation Editor Feature: Add type-to-search ability to AI vocal set and head chooser dialogs Feature: Let DR remember the shader in ShaderClipboard after closing Feature: Add option to show "Other Materials" in Texture Browser Fixed: Edit Objectives dialog doesn't adjust its height when selecting a component Fixed: DR can't find materials whose names start with table Fixed: It's possible to delete the classname spawnarg through the context menu Fixed: All spawnargs with the same value as the "name" spawnarg iterate when the entity is cloned Fixed: Removing a Stim/Response entry can break the remaining entries Fixed: Loading error caused by non-Latin character in filename Fixed: Texture Tool: crashes on brush surfaces with texture scale 0 Fixed: Undo after thickening a cylinder cap along vertex normals causes crash Fixed: Readable Editor Crash Fixed: Python 3.8 does not get linked (Linux) Fixed: ConnectNamespacedWalker Warning when cloning selection containing links and targets Fixed: Show English difficulty names in the Difficulty Editor instead of the #strNNNNN IDs Fixed: 'Reload models' reveals hidden models Fixed: 'Show help' etc. checkboxes in entity inspector aren't remembered by DR Fixed: 'Show help' tooltip text updates incorrectly Fixed: Changing classname ties entity's visibility to 'Default' layer Fixed: Resized Models lose their scale in auto-saved maps Fixed: Autosaves don't save last camera angle & position Fixed ToggleFullScreenCamera command for Embedded and RegularLeft layouts Tweak: Removed/disabled close button from all dialogs Tweak: Allow fixed Subdivisions to go higher than 32 Tweak: Targeting projected lights: let the line point to the light source instead of the light volume's midpoint Tweak: Collapsing a folder in a treeview now collapses all child elements too The list of changes can be found on the our bugtracker changelog. Have fun mapping!

Welcome to forums! Thanks for sharing this! The main problem with having more ways to install/build TDM is maintaining all of them, and making sure players don't get into more problems. That's why we keep away from having official TDM packages in Linux distributions and similar stuff. Is there any benefit in this flatpak approach, compared to running tdm_installer manually? P.S. You should not specify checksum for tdm_installer.linux64.zip, because this file is regularly updated, and each update changes the checksum.

With regards to edit: uses spoiler tags now

Hi, great mission. Not sure how to do spoiler tags, so I'll just ask this generally: It appears that I have exhausted every possibility, but cannot find the item that the main quest revolves around, I have well exceeded the loot and found 4/6 secrets, but the main item, which seemingly should be obvious, I cannot find. Is my game bugged, or am I missing something? I have the key that I assume leads to the item, but cannot find where to use it, for the life of me.

Maybe it's easier to google the issue to see what the forums come up with.

In my opinion what is most needed is a user-friendly searchable asset repository that asset creators can use to store their models/sounds/textures etc in such a way that they are easily obtained and used by other mappers without having to duplicate effort. We have lots of talented people producing content but the only way to share it is via manually downloading other missions and extracting the assets (and needing to contact the author for permission), or with ad-hoc "My stuff" threads that get posted on the forums from time to time. If you have good web design skills this seems like an area where you could really contribute, because AFAIK there aren't many people on the forums with the time, energy or skills to build such a resource. What I think a site would need is: Browsable by category (All Sounds, All Models etc).Full text search within or across categories (Find anything called "chair" in Models)Restrict results by format (only show me ASE models because I don't have anything that will edit LWOs).Each item has a textual description and a number of images (if appropriate). Even better if you can embed a sound player for audio assets.Author information and contact information is available, and the licence for each asset is clearly displayed.Unlimited user tags for each asset, which can be clicked on to use as search terms.An "asset" should be able to contain a ZIP with more than one file, for example if someone uploads a sound file as several .ogg files with a .sndshd shader attached.

https://forums.thedarkmod.com/index.php?/topic/21333-tdm-wont-run/&do=findComment&comment=471717

Hey Xolvix! Yes there has been a long wait between act 2 and 3, longer than I would have preferred. But between personal events that have popped up and taken my time away from mapping and also big world issues, it has just extended that time even further. Work is being made though, in fact I actually just took a break from working on Act 3 to check the forums and saw your message. The wait should be over soon Re: your spoiler question

Thread created in the Beta test forums!

https://forums.thedarkmod.com/index.php?/topic/21207-210-x-rays/ Another big gameplay addition in 2.10 were the improved security cameras. Other features which indirectly impact gameplay were things like removing the entity limit (my mission would not function without substantial compromises if that was not done) and the productivity boosts which came from compile time optimization and the connection and collaboration features added to DR.

Evenin, Taffers! My FM for the Grand Christmas FM Contest, Business as Usual... updated 16-01-10 (fixed all of the minor errors people were having) "Got a new place in the old quarter, but as the saying goes 'the more things change the more they stay the same..." "...Tiss the holiday season and the first snows are upon us, bah bloody humbug. As usual there is a local thief who needs taking down a peg or two and some noble boasting about his wealth down the local tavern. Thankfully this part of town is free from the likes of the Builders, but my 'old friends' the Guardians are as usual keeping an eye on things..." Download links: filefront Build Time: 5 weeks, starting December 13th. Thanks:- Huge respect to the Dark Mod team for such a great mod and for all the hard work they put into it and continue to put into it. Special thanks to Fidcal, Serpentine and others for their help on the forums and to my beta testers: Serpentine, 7upMan, StiFuNelson, FFox, Acolyte, Chiron and others who did an awesome job. Known issues:- # This mission will have less than optimal fps at a few points on the map. # Enabling bloom on low end PCs will drop off 5-10fps # On low end PCs I recommend, V-sync is off, AA is off, Aniso is 4x or lower. # Additionally, on low end PCs you may have to disable player shadow - bring up the cmd line in tdm (ctrl-alt-`) and then type the following line ' g_showPlayerShadow 0 '

I was referring to D3W advice in general, not the specific text you posted. I've seen several forum posts on D3W and I think even these forums where people have repeated the "fact" that Doom 3 has a problem with more than 3 lights hitting a surface, and advised mappers to cut up brushes to make sure they never see a cyan surface in the r_showLightCount view, even though this was a waste of time that made no difference to frame rates back when I was doing it on a Radeon 9800 XT in 2006. I suspect that the "3 light limit" comes from the descriptive text in the explanation of r_showLightCount: 1. Black= No light hitting the surface. 2. Red= 1 light hitting the surface (this is excellent). 3. Green= 2 lights hitting a surface (this is great). 4. Blue = 3 lights hitting a surface (This is getting bad. You need to keep these areas small, but it is ok to have a number of smaller areas in a room that are blue). 5. Cyan, pink, or white= 4+ lights hitting a surface this is bad and you should only have this in very small, isolated areas. It would be easy to interpret these descriptions as implying that something bad happens between 2 lights ("this is great") and 3 lights ("this is getting bad"), even no there is no such limit and these textual descriptions were (as far as I can tell) just off-the-cuff phrases that never actually reflected any empirical performance testing. There is no such limit for maximum lights, because light count is just one of many factors influencing performance, along with poly count, shadow count, shadow mesh complexity, number of shadow-casting lights, number and size of open/closed visportals and many other things. Giving suggested limits for particular scene elements is counter productive because these limits tend to get enshrined in documents and forum posts and propagated through time as a sort of "cargo cult", where people believe that as long as they have fewer than a certain number of lights or polygons then their scene will be fast to render, even though there may be many cases where having more lights/polygons would be fine if other elements of the scene are simpler, and vice versa. The only meaningful way to address performance is based on empirical testing, with guided optimisations based on this data. For example, if you have a scene that is particularly slow to render, and you find that you have a large surface hit by 20 different lights and they all cast shadows, this might be the thing to optimised, whereas in another scene you might find that you have 10 million polygons in view due to a reflection surface and too many open visportals, and these are the things you need to fix. But in no case does this mean that if you stick to 19 different lights and only 9 million polygons, you will never have a problem with performance. No need to get defensive; I wasn't criticising you, just pointing out that some of that old advice from D3W and other forums isn't particularly accurate and shouldn't be relied upon by today's mappers, particularly when it asserts particular numeric limits that quickly become obsolete due to the evolution of hardware, and might not have been correct to begin with. Nothing wrong with looking at light counts in conjunction with other items (but you must also consider the area of the over-lit polygons, not just the count, and consider the effect of light scissoring which considerably restricts the actual area that is illuminated based on the size of the light, even if that light hits a large polygon), provided you don't become attached to certain fixed "ideal light counts" which are just too crude a measure to be useful. Overall my advice with light count and everything else (polygons, shadows etc) is: Minimise everything as far as you possibly can without compromising the artistic intent. Use in-game diagnostics and statistics as a guide, without being hung up on particular numeric thresholds and values. Test on a variety of hardware (especially mediocre hardware) if you can, to avoid producing a map which only runs well on your super high-end rig.

Yes, Q4 and ET:QW both had their own implementations but D3 never did. (It appears from the leaked D3 demo that at one stage its parser was going to use the C preprocessor, or something like it. DECAL_MACRO is a leftover from that era but is no longer implemented in the same way; probably id never used the preprocessor for anything else and decided it wasn't worth it.) Someone did make this though: https://forums.thedarkmod.com/index.php?/topic/18843-material-generator-bash-script/