Search the Community

Well, my idea does not work. In reality, the penis gets created/recreated/reattached many times: anim urinate models/md5/chars/guards/proguard/animation_urinate.md5anim { prevent_idle_override frame 1 call overrideLegs frame 30 attach atdm:penis_s penis hand_l frame 30 sound snd_rustle frame 55 reattach penis LeftHips_Dummy frame 70 destroy penis frame 70 attach atdm:penis_urinating_s penis_urinating LeftHips_Dummy frame 70 sound urinate frame 340 destroy penis_urinating frame 340 attach atdm:penis_s penis LeftHips_Dummy frame 375 reattach penis hand_l frame 425 destroy penis frame 425 sound snd_rustle } As you see, the penis is already destroyed at the end of animation. And then there are two more ways to delete it: "attach" command looks at "remove_delay" spawnarg, and if it's positive, then schedules removal of the attachment penis also has "tdm_suicide" script attached, which also checks the same "remove_delay" spawnarg and deleted the same entity after this delay from script thread. So, why do we have 3 ways to destroy the penis?

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)

I think the writing is on the wall. Advanced upscaling will be adopted as widely as possible as the free performance band-aid for the gaming industry. The majority of players will probably run it automatically without even noticing. Recently we've seen rumors of Microsoft working on a Windows upscaler (which may be similar to AMD's RSR in that the game developers don't need to touch it) and Sony may include an NPU in a PlayStation 5 Pro for their own bespoke console-level upscaling solution (not an FSR 3/4, although those can be supported). The irony would be if Nvidia ended up killing the demand for gaming GPUs faster by marketing DLSS so hard, that there's less "need" for new and top-end GPUs. But they won't care because they prefer to chase more lucrative markets like AI, datacenter, automotive. I say "faster" because there is some point in the future when additional hardware can't push the boundaries of graphics, or faster hardware can't be created. We'll see an evolution of Unreal Engine 5's photorealism approach, adoption of 8K resolution, possibly 16K for VR, and a push to the 240-1000 FPS range. Generated frames could be used for a free doubling if not quadrupling of FPS to hit those high numbers, and upscaling tends to work better when your input/target resolution are already very high. For VR specifically, foveated rendering can slash hardware requirements, possibly by 80% or more if the implementation is good enough. On the hardware side, there's still free lunch to be had with a few additional node shrinks. Stacked L2/L3 cache could be extremely beneficial, think the 3D V-Cache version of Infinity Cache (Nvidia has gone with big L2 with Lovelace). We don't see adoption of High Bandwidth Memory in consumer GPUs because it is in such high demand for AI/enterprise products, but there's no technical reason it can't be used. We will see the blossoming of mega APUs this decade.

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

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

It's not even that there are free asset sites or AI apps^. Models still need work as they have to be adapted to the game polycount limits, and textures need to be adjusted to work with game art style and shading system. Sometimes doing something from scratch will be faster. And with AI tools, it misses the point even more so. And the point is, making textures, models, and sounds is great fun. It's an opportunity to grow as a creative person, and an occasion to connect and network with other people, even if it's hard to communicate sometimes. And TTLG in particular has plenty of creative people to choose from. By choosing AI, or grabbing stuff from other games, you miss that opportunity, and everything that goes with it. If everyone starts doing it, the community artists will disappear.

I've been meaning to suggest this for months, but the previous improvements have already made Layers so nice to work with that I just got lazy about this. But there's a few things I think could still be improved. And personally, I would prioritize the first one below, if I had to pick one. I haven't been following DR's development, so I don't know if any of this is already done and ready for the next release. But in case it's not, here goes. 1- it would be nice to be able to right-click a layer in the Layers panel, and have all the options to add to layer and move to layer and remove from layer, right there. This would make it much easier and quicker to manage layers. And, I personally keep adding prefixes to layer names, so that they're sorted in the list below, so I can find them easier, because the list gets big and confusing. This improvement would remove the need to do that. It would even remove the need for using this list, I think. 2- It would also be nice to add a new layer directly as child of another layer, just by right-clicking the intended parent layer. Currently, you have to click the New button at the bottom, and then manually drag the layer to its intended parent. Or when clicking New, the new layer could be created as child of the selected one. 3- I've suggested this one before, but I don't know if it's doable or not. It's harder to explain and I think the benefits aren't very obvious. It would be nice to override the visibility of objects that are contained in multiple layers, by toggling one of those layers on/off. So the layer you toggle, overrides their visibility. So regardless of whether its objects are visible or not, hiding this layer, would hide all of its objects, and vice versa. This can be useful when you have certain objects in their respective layers, but then you'd like to have also have a way to toggle all of them on/off at a single click. And with this improvement you could add them to a separate layer, and then just use that layer to override their visibility whenever you needed. For example, to get the ceilings of a whole bunch of rooms out of the way all at once, so you could have a clear view of the rooms while you put in furniture or path nodes or something. Currently, objects are always visible if any of the layers that contain them is visible, so this kind of thing can't be done. (And to be honest, because of that, currently it seems to me that there's no point having objects in multiple layers.) This is also useful for grouping things for easy group-selections. Arguably, you can also use selection sets for that, but the way you create and delete them makes them more suitable for quick and dirty one-time grouping, rather than something a little more indefinite. The two approaches have different levels of control, which makes them appropriate for different use cases.

I think that's just your specific assumption. You can use filters for very map specific things. It's not difficult or a lot of work to make them. So you're saying you use hotkeys for layers? I never use hotkeys for filters. Accessing them in the menu is just 2 clicks.

Something I was thinking of: Even if some assets are non-commercial, are all assets at least accounted for to make sure they're credited accordingly and can be distributed? I ask following an issue in another great project I work with called Red Eclipse: They don't have NC assets but did have a few texture packages they had to remove because they later found out their clauses were incompatible with the project. If this hasn't happened in well over a decade it's very unlikely anyone would complain today and request removal for any reason, but if any resource had its license misunderstood that could destroy existing FM's unless perfect replacements were found. Obviously I presume the team never included any asset randomly found on the internet without verifying their explicit requirements in detail, but it doesn't hurt to check. I think the best that can be done otherwise would be to have a list of which assets are libre or have the NC clause: That way a map can choose to use those models and textures that are free if the author wants their FM to be fully libre, albeit this would handicap an author in what packages they can use. If core assets like character models or textures are also NC, the idea is likely pointless as you can't make a FM without those, at best you can skip a few texture packages... not sure about other things like core scripts or defs, since they're technically code I presume those are GPL?

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

hello everyone since i discovered the " tdm_loot_stealth_stats.pk4 " I´m trying for supreme Ghosting . (Thx to snatcher , only cause your modPack i found it ! ) and now that there was mentioned a new Campain for ThiefGold I went in and downloaded the new stuff of 23 It seems Klatremus and Marbelman are more on TTLG , where i had fun reading things in : TTLG Thread: FMs - Ghost/Perfect Thief Results (Part 9) [SPOILERS] my Question : does there exist anything similar to the tdm_loot_stealth_stats for Thief1/Gold-Thief2 - or something to implement in AngelLoader ? P.S. : Klatremus ? what would you need from me to have HazardPay reported as SupremeGhosted ?

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!

Currently I'm playing the "Perilous Refuge" fan mission. My TDM version is 2.07/32. I tried to change the FOV by the advanced video settings dialog to an higher/wider value. First it seems to work fine ( also I'm not sure after all). Then I tried to change it even more but nothing happened. The wider FOV only happens if I grap any object in game e.g. a candle holder, but switches back to the default FOV if I drop the object again. Can someone tell why this doesn't work ? In an older forum post I read of how to change the FOV by editing some INI file but I didn't tried this yet, also since it don't seem to be the common way to do it no more. So I don't know if this would work better. Could someone help me out please ? Greetings Martin My OS is Win7/64 Graphics Card is NVidia GTX 960

At first I thought it was some wild precision bug but it looks like the skin might be nonsolid somehow and SteveL's change made the nonsolid attribute work? Either that or skin detection is somehow borked in this map. Feel free to edit the map, I'm no expert mapper but I might be able to perform some workaround by manipulating the entity. Edit: I fixed it with the following change: // entity 4 { "classname" "atdm:mover_door" "name" "atdm_mover_door_8" "lock_picktype" "-" "lock_pins" "0" "locked" "1" "solid" "1" "model" "atdm_mover_door_8" "origin" "710 -248 2050" "rotate" "0 90 0" "snd_close" "door_shut_06" "snd_open" "door_open_08" "used_by" "Balcony_door_keey" // "skin" "door_007_1" // primitive 0 Will upload the fix to the mission database. I don't see anything wrong with the door_007_1 skin but I would advise testing it in-game before using it going forward until this is fully sorted. Edit 2: The updated mission is now available in the mission database. Feel free to offer other fixes to this mission as long as they do not: Change visuals Change gameplay design ( Any purely bugged things that the mission author acknowledges "needs fixing" such as keys that are inaccessible or critical items that fall through surfaces when touched, etc can be fixed by any mapper and submitted for validation by the team. )

Aw... I had hoped to get to beta test this! Had the thread open but took too long in the end, sorry about that. Congrats on the release, will likely be the next FM I play, can't wait to give it a go!

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

PLAYERS 1) A lot of effort was put into optimizing loading times. It includes: better integration of decompression, multithreading, immutable texture storage, handwritten normal map compression and mipmap generation, removing artificial delays. As the result, we even had to modify loading screens of some missions, because allocated 10% of loading time was no longer enough for a player to read the hint 2) Generic performance improvements were done too. Most importantly, we fixed performance regressions since 2.07: rendering static geometry (5598) and soft stencil shadows with antialiasing. This hardly makes a difference, but it is nice to know that TDM can now use AVX instructions on Linux builds too. 3) We made some changes to window / input systems. Most importantly, Linux build now relies on GLFW library to create window and handle keyboard / mouse (thread), so a lot of the issues with OS integration on Linux should go away. On the Windows side, some minor changes were made to fullscreen/borderless modes. 4) New implementation of object dragging / manipulation (thread) Afraid to grab a candle near a sleeping guard? Hopefully, you will make less noise while moving objects in 2.10. And if you hold the creep button, the moved item will not make any noise at all. Also, dragging unconscious bodies should feel better now. Rats slighty spoiled the joy of this improvement (rats often do), but hopefully it is fixed now Finally, now you can control how far a rock flies by holding throw button for a different amount of time. 5) New visual style for frob-highlighting objects. This point is still surrounded by debates though (thread, poll), so the fate of the frob outline is yet uncertain. 6) Tooltips are now shown in the main menu. Perhaps the text is not perfect yet, but this is a birth of the long-awaited feature! 7) Tweaked starting new mission in the main menu. The old way of "installing" and starting missions was quite confusing for newcomers. So we reorganized the main menu a bit, and now it is hopefully more intuitive. MAPPING 1) Entity limit is no more (thread). Well, number of entities is technically capped by 65536, but I don't think it can be reached by ordinary mapping. You should no longer use the insane tricks of the past striving to reduce the number of entities (unless the tricks have other benefits, of course). 2) Behavior of spotlights (projected lights) reverted back to how they worked in 2.07. It means that the missions released before 2.08 should now look as intended. The sad thing is that the missions with projected lights tweaked for 2.08 or 2.09 are probably a bit off now. Also, fixed a bug that spotlights illuminated surfaces outside their light volumes. 3) Security camera improved. Security cameras have been reworked from the ground up with the aim of bringing them to the same level of polish as TDM's AIs, both when it comes to stealth gameplay and how mappers can work with them and customize them. Most importantly, security cameras in new FMs will track the player once they catch sight of him rather than freezing in place, making them considerably harder to shake off. All the details can be seen on the wiki page. 4) Volumetric lights can now be used on projected lights (thread). Unlike adding fake translucent geometry, the real volumetric lights automatically match their source light, including light volume geometry, projection & falloff texture, and even shadows. Full description of available settings is available on the wiki page. 5) X-ray screens feature added. This feature that was originally in Doom 3, has been reintroduced to TDM and developed further. The screens are able to change the appearance of entities seen through them, even making them appear or disappear if desired. Look out for them in future Inventors Guild and magical themed FMs. You can find the thread here with links to the relevant wiki articles. l 6) Added a system for tracking secrets. Now it is easy to set up, with no custom scripts required. They'll also be shown on the mission statistics screen at the end of the mission, if the FM uses the new system. More can be read on the wiki page. 7) Main menu GUI has been reworked to allow more customization. Mappers can change music, background, disable screens in the uniform way. Debriefing videos work exactly as briefing videos do. The same customizations can be applied to ordinary missions and separately to every mission in campaign. You can find more details in guis/mainmenu_custom_defs.gui inside tdm_gui01.pk4. A lot of the released missions were updated to use the new customization system (thread). Which unfortunately means that their customizations won't work in 2.09 and earlier versions anymore. 8| Dmap times have been reduced (thread). Optimizations were made all over the dmap code, adding some new algorithms and data structures. Of course, the time difference varies between maps. As a side product, precision has been improved in a few places. 9) Added location diagnostics to dmap (thread). Setting up location entities and separators is an error-prone process, and previously there was no good way to find the error. Now dmap will post warnings and even produce pointfiles in case something is wrong with locations, similar to already existing visportal diagnostics. 10) Added native support for PNG image format. Now PNG images can be used in materials. In some cases PNG is a good alternative to TGA for uncompressed images. Note however, that loading PNG is slower than loading TGA, and we have yet to discover if this is a problem or not. As a side note, DDS images can now be used in image programs, although doing so is discouraged because of additional loss of quality due to compression. 11) Subtitles can now be assigned to sound files (thread). While implementation is a bit raw yet and needs to pass test of time, subtitles have already been added to Saint Lucia prebundled mission. Note that we did not consider localization of subtitles yet (localization as a whole is in weird state in TDM). Full description is available on the wiki page. 12) New script events have been added to the repertoire for use by mappers: a) sys.VecRotate( vector vec, vector angles ) rotates a vector by a set of angles, allowing to match vectors such as offsets to an entity's current orientation. b) entity.getEntityFlag( string flag ) allows to find out properties about entities such as "notarget" (for the player entity) or "invisible". c) $player1.getCalibratedLightgemValue() retrieves the current value of the lightgem, using the same weighting as AIs do. d) entity.setSolid( boolean state ) allows to change the solidity of an entity at runtime. Note that it's still experimental. e) sys.getLocationPoint( vector point ) returns the location of a point in space. f) sys.pointIsInBounds( vector point, vector mins, vector maxs ) evaluates whether a point lies within a volume specified by 2 corner points. g) sys.getTraceSurfType() returns the type of surface the most recent trace has hit, such as "snow", if any. *) Some other improvements: a) Supported "set XXX on head" spawnarg on AIs. b) Some LOD improvements, e.g. for lights. c) Hot reload supports more of the popular spawnargs (i.e. without respawn). d) In-game downloader can update the currently installed mission. ASSETS 1) Automaton AI from Ulysses mission by @Sotha have been added to core, together with new prefabs for (cosmetic) recharging stations to include in patrol routes and a camera screen showing what the automaton sees. 2) @Wellingtoncrab contributed a whole new suite of fancy wooden furniture pieces including prefabs. They can be viewed in their release thread. PROGRAMMING Some interesting things happened on programming side too. First of all, the limited GL profiling has been replaced with Tracy profiler, which has its own cool viewer. It has greatly helped us in our optimization efforts. More technical stuff: generic hash table has been added, Clear in idlib method now works as most programmers expect, unit tests integration has been improved. Another major event that happened this year is migration to the new mission database, based on SVN repository. Hopefully, there will be less confusion about mission updates, and old versions of FMs will not be lost anymore.

@nbohr1more@Dragofer Update to the post quoted above: only missions with turrets are concerned, all others work fine.

The entities you mention don't have a def_attach for the light so they don't need a name_attach. If you want to change the light properties you can do it directly on the entity instead of using 'set key on name_attach' like you would on other 'combined' light entities. I don't know what these types of entities are called or how they are put together (I haven't looked into it), but that's the difference in how you customise them. Maybe they inherit from some parent that combines lights and models instead of using attachments. I think in that newbie question thread the sconce object was just an entity that someone forgot to add the name_attach spawnargs on.

You can work around this error by putting a completely empty file called tdm_turret_scriptbased.script in your script folder, and temporarily removing all turrets from the map. Would still be interesting to see whether 10518 is the first build where the problem appears, or beta1.

Mission: "The Elixir" Reading: Lady Barrington's Diary I checked the mission thread, and nobody else seems to have issues. 2.11 Well, now I found a thread already existed. I can't find a way to erase my topic, so please do so freely. Looks like a hopeless bug. Luckily it is rare.

Thanks. Those methods might not work well unfortunately: Using an objective is overkill as they're meant to be standard characters you dynamically drop to the map and should just work... triggering would have worked but apart from the AI being made to patrol, I don't think it's possible for a def to reference another def as a target since those need to be linked on the map and there's no name for the AI to refer to the attachment by for a trigger. What do attached lights that turn off when the wearer dies use? Actually I think the Automaton has that so I can probably look at its example for the lamp component. It probably wouldn't work for my rotator though, stopping rotation is different from turning off a light... unless the light is also targeted or uses the SR system so I can reach the "use" stimuli via spawnargs after all? Another option would be having my fan as a texture, it's thin enough anyway: I define a version of the material that rotates and one that doesn't then switch the skin. But then the question becomes how does the AI change the skin of an attached entity on death? And a flat surface is uglier anyway I want to be up to date with quality standards so I'll have to think about this.

List of major console variables and commands: PLAYER tdm_holdfrob_* --- set of variables that affect the reworked frob controls. tdm_autosearch_bodies --- automatically take items attached to unconscious bodies on frob. pm_headbob_mod, pm_lean_* --- allows to reduce some player movements. HELPER tdm_show_viewpos, screenshot_viewpos --- embedding viewpos into screenshot for better bug reports. tdm_open_doors, tdm_close_doors --- cheats to make mission testing faster. TROUBLESHOOTING r_useLightPortalFlow, r_useLightPortalFlowCulling --- improved light-entity interaction culling. Most major effect on shadows. This cvar is responsible for causing light leaks with stencil shadows, please report all of them! (thread) r_useNewRenderPasses --- selects from several renderer backend code paths. This is similar to the old r_useNewBackend cvar which has been deleted. r_shadowMapSinglePass --- faster code path for filling shadow maps. r_useEntityScissors, r_animationBounds --- improved bounds estimates for rendered entities. r_postprocess_dither --- new dithering in tonemap postprocessing for less color banding. r_shadowMapAlphaTested --- experimental mode for alpha-tested surfaces with shadow maps, where transparent areas of texture don't cast shadows. s_realTimeDecoding --- selects code path for decoding sound samples. tdm_subtitles_* --- many cvars for subtitle improvements (location cue, duration extension, debug text).