Search the Community

Well I didn't get terribly great performance. I was frequently hovering around 30 fps even in simple interiors, for some reason. However, this is one of the greater FMs ever released so far for the Dark Mod, in my opinion. It's architecture and layout, difficulty balance, unique gameplay, readables and lore, all excellent across the board. Lots of opportunity for alternative routes and solutions - for example, I finished the mission with three sets of lockpicks and two sets of "peculiar glasses". So many little stories to discover and threads left open to interpretation or maybe a sequel... It's also a great twist on the usual plague quarter mission. I scored it 5/5/5.

I had some catching up to do but figured I'd give this one a try, thinking it would be a small, short map. An appetizer before going through larger missions. I start the mission, leave the apartment, and immediately know this one is going to be special. 7 hours later, the mission completion screen greets me and I feel a bit sad the ride is over. This FM is that good. I'm a huge sucker for tight alleyways and verticality so I was instantly hooked. The district is huge, with many paths to take, places to rob, and even more secrets to discover. It's really well made and feels like a real place. Speaking of which, informing the player where he is and whether the place is hostile or not when entering a new area was a neat addition. It really helped a ton and prevented me from getting hopelessly lost. Going about the streets without the need to hide was a pleasant change of pace and gave me a chance to admire the architecture. The ambiance and lighting further highlight the creativity that went into this. To me it seems like a passion project, there is so much care and attention to detail! Colour me surprised. Going into this and seeing it was the author's first mission, I expected an okay mission, not a masterpiece that instantly made it among my top 5 all time favourite TDM missions. Another surprise was the performance. Dunno what sort of magic you did but it runs great in all areas. A huge thank you to @Wellingtoncrab and all others involved in the map's creation, you have made a piece of art.

Some parts of this WAD are artistically an A++ in terms of music and level design. Others suffer from too much copy/paste architecture. The volcano level is especially a treat. BTW I break the rules of most of the musicians and (instead of using the Roland GS soundfont that they would expect/tell you to, use the following one). Because in most cases, it sounds a hundred times better. Basically, instead of midi files sounding like they are being played on a cheap little keyboard, it sounds like a huge, expensive organ. Of course you pay for it in terms of memory use. 240MB vs 6MB for the standard soundfont that everybody uses, but on a modern computer, who cares? There are much bigger soundfonts than this one floating around, but I personally would not use them, because in my testing they didn't sound any better, actually worse, than this one. All of the instrument sounds have been perfectly balanced with each other in terms of volume and quality in this soundfont, it was obviously put together by a professional.

Mine is a test map yes, the windows were taken from Black Mage, so load up that, right after the cutscene, and look up at the tower. Though, I don't think you'll get it, RX570 is different hardware and driver architecture. GCN vs RDNA

So interestingly, on the computer with the i7 4770k and EVGA 980ti, I get worse performance with r_shadowmapsinglepass 1 by about 8 fps. r_usemultidrawIndirect set to 0 or 1 makes no difference, maybe 1-2 fps. Bizarre the AMD's architecture is so sensitive to the changes but Nivida's is not.

-> https://forums.thedarkmod.com/index.php?/forum/13-music-sfx/

I mentioned this in the improvements thread - https://forums.thedarkmod.com/index.php?/topic/11058-things-that-could-be-improved/page/95/#comment-473534 Bright readables in a game that is 99% darkness literally burns my eyes.

@HMart, you took issue with me saying: This was my summary of what I thought you meant in these post fragments from a forum linked to by Ref 10 (namely, https://forums.thedarkmod.com/index.php?/topic/20100-idtech-4-gui-scripting/#comment-439778 )... I see I probably shouldn't have added the "[as float parameters]" to the ambiguous "as well" phrase, and perhaps "recommended TDM try" is too strong. Overall, would this be better? "In Ref 10, it is noted that in transition statements, a 4-value color vector must be either a literal or (less reliably) a definevec4. Using a #defined macro for the color vector won't work currently... an idea for a future improvement?" EDIT - I see that a broader revision was needed. So changed to this in https://wiki.thedarkmod.com/index.php?title=GUI_Scripting:_TDM_vs_Doom_3,_Quake_4 ====transition 4-6 parameters==== Often, transition statements have a pair of 4-value color vectors as their 2nd & 3rd parameters. As the discussion in [[GUI Scripting: References & Resources | Ref 10]] indicates, each vector is traditionally represented by a double-quoted literal: transition "matcolor" "1, 1, 1, 0" "1, 1, 1, 0.8" "300" This was id Studio's preferred method, but using a definevec4 user variable was a possible alternative. In addition, TDM can #define colors for transitions. Unfortunately, due to syntax differences, for a particular color, it is not possible to create a single #define that would work with both properties and transitions; thus: #define INACTIVE_COLOR 0,0,0,0.50 #define SINACTIVE_COLOR "0 0 0 0.50" See [[GUI Scripting: Preprocessor Directives]] for further examples. (Possible future improvement: Changing TDM's parsing to let a transition also accept color vectors with commas.) See also the discussion above about 4vect properties and _x, _y, _z, _w suffixes.

Hello everyone! I made 2 changes in the source code. Could you, please, take a look at this? - CMake: Added check of compiler for support C++14 standard CXX_STANDARD supported values are 98, 11, 14, 17 and 20. Ref: https://cmake.org/cmake/help/latest/prop_tgt/CXX_STANDARD.html - ThirdParty/devil: fix for MCST lcc compiler LCC-Win32 and MCST lcc compilers define same identifier (LCC). Have been added check of MCST Elbrus 2000 (e2k) architecture. Ref: https://en.wikipedia.org/wiki/Elbrus_2000 Attached the patch with my changes. C++14_check_for_CMake_+_fix_for_ThirdParty-devil.patch

So... What was up with the forums all day yesterday..?

A spectacular mission! The architecture, the amazing new effects, and of course a couple of unique and original ideas that greatly add to the gameplay. I will certainly play this over trying to uncover the secrets now...

For a while, I've been researching the under-documented GUI scripting language and writing up a new wiki series about it. Fruits of this labor can be seen here: https://wiki.thedarkmod.com/index.php?title=GUI_Scripting_Language As time, interest, and need allows, I hope people will it check parts of it out. It is certainly possible that I didn't get everything right; feedback can be offered here: https://forums.thedarkmod.com/index.php?/topic/21642-feedback-on-wiki-gui-scripting-language-series/ Thanks

I merged everything into my master branch now. It was quite the ride, since the architecture has changed quite a bit in the meantime. I re-played some of the commits to orbweaver/master, but the huge merge commit I was unable to integrate, it was just not matching up. I also had loads of conflicts, mostly because of the architecture changes, but also due to tons of whitespace adjustments. (If you guys want to make my life easier for the next merge, please don't change the whitespace of an entire file, it makes it really hard for me to spot the relevant code lines in a git conflict.) The plugin is compiling in Windows now, but I haven't even tested it. I have to download the correct mod version first, and I'm out of time for today. I'll also do some refactoring in the plugin itself.

Gosh.. Since when did the image upload in the forums stop working... Anyway.. I tried out the new view setup - thanks a lot for all the advices. I positioned a little "attribute bar" to the right. So as soon I select an entity I can see its spawnargs. However what did not matter as it opened as a new window before does come to light now that it is just a small bar: The size of the spawnargs view is really small and there's lots of empty space that could be used for it instead - however I cannot enlarge the attribute / value part of the window - it just stays by a few rows. Maybe I'm doing something wrong - maybe it is a possible new feature in the next update - here is the screenshot: https://ibb.co/PcSmFT2

What I was trying to get at that there is no real difference. The end result is the same. The biggest drawback to the "theme" thing is that to create multiple themes, you have to visit almost everything mutliple times - or make one grand swep through things and assign the into multiple themes - at which point you might just as well "tag" them. For me this is semantic hair splitting, regardless on wether you use: * theme A: contains element a, b,c, d * theme B: contains element a, b,x, y or: * element a: tags A, B * element b: tags A, B * element c: tags A * element d: tags A * element x: tags B * element y: tags B The result from a point of getting the search result is the same, search for A and you get the same "set" in both cases. Just the storage is a bit different laid out. You are storing the same information in both cases, and with the over 10000 "things" we have in TDM (possible 15..20000), you need some sort of central storage and editing, anyway, because there is NO WAY you are gonna sort 2000 material shaders into themes, or tag them manually, and then repeat the same for sounds, particles, skins etc. Edit: Searching for "A" is a bit easier with the themes, because you can just "take" everything in the theme. But thats a storage algorithgm difference, and needs not to be visible to the user. The idea here is that a theme works good if the users wants anything in the theme, but breaks down if you add search modifiers. Like "give me everything from theme A but no sounds, and then add every entity from theme B". At this point the user might as well say "give me everything tagged with A except sounds, and every entity tagged with B" and there is no difference in output. Just that parts and mixing themes makes no so much sense as just saying "give me a list of things that match these tags", which essentialy is. The "theming" thus leads the user to believe they get something different, which they don't.

1. If you want to use custom work (sound, models, textures) from released missions, best thing is to ask the author if he/she agrees. So far, Sotha is the only one who permits unlimited usage of his custom work (he expressed that here on the forums). He just wants to be credited. 2. If mission authors from released maps are not available anymore, then I do not know what to do. @Dragofer@nbohr1more: Any suggestions? I would say, that's the same situation as described above, just replace "released mission" with "abandoned work". As for my released work, feel free to use whatever you want.

I'd say the Tech Support forums are the correct place for rendering issues like this. The DarkRadiant forums are for development and feedback on DR, while the Newbie DarkRadiant Questions thread in the Editing Guild is for general mapping questions. Regarding the silver platter, if I'm not mistaken it contains a reflective stage in its material, which might be conflicting with your mirror. It's not a very noticeable reflection imo, so could derive a new material without that stage and apply it via a skin as a workaround (if nothing else works).

Also, fllood isn't active on the forums a lot it seems, so maybe another person can give authorisation when @fllood isn't around? Just an idea. I guess I could pm this to fllood. Edit:

Would be interesting to also see a shot of the mission in DR too for mappers to get a better idea of how much there is and how dense (brush, patch and entity counts would be good too). @Baal Have you tried sending a PM to fllood? Simply pinging them with @ only gives them a notification when they log into the forums, while a PM will also get sent to their email.

Doom 3's fog design is pretty strange. It re-uses the light architecture to define the volume but it treats the player as the "light_center". The projection image is then projected outward from the player's eyes. From that description ( via the GPL source ), one would expect the "lightFalloffImage" would have an effect on the outward density from the player? From old doom3world.org discussions I recall that it was claimed that the falloff image instead defines the vertical density of the fog in relation to the real light_center. Thus, one could potentially make the transitions smoother by making sure the falloff image was darker near the boundary areas via estimating the radius distance to the real light_center. Not very practical. Looking over the code, I do not even see where lightFalloffImage is handled by fog. It seems to only get the projection image and "fog enter image" that is auto-generated in image programs so I think lightFalloffImage is ignored by fog? https://github.com/TTimo/doom3.gpl/blob/aaa855815ab484d5bd095f347163194ac569abcc/neo/renderer/draw_common.cpp RB_FogPass // find the current color and density of the fog lightShader = backEnd.vLight->lightShader; regs = backEnd.vLight->shaderRegisters; // assume fog shaders have only a single stage stage = lightShader->GetStage(0); ( nbohr1more: doesn't the lightFalloffImage count as a stage? if so, what happens to materials which include it? ) // texture 0 is the falloff image GL_SelectTexture( 0 ); globalImages->fogImage->Bind(); ( nbohr1more: why are they calling a projection image a falloff image ? ) // texture 1 is the entering plane fade correction GL_SelectTexture( 1 ); globalImages->fogEnterImage->Bind(); ( nbohr1more: this image is auto generated, is it somehow altered by lightFalloffImage ? Not that I can tell ) qglDisableClientState( GL_TEXTURE_COORD_ARRAY ); qglEnable( GL_TEXTURE_GEN_S ); qglEnable( GL_TEXTURE_GEN_T ); // T will get a texgen for the fade plane, which is always the "top" plane on unrotated lights ( nbohr1more: this seems to track with the Doom3world description of "vertical density" but is it really controllable ? ) fogPlanes[2][0] = 0.001f * backEnd.vLight->fogPlane[0]; fogPlanes[2][1] = 0.001f * backEnd.vLight->fogPlane[1]; fogPlanes[2][2] = 0.001f * backEnd.vLight->fogPlane[2]; fogPlanes[2][3] = 0.001f * backEnd.vLight->fogPlane[3]; // S is based on the view origin float s = backEnd.viewDef->renderView.vieworg * fogPlanes[2].Normal() + fogPlanes[2][3]; fogPlanes[3][0] = 0; fogPlanes[3][1] = 0; fogPlanes[3][2] = 0; fogPlanes[3][3] = FOG_ENTER + s; qglTexCoord2f( FOG_ENTER + s, FOG_ENTER );

Hello! I just joined the forums to report an annoying bug. I don't know if it's specific to this map or just a game bug but I have played most of the other missions and this is a first for me. Before i picked up the key to the junkroom i tried to open the door and i got the "needs junkroom key" message on my screen... but that message never went away. I had to complete the mission with that on my screen the entire time, overlaying all the other messages that appear. a reload/restart didnt do anything to solve the problem. A few of the on-screen messages at the beginning didn't make sense to me and were kind of cryptic, like a riddle i didn't get. one of them was something about an alarm? otherwise i liked the mission, pretty challenging and I know i missed some spots. cheers

DarkRadiant 2.13.0 is ready for download. A lot of fixes and improvements made it into this release. Several point files can be selected for display now. DarkRadiant is now capable of comparing maps, both in differential A vs. B comparisons as well as three-way merge scenarios (when both maps share the same ancestor). Windows and Mac Downloads are available on Github: https://github.com/codereader/DarkRadiant/releases/tag/2.13.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.12.0 Feature: Ability to choose from several different pointfiles Feature: Aspect ratio preserving Fit Texture option Feature: ModelSelector: add ability to rescan folders without having to reload all models Feature: Add "Show Material Definition" to ShaderSelector tree views Feature: Paste material-header to surface from clipboard with hotkey. Feature: A way to display editor_usage in the Entity Inspector window Feature: Selection by coords Feature: Three-Way and Differential Map Merge Feature: Map Comparison/Diffing Feature: Git Version Control Integration Plugin Improvement: Show axis when 'R'otating entities Improvement: Improve workflow for adjusting light brightnesses Improvement: Map Loading Performance Improvements Improvement: Refresh entity inspector when reloading defs Improvement: Increase maximum zoom level of 2D views Improvement: "Choose entity..." button for all def_ spawnargs Improvement: CTRL + MMB in orthoview: place camera at height of most recent selection Improvement: Added Documentation for Layer Script Interface Improvement: "Shift textures randomly" shifts all selected faces by the same amount Fixed: Problems with particle preview obstructing the view Fixed: Cannot view or copy from built-in Filters Fixed: Auto-save is slow when animation or particle viewer is playing Fixed: Non uniform light volume scaling not working Fixed: BC5 normal maps cannot be loaded Fixed: Copying a particle in the Particle Editor creates an ___editor list entry which can lead to crashes Fixed: Create Entity window no longer remembers the previous item Fixed: Model exporter: no model is exported if folder path doesn't exist yet Fixed: Non power of 2 textures show up black in Fixed: 'Change game/project' fails to save if a decent-sized .map was loaded Fixed: Reload Defs is messing up the entityDefs Fixed: Crash when using Reloading Defs after placing an Entity Fixed: Entity & Speaker windows don't remember their size Fixed: Restore non-uniform scaling for texture browser. Fixed: Some ASE models do not load Fixed: Prefabs importing miles away Fixed: Path entites rotate 15 degrees, each time when dragged. Fixed: Crash when activating GameConnection Feature "update entities on every change" Fixed: Model previewer not displaying ASE or LWO models Fixed: Crash when selecting an MD5 model in "Create Model..." menu Fixed: Crash when activating the Material Editor in Doom3 game config The list of changes can be found on the our bugtracker changelog. Have fun mapping!