Search the Community

I notice now that the sitting pose of ai is like they're leaning, but in this case there's no back to lean on. I guess there's that shining mirror plate. If you don't want it to reflect, you could remove the reflection from the material?

I think it's time to replace the frob material stages with a shader (probably add a param to the existing ambient shader) There is more than one angle to this issue but I am mainly concerned about too many stages in materials that are somewhat taxing in terms of performance. Imagine rendering of 3K surfaces interacting with 3 lights in average and using materials with 7 stages in average. The renderer loops through every stage for every surface making it ~ 20K checks per loop. It has to happen during the depth stage, then each light and then the ambient pass resulting in 100K checks. It makes sense to try to reduce this load, especially considering that the frob stage is relatively rarely invoked and the checks happen on the backend making it hard to parallelize the computation. I am thinking adding a top-level material keyword that would apply as frob color and get passed to the ambient shader when the surface is a part of a frobable entity. I would like to hear your thoughts from the mapper/designer POV.

Good catch. I fixed the .gui name, and added afterwards this brief explanation: The value here is a path to a custom video material shader. It is set at runtime by the engine, based on information the FM author provided in mainmenu_custom_defs.gui as, e.g.: #define MM_BRIEFING_VIDEO_MATERIAL_1 "video/tdm_briefing_video" (In older FMs, the video was chopped into parts, in which case the engine updates the value just-in-time. See comments in mainmenu_custom_defs.gui for details.) FYI, there is a similar system for debriefing videos.

Cool, I think this should help a lot. First off, there is an alpha channel in my vertex-blend texture, so I'll remake that without it. The "blend diffusemap" was from the DrVertexBlend tutorial, but I'll try using "blend add" instead. I had mistakenly thought the first line of the material file was referencing the vertex-blend image, so I should just be giving the material a name there? OK, I'll fix that too. Thanks!

I'm not having much success with vertex blending a cobblestone path with grass. I've applied it to an .ase model imported from Blender. I followed this tutorial: https://wiki.thedarkmod.com/index.php?title=DrVertexBlend_(tutorial)#Vertex_Painting_Each_Object In DR, my custom material file does show up in the material editor and it seems to be getting applied to the model but incorrectly - it's just a uniform green. In game, the model is greyscale - I think it's getting textured with my vertex-painting, instead of the grass and cobblestone. Here's the mtr file. Have I overlooked anything? textures/darkmod/map_specific/lawn_vertex_blend { surftype15 description "grass" qer_editorimage textures/darkmod/nature/grass/short_dry_grass_dark_ed.jpg { blend diffusemap map textures/darkmod/nature/grass/short_dry_grass_dark vertexColor } { blend bumpmap map textures/darkmod/nature/grass/short_dry_grass_local vertexColor } { if ( parm11 > 0 ) blend gl_dst_color, gl_one map _white rgb 0.40 * parm11 vertexColor } { if ( parm11 > 0 ) blend add map textures/darkmod/nature/grass/short_dry_grass_dark rgb 0.15 * parm11 vertexColor } { blend diffusemap map textures/darkmod/stone/cobblestones/cobblestones02_square_dark inverseVertexColor } { blend specularmap map textures/darkmod/stone/cobblestones/cobblestones02_square_dark_s inverseVertexColor } { blend bumpmap map textures/darkmod/stone/cobblestones/cobblestones02_square_dark_local inverseVertexColor } { if ( parm11 > 0 ) blend gl_dst_color, gl_one map _white rgb 0.40 * parm11 inverseVertexColor } { if ( parm11 > 0 ) blend add map textures/darkmod/stone/cobblestones/cobblestones02_square_dark rgb 0.15 * parm11 inverseVertexColor } } "lawn_vertex_blend" is the vertex-blended DDS image file exported from Blender and is also referenced in the .ase file.

Thanks for the replies, gonna try those spoiler Tags again now for my short review (oh well it inserted one above my text now and I can't seem to delete it on mobile - this text editor is strange)

Just finished this mission and wow I gotta say in great honor to Grayman and of course the rest of the team picking it up, this was something I've never seen before in any other TDM mission, especially visually wise. I am so happy that grayson gave green light for other experienced mappers to finish his last mission. And what came out of this is really something special. I'll put my review in spoiler tags since I'm now referring to critical mission details. Edit - How do I put spoiler text here on mobile?? [spoiler] test [/spoiler][SPOILER] test [/SPOILER] [spoiler[spoiler [sfah

When exporting from Blender to TDM in .lwo format, it's necessary to set the material names to textures/darkmod/,,,,something. If an object has a lot of textures it's going to be tedious to search the mtr files to get the right name. The same goes for applying textures to imported .lwo objects. I wrote this plugin to make that task much easier. Version 2.8.0 Download: Go to the GitHub page: https://github.com/RSoul82/Blender-TDM-Material-Manager Right click the .py file, then go to Save As and put it in some folder. (Or go to Clone or Download and save it as a zip file to your computer). The old version, for Blender 2.79, is here: https://github.com/RSoul82/Blender-TDM-Material-Manager/tree/Blender-2.79-archive (this is unlikely to be upgraded unless it causes serious problems) It'll be interesting to see how this is in the wild.

I confirmed that the noPortalFog material flag fixes this behavior: Modified delta1_fog material def: // legacy fog material fogs/delta1_fog { fogLight noShadows noPortalFog // prevents fog distance from closing portals { map _fog alpha 0.5 colored } } I'll look into added an entity flag because that's way more convenient than using override materials.

I finally got around to finishing this. It took me almost five hours but I managed to get all the loot and alert nobody. Some of the treasure I had to find on my way back because I'd missed it on the first try, but it did at least give me something to do on the return trip. Really nice mission, with lots of varied environments and (mostly) logical puzzles. The whole thing looked great too. St Wilbert's tomb was a highlight, as was the underwater base. Battlestar Galactica reference! I thought the tile floor spam in the Citadel itself made moving around more tedious than dangerous. Super cool mission. I'm looking forward to playing Anomaly, and then seeing what more you have in store for the HH series.

No, it does not. Caulk, shadowcaulk, or any other opaque material are the same for the sake of area/portal structure. All brushes with such textures are blockers of the same kind. The difference is that caulk is not rendered, is not lit, and does not cast shadows. Shadowcaulk is supposed to cast shadows (while still not being rendered and not lit).

Okay, I had no idea, I have googled it up now and you are right, to my own surprise. Done, I´ve put some paragraphs which were previously not in spoiler tags into spoilers.

Thebigh is right. The pronunciation tripped me up too, but that is apparently how Leicester is pronounced. Also @TarhielI'm glad you are loving the FM but do you mind putting spoiler tags on your post please

Hi, I need to know what the code is to use Spoiler Tags. I am using my tablet and I don't have the options to use anything, like spoiler tags, quote tags, text changes etc. Thanks

The modules are comprised of models, they are completely ignored by the area-portal graph. And now they don't cast shadows if it is proved that light beams travelling though visportals don't touch them. If you use caulk to create areas, then there is nothing that would cast shadows: brushes don't cast shadows because they don't exist (caulk), and modules don't cast shadows because according to area-portal graph they are not hit by light to begin with. There is internal material called "shadowcaulk". As far as I understand, it is not drawn as ordinary surfaces, but it does cast shadows. I think in order to work properly with new optimization, shadowcaulk should be preferred to caulk for the brushes.

@MirceaKitsune try something other than caulk on that brush and see if it goes away. Make sure it's not a no shadows or transparent material.

@Goldwell This missing material I found in TDM 2.03: This does have vertex program code (arb?) still in it, not sure if really needed. This is how it looks ingame (when I add the material to the fms material folder): Not sure if this is how it's supposed to look, but better than nothing. This texture now shows up fine (previously I reported there was a black square on it). Maybe Dragofer fixed it for 2.11:

We will look at some of this stuff, but SPOILER tags, please!!!

Public release v1.7.6 (with Dark Mod support) is out. Improvements since the final beta 14 are: Fixed a few remaining bugs with zip/pk4 support. Game Versions window now properly displays TDM version. Import window no longer has a vestigial off-screen TDM field (because TDM doesn't need or support importing). Web search option is now disabled if an unknown/unsupported FM is selected. If an FM with an unknown or unsupported game type is selected, the messages in the tab area now no longer refer to Thief 3 ("Mod management is not supported for Thief: Deadly Shadows"). The full changelog can be viewed at the release link. The de facto official AngelLoader thread is here: https://www.ttlg.com/forums/showthread.php?t=149706 Bug reports, feature requests etc. are usually posted there. I'll continue following this thread though. Thanks everyone and enjoy!

Regarding issue #4991, Id like to help if I can by giving you guys some sound samples. Ive got some moderately decent equipment I think can be utilized to capture some ladder slide sounds. Ive got a Behringer C-1 mic and an AKAI EIE Pro audio interface that need to see more use. Ive only ever really used it to record some garage band jam sessions. Unless you know audio brands thats all pointless info, what Im getting at is this: despite using it in a non controlled chaotic atmosphere, we got really decent levels and it sounded alright for having 5 instruments going at once. In a controlled environment where I can focus on just one sound, I think I could really capture some viable samples. But before I get out all the cables and turn a closet into a recording booth Id like to have a really solid plan so I can execute all the recording in one go. Or in as few sessions as possible. So how best to go about this? What materials do we need? (Metal, wood, vines/foliage) What variables are we looking for? (Gloves/no gloves, if gloved then fabric or leather, speed, length of slide, friction coefficient from pressure applied, do we want that satisfying squeak from the palms/fingers as they drag across a smooth surface) What factors/variables are most desirable for this particular project? I want to have a real solid plan of attack and thorough steps laid out in a notebook, so the longest aspect of the recording process will be saving/naming each file. What do you guys think? I want to help any way I can so lets form a plan!

This may make sense in that the performance impact of the volumetric effect can scale with how much of the effect is filling the screen. We shipped with a “performance mode” but had to setup the entities by hand to do it (so it’s not perfect). If you change the LOD detail settings to “Low” or “Lowest” this will disable certain lights, particles and such that can be very heavy to render. You can try these settings and see if you notice an improvement. If not sending us some pictures of heavy areas (with spoiler tags please) will be helpful with tuning these “performance modes” in subsequent patches. Thanks for playing!

Wonderful, thank you! I had success in getting the base setup to work with one of the symbol textures, couldn't ask for better functionality I use the following material setup adapted from that example, might simplify it further if specular doesn't need to be defined separately like that: lights/biground1_spectrum { spectrum 1 description "Round point light." { forceHighQuality map lights/biground1.tga colored zeroClamp } } textures/darkmod/decals/symbols/magic_symbol_circle01_spectrum { qer_editorimage textures/darkmod/decals/symbols/magic_symbol_circle01_ed translucent noshadows twosided nonsolid spectrum 1 sort 5 bumpmap heightmap (textures/darkmod/decals/symbols/magic_symbol_circle01, 2) diffusemap textures/darkmod/decals/symbols/magic_symbol_circle01 { blend specularmap map textures/darkmod/decals/symbols/magic_symbol_circle01 red .25 green .25 blue .2 } // TDM Ambient Method Related { if (global5 == 1) blend add map textures/darkmod/decals/webs/web4 scale 1, 1 red global2 green global3 blue global4 } } There are three secondary problems I'll need to address now, let me know the solutions you propose. When given "texture lights/biground1_spectrum", the light will illuminate the hidden symbol as desired, but no longer shine on anything else. I presume there's no way to tell it you want "spectrum 1" but also for it to shine on everything else like a normal light? If not I'll just have to give my lantern two light sources. How to make the lantern entity work with this? I'd prefer the player being able to press the use key while holding it to turn the light on and off. I'm using atdm:moveable_lantern_oil_hand_colorme_lit: Apparently the lantern ent doesn't inherit a light type itself but attaches one similarly to the torch... I'm seeing "def_attach light_lantern_oil_omni" so I can probably just inherit and override that. Anything special I must do to ensure the still light toggles when the lantern is used? Especially if I'll have to attach the UV light separately to get both UV and standard lighting, will operating the lantern toggle both the normal light and my additional "def_attach_0 light_lantern_oil_omni_spectrum"? This works fine with a decal texture, but I was wondering if there's an easy way to make it work with an in-world GUI for text written as a spawnarg? That's when you make your patch func_static, texture it with "textures/darkmod/decals/signs/decal_gui", give it the spawnarg "gui guis/readables/sign_text_decals/sign_text_camberic.gui", then use "gui_parm1 my_text" to make it say something. Is it as simple as creating a "textures/darkmod/decals/signs/decal_gui_spectrum" with the "spectrum 1" keyword in the material and it just works? I believe GUI text wasn't rendered like a conventional material per say, as the fonts themselves don't inherit the properties of that material nor receive light to my knowledge.

The compilation for the latest version pulled from Github fails for me with the following error messages: /usr/bin/ld: CMakeFiles/radiantcore.dir/vfs/DeflatedInputStream.cpp.o: in function `archive::DeflatedInputStream::~DeflatedInputStream()': DeflatedInputStream.cpp:(.text+0x1b): undefined reference to `inflateEnd' /usr/bin/ld: CMakeFiles/radiantcore.dir/vfs/DeflatedInputStream.cpp.o: in function `archive::DeflatedInputStream::read(unsigned char*, unsigned long)':/usr/bin/ld: CMakeFiles/radiantcore.dir/vfs/DeflatedInputStream.cpp.o: in function `archive::DeflatedInputStream::~DeflatedInputStream()': DeflatedInputStream.cpp:(.text+0x1b): undefined reference to `inflateEnd' /usr/bin/ld: CMakeFiles/radiantcore.dir/vfs/DeflatedInputStream.cpp.o: in function `archive::DeflatedInputStream::read(unsigned char*, unsigned long)': DeflatedInputStream.cpp:(.text+0xaa): undefined reference to `inflate' /usr/bin/ld: DeflatedInputStream.cpp:(.text+0xca): undefined reference to `inflate' /usr/bin/ld: CMakeFiles/radiantcore.dir/vfs/DeflatedInputStream.cpp.o: in function `archive::DeflatedInputStream::DeflatedInputStream(InputStream&)': DeflatedInputStream.cpp:(.text+0x149): undefined reference to `inflateInit2_' collect2: error: ld returned 1 exit status make[2]: *** [radiantcore/CMakeFiles/radiantcore.dir/build.make:4154: radiantcore/libradiantcore.so] Error 1 make[1]: *** [CMakeFiles/Makefile2:787: radiantcore/CMakeFiles/radiantcore.dir/all] Error 2 make: *** [Makefile:130: all] Error 2 DeflatedInputStream.cpp:(.text+0xaa): undefined reference to `inflate' /usr/bin/ld: DeflatedInputStream.cpp:(.text+0xca): undefined reference to `inflate' /usr/bin/ld: CMakeFiles/radiantcore.dir/vfs/DeflatedInputStream.cpp.o: in function `archive::DeflatedInputStream::DeflatedInputStream(InputStream&)': DeflatedInputStream.cpp:(.text+0x149): undefined reference to `inflateInit2_' collect2: error: ld returned 1 exit status make[2]: *** [radiantcore/CMakeFiles/radiantcore.dir/build.make:4154: radiantcore/libradiantcore.so] Error 1 make[1]: *** [CMakeFiles/Makefile2:787: radiantcore/CMakeFiles/radiantcore.dir/all] Error 2 make: *** [Makefile:130: all] Error 2 Any idea how I can fix this? Thanks

Good work! I enjoy short missions because things are nice and focused - you get in, you get out. Also I tend to do better with the loot amounts and I was able to get all the loot without too much trouble, which is rare for me. If I were to make a suggestion though - I found the intro briefing sequence a bit distracting because it was so obvious the narration was pitch-shifted to make a deeper voice. If you felt the original voice wasn't deep enough for your needs, I would either get someone on the forums to record it for you or just leave as is. That's my only real complaint and it's not even about the mission itself, so pretty good first start!

oops nope its a single step lacking for the make routine [ 98%] Building CXX object radiant/CMakeFiles/darkradiant.dir/xyview/tools/MeasurementTool.cpp.o [ 98%] Building CXX object radiant/CMakeFiles/darkradiant.dir/xyview/XYWnd.cpp.o [ 99%] Linking CXX executable darkradiant /usr/bin/ld: //usr/local/lib/x86_64-linux-gnu/libgio-2.0.so.0: undefined reference to `g_utf8_validate_len' /usr/bin/ld: //usr/local/lib/x86_64-linux-gnu/libgio-2.0.so.0: undefined reference to `g_source_set_dispose_function' /usr/bin/ld: //usr/local/lib/x86_64-linux-gnu/libgio-2.0.so.0: undefined reference to `g_unix_get_passwd_entry' collect2: error: ld returned 1 exit status make[2]: *** [radiant/CMakeFiles/darkradiant.dir/build.make:2669: radiant/darkradiant] Error 1 make[1]: *** [CMakeFiles/Makefile2:1008: radiant/CMakeFiles/darkradiant.dir/all] Error 2 make: *** [Makefile:130: all] Error 2 but you DEVeNIGHTly solved the -dev problems