Search the Community

All is working and has a basic directory and save system, with automatic scaling to the recommended dimenstions (upper left) and can be used just to make the maps for input images (to the right from the directory and name, the red lines indicate how the reference image stays as it is), or have the inputted image as a reference for the AI to work from. I tried to make it as simple as possible where things can be bypassed (like maps and saves) and a lot of nodes are hidden under other nodes, and nodes are pinned so you can't drag them around without unpinning them. Next step: getting it all ready and packed for download and install so ppl can use it .. and some sort of manual I guess : P @nbohr1more I see the texture guidlines were updated! But now I wonder about the recommended dimension or the heightmap?

It was my fault at the very beginning but later I started following these guidelines: Precaching (def files). When I debug my mods (decl_show 1) I notice nothing unusual except for the images: parsing material path/to/image Trying to load image path/to/image from frontend, deferring... 0x0 path/to/image Whatever it is, when image X is required by the game for the first time it can cause a stutter. I say "can" because sometimes the stutter happens and sometime it doesn't OR sometimes I notice it and sometimes I don't.

This was a great excuse to play this mission again. Its still amazing even after all these years. The EFX changes sound pretty good, however, I agree with @SeriousToni. @datiswousCAVE should be replaced with either STONEROOM or CASTLE_LARGEROOM. I find that castle sounds pretty good for large echo chambers. For future reference. the EFXs with prefixes sound the best (CASTLE_ , FACTORY_, ect). The ones above that have some weird effects, but are pretty specific and some just sound wrong.

Thanx, in the Texture guidlines I read normalmaps should be TGA (uncompressed, no RLE) and I can't find any "node" for comfyUI that can save to TGA .. but I have a node that can save to DDS (bc1, bc3 or bc5) with mipmaps. Thing is that this node also creates a json with it. There is an other node that saves in DDS that it has no settings but doesn't create an other file with it. If this node puts out bc5/dxt5 with mipmapping, would it be acceptable to save diffuse, normal, specular and height with it? The other thing is, since it can't save in TGA, what fileformat would be preferable for the highres backups? I'm now making a automated save structure for the different maps where project name, material type, optional sub type and material name can be set globally and it will save in projectname/(dds)/textures/materialtype/(subtype)/materialname The materialname wil be assigned the appropriate postfix; _local,_s,_h,_ed. I think the folder HighRes will be in in projectname/textures/materialtype/(subtype)/HighRes. Or would there be a better directory for that? The maps will be downsized to the apropriate max resolution before saving, but ofc. the high(er) resolution images won't be downsized. It's quite a puzzel, but it should all work in the end : )

Pff .. now I have to try and implement this I guess: https://www.reddit.com/r/comfyui/comments/1blhkk6/comfyuitexturesimple/ https://github.com/gokayfem/ComfyUI-Texture-Simple I want to finally get a good save name and save path structure where the material class name can be set to have the output saved in a folder with that material class name. And the material name that will be set to all outputted files like: name_diffuse, name_normal, name_specular, name_height, name_editor ( or however these are called in TDM / however the general syntax for texture files is?). When that all works, I like to simplify the whole UI as far as possible and have toggle buttons for creating and saving the maps, so you can only generate a (diffuse) image till you have something you like.

I guess if these are mission specific textures, you could use material keywords to do the inversions: { blend bumpmap map scale( invertColor( /path/to/bumpmap ), 1, 1, 0, 1) } invertcolor does all RGB, the scale reverts blue

Ah, it's the Aniso x16 issue. I forgot to turn it down to x8. That's an issue going way back, by the way: sometimes when you look at a surface at acute angles, you get GPU load spikes, without any visible reason. I never had problems with other games going all the way to AF x16. Wonder what's with that in TDM. Anyway, I tested it with uncap FPS and VSync off too. I've never heard my GPU fans being this loud Default material: Geometry: POM:

Those hand animations are very nice to see, especially the compass animation. Can you make animation for holding / showing the map, like in sea of thieves? (Also asked for in https://forums.thedarkmod.com/index.php?/topic/21038-lets-talk-about-minimap-support/#findComment-463678

Default material: With POM: With some elements on geo: These have no LOD, so that 23% GPU load looks a bit sus, maybe there was a hiccup there. All in all, performance stats do look similar. As for POM, it does look pretty cool, 20 steps look good, even without much texture authoring on my end. I sure wouldn't want to model these pebbles by hand

Raytracing is special API, it has to be used explicitly. And it does not even exist in OpenGL. It is in the latest dev version, but it is not something that magically works for all existing shaders. You need to find a material with parallax stage, or create a custom one. The latest dev build contains many parallax materials made by @Wellingtoncrab.

Okidoki, I finally bit the bullet & went with a Recoil 17 from PC Specialist Specs I went for are Chassis & Display: Recoil Series: 17" Matte QHD+ 240Hz sRGB 100% LED Widescreen (2560x1600) Processor (CPU): Intel® Core™ i9 24 Core Processor 14900HX (5.8GHz Turbo) Memory (RAM): 32GB PCS PRO SODIMM DDR5 4800MHz (1 x 32GB) Graphics Card: NVIDIA® GeForce® RTX 4080 - 12.0GB GDDR6 Video RAM - DirectX® 12.1 External DVD/BLU-RAY Drive 1TB PCS PCIe M.2 SSD (3500 MB/R, 3200 MB/W) Operating System: NO OPERATING SYSTEM REQUIRED The case seems to be made of metal not plastic & there's an optional water cooling unit, which I didn't get For the OS I disabled fast boot & secure boot, loaded Zorin 17.2, used the entire disk, without any installation issues Zorin is a Ubuntu fork so Ubuntu & it's other forks shouldn't have an issue if anyone else gets one of these The only minor issue is the keyboard backlight isn't recognized by default, but the forums are full of info on sorting that out, not that I'm too bothered I've installed TDM & it runs beautifully I also copied my thief 1 & 2 installations from my desktop, I had to uncomment "d3d_disp_sw_cc" in cam_ext.cfg to get the gamma processing working but they run happily too The fans switch on when booting & switch off again after a few seconds, the machine isn't stressed enough to turn them on running TDM so far - this is not a challenge btw On the whole, I'm extremely pleased So thanks for all the advice

Yes: A round patch should mitigate the effect of parallax being constrained to real geometry. Just make sure the material coordinates are perfectly aligned. For buildings my advice would be to have a pillar brush jutting out in corners. Which reminds me of my question earlier, still curious to hear answers: Can we have material based building modules with parallax, as an alternative to the building module meshes? The new building modules are great but I'm definitely running into my fair share of issues with them: Having depth-based beams and panels for both building exteriors and interiors could look really amazing!

As far as I understand the blooming effect only occurs (with bloom on) when the rgb values of a material exeed 1. Before the implementation of bloom, rgb values were only effective between 0 and 1, so probably no missions should be effected by unwanted bloom effect.

Some sort of buffer overflow. Are you using any parameters that reference "long" floats? Are all your variables lower case or case matched ? ( Linux is case sensitive )

Definitely do the first run on easy, the difficulty adds a few extra guards and reduces the arrows you start with. The loud footsteps surprised me too, I guess it's how the stone material propagates... I positioned some of the carpets to mitigate hearing based difficulty, don't forget to make use of moss arrows too where appropriate. And yeah I should have made the intended way to exit more obvious, if I ever update this I'll consider it.

With the functionality I'm hoping for, tabbed maps would be opened when DR starts and stored in memory so clicking between them shouldn't imply any noticeable slowness. It's like tabs in web browsers like Chrome or Firefox: If a tab is there the website is already loaded, clicking to switch between two open pages doesn't reload them each time. At very worst all assets in use should be loaded and retained in memory just once. Thus clicking on a different tab doesn't cause DR to load or unload anything; Any asset used by any map in any tab remains loaded till the last map to reference that asset is closed.

I meant it's not the team's responsibility to ensure backwards compatibility, at least if it's some special case (they use a deprecated system in a weird way that breaks, which is how it usually if very rarely happens). It's just managing mapper expectations that there's a small chance their FM may become broken in the indefinite future if they do that. But I basically agree with stgatilov that this, and the other things he mentioned, aren't really the job of the TOS but some "Read this before you submit an FM" note. Edit: Oh one thing about disgruntled mappers though, in my own org we'd have some term that if there is a dispute between the mapper and the organization, they agree to good faith private negotiations and failing that arbitration instead of going to court. But we've never had any dispute to that level. By the way, I don't do IP law professionally (although I took the class). I work in a different area. So I don't necessarily know anything anybody couldn't learn with a few hours online research. But it makes sense to have a statement that our terms disallow illegal or infringing material so there can't be any claim that the forum / team condones or invites it, mostly as a formality. If I were tasked with making a TOS, the first thing I'd do is find a number of other TOS's out there for similar projects and use them as a template or starting point. The bigger the org, the more likely it was vetted by their lawyers. If there are terms they almost all share, that's a sign they're the important ones. There's also the part about creating or modifying a TOS mid-stream, after 100s of FMs were released under whatever terms they were at the time (I haven't looked at it recently).

I think we should first decide what do we want TOS for: To protect TDM from legal issues? To protect TDM team from angry mappers in case of conflicts? To guide mission authors in their work? In my opinion TOS should only cover legal issues, and wiki articles about making/releasing missions should cover author guidance. The chance of getting malware in a mission only increases after we write this publicly. Better don't even mention it, we are completely unprotected against this case. By the way, isn't it covered by "illegal" clause? I'm not sure this is worth mentioning, but I guess @demagogue knows better. By the way, which jurisdiction defines what is legal and what is not? Isn't it enough to mention that we will remove a mission from the database if legal issues are discovered? I think this is worth mentioning simply because mappers can easily do it without any malicious intent. We already had cases of problematic assets, so better include a point on license compatibility. It is a good idea to remind every mapper that this is a serious issue. I also recall some rule like "a mission of too low quality might be rejected". In my opinion, it is enough. You will never be able to pinpoint all possible cases why you might consider a mission too bad in terms of quality. And even the specifics mentioned here already raise questions. Having such a rule is already politics. I feel it does not save us from political issues but entangles us into them. If there is a mission which contains something really nasty, it will cause outrage among the community (I believe our most of active forum members are good people). If people are angry, they will tell the mission author all they think about it. And if the author won't change his mind, he will eventually leave TDM community. Then the mission can be removed from the database, perhaps with a poll about the removal. But it sounds like an exceptional case, it is hard to predict exceptional cases in advance. This is not even terms of service, but a technical detail about submissions. The mission should be accompanied by 800 x 600 screenshots. Or we can make them ourselves if you are OK with it. This is again purely technical, and I'm not even sure why it is needed. Isn't it how TDM works? If mapper does not override loading gui file, then default one is taken from core? Is it even worth mentioning? I think we should discuss mission updates by other people in general. This is worth mentioning so that mappers don't feel deceived. The generic rule is that we don't change missions without author's consent. But it is unclear how exactly we should try to reach the author if we need his consent. PM on TDM forums? Some email address? However, sometimes I do technical changes to ensure compatibility of missions with new versions of TDM. Especially since the new missions database has made it rather easy to do. Luckily, I'm not a mapper/artist, so I never fell an urge to replace model/texture or remap something. But still, it is gray zone. On the other hand, I think the truth is: we can remove a mission from database without anyone's consent. I hope it has never happened and will not happen, but I think this is the ultimate truth, and mentioning this sad fact might cover a lot of the other points automatically.

Yeah the reason you'd mention no illegal or infringing material is for us to be able to say we're acting in good faith, if somebody finds their IP in an FM, they can't or it's not as straightforward to want to sue us for it. In practice I think it's more of a formality. As for FMs that don't finish or have buggy elements, there are demo-like or novelty FMs that might have both of those. Somebody mentioned the Tutorial itself. I wouldn't want to discourage somebody being creative, and I'd probably word it differently. Something like FMs should be "complete" before being submitted, but leaving it technically open what "complete" means. I guess it might give some examples "... including but not necessarily in special cases ..." that it starts and ends, is not egregiously buggy, does not consistently crash, etc. But I think even here it should be an encouragement instead of a hard rule, like we encourage mappers to get their FMs beta-tested, confirm that it starts and finishes, doesn't consistently crash, before submitting, and we may ask that you work on an FM more before uploading it if it is manifestly broken "without justification" (to leave open the possibility of "broken" FMs with a justification, like a novelty FM). Some of you might remember that TTLG ran a "buggy FM" contest once where broken FMs was actually the theme, and it was an amazing contest. Some of those FMs were broken in very creating, fun, and interesting ways, and it might be good to have FMs like that sometimes. The intentionality part was important though; you could have something broken if that's part of the artistic intention, so language that could leave something like that open may be good, or again encouraging people to always betatest and avoid unintentional crashing or broken FMs, etc. Because of past experience, we might also have language to give expectations regarding possible changes after they submit. Like an alert that while we make every effort to make sure future changes to the game are backwards compatible, it's possible a change breaks an FM. Also other people may want to take assets or things from the FM for their own FM, so we should say that technically, when you submit, you agree to the license we have for our assets (I forget exactly, CC-nc something something). So under that license people can use those assets. If you don't want that, you might make a personal appeal in the readme... The other worry is when people just take big chunks of the map itself, or make their own levels in the same maps... I wonder if we could have people make explicit what they consent to having done to their maps post release, if they allow the translation file, other people to use their map work, etc. But make it clear that the map is under the CC license, which allows people to use anything from it, and they can make a personal appeal that isn't binding, but people may be moved by it. And then we might have our own internal standards what seems egregious enough not to allow, like if someone completely takes another person's map and basically tries to recycle it under their own name, or when it's a team made map and the team disagrees what happens to it. Anyway, whatever we think, it's good to have language about it here to help manage expectations about what might happen, so it's good to think about what we should say to minimize conflict later on.

Yeah I'm aware of the use cases - I mainly used it for particles and preventing models from showing up through walls. The point of the thread was to reveal why it was even created, as the thread I linked contains advice from @stgatilov to NOT use it at all: https://forums.thedarkmod.com/index.php?/topic/21822-beta-testing-high-expectations/page/10/#findComment-490707 If that's the advice, an explanation is needed and the Wiki updated.

It's never a problem, until when one day it is a problem. That said, maybe this is a disease where continuous preventative treatment is worse than a targeted remedy after infection. I'm reminded of an incident I saw in the 0AD RTS project's community where someone (possibly as a troll, but maybe genuinely) complained about "immodest outfits" worn by female villagers and hero units for some of the civilizations being in breach of the project's content and exclusivity guidelines. The tremendous irony was that the bikini tops on those character models were already a concession to modesty, considering the historical reference art they were modeled from were even less covered up. Any rule set is going to contain oversights and ambiguities that trolls can exploit.

Just uploaded version 4 of this FM: Primarily this is a bug fix update, using TDM's many new diagnostic tools to fix issues like non-functioning visportals, dead-end GUI elements and sounds not playing due to a wrong sampling rate. The console now posts no warnings about FM-specific assets. Added subtitles provided by datiswous. Adjusted the river forest skybox to look more like it did when I originally released the FM, counteracting subtle, but significant changes to how transparent (leafy) surfaces are rendered in fog. Added a black fog to make the ravine scene look more bottomless. Also, wisps no longer leave behind black boxes at their starting positions. The AI in the bunk cabin of the starting ship should no longer be able to see the player through the corner of the bunks model (all nonsolid items should have visual-clip now). Cleaned up obsolete clutter from old-era material shaders. As a side effect, Linux users should now be able to start up the FM. Switched moonlights in certain outdoor scenes to the new parallelSky system. Got completely rid of the rotation hack for scaling models. Recompiled the maps using the newest version of TDM's compiler, benefitting from a lot of things that stgatilov changed over the years.

Yes, but I think png and jpg require a material def that can then be referenced by the GUI keyword for images via the material path

I plan on playing TDM with some friends over Christmas and want to pre-select some suitable short to semi-short missions for newbie players. A medium mission is okay if it is very easy. For reference, I can mention that I enjoyed the following missions: A New Job (I enjoyed the city-maze aspects with the climbing and the objectives in the tavern) I'd call this mission medium length. Tears of St Lucia (I enjoyed the atmosphere in the church and the multiple entry-points, but there was a little too much reading for the playing sessions I plan) I'd call this mission medium length. The Bakery Job (I enjoyed the sense of a simple job and that it was a fast play-through) I'd call this mission short. Closedmouthed Shadows (I enjoyed that it was a fast play-through) I'd call this mission short. Requiem (It is very well made in almost all aspects, but it is far too long for the playing sessions I plan) I'd call this mission very long. The Builder's Influence (I enjoyed the multiple entry-points, but there was a little too much reading for the playing sessions I plan) I'd call this mission medium length. (None of my comments above are intended as critique of any mission, just that some aspect of that mission may not be suitable for the playing sessions I plan. The "too much reading" in The Builder's Influence was something I did not mind when I played that missions by myself, especially considering that it was well written and contributed to the atmosphere and explained some of the back-story.) It is perfectly fine to suggest a series, just as long as each mission in the series is short or semi-short. Thanks in advance for helping me with this.

The second half looks like what I imagine the current material being upgraded to, I don't think one can truly say it alters the original too much. The first half is indeed very shiny, I'd go with making it part of a whole new outfit like for royal knight maybe!