Search the Community

Innovation is good: someone has a new idea (or need) and executes it to the best of his/her knowledge and ability. When we start borrowing and adopting other people's innovations we are no longer innovating but creating a trend, for better or worse. Stgatilov is touching the tip of this, still small, but growing by the mission iceberg.

In By Any Other Name, I needed to deactivate the sword, bow, and blackjack for a while (during the middle part of the mission). I couldn't figure out how to "turn off" the bow, and then later turn it back on again. So I ended up cloning tdm_weapon_arrow.script, and modding it (adding a special variable that got checked when you tried to raise the bow). Pretty kludgy, and obviously can lead to breakage. (I also had to make similar changes to tdm_weapon_blackjack.script and tdm_weapon_shortsword.script.) Maybe all I need to do is remove all of the arrow ammo. That way the bow won't raise. That still leaves the blackjack and sword. I think there was a way of deactivating weapons, but I couldn't activate them back on again (?)

So because of bugtracker 5600, does that mean that 10 FMs (Written in Stone, Northdale 1 and 2, Volta 2, Hazard Pay, etc.) do not work in this new dev build, and yet, the dev build was released anyway? That's not cool.... The bow is kind of an important gameplay element, especially for Hazard Pay. Why even release this build if it breaks 10 existing FMs?

Why the sad face? Also, Kingsal would be better able to explain the changes, and he actually modified the script so that it is more TDM-friendly. This modified script is in Eye on the Prize and Moongate Ruckus

So this revised script is part of Kingsal's arrow mod, and the script tweaks a few values such as the ARROW_zoomdelay from "6" seconds to "3" and a few other things. I also thought this was the script that increases bow draw speed, but I guess that is done in the associated .def files instead. These tweaks were made so that gameplay would feel a bit more fluid when drawing and firing arrows.

Wow! These shots look incredible, you really nailed the architecture! Unfortunately, I don't think I'm gonna have the time to beta test this, but we'll see. I just wanted to tell you that these shots look rad!

Welp it's about that time again to wheel out The Lieutenant for another mission and I could use some help making sure it's at least somewhat playable. Please register your interest here and I'll start a new beta testing thread soon. Due to custom assets the file size is quite large (about 500 MB). Potato users welcome. Some screenshots:

As a matter of fact, I implemented passing info from briefing to game and from game to debriefing: https://bugs.thedarkmod.com/view.php?id=6509#c16671 At some moment I think I should put this info to wiki... This will be available in the future dev build. P.S. By the way, you can also override which .map file to start, although I'm very skeptical that this feature is worth the trouble you'll get in maintainability. Small variations of the same map should be better implemented by writing the "main" game script.

As you probably know, overriding core files which are not specifically designed for that is fragile and unsupported. Indeed, it usually works... until it does not Here is the list of missions which completely override tdm_weapon_arrow.script: ahouseoflockedsecrets @Moonbo byanyothername @joebarnin cauldron_v2_2 @kingsal good @Amadeus hazard @kingsal northdale1 @Goldwell northdale2 @Goldwell seeking @Amadeus@Dragofer@Wellingtoncrab snowed_inn @Goldwell @kingsal written @Amadeus @Dragofer I have just got rid of creating cvars dynamically (5600), and shooting the bow stopped working in these missions. Because they distribute an old version of the script which runs in "debug mode" that relies on dynamic cvars. Core version was updated some time ago and this debug mode was removed. I'd like to ask authors: why did you decide to override this script? Perhaps we can add some customization points and delete overrides?

Could somebody update the article about the lightgem? 1. Add a sentence that a red frame around the lightgem indicates that it is at maximum intensity. (see https://bugs.thedarkmod.com/view.php?id=6525) 2. Remove the lingering quotation mark after "Stealth & Shadows". Update: Dragofer added a sentence about the red frame in this edit, but the orphan quotation mark is still present.

If it really crashes, then you can record crashdump and send it to someone with debugger. This often allows to learn what is wrong (but not necessarily where is the error).

Never thought it was enabled.....thanks! Stupid camera lens "simulation" effects (bloom when overdone, chromatic aberration, flares, dirt, etc.....even DISTORSION of the entire viewport in Atlas Fallen - it's only acceptable in a sniping UI) The only thing rivaling in "detest" feeling with camera lens effects is the pre-sharpening pass in case of Temporal AA (Chernobylite) or Depth of Field too (yes, I see you Dishonored 2 / DotO)

Disable Lens Flares For those making their own with Reshad or just dislike the look. Thief Game>Config>ThiefEngine.ini Look under [SystemSettings] LensFlares=True to LensFlares=False ON OFF

Found the White Flash Hex Value but not the one for the Shroud effect. I'm playing the Epic Version.

I like the Transition from dusk to night in the Prologue and the fact that it didn't last long. Hiding and stealing during the day feels weird to me. I couldn't digest Mankind Divided as much as I liked the Artistic touches for this reason. The Prague map felt so Arbitrary.

Ps. sorry for the huge wall of text....

Oh, some implementations might work a little differently from what I remember the term megatexture referring to. From what I used to know, it meant turning the entire level into a single model or set that uses a single enormous texture. While the concept may have its upsides, there are two major issues that negate any benefit in my view: The first is system resources, you don't benefit from any reuse as every pixel is unique, the only way to do it at scale is with a gigantic image thus a huge performance drop in pretty much every department. The second issue is that level design becomes far harder and more specialized... while here in TDM we only need to draw a bunch of brushes and place some modules to make a level, an engine based on megatextures would require level designers to sculpt and paint the entire world in software like Blender which is far more difficult and we likely wouldn't have even half of the FM creators we do today, even for those that know how to do it imagine the task of manually painting every brick on every home and so on.

Yes, if you turned too fast, you could see the textures pop in. Most Unreal engine games still do this when you start...

Completely disagree it was a very good idea that unfortunately came too early with idSoftware RAGE 1 because hardware was still and is not truly ready for it. Megatexture is for textures, what UE5 nanite is for geometry, it permits huge amounts of texture data in a level and even totally unique textures per each surface, no repetition unlike older methods. MT isn't simple a giant texture slapped unto a level, it is a type of virtual texturing system, the MT is a huge "texture" but it's data, is not all drawn on a level at the same time, like a normal one is, it is broken into smaller squared peace's and those peace's into even smaller ones for LOD aka mipmapping, then those peace's are streamed in, in real time has the player moves around. Again IMO It is a very cool idea and if the hardware was fast enough, to stream it fast and it was possible to compress the MT data, to very small amounts and still keep good quality, it would be a fantastic system for very unique levels. Rage 1 world may look bad at close distance, but at medium to large distances imo it looks fantastic and totally unique.

The Megatextures concept predates idSoftware. It even predates hardware accelerated 3D in consumer graphics. The problem it solves is managing image diversity. It is well suited to photogrammetry where almost nothing is repeated \ tiled. It is not well suited to human texture artists because even the most perfectionist ones are going to use some sort of template that they repeat and thus it is a waste to store the resultant work as unique pixels rather than tiles.

Rage didn’t have terrible loading times but people complained that it took awhile for the texture fidelity to catch up. Doom 2016 tried to fix that by front loading more but they went overboard with that.

Megatextures were a horrible idea for obvious reasons, not sure why ID chose to learn that the hard way. The concept from what I remember is the whole map uses a single gigantic texture... instead of how we independently pick a couple of 1024 px brick materials for a few brushes and surfaces, the whole map acts as one model with one material and a single texture which probably needs to be 1 million x 1 million pixels even for a small level. This is ridiculous from a perspective of system resources with 100's of GB's of storage and huge (v)RAM requirements and hours of loading time, as well as raising the skills required for level editing since you now need mappers to also be texture artists and sculpt / paint their levels instead of just placing stuff. The only thinkable benefit is there's no repetition since every pixel on every part of the world is unique, but who notices any similarity with independent texturing if it's done right anyway? Detail textures have yet another advantage there: Since you scale the pattern independently on top of the original texture, you can make every surface appear as if it has unique pixels like megatextures. Hence why I'd advice having the details be very high-res, 4k or 8k even 16k if we can take it: Yes that's enormous, but remember we'd only have a few patterns probably no more than 15 in total, and can store them as grayscale then use a single image to modify both albedo / specular / normal (heightmap to normalmap): Map the detail in world space rather than the brush or model UV map, and the resulting pattern on every surface in the world will always be unique since the original and detail textures will be out of sync.

Wasn't "Megatextures" the reason Doom 2016 (IdTech 6) takes years to load though, even on a high-class SSD? I've then heard that Megatextures were scrapped out in Doom Eternal (IdTech 7), which apparently could add to the fact it loads incredibly fast.

I think that this discussion is probably similar to discussions that idSoftware themselves had about the challenges of texture storage in engines that heavily rely on Normal Maps for real-time lighting. The conclusion was Megatextures ( later known as partially resident textures ) but the suggestion was a little too ahead of its time. Heck, early Megatexture games would probably benefit from detail textures more than idTech4 because they capped the pixel density to allow larger map-sized textures. Many modern games have caught up and use partially resident textures but do so in a more conservative way thus making them part of a hierarchy of texture usage methods that includes texture atlases and traditional tiled textures.

I always say that...The only thing that beats a fail is a try. I'm actually interested in these Detail Textures now that you further talked about its history and how today we'd use it on 1080p for 512 and 1024 textures. If anything, it would be a fun experiment just to see how it would look and how it would go. Also, yeah, I wouldn't want the game to be bigger than 100GB and have extreme loading times, all in the name of modern textures at 4k, I have a very hefty computer but that doesn't mean poor ol' but venerable IdTech 4 wants to handle it.