Search the Community

damn, as in poor framerates?..

I think I have a way to do this without scripting. The idea of the Key entity and key targets seemed to pan out. What do you all think? ---------- 1) the inventory object to pick up in the map is an atdm:key_base with the model and inv_model overridden. So, this looks like a custom inventory item. 2) the target objects to use this are atdm:froblock entities with their used_by as the entity #1, trigger_targets enabled, sounds customized, etc. In my case, make a sound, emit a puff of smoke, then simply remove the target item, all things that can be done with relays and targets. So far, this seems to do what I intend. Does this seem sound? Now that I look back on this convo, I didn't explain what I intended well enough. I bet some experienced mapper could have suggested this. So, my apologies.

DarkRadiant is presently suffering from huge slowdowns when editing complex maps. They appear to increase the more models and entities are added to a map: With the building modules used in a lot of places, one of my maps is at the point where DR freezes for over one second whenever I merely toggle a filter which is very annoying for every repeated action. The lag occurs both when moving the 2D or 3D camera or viewport around, as well as enabling or disabling filters or using Control + F to go in and out of editing a group. From what I can tell as an end user, this seems to occur because DR drops models that are no longer being rendered from memory, so whenever a change in the camera or viewport is made everything that pops into view or is recalculated floods back in. While this may be nice to save on RAM, my suggestion would be a change or at least an option to disable this behavior and keep everything precached: Like TDM itself, DR should maintain every model and texture used by the map in memory, only removing it once every last instance has been changed or deleted from the map being edited.

heh come to think of it i also owned an old hp workstation tower model that was an absolute nightmare to upgrade too. this model had rambus memory modules and some horrid onboard gfx card which i couldnt even upgrade with an agp model since the board only had PCI slots it came with windows 2000 server installed but i found out it also ran win98 so i retrofitted it as a monster retro computer with dual voodoo2 cards since those were quite a lot faster than the onboard card. damn thing sounded like a jetplane because the rambus memory got insanely hot hehe. the memory modules were also rather pricey but i managed to get about 16 gb slammed in there and still it was slow as molasses sigh. i sold it to some guy who just liked that it was uniq for a pittance. the 16 gb ram was not even needed for a win9x pc since it could only use about 3 gb's but it still ran win2k at the time i installed them so i left them in.

So, if I understand you, no Thief Gold FM does sound and text notifications of completed objectives? The missions in The Black Parade surely did. I'm completely confused now. I was sure that original Thief Gold had those objective complete notifications (at least the sound). Reading this thread suggests otherwise though: https://www.ttlg.com/forums/showthread.php?t=132977

A reminder for folks who have poor performance in this mission. The latest 2.12 "dev builds" have some major performance optimizations that may improve your experience:

I don't know if it's mentioned anywhere else on the Wiki, but it's worth mentioning that the first global keywords are for sound: // Use on of the predefined surface types like: // none, metal, stone, flesh, glass, wood stone And this: //surftype15 //description "carpet This is a carpet texture." I think this is sound as well, but I also think 'description' does other stuff, for example for using with vine arrows: stone description "vine_friendly" If someone has a list (or link to code) where all this is defined for TDM so mappers are aware, that would be useful. I would also move the 'special keywords' section up so it's before the obsolete stuff - that old stuff needs to be relegated to the very bottom. I would also change the title of that section from 'No ambient and frob -stages needed' to something like 'Deprecated stages' and say it's just there for historical reference.

This can be removed as well, you don't need to specify texture map slots you don't use. In some cases you even shouldn't.

ooh my bad . "Peeking through door" is a poor choice of word to describe "poking your head around the door to see what is inside the room" . Ultraviolet(UV) thief detection powder is designed for theft detection and the identification of stolen or altered items but i think it's too advanced for an era in which TDM is taking place.

I just recently became aware of this feature: https://wiki.thedarkmod.com/index.php?title=Particle_collisions_and_cutoff Unfortunately I completely missed it, as when I went to create weather effects in my FMs I just followed this (which doesn't mention it): https://wiki.thedarkmod.com/index.php?title=A_-_Z_Beginner_Full_Guide_Page_3#Rain_and_Snow The point of this thread is to a) make people aware of it and b) gather feedback from any mappers that have used it so we can get some mapper-focused documentation in the Wiki. The page above is great for background information about how it works, but as a mapper I really just want to know: What are the limitations of this (i.e. when should it be used and when shouldn't it be used)? Why isn't it the default behaviour? Why all this work to get it into the map? What built-in support for it exists (particle definitions, materials, etc). Do I need to create all this stuff myself? Texture layout vs. Linear layout: what's the difference in the end, pros/cons, why would I use one over the other... Why does it need a separate command (runParticle)? Can this just not be bundled in with dmap? A clear, step-by-step instruction on how to implement it in a map from beginning to end using a simple use case. Tagging some users who have relevant experience with this: @stgatilov @Goldwell @Amadeus

No warnings during dmap re: the patch, how do I check if a patch has a "[0..1] non-overlapping texcoords"? Is it correct in interpreting that to mean the texture has been fit to the patch? If so then yes. This is the patch copied from DR if that helps: <?xml version="1.0" encoding="utf-8"?> <map version="1" format="portable"> <layers> <layer id="0" name="Default" parentId="-1" active="true" hidden="false"/> </layers> <selectionGroups> <selectionGroup id="415" name=""/> <selectionGroup id="416" name=""/> <selectionGroup id="417" name=""/> <selectionGroup id="418" name=""/> <selectionGroup id="420" name=""/> <selectionGroup id="421" name=""/> <selectionGroup id="423" name=""/> <selectionGroup id="424" name=""/> </selectionGroups> <selectionSets/> <properties> <property key="EditTimeInSeconds" value="20837"/> <property key="LastCameraAngle" value="69 332.186 0"/> <property key="LastCameraPosition" value="20.0088 1653.64 531.677"/> <property key="LastShaderClipboardMaterial" value="textures/darkmod/nature/snow/snow_rough01"/> </properties> <entity number="0"> <primitives> <patch number="0" width="3" height="3" fixedSubdivisions="false"> <material name="textures/darkmod/weather/rain2_heavy2024mtr"/> <controlVertices> <controlVertex row="0" column="0" x="-448.000000" y="1712.000000" z="720.000000" u="0" v="0"/> <controlVertex row="1" column="0" x="-448.000000" y="1568.000000" z="720.000000" u="0" v="0.500000"/> <controlVertex row="2" column="0" x="-448.000000" y="1424.000000" z="720.000000" u="0" v="1.000000"/> <controlVertex row="0" column="1" x="-76.000000" y="1712.000000" z="720.000000" u="0.500000" v="0"/> <controlVertex row="1" column="1" x="-76.000000" y="1568.000000" z="720.000000" u="0.500000" v="0.500000"/> <controlVertex row="2" column="1" x="-76.000000" y="1424.000000" z="720.000000" u="0.500000" v="1.000000"/> <controlVertex row="0" column="2" x="296.000000" y="1712.000000" z="720.000000" u="1.000000" v="0"/> <controlVertex row="1" column="2" x="296.000000" y="1568.000000" z="720.000000" u="1.000000" v="0.500000"/> <controlVertex row="2" column="2" x="296.000000" y="1424.000000" z="720.000000" u="1.000000" v="1.000000"/> </controlVertices> <layers> <layer id="0"/> </layers> <selectionGroups/> <selectionSets/> </patch> </primitives> <keyValues> <keyValue key="classname" value="worldspawn"/> <keyValue key="difficulty0Name" value="easy"/> <keyValue key="difficulty1Name" value="medium"/> <keyValue key="difficulty2Name" value="hard"/> <keyValue key="shop_skip" value="1"/> </keyValues> <layers> <layer id="0"/> </layers> <selectionGroups/> <selectionSets/> </entity> </map>

@Geep Regarding 0.24 vs 0.25 font scale. I think there was purpose, though I can't say now which exactly. Maybe it was to ensure that all the text fits, maybe it was to make vertical padding symmetric. Anyway, why do you think 0.24 and 0.25 differ? I did not look in the code yet, but I think what engine does is 1) choose most suitable image, 2) render quad texture with it. Indeed, we can avoid some blurring if the pixel size of the quad exactly matches the image size. But I guess the engine counts font size in 640x480 virtual resolution. So even if the font size would be "12", it would later be stretched over whatever width you really have (if your aspect ratio is 16:9 then height would be stretched equally, but otherwise it would be stretched with different factor).

Make sure the gas lamp light is not set to no shadows. Same with the wall texture, make sure you didn't accidentally use _ns version of a texture

An impossibly huge stone bridge that only makes sense in a Quasi-Medieval/Steampunk fusion world. (stone is a crappy bridge material) - It does exude that 'TDP' classic feel somehow; not a trait most TDM missions have. Poor FPS near many upper bridge sections, and a horrible TDM FREEZE!! bug (never seen in any other mission - including a few others that up crash at random), as well as numerous geometry holes in the map...Did I mention the many Free-Runner traps on roof sections? Quite well-thought out interiors (if kinda HUGE scaled), give this FM one of the old-school'iest play-feels I've done in a while; One to watch for a updated 1.1 version with the bugs fixed... Try it later, is my recommendation.

When the time comes to review my life, with the Master Builder before me, I'll say I was a sneaky taffer who cared for the poor.

Of course, it is one of the reasons for the decline of online forums, since the advent of mobile phones. Forums on a mobile are a pain in the ass, but on the other hand, for certain things there are no real alternatives to forums, social networks cannot be with their sequential threads, where it is almost impossible to retrieve answers to a question that is asked. has done days ago. For devs for internal communication, the only thing offered is a collaborative app, such as System D (not to be confused with systemd). FOSS, free and anonymous registration, access further members only by invitation, full encrypted and private. https://www.system-d.org

Here's an example. For testing I created a room out of a bush and put the portal sky texture on the inner side. This is the portal sky texture in the background and it's just used to seal my playgorund. In the foregound you see a lever, which is supposed to open a secret door. The wall and secret door also have the portal sky texture. So I'm hoping to see my skybox on the wall, which you could then open and be in another room all of a sudden. This is what it looks like in DR: And here's an ingame screenshot. As you can see, instead of the skybox texture the wall is invisible. The player is supposed to see the sky instead. Also, I'm looking for a way to use multiple skyboxes. Since there's only one portal sky texture I don't see an elegant way to do this. I'd imagine that this would requrie naming the skyboxes and scripting the portal sky texture, in order route it to the currect skybox. But thats just me guessing on a potential solution, without having the actual technical skills yet.

Greetings everyone! I recently got into TDM and am already having a lot of fun playing through and ghosting missions. However, coming from Thief, I am mostly relying on the rules and my experience with that game, while there are clearly differences in how TDM works. Right now, there is talk in the ghosting discussion thread on TTLG to amend the ruleset and include clarifications pertaining to TDM. So I wanted to drop by and ask: is there an active TDM ghosting community already and have any rules for this playstyle been developed? I would also like to ask someone to take a look at the draft of this addendum to see whether everything looks correct: https://www.ttlg.com/forums/showthread.php?t=148487&page=16&p=2473352&viewfull=1#post2473352 Thanks!

A Problem Arises I've paused subtitling of the Lady02 vocal set, because of a problem with the voice clips described here: https://forums.thedarkmod.com/index.php?/topic/21741-subtitles-possibilities-beyond-211/&do=findComment&comment=490151 While a way forward is being determined, I'll work on a different vocal set. Maybe manbeast, for which Kingsal just provided me the voice script.

Here's the pre-release build 3.1.0pre2 After this pre-release phase I'm going to consider doing this differently, like pushing out the releases more regularly, skipping the "beta" phase. It's a lot of work putting the pre-releases together, and I'm somewhat tired of it. What's new: The Texture Tool got its Free Scale operator now, allowing you to fit the texture with the mouse instead of having to type in the percentages. A lot of work went into the Declaration handling (EntityDef, Skins, Materials, Particles, etc.), which is now much more robust and more conformant to how the game is doing things (at least until TDM 2.10). The Material Editor got a plethora of issues resolved Improved the Model Export dialog and options For more things that have changed or fixed, see the list below. Download Windows Portable x64: https://drive.google.com/file/d/12zKwbeesRIMP7DNeGd0znGl5xqBVrrPX/view?usp=sharing Download Windows Installer x64: https://drive.google.com/file/d/12u5YtpDvpIPL7cR8EPdIIFcnjx9TzpCe/view?usp=sharing Linux folks need to compile this stuff from source, instructions for various distributions are on the wiki. If you happen to run into a crash, please record a crashdump: How to record a crashdump Changes since 3.0.0 can be seen on the Bugtracker changelog, here's the summary: #6065: Feature: DR doesn't consider wildcards in skins #5503: Feature: Reload Images #5805: Feature: Texture Tool free scale #6021: Feature: Add "Show Definition" to all ResourceTreeView instances #6003: Fixed: "Reload Defs" doesn't remove entities that have been commented out #6007: Fixed: 'Reload Sounds' doesn't load new FM sound shader definitions #5504: Fixed: Reload Defs is not sufficient for reloading modelDefs #6035: Fixed: Models are reset to origin after reloadDecls #6064: Fixed: Skin Chooser doesn't preselect non-matching skins #6062: Fixed: Moving speakers deletes distance spawnargs if they're the same as in shader #5988: Fixed: Unable to select func_emitter with particle attached #6000: Fixed: Particle Editor Preview lacks vertex colours in lighting mode #6061: Fixed: Particle effects still visible when hidden via layers or filter #6036: Fixed: Entities referring to modelDefs should use the "idle" pose where possible #4910: Fixed: DR does not parse materials in def files #5982: Fixed: Modifier Hint Popup can crash when hitting Ctrl/Alt/Shift keys during shutdown #5981: Fixed: Insignificant digits displayed in Surface Inspector shift/scale/rotate values #5727: Improvement: Skin Chooser: show in which .skin file the skin is defined #5977: Improvement: Declaration Block Parsing overhauled #6023: Improvement: Python Interface for IDeclarationManager #5972: Improvement: leave player start entity selected after placemen #6066: Improvement: Let Map Info show materials used by models #6073: Improvement: Renaming Declarations causes problems when saving it later #6057: Improvement: Light Texture Preview should display editor images if present #6002: Improvement: Remove comments about particle generator in .prt files #6071: Material Editor: New Material is locked if the default unnamed name is already in use #6031: Material Editor: allow to delete materials #6054: Material Editor: image browser's "cancel" button rewrites the material source text #6030: Material Editor: does not save manual edits to source text #6055: Material Editor: should show .mtr the material is defined in #6069: Material Editor: after "Reload Images", image previews are only updated when selecting a different material #6050: Material Editor: suboptimal preview for cubeMap materials #6042: Material Editor: preview object doesn't have smooth shading #6043: Material Editor: preview doesn't take "scale" into account in Textured Mode #6053: Material Editor: blend add stages are rendered separately in preview in lighting mode #6059: Material Editor: test frob highlight button not working #6045: Material Editor: doesn't remember settings from previous session #6046: Material Editor: image thumbnails use "scale" keyword from previously selected material #6056: Material Editor: frob highlight stage not updated correctly when changing diffusemap #6049: Material Editor: using Escape to close ignores unsaved changes #6051: Material Editor: Global Settings should be preselected #6052: Material Editor: some declaration text is lost while editing#6047: Material Editor: clicking "cancel" when selecting a light classname clears the classname field #6034: Material Editor: new materials always sorted last #6033: Material Editor: filter for image browser #6037: Material Editor: can't unlock editing on materials in "Other Materials" folder #6029: Material Editor: tries to save materials in DarkRadiant folder if no FM is installed #6048: Material Editor: allow to change preview backgroun #6040: Material Editor: preview renders shadows for noshadows materials Changes since 3.1.0pre1 #5997: 'Export selected as Collision Model' doesn't auto-create path folder and throws error #6013: Model exporter: manually enter export origin #6012: Model exporter: export origin choice should use a radio button #6014: Model exporter: only 1 entity's model is reloaded #6011: Model exporter: "Use entity origin as export origin" still uses map origin #6015: Model exporter: rename "Center Objects around Origin" Thanks for testing, as always!

I noticed the mixed response to the silent toggle change. I haven't had such a toggle on any of my Android phones. I don't want it silenced very often, and if I did I can spare the 2 seconds to look at the screen. I have noticed older folks will silence their phones on accident and then misplace them, wasting much more time. If someone is hiding in a closet and can't silence their phone fast enough and it alerts the nearby axe murderer, c'est la vie. While a physical interface was removed, technically another, different one was provided. I'm annoyed at buttons and ports being taken away in the pursuit of waterproofing, thinness, selling expensive accessories, etc. There were rumors of portless iPhones that have not come to pass (yet), and a real example of a portless laptop. People do take incremental performance and efficiency improvements for granted. There are not many areas of life where something would suddenly get 10.. 15... or 20% better, but that's what you tend to see with SoC improvements every 1-2 years, and they compound over time. Smartphone performance has reached a "good enough" level for many use cases, but additional silicon improvements can be used to extend battery life, and it looks like Apple is trying to make AAA gaming a thing on iPhone 15 Pro. Apple has always been stingy with RAM, while fanboys have insisted that iOS uses RAM more efficiently than Android. In reality, Apple may be slightly better at RAM management, but they are still cheaping out, and no amount of magic can stop you from running out if you open lots of large websites, apps, or whatever. On the Android side, there are gratuitous amounts of RAM thrown into phones for marketing purposes, especially in China which pushed some models up to 18 GB and now 24 GB, and there may be poor utilization of what there is. For example you get pages/apps reloading instead of using all of that extra RAM.

PLAYERS * Volumetric lights appeared late before the previous beta, so the quality of volumetrics in 2.10 was rather poor, and the dithering pattern was very annoying to look at. The feature received a lot more development, and now adheres to the standards of modern rendering. The dithering pattern is gone, performance should be much better, and now you won't miss volumetrics even if you prefer to play with stencil shadows all the time! (thread) * Thanks to a certain "AI-heavy" mission, the game code has received major optimizations. It is most noticeable in low performance conditions, when game modelling takes a lot of CPU time. Previously the game could easily descend into the "spiral of death" with FPS falling below 5, now it is way harder due to better scheduling of AI thinking. There is a variety of other game code optimizations which make our lives slightly better. * New version includes several optimizations for shadows, mostly stencil shadows. A long-standing inefficiency of stencil shadows with antialiasing is fixed, new tile-based optimization is added for soft stencil shadows (thread), small lights with large meshes work faster due to BVH efforts (thread). On the side of shadow maps, the rules for distributing the resolution budget are changed: small distant lights no longer steal precious bandwidth for themselves. * There are several improvements on gameplay side as well. The core mechanics of blackjacking enemies has received subtle, yet helpful improvements (thread). Now you can grab many close pieces of loot by holding down the frob button, instead of picking up each item individually. There are several improvements to crouching, making it more responsive (thanks to @Daft Mugi). The in-game downloader now supports "sort by release date" ordering. * There were a ton of small bugfixes for issues like: bow stuck after load, wrong strafe-walk sound, crash when saving shortly after the death of an elemental, melee combat crash, issues with leaning onto doors, missing fracture sounds after loading a save, X-ray glitch in the first frame, toggling solidity/visibility, lightgem on game load, etc. MAPPERS * The engine now supports OBJ model format. This format is much more popular than ASE and LWO. The engine loading code is very lightweight: it will use your model exactly is as, and load it very quickly. The OBJ format is preferred for large meshes due for faster loading times. The only possible downside is somewhat larger download size compared to LWO, although not much and not always (thread). * Renderer should deal with large meshes much faster, thanks to BVH optimizations. Recall that idTech4 was made for very low-poly models. When renderer frontend sees a "surface" in a model, it always treats this surface as an atomic piece, doing all computations for all of its vertices and triangles. This is very good for low-poly models, can heavily drag performance down with large meshes, as several recent missions noticed during beta. The BVH data structure breaks every surface into smaller chunks, allowing renderer to quickly cull away whole chunks. This makes a big difference in case of large meshes (e.g. terrain) lit by many small lights (thread). * You no longer have to write frob-highlight stages in materials, since they are added implicitly. The problem with these stages was that were very easy to forget, which resulted in no highlight on frobable items. Also it increased cognitive load and scared mappers away. While writing frobstages is no longer necessary, the old stages work just fine. So mappers can still customize frob-highlighting if they really want to (thread). * It is now legal to override a single decl of core game in your mission. Recall that "decl" means a material, a skin, an entityDef, a particle, etc. Note that overriding a whole file from core game always worked as expected, but overriding a single decl from a file did not work reliably before (despite the common belief that it should). * The major cleaning of shaders resulted in some changes in lighting model. The aim was to make TDM lighting closer to the standard Phong model, and make it more logical in general. The changes should rarely make a big difference, aside from probably stronger specular (thread). * Added error-reporting to the GUI scripting engine. Implementing GUI scripts is very hard, error-prone, and confusing. Aside from surprising differences in Doom 3 GUI behavior compared to e.g. Javascript in DOM, a lot of confusion was caused by total lack of any error handling whatsoever! In the new version, all possible errors should result in easy-to-understand console warnings, so writing correct GUI is much easier. Also, we fixed a few features, and added a few new ones to the GUI engine (thread). * dmap command received minor improvements. Yet another big rewrite happened for T-junctions fixing code, since it took tremendous amount of time on one mission. Also a few precision improvements were made. * Other small fixes and additions: added script functions getAnimRate / setAnimRate for tweaking animations added script function setObjectiveNotification for silent objective change added script function getCurInvItemCount for interaction with inventory added script variable "AI_ENEMY_TACTILE" to the base AI scriptobject, which is true whenever the AI is in tactile range of an enemy added spawnarg absence_alert_increase for loot items as a proper substitute for absence_alert, giving control over how much an AI gets alerted if that piece goes missing added spawnargs allow_idle_anims / allow_random_headturning for customization during a running mission, useful i.e. for cutscenes AIs notice broken fracture entities trigger_multiple now works on stationary AIs almost doubled tracemodel limits, raising the restrictive limits for making collision meshes for moveable items door movers can now call "used_action_script" whenever something like a key, lockpick or other item is used on them, if they have the spawnarg "call_used_action_script" "1". ASSETS * Many new assets from capable creators in our community have been incorporated into the core assets. These include: Loot assets: Detailed coins and ingots with accompanying lore. Link Ancient loot items suitable for museums, collectors and ancient sites, first seen in the Volta series. A tiling treasure hoard texture for those with unimagineable wealth. 6 detailed book skins including 3 that are lootable, a first for TDM. Link Security assets Highly detailed standing and wall safes - with or without an accompanying combination lock. Link The combination "safe lock" is now part of core assets and can be operated by either scrolling or frobbing. Mappers no longer need to track down this asset and include it with their FM files as a custom asset. Wall-mounted locks in the style of those commonly found in the original Thief games. Camgoyle sentry, a magical stone guardian based on the security camera shooting magical projectiles at the player, first seen in Written in Stone. The prefab also includes a power source pedestal. Link Fully useable audiograph for playing recorded sounds, first seen in the Accountant and Shadow of Northdale missions. A new full-featured scriptobject makes them easy to implement and control via spawnargs. Wiki Furniture assets Posh upholstered armchairs and sofas for the wealthiest nobles. Link A new high-detail grandfather clock with a working scriptobject and a mantle clock. Link A gothic-style cabinet. Link Office assets Including bundled stacks of paper, blueprints, a letter, crumpled paper, waste bins, an end table and an ornate table. Nautical assets Full-scale modular ship prefabs with interiors, allowing anyone to assemble a ship for a nautical mission in a matter of seconds. 1 merchant galleon and 2 smaller sailing ships are available. Link Link Link A large galleon ship wreck in 2 pieces for those sailors who have met an unfortunate end. Decorative assets An impressive multi-tiered wall fountain, first seen in the mansion in Noble Affairs. A new pair of marble lion statues. Link A standing stone menir with carved symbols on it, ideal for pagan missions. Link Stone pedestal with purple cloth for presenting valuable items. Textures High-resolution cobblestone textures for detailing the streets of TDM. Link Starry wallpaper. Lamps A set of 6 bronze vintage lamps has been added for particulary posh establishments. Link Thief-style charge post streetlamp. A new open-top carriage, the barouche. Link Miscellaneous other models, including: wall planter, 7 small "foliage" herbs, 2 mine carts, 6 shop signs, equippable feather duster and 5 decor plates * We fixed all loading warnings on all existing assets. This became possible after creating an automatic map generator which forces the engine to load all assets from every group. All the references to missing files are fixed too, which means a variety of assets have become available: Old noblewoman skin, plain mage robes skin, moor helmet, electrical arcs, stone window decals (5178), yellow banner skin (5563), wine barrel (Link), grass particles (5689), lampion lights and more graffiti decals. PROGRAMMING Under the hood, we updated third-party libraries, and moved to Visual Studio 2022. The "Debug With Inlines" configuration was split into "Debug Editable" (with hot-reload support) and "Debug Fast" (fastest debuggable). Marking the final step in transition to tdm_installer, the old tdm_update program is finally removed, with TDM packaging code extracted to standalone program.

Black Parade is released ! https://www.ttlg.com/forums/showthread.php?t=152429

Another thing, this time about models. It seems like there are two sections for exporting models, one in File and the other in Scripts. IIUC, the latter is redundant so it can be removed. Second thing is a bit more controversial I guess, but IMO exporting model geometry should be disabled. This way you can use DR to e.g. export .ase to .obj and modify otherwise unchangeable models (ase can be exported, but not imported into any modeling software). Artists have no control over how their assets can be used, and this way they can be spliced, hacked, and bashed by mappers. Even if you copyright or otherwise restrict the usage, you'll have hard time tracking down those who don't give a crap about modellers. This is also related to use of other models, or derivative works from other models. There are many free models that are not entirely CC0, but they're free / allow derivative works, but on a condition of, e.g.: "you may not use the asset in a way that allows others to use or access the asset as a stand-alone" – this is a standard license quote from a popular 3d hosting platform. So having DR as an .ase -> .obj exporter makes such terms impossible to follow. Exporting brushwork or patches is obviously fine, if anyone works this way.