Search the Community

@snatcher I understand that when you feel your work doesn't live up to your goals that you don't want it out in the wild advertising your own perceived shortcomings but that leads to a troubling dilemma of authors who are never satisfied with their work offering fleeting access to their in-progress designs then rescinding them or allowing them to be lost. When I was a member of Doom3world forums, I would often see members do interesting experiments and sometimes that work would languish until someone new would examine it and pickup the torch. This seemed like a perfectly viable system until Doom3world was killed by spambots and countless projects and conceptual works were lost. I guess what I am trying to say is that mods don't need to be perfect to be valuable. If they contain some grain of a useable feature they might be adapted by mission authors in custom scenarios. They might offer instructive details that others trying to achieve the same results can examine. It would be great if known compelling works were kept somewhere safe other than via forum attachments and temporary file sharing sites. I suppose we used to collect such things in our internal SVN for safe keeping but even that isn't always viable. If folks would rather not post beta or incomplete mods to TDM's Moddb page, perhaps they would consider creating their own Moddb page or allow them to be added to my page for safe keeping. Please don't look at this as some sort of pressure campaign or anything. I fully understand anyone not willing to put their name next to something they aren't fully happy with. As a general proviso, ( if possible \ permitted ) I just want to prevent the loss of some valuable investigations and formative works. The end of Doom3world was a digital apocalypse similar to the death of photobucket. It is one of my greatest fears that TDM will become a digital memory with only the skeletons of old forum threads at the wayback archive site.

I'd love some criticism, thank you! I'm very glad that you got super absorbed into this FM's atmosphere, I loved reading your theories about the story! Your criticism about the readables/story is entirely valid and highlights an element that is most often criticized about Lovecraft's work: you rarely get straight answers or a clear picture of the greater threat. I encourage you to read the original "The Terrible Old Man" (all of H.P. Lovecraft's works are in the public domain and readable online), as you'll get an idea of how short and vague the source material was as well as the careful moves I had to make to not show my hand too much when constructing the narrative. Whether or not I kept in line with Lovecraft's principles is for others to judge, but I'm glad your imagination went wild with this FM! Your curiosity regarding what the bottles are, what the purpose of the little statuettes is, and immersion into the story from what little breadcrumbs I planted gave me a smile from ear to ear. Thanks, Bergante!

Congrats on the release! Remember to check ThiefGuild as well as the DarkFate forums (via Google Translate) for additional feedback.

I think this will always be a divide. Engine coders will want a universal behavior that acts the same way across all missions. So if we want to offer the additional benefits of Shadow Maps, we will need to break lots of missions and then work to fix them. Mappers will probably want material or entity flags that force these behaviors so that they can force usage where they prefer. I think defaulting to consistent with Stencil rules is a good idea. Maybe this is a good case for using mission.cfg and have it force the cvars to enable the features?

As everyone know, right now we have both stencil shadows and shadow maps in the engine, and the player is mostly free to choose whichever he likes more. Due to the reasons I provide below, stencil shadows will most likely be dropped in some future, but that future is definitely not here yet. Unlike shadow maps, stencil shadows do not support: Alpha-tested shadow occluders. Shadows on translucent surfaces. Volumetric lights with account for shadows. Soft shadows with contact hardening. Point 4 can be ignored, point 3 has an automatic workaround by forcing lights with volumetrics to shadow maps. Points 1 and 2 result in major difference in behavior between the two modes. For the reference, we have one more technical difference: Front faces cast shadows in shadow maps mode, but don't cast them in stencil shadows mode. I recall how initially volumetric lights had their shadows disabled in stencil shadows mode, and mappers were not happy because that's a big difference in behavior. One issue was that every mission has to be beta-tested in both modes. That's why right now I mostly follow the same strategy: Alpha-testing is disabled when rendering shadow maps (since 2.12), unless you enable r_shadowMapAlphaTested. Shadows are disabled on translucent objects (since today's 2.13 dev build), unless you enable r_shadowMapOnTranslucent. I wonder if this is still what majority of the mappers think is best?

Changelog of 2.13 development: dev17042-10732 * Restored ability to create cvars dynamically, fixing bow in missions (5600). * Fixed issue where .cfg files were saved every frame (5600). * Added sys.getcvarf script event for getting float value of cvar (6530). * Extracted most of constants from weapon scripts into cvars (6530). dev17035-10724 * Support passing information between game and briefing/debriefing GUI via persistent info. Also changed start map & location selection, added on_mission_complete script callback (6509 thread). * New bumpmapped environment mapping is now default (6354). * New behavior of zero sound spawnarg is not default (6346). * Added sound for "charge post" model (6527). * Major refactoring of cvars system to simplify future changes (5600). Known issues: * Bow does not shoot in some missions (only in this dev build): thread dev17026-10712 * Nested subviews (mirrors, remotes, sky, etc.) now work properly (6434). * Added GUI debriefing state on mission success (6509 thread). * Sound argument override with zero now works properly under cvar (6346 thread). * Environment mapping is same on bumpy and non-bumpy surfaces under cvar (6354 thread). * Default console font size reduced to 5, added lower bound depending on resolution. * Added high-quality versions of panel_carved_rectangles (6515). * Added proper normal map for stainglass_saint_03 (6521). * Fixed DestroyDelay warning when closing objectives. * Fixed the only remaining non-threadsafe cvar (5600). * Minor optimization of depth shader. * Added cm_allocator debug cvar (6505). * Fixed r_lockView when compass is enabled. dev17008-10685 * Enabled shadow features specific to maps implementation (poll). * Auto-detect number of parallel threads to use in jobs system (6503). * Improved parallel images loading, parallelized sounds loading, optimized EAS (6503). * Major improvements in mission loading progress bar (6503). * Core missions are now stored uncompressed in assets SVN (6498). * Deleted a lot of old rendering code under useNewRenderPasses + some cleanup (6271). dev16996-10665 * Environment mapping supports texcoord transforms on bumpmap (6500). * Fully disabled shadows on translucent objects (6490). * Fixed dmap making almost axis-aligned visportals buggy (6480). * com_maxFps no longer quantizes by milliseconds on Windows 8+. * Now Uncapped FPS and Vsync are ON by default. * Supported Vsync control on Linux. * Added set of prototype materials (thread). * Fixes to Stone font to remove stray pixels (post). * Loot candlestick no longer toggle the candle when taken. * Optimized volumetric lights and shadows in the new Training Mission (4352). * Fixed frob_light_holder_toggle_light on entities with both skin_lit and skin_unlit. * Now combination lock supports non-door entities by activating them. * Added low-poly version of hedge model (6481). * Added tiling version of distant_cityscape_01 texture (6487). * Added missing editor image for geometric02_red_end_HD (6492). * Added building_facades/city_district decal material. * Fixed rendering with "r_useScissor 0" (6349). * Added r_lockView debug rendering cvar (thread). * Fixed regression in polygon trace model (5887). * Added a set of lampion light entityDefs.

Welcome to the forums Ansome! And congrats on making it to beta phase!

"...to a robber whose soul is in his profession, there is a lure about a very old and feeble man who pays for his few necessities with Spanish gold." Good day, TDM community! I'm Ansome, a long-time forums lurker, and I'm here to recruit beta testers for my first FM: "The Terrible Old Man", based on H.P. Lovecraft's short story of the same name. This is a short (30-45 minute), story-driven FM with plenty of readables and a gloomy atmosphere. Do keep in mind that this is a more linear FM than you may be used to as it was deemed necessary for the purposes of the story's pacing. Regardless, the player does still have a degree of freedom in tackling challenges in the latter half of the FM. If this sounds interesting to you, please head over to the beta testing thread I will be posting shortly. Thank you!

This one has nothing to do with the change. It happens in 2.11 too. I have no idea what is wrong here, and why one patch casts shadow while the other similar one does not. There is even auxilliary surface with "shadow" material inside the stairs, which should also cast shadow but it does not.

Are you aware of the pointfile feature? Dmap writes these .lin files into the maps directory. Display them with File->Pointfile and look for red lines that visualize problems like leaks and visportal problems. Which faces of a brush are sealing depends on the material assigned to the face. I don't know exactly which ones seal and which don't.

New script for mappers: my flavour of a fog density fading script. To add this to your FM, add the line "thread FogIntensityLoop();" to your map's void main() function (see the example in fogfade.script) and set "fog_fade" "1" on each foglight to enable script control of it. Set "fog_intensity_multiplier" on each info_location entity to change how thick the fog is in that location (practically speaking it's a multiplier for visibility distance). Lastly, "fog_fade_speed" on each foglight determines how quickly it will change its density. The speed scales with the current value of shaderParm3, using shaderParm3 = 1000 as a baseline. So i.e. if shaderParm is currently at 1/10th of 1000, then fade speed will be 1/10th as fast. Differences to Obsttorte's script: https://forums.thedarkmod.com/index.php?/topic/14394-apples-and-peaches-obsttortes-mapping-and-scripting-thread/&do=findComment&comment=310436 my script uses fog lights you created, rather than creating one for you. Obsttorte's script will delete the foglight if entering a fogfree zone and recreate it later more than one fog light can be controlled (however, no per-fog-light level of control) adding this to the map requires adding a line to your void main() script, rather than adding an info_locations_settings entity with a custom scriptobject spawnarg in my script, mappers set a multiplier of fog visibility distance (shaderParm3), while in Obsttorte's script a "fog_density" spawnarg is used as an alternative to shaderParm3 smaller and less compactly written script fogfade.scriptfogfade.map

So I was reading the DarkRadiant Script Reference and it gives an example to move the cameraview by setting coordinates: import darkradiant as dr camview = GlobalCameraManager.getActiveView() camview.setCameraOrigin(dr.Vector3(50,0,50)) This works, but then I wanted to use the tdm position coordinates that you can get by doing getviewpos in the console in tdm. But these coordinates don´t give the same position in DR. Why is that? Is there an other way? Edit: WHOOPS it does actually work. (some layers in the testmap were disabled)

Here's my first FM. A small and easy mission, inspired by Thief's Den and The Bakery Job, where you must find and steal a cook's recipe book in order to save a friend from going out of business. Download: Mediafire (sk_cooks.pk4) TDM Website's Mission Page The in-game mission downloader Thanks to: The people who helped me get this far, both in the forums and on Discord. The beta testers: MirceaKitsune, Mat99, Baal, wesp5, Cambridge Spy, jaxa, grodenglaive, Acolytesix ( Per the author in the beta testing thread. ) Skaruts has given permission to the TDM Team to add Subtitles or Localization Strings to this mission. (No EFX Reverb.) If anyone from the Community or TDM team wishes to create these we will gladly test them and update the mission database.

With TDM 2.12, after the credits finished, the "Mission Complete" screen did not display. I found that the screen was black and I could hear my footsteps when I tried to move around. I think the reason for the mission not completing successfully was that the "Do not kill or harm allies" objective was never marked as "1 = STATE_COMPLETE" instead it was left as "0 = STATE_INCOMPLETE". Note, I didn't use noclip throughout the mission. Same as: https://forums.thedarkmod.com/index.php?/topic/18054-fan-mission-the-accountant-2-new-in-town-by-goldwell-20160509/&do=findComment&comment=458491

How about using TDM automation framework (and maybe pcem/qemu)? More info see: https://forums.thedarkmod.com/index.php?/topic/19828-automation-features-and-discussion/

IIUC, fresnel uses view direction and surface normal vectors. This is a comparison between simple brush cube and one with chamfered edges on geometry, both using the same tiling material: Brush cube is on the right; in the background you see a cube with chamfered edges. There is a thin line on the bottom of the brush cube, because it matches the normalmap, the mortar part of the bricks. But as soon as I change texture coordinates of the brush: While the chamfered cube has enough geometry to work with fresnel shader, even if I change texture coordinates: So it seems to work as described, it needs either geometry normals or details faked on normalmap. I think fresnel in other pre-pbr engines, like UE3, works the same or similar way.

Hm, I am not sure I follow. Shouldn't the behaviour of the Rim shader be independet of actual geometric complexity and normal map based complexity? If the answer is yes, then brushes should also look fine because the applied material provides geometric complexity. Reshade is awesome. I use it all the time to improve the visuals of old classics. The Post-Lightmaps-Era games just look so much better with some SSAO...

OK. Thanks! In my case the issue is moot because I don't know how to do it. Hence my plea for help... If an FM author built their mission using assets that are licensed CC-BY-NC-SA (which I believe all do), if I understand correctly then that means they must license that mission under CC-BY-NC-SA too. Which in turn means anyone can build further on their work as long as they follow the conditions stipulated in the license. It seems odd to release a work under a certain license and then say "but I don't want you to do what the license explicitly grants you to do". "Applying a Creative Commons license to your material is a serious decision. When you apply a CC license, you give permission to anyone to use your material for the full duration of applicable copyright and similar rights." (https://creativecommons.org/faq/) If an author once benefited from the license when they created their mission, why would they not want others to benefit similarly from the same licenses? The license requires their name be mentioned in every remix that follows. At the same time I can understand that some creators more than anything want to create. The desire and drive to create may be so great that they accept conditions during the time of creation, to give them artistic freedom and to use the best available assets; contitions that they regret later when their work is finished and published, and they want to keep control over it. For the OMs I think the project as a whole would benefit from a relaxed and welcoming stance towards changes.

@stgatilov Can answer this one. I think there's an argument for having this as a material effect to make assets stand out but I am not sure about "tying it to the ambient" light when we eventually plan to have those lights globally render proper fresnel at some point.

On a slightly related note, why ambientrimcolor material keyword was removed in 2.11? Notes show that it was "unused" – was it even advertised to mappers and content creators?

To cater to both audiences. I mentioned LibreGameWiki as one example. nbohr1more mentioned other uses. Explicitly allowing reuse and spread will help TDM reach a wider audience and would hopefully attract more volunteers. More volunteers which can help improve both TDM versions. There are several benefits for a project of being in the Debian repo. One is that TDM Debian-users can report defects on any package directly to Debian (no need to register on separate forums). Debian may then fix the issue themselves (in their "TDM-libre" package) and will offer the patch upstream to TDM, who can then choose to accept or reject the patch. I envision "TDM-libre" to have the same capability of downloading any mission as regular TDM. The only difference is that "TDM-libre" would come packaged with the regular engine (which is GPL+BSD) and an included mission that has libre media/gamedata. When I play TDM by myself, I want the unlimited-play and can accept commercial restrictions. But if I were to promote it somewhere, or charge for a stream when playing online, or make a video, I would want a version without commercial restrictions (and can temporarily accept limited-play) to make sure I don't violate anyone's copyright. Perhaps. That's what I'm trying to find out.

I suggest you use the term "I", to make clear that it is something YOU want, and that you speak for yourself. But, as wesp5 mentioned, I don't really know what this is about, at all. And, I'm also wondering about all the newly registered people lately, who just arrived at this forum, and already want to revolutionize this mod. This is a thing I noticed 2 or 3 years ago, and which hasn't been present in the 15 years I play this mod and frequent these forums now. Really seems like a common thing these days, to not knock on the door, but kick it in, and stomp right in.

When talking about a possible libre version of TDM (https://forums.thedarkmod.com/index.php?/topic/22346-libre-version-of-tdm/) it seems we believe all media/gamedata included in TDM is licensed CC-BY-NC-SA. I am not familiar with how the process of adding new media/gamedata works today; I have seen files uploaded to the bugtracker which developers then commit to SVN, but I don't know if there are other ways. It may be a good idea to implement a process that when new components (media/gamedata included in TDM) are added, the contributor is asked to be explicit about the license (a choice which may defaults to their previous preference, for usability). It won't fix the past, but it may help in the future. This will make it easy for contributors to add future data under a more permissive license if they choose. Libre media can be added and its license can be tracked, rather than assumed to be CC-BY-NC-SA. I suggest looking at how Wikimedia Commons has implemented this: the contributor state the source and license at the time the data is uploaded. This can be done either by providing urls or by saying "It's my work and I choose this licsense". The first step could be to add a way to keep track of each filepath in SVN, author, license, sources. Start by setting the value for each file's license to "(default/legacy CC-BY-NC-SA)". Possible implementations for a user interface for new additions are: * Use our own wiki, which runs Mediawiki (same as Wikimedia Commons). I see several benefits of this, but we also need a way to accept uploads of batches, not just single files. * Look at how other open source projects have solved this. There may be more appropriate solutions available. ... but I'll leave the implementation open. Suggestions are very welcome! If the author of each file already in SVN can be tracked, then it may be possible that the author is willing to give a blanket permission for all their past files in one statement, and all their files in SVN can be updated in one commit. A productive contributor willing to release some of their work under a more permissive license could make a big change. If Dark Radiant would support letting mappers search media/gamedata by license (does it already?), it would make it easier for mappers to create a completely libre mission, which would help facilitate a TDM-libre release. If I understand things correctly. This post does not address all details and it may contain misunderstandings or assumptions, but it's a start. Also relevant: * Is there a compiled and maintained list of recommended or deprecated resources for mappers to use? * https://forums.thedarkmod.com/index.php?/topic/20311-external-art-assets-licensing/

Yes, I considered this idea. But it won't help much, I believe. If several mirrors are allowed, you can split your surface into individual planar polygons and hope for the best. But if you have 10+ polygons, then I suppose the best won't happen Internally, the material has "mirrorRenderMap" keyword which triggers rendering of subview. This subview is than copied into a texture. In the main view, the surfaces with mirror material should be rendered as any other surfaces, it can just use this dynamically generated surface. I'm not sure what exactly you want. If you want the mirrored view to be distorted by normal map, then yes: this is definitely not supported. The reflected texture is generated as if reflected by a perfect plane. Maybe we can add some kind of warp shader that deforms the image mathematically according to the normalmap, but this would be a new feature.