Search the Community

So a long standing issue with the light model entities in the core, is that the main light source is hard bound to the origin of the model. This isnt great, because it means the origin of the light is then directly in the same plain as a wall or ceiling @ 0, 0, 0. which has an unpleasant effect visual effect on a lot of the stock textures. If the engine code could be updated/edited so the main/default light for each light entity could be somewhere that isn't the at 0 0 0 of a model, I would have no issue taking on the task of checking and fixed every stock light.. In my humble opinion, this should 'not' significantly break any existing FM's, because all we will be doing is moving the origin of the light source to where light would be emitted from IRL, eg the housing, bulb or arc etc.

============== -= IRIS =- ============== WELLINGTONCRAB TDM v 2.11 REQ Ver. 1.3 *For Maureen* -=- "Carry the light of the Builder, Brother. Unto its end." -Valediction of the Devoted "What year is this? Am I dreaming?" -Plea of the Thief Dear Iris, I am old and broken. When we were young it felt like the words came easily. Now I find the ink has long dried on the pen and I'm as wanting for words as coin in my purse. I can tell we are nearing the end of the tale; time enough for one more job before the curtain call... ============== -Installation- Requires minimum version of TDM 2.11 **Dev build dev17056-10800 (2.13) fixes several visual effects which have been broken in the mission since the release of 2.11. For that reason playing with that version or later is currently recommended** -Iris does not support mods or the Unofficial Patch- Download and place the following .pk4 into you FMs directory: Iris Download ============== Beta Russian Language Translations by @kalinovka Mirror #1: yandex.ru Mirror #2: Google Drive ============== *Thank you for playing. Iris is a large mission which can either take as quickly or as long as you are compelled to play. I hope someone out there enjoys it and this initial release is not completely busted - I tried the best I could!* *Iris both is and isn't what it seems. If commenting please use spoiler tags where appropriate. If you are not certain if it would be appropriate a good assumption would be to use a spoiler tag* *Support TDM by rating missions on Thief Guild: https://www.thiefguild.com/* ============== WITH LASTING GRATITUDE: OBSTORTTE - Whose gameplay scripts from his thread laid the foundation which made the mission seem like something I could even pull off at all. Also fantastic tutorial videos! DRAGOFER - Who built upon that foundation and made it shine even brighter! And whom also provided immeasurable quantities of help and encouragement the past couple years on the TDM discord. ORBWEAVER & GIGAGOOGA - For generously offering their ambient music up for use. EPIFIRE - Who lent me his fine trash and trash receptacle models. AMADEUS - Who was the first person who wasn't me to play the damn thing and provided his excellent editorial services to improving the readers experience playing TESTERS AND TROUBLESHOOTERS: AMADEUS * DATISWOUS * SPOOKS * ALUMINUMHASTE * JAXA * JACKFARMER * WESP5 * ATE0ATE * MADTAFFER * STGATILOV * DRAGOFER * KINGSAL * KLATREMUS - What can I possibly say? Playing this thing over and over again could not have been easy. Deepest thanks and all apologies. -=THANKS TO ALL ON THE TDM DISCORD AND FORUM=- ==SEE README.TXT FOR ADDITIONAL ATTRIBUTIONS & INFORMATION== HONORABLE MENTION: GOLDWELL - If I hadn't by chance stumbled into Northdale back in 2018/2019 I would probably still be trying to get this thing to work in TDS, which means it probably would not exist - though more details on that in readme. ============== Boring Technical Information: *Iris is a performance intensive mission and I recommend a GTX 1060 or equivalent. I find the performance similar to other demanding TDM missions on my machine, but mileage may vary and my apologies if this prevents anyone from enjoying the mission.* *Iris heavily modifies the behavior of AI in the game, how they relate/respond to each other and the player. So they may act even stranger than they do typically in TDM. Feedback on this is useful - as it can potentially be improved and expanded upon in future patches.* -=- This is my first release and it has been a long time coming! If I forgot anything please let me know! God Speed. 2.10 Features Used:

EDIT: Here's a script that exports smaller md5anim files and doesn't require baking: I tested this addon for importing and exporting md5.mesh and md5.anim in Blender: https://github.com/KozGit/Blender-2.8-MD5-import-export-addon It works with Blender 3.6.15 which is the latest version in the 3.0 series. It doesn't work with Blender 4.2. It seems that the culprit is the change in the 4.0 series from bone layers to bone collections. Here's an updated .blend file with male NPC animations. .blend file with a female model Like before: use armature_control to animate the model when you're done, select the tdm_ai_proguard armature object and Bake Action to Pose; select Visual Keying for the exporter to work you need to select both the tdm_ai_proguard and a mesh object that's being animated, e.g. proguard_armor

I don't know how these entities work in detail, in case your asking me. There seems to be some scripting involved. I have not looked closely at the implementation. But the way I do it often, is basically two entities (light and model/behavior), that have to be linked somehow. I just shrink down the original light, and target my light to it (Maybe any other way would not be that much different). But it means there is an extra light entity, when only one is used.

Okay. I think the core issue comes from the idea of merging a model and light into one entity. Is it really hard to make the separate? UPDATE: There is something called localLightOrigin in the code. I think it comes from "light_origin" spawnarg and is also affected by "setLightOrigin" script event.

Thanks for playing again! It will be a little bit before I can boot up the mission and check this, but there was at a certain point a diff issue in a patch vs what got pushed to the mission downloader which was fixed, which included issues with this model and few others. I wonder if maybe you are still rocking that version. Is this a recent download from the mission downloader?

That does not solve the issue I described, unfortunately (it's a slightly different problem). There is another point (the "middle" of the light volume) that can't be changed. The model is always located at this point. I have to use a secondary light, to do what I want (as described in my ealier post). It's very inconvenient.

entityDef atdm:lamp_hanging02 { "light_center" "0 0 -68" "editor_setKeyValue light_center" "0 0 -68" I think the light_center spawnarg does exactly what you need: specifies the offset of light origin from the model origin.

There is a missing model (playing on TDM 2.14). This is a very special mission. I love the way safe combinations are not just written down and lying around somewhere, for example. (Apparently I've gotten more stupid since I last played it, because I can't figure out the first and easiest one anymore)

in the material file: tdm_forest_treebark_mossy The normal texture has a typo: .../forest_treebafork_mossy_local should read: .../forest_treebark_mossy_local

For the people eager to play with the latest state of development, two things are provided: regular dev builds source code SVN repository Development builds are created once per a few weeks from the current trunk. They can be obtained via tdm_installer. Just run the installer, check "Get Custom Version" on the first page, then select proper version in "dev" folder on the second page. Name of any dev version looks like devXXXXX-YYYY, where XXXXX and YYYY are SVN revision numbers from which the build was created. The topmost version in the list is usually the most recent one. Note: unless otherwise specified, savegames are incompatible between any two versions of TDM! Programmers can obtain source code from SVN repository. Trunk can be checked out from here: https://svn.thedarkmod.com/publicsvn/darkmod_src/trunk/ SVN root is: https://svn.thedarkmod.com/publicsvn/darkmod_src Build instructions are provided inside repository. Note that while you can build executable from the SVN repository, TDM installation of compatible version is required to run it. Official TDM releases are compatible with source code archives provided on the website, and also with corresponding release tags in SVN. A dev build is compatible with SVN trunk of revision YYYY, where YYYY is the second number in its version (as described above). If you only want to experiment with the latest trunk, using the latest dev build gives you the maximum chance of success. P.S. Needless to say, all of this comes with no support. Although we would be glad if you catch and report bugs before the next beta phase starts

Could you give some example? E.g. some problematic "light model entity"...

How you can help depends a lot on what skills you have. I can Record Video Recording "Let's Play" videos or simple walkthroughs of existing missions and posting them to Youtube is great exposure for the mod (see example .) Be sure to let us know so we can link to them. If you have some editing ability, Video tutorials, where you explain how the mod works, or how to use specific tools, would also be great. Video trailers, showcasing interesting places and features, are also great for publicity. An example is . I can Write Writing reviews for missions are always nice, especially if they include good screenshots. Not only does it give us something to post on other forums, but it makes mappers feel good when their mission gets attention (especially if it's positive). We have a collective thread to post reviews in: http://forums.thedar...s-walkthroughs/ Writing reviews of the mod as a whole, targetted an an audience that doesn't know much about TDM, is also very useful. You could also try offering your services to mappers to create interesting readables, or to proofread for their mission. I can Act and Record Audio We are always on the lookout for good quality audio recordings for vocal sets. If interested, you can pick a few different lines from this script: http://wiki.thedarkm...t:_Average_Jack and send the recordings to Springheel, who then writes a script based on the type of voice you have. I can Translate We could always use translations of our menu/hud into more languages. Also, only a few FMs are aavailable in more than one language, so there is a lot of work there, see the I18N Translator's Guide in the Wiki. I can Model Great! Take a look at the model request thread:http://forums.thedar...-requests-here/ and pick something that interests you. Or just post a, "Hey, anybody want a model?" thread in this forum and I'm sure mappers will get back to you. I can Animate Fantastic. We can always use more good animations. Our current character rigs use a Maya skeleton. PM Springheel for more info. I know C++ Have a look at our coding section in the wiki, pick an issue or feature from the bugtracker of the mod or the leveleditor, download the recent sourcecode release (or better ask for an SVN checkout) and get cracking. Make sure nobody is already working on that specific issue and feel free to ask questions. I can Edit Images We can always use completely new textures and/or improved versions of older textures. How to get started and how to import them into the mod. I can Take Photos Good quality photos of useful textures (medieval-ish building facades, dirt, rocks, wood, etc) are always welcome. The fewer directional shadows and higher resolution, the better. I don't have any skills Even if you can't do any of the above, you can still help out. Talk about TDM in other forums; share your (preferably positive) experiences with other gamers you know. Last, but not least, compliment people when you like their work. Saying "thanks", to a developer or, "I really enjoyed your mission" to a mapper will make their day. -------------------- I'll update this further as more things occur to me.

the dev of the dcotepatch actually managed to recreate the script engine source code from the debug files on the cd. you can also modify running speed and jump height with the patch as well as sanity thresholds to make it a little less painfull to play. i use an old tool to patch the game executable to limit cores to 4 since it has problems with todays multicore processors (also needed with the gog version if you have a cpu with more than 4 cores) the gog version is limited to 60 fps cause unlimited breaks multiple sequences like attack of the fishmen so you cannot escape when they break down the door to your room. there was an old bug with shaders that caused raindrops to look like diamonds on ATI/AMD cards. this was also fixed by the gog version as well as the invisible sorcerer bug in dangerous voyage. if you encounter stuttering while moving it is caused by mouse polling acting up (many old games from back then had the same problem on modern machines "F.E.A.R feks.). there is a directinput wrapper on the pc gaming wiki that fixes this though it is for F.E.A.R it works fine with this game as well. alt tabbing crashes the game, use dgvoodoo2 or dxvk to allow it. the game also looks kinda bad on widescreen this can be fixed by using this https://github.com/ThirteenAG/WidescreenFixesPack/releases/tag/callofcthulhu for other bugs that might crop up see https://www.pcgamingwiki.com/wiki/Call_of_Cthulhu:_Dark_Corners_of_the_Earth there is also a HD pack for it though it uses an old version of sweetfx (reshade nowadays) works quite fine though the upscaled textures themself do not up the looks by that much (probably because upscaling filters back then were rather poor "no AI"). if you want to try your hand at upscaling the games texture use this -> https://dcotetools.sucklead.com/p/xbdsplit.html be sure to backup all files just in case. the game uses dds format so they will have to be converted beforehand if using upscayl as it does not support dds format. afterwards you will have to convert the upscaled images back so be sure to note which dds format the game uses.

It seems a driver problem, not really strange for me. I don't think that it is really a TDM problem. In other Forums I see a lot of different issues with Logitech Mices and drivers, myself I had also problems with Logitech Mices. Nerer had again Problems buying specifically gaming mices with cable, these are way more robust and stable for obvious reasons. Maybe changing the Mouse will solve the problem. Currently I use the Rival 3 Gen 2 from Steel Series since several Years, very precise and responsive, apart with a good price (some Years ago I paid ~€30, now it costs somewhat more as I saw in its Homepage.

I "vibe code" the old/amateur way by asking for specific functions to be made. But from what I hear, the most advanced workflows encompassing entire projects and actually spending money on frontier model tokens are yielding stupendous results. And it will only get better, and probably fast, because coding is a major area of focus, and adjacent to the effort of trying to use models to create better models. On local AI, the RTX PRO 6000 Blackwell 96 GB price has doubled to $16,000, Gorgon Halo 192 GB will probably be at least $5,000, and you can buy a GB300 DGX Station with a 748 GB memory pool for around $95,000. I believe those kinds of capabilities will become dirt cheap after 3D DRAM takes off.

So as many mappers may know, getting NPC's to path find over the top of func_static patch based terrain is a ball ache. The current method is to place lots of perpendicular MC brush at varying heights under the patch, loosely aligned to the surface of the terrain etc. When the terrain brush is all one texture type, the above is a viable solution. But when you introduce vertex painted terrain patches, the issue of different foot sounds becomes a question. As in for reasons I don't understand yet, you only hear one foot sound type, eg grass or stone etc. So I came up with a technique that I don't know if anyone has used before. To get around the foot sound issue, I place a nodraw solid brush (NDS) with different textures (grass/stone/etc) to cover the different parts of the terrain . And as every mapper knows, trying to raise/lower the vert point of a square brush, inevitably causes other verts to move when you don't want them too. So my solution was cut the square brush up into triangles, so for a square brush that's 4 triangles. Here is an example of a large vertex painting terrain brush, with 3 different textures that I have placed a bunch of NDS brush under.

edit: TL;DR: I've tweaked the .lwo exporter to preserve autosmooth angle Ahem. When I started writing this post a couple of days ago, it was supposed to be a "please help me, models won't smooth" kind of thing, but as I started taking screenshots and such for a comprehensive view of the problem, the question morphed into a "is there a hack to get .lwo's to export the way .ase's do", then to "how to get the same surface smoothing from Blender as you can get from Lightwave" and eventually to "does anyone around know python and blender enough to fix the export plugin". But then I fixed the addon myself, so it was almost as if there's no point to the thread. However, while googling around for a solution I stumbled upon a whole bunch of incomplete (1,2) or outright wrong (1,2) information, and whenever the question came up the issue was never really resolved completely. That might be because the problem isn't obvious, since a lot of exported models will actually end up correctly smoothed on export, leading one to believe wrong shading in rare cases is due to modeling mistakes / bad shadowmesh / etc. Point is, having the definitive .lwo smoothing post seems useful. Identifying the problem: Here's the mesh. I add an 'edge split' modifier (I use sharp edges while modeling the low poly, so I can uncheck the 'edge angle' option). I can now apply the modifier(s) and export to .ase (triple the mesh either in export options or in modifiers beforehand). The .ase looks alright in-game: Now I'll export it to .lwo using this script. Depending on export options, here are the results: If I also check "remove doubles", I'll lose all of the split (sharp) edges: (recalculating normals on export can be unpredictable as well, so clean up the model beforehand instead) Right about this point I start searching for a solution online, stumble upon this and try the renderbump hack. However, all it seems to do is weld all of the vertices back together at runtime and attempt to smooth the whole surface, similarly to "remove duplicates", but with no upper threshold. (to anyone possibly reading this in the future: don't forget to revert your changes to the materials!) Source of the problem: At this point I still wasn't sure if it's even possible to get .lwo's identical to .ase's, so I installed Lightwave. Naturally, it took some time to eventually stumble upon Surface Editor (F5), and the "smoothing threshold" contained therein. But then I just had to crank it up to 180 and export to "LWO2". That fixes everything in-game: So the issue is trivial, I just have to find a way to somehow pass on a smoothing angle through the exporter. However, the "auto smooth" option on the object data tab doesn't seem to affect anything regardless of angle. Long story short, after some hex-comparison magic, I home in on SMAN block in the exporter script: So what it actually does is set your smoothing angle to either 90°, 86°(??), or 0°, depending on whether you've chosen "idtech compatible", "smoothed", or neither. The solution: Now, I don't know Python and I don't know Blender scripting, so I can't say with full certainty that I didn't break anything. But I did cobble together a version of the script that seems to do the job. Here it is, mirror / do whatever you want with it. If your mesh has autosmooth enabled, and you've checked "idtech" or "smoothed" on export, your chosen autosmooth angle will now transfer to the surface in .lwo: I took the liberty of changing the default export options to what seems to suit TDM the best, you can just open the script in notepad and edit them to your taste. Wrapping up, there are still some mysteries I didn't solve, such as "idtech compatible" models taking up only half the size of models exported otherwise (including from Lightwave itself), there doesn't seem to be any visible difference in-game, at least in TDM. That "1.5 radian" in the code still makes me scratch my head. And I still don't know if the 4-8x size savings over .ase matter for in-game memory at all (but at least I know I won't have to edit the *BITMAPs manually anymore). Even after all this, the .ase still has just slightly better shading, but since the outputs of the exporter and Lightwave itself are now identical, seems safe to say it's as good as it gets.

This was also always an issue for me. When I place lights, I like to control and fit the location of the light volume exactly into its environment (for example to keep lights from extending into adjacent areas or to create shadows). That means the center (or origin) of the light volume is at some random location in the room, and almost always the wrong place for the model (which is on the wall or ceiling in most cases). But that's how all the light entities work and I have to use an inconvenient workaround.

I see we have independently noticed this problem. I have proposed named strings for these instead of numbered strings in https://forums.thedarkmod.com/index.php?/topic/23204-proposed-i18n-improvements-for-tdm-215/ Would you be willing to change your patch to use those names? I'm translating those strings into the 16 languages now. I'll look to your translations for the German versions.

That's a cool feature that I will have to have a look into at some point, however - - you would be doing ping-pong workflow between blender and DR, trying to guess in blender where the raised parts of the terrain should be and then finding in DR its cliping into or cover something etc. - texturing on brush would be a nightmare in DR, and this would also have to be done in blender. This would be fine if the terrain brush was the only one in that location, but if it had adjacent terrain that the texture had to align too - more ping-pong. The above only works if your creating the terrain/s right at the start when blocking out your map, but some mappers don't work that way (ie me) I build stuff on the fly and out of order and sometime come back to a map to do a detail pass and change a bunch of stuff.

I don't think it is okay for randomly force non-native letters onto languages. For instance, there are 8 non-ASCII letters in the English set now. Isn't it that every language has its own font texture? { char 0xC2 0xAC : 0xAC // ¬ -> ¬ char 0xC2 0xAE : 0xAE // ® -> ® char 0xC3 0xA0 : 0xE0 // à -> à char 0xC3 0xA2 : 0xE2 // â -> â char 0xC3 0xA7 : 0xE7 // ç -> ç char 0xC3 0xAA : 0xEA // ê -> ê char 0xC3 0xB1 : 0xF1 // ñ -> ñ char 0xC3 0xBC : 0xFC // ü -> ü }

I remember there was something like this in fm The Accountant. Probably not done the same way. I guess it kind of depends how you want it to be. Do you want it to look like the animation goes to the middle, or do you want it to look like the animation goes inward. If you then look to the side, it looks kind of wrong. I wonder if you could do this with a pom texture.

We have been collecting textures for 4+ years, by nearly a dozen different people. It is inevitable that some textures will not stand up well in terms of quality. This thread is the place to nominate textures you think are poor and should be either fixed or removed. The following process will be followed (we are currently on step 1):