Search the Community

Part of my point was that breakable electric lights could have an interesting contrast: They'd attract attention while also making it harder for you to get caught. When broken they should create a loud popping noise that makes nearby AI walk to them and investigate the disturbance, if they see the broken lamp even draw their swords and do an alert search... however once they've calmed down and moved on, you're rewarded with the ability to sneak there without being seen. The player will have one of two typical strategies: Either wait until there's no guards nearby in order to shoot a lamp, or shoot such lights if it's better to have guards searching but not able to see you compared to the guards being calm but able to spot you in bright light. Mappers would themselves place those lamps in areas where they want to create this particular challenge.

For the FM? For beta 1 it's here: https://drive.proton.me/urls/H1QBB04GA0#oBZTb1CmVFQb I've already done around 100 fixes though, so you might want to wait for beta 2 which should be ready in a couple of days hopefully. All links are in the first post of the beta thread here: https://forums.thedarkmod.com/index.php?/topic/22439-the-lieutenant-3-foreign-affairs-beta-testing/

This topic is going in different directions and it is difficult to tell if we all are in the same page. Facts: Stgatilov wants to change (improve, I guess) something and while implementing the change he realizes he will break some mission in the process. Mappers have been including (now obsolete) core files in their missions and the developer wants to know why these files were included in the first place, as in: the purpose. Changes in two mission are unavoidable, unless the authors go back and revisit the entire logic of their missions. Changes in eight missions are avoidable, in the sense that missions remain essentially the same with or without these changes. Regardless, if the improvements are to be implemented ten missions need to be reviewed and updated. Now my opinion: Considering how the topic is going the next time Stgatilov wants to improve something similar he might think it twice (we all lose because of ten missions). If these same improvements were to be implemented in the future chances are not ten but fifteen missions would have to be reviewed and updated which begs the question, does the inclusion of core files in missions put the present and future development of some areas at risk? No, as long as things remain under control: preserve what must be preserved, encourage and support innovations, identify and address trends. This requires an effort by all parties involved.

That's a very valid question. Personally, I'd say the key is to watch what the otherwise-disengaged fringes of the community are saying. If first time posters or long time lurkers start coming out of the woodwork about well made new missions, praising them for their geometry and story but saying that innovative parts of the gameplay felt frustrating or off, that's probably the first sign that the innovations are starting to get out of hand. For a more concrete example, re-read the comments on Hazard Pay. As much as I and many others love that mission, it's clearly a case where the author strayed further than many people were comfortable with. It also points to the likely endgame if authors do take their customization too far. After getting the negative feedback, kingsal made adjustments, and now the mission is much more friendly towards player preferences that don't match the author's original vision. You don't need to restrict the mapmakers' tools to stop them from straying too far from the traditional formula. When people start speaking up, the authors will rein themselves in on their own.

I can only speak for myself, but I think option 2 would be fine. This will at least allow the missions to be playable on the dev builds for now, and we can see if any other issues pop up

Yep, moved on to greener pastures. BTW, what I quoted above from him will soon be untrue for Stone 24pt due to my upcoming bitmap surgery. Actually, the values in the current stone .dat file are already misaligned with what any archival font patcher script would produce, due to 2.12 tweaks with q3font & refont. I'll add a note to the wiki about this (explaining it better than here).

I think this is a slippery slope fallacy. Just because the ability to customize exists does not mean most mappers will use it. On the contrary, if one considers the customization that are already available, we see that the overwhelming majority of mappers stick to the defaults. The exceptions are interesting also. Kingsal's the only mapper that readily comes to mind who habitually deviates from presets seemingly just for the sake of being different. However everything they make is clearly in service of cohesive visions. Hazard Pay, no matter how you feel about it, unarguably loses a great deal of its survival horror character if you take away the napalm arrows or the punishing save system. The Voltas don't need to use Thief style elemental crystals in place of TDMs arrow model, but the fact that they are there makes a definite statement about the author's awareness of their inspiration for their work in TDM from the original games, which in turn draws attention to other, subtler creative choices. I think it's also telling that some of kingsal's modifications have been adopted by other authors. As OrbWeaver said, "If the defaults are widely disliked, they should be changed." However, how can the community come to a consensus unless there are maps to showcase the advantages of new innovations? Requesting, or worse requiring, players to go in and manually change settings in order to experience a new mechanic is never going to gain any traction. Certainly it is not worth the effort of creating an entire map built around a new paradigm.

As a player, one thing I'm also not too fond of is the lack of uniformity. I think mission authors should take into account that especially players new to the mod want to figure out how the weapons work, and, they will have a hard time doing so, if many missions tweak the weapons. Apart from the "WTF" moment, they will also not know what the default behavior of the weapon is. Also not a fan of some other things some missions introduce, like the different sounds for foot steps etc. Most of them don't improve anything over the default sounds, to be honest. They're rather worse, and irritate me every time I play a mission with custom sounds.

I created discussion here and mentioned authors (maybe I missed someone though). Unlike the previous thread about main menu GUI overrides, I think the new one does not look aggressive . The main question there is why this was done, and how to adapt to avoid this problem now and in the future. Indeed, all the missions will be fixed by 2.13 even if some authors don't respond. Dev builds regularly break something, although usually it is done unintentionally. I added "known issues" point on the dev build, which happens pretty rarely. I apologize for the negative emotions this change has caused. Sometimes I am too rough in communications. Moreover, I am not a creative kind of person, I'm more a technical type of person. Thus I believe in interface boundaries, so in my mind the blame for breakage is always on the side that violates these boundaries. Anyway, I know I'll have to fix the breakage, probably myself if necessary.

Speaking of ARROW_ZOOMDELAY. Just changing it from 6 to 3 will not add any customization options. I think all the macro constants should be converted into spawnargs. Hopefully, we have a proper entityDef that can hold these spawnargs.

Yeah, as I said elsewhere, it's not so much that the missions are broken that is frustrating to me and several other affected authors, it's that there was zero communication to the affected authors that this was going to be happening beforehand. There is no reason why a message couldn't have been sent to the affected authors saying "hey, this will be broken in the upcoming dev build for X reasons. I thought you'd like to know before surprising you." Or even an open discussion beforehand about why these authors decided to make these customizations to begin with. Plain and simple, that's just a lack of respect. If you have the time to break these, you have time to communicate and see if there might be a solution to avoid all this (and there is!). And perhaps from YOUR perspective, you might think this reaction seems silly, unnecessary, and that this is totally fine, but from my perspective and that of a few others, it's not. EDIT: In addition, when creating or modifying existing assets, I and others take great care in making sure that these changes don't break existing maps. And if they do, we do whatever we can to own up to that and fix it. I do expect that same level of respect to be shown to existing maps so they aren't just broken with reckless abandon and no clear path forward.

Will it have an automap?

Good question. Maybe because I don't feel myself too guilty breaking these missions? Maybe because I know that fixing them will be a long story. And I feel confident that we (or more likely I ) will be able to fix all of them by 2.13. You might have noticed that I have also enabled two behavior changes in the latest build (1 2). In these cases it is not even mappers' fault that behavior change is needed. I have a script which can update all missions at once so that they work properly both in 2.12 and dev builds. But somehow I feel I should wait for at least some feedback on the new behavior before doing a massive change to dozens of missions.

I will have a look. No promises eh.

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.

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.

Also, related to font improvement, I've just released "ExportFontToDoom3All256", a reconstruction of an earlier but now lost tool variant. This is described and available in the wiki article ExportFontToDoom3 I tested that tool using one of the TDM FM fonts, Andrew Script, for which a TTF file is available. I generated a fresh set of bitmaps (newly including any available Latin-1 characters). I also mucked about with FontForge, to reconfigure that TTF to be ordered like the TDM custom codepage. However, Andrew Script is missing a fair number of Latin-1 glyphs, so it would take some work to make it good (whether by editing in FontForge or post-export as bitmaps). I'm putting that aside for now, since the jury is out on whether Western language support in FMs and their fonts will become viable (see Western language support in 2024?). Instead, I plan to turn my font-improvement-for-2.13 attention to Stone 24pt, which (because its used in HUD captions) is more clearly worthwhile to work on. Looks like I'll have to convert the Stone DDS to TGA as a prerequisite to bitmap editing.

If it's supposed to be an octagon, I don't think the corners need to be bevelled. Certainly it looks much better to bevel square corners, but the angles of an octagon don't look bad imo. If you want a smooth cylinder though, the default cylinder patch has 16 sides, which looks smooth enough in game. That would be easier than bevelling 8 corners. Speaking of smoothing; I was pleasantly surprised to find that if you make a model in Blender with smooth-shading ticked, then export an ase file, it will retain the smooth shading when imported to darkradiant.

Query: when playing a level, how sharp must a corner in the level geometry be for it to look bad to you? I'm sculpting my current FM from scratch as there aren't many prefab modules fitting my theme and the question has been nagging me for a bit. I've been using bevel patches to smooth out 90 degree corners made of brickwork for a slightly more realistic look to them, but I'm not sure where else I should be smoothing out the angles of my level geometry. Most notably I have a larger room where the main center piece is a large octagonal tower made of brick and I'm unsure if players will find its sharp angles unappealing to look at despite its ornamentation. Try as I might to smooth out those corners, an octagon is still an octagon.

Snatcher, so is this part of your modpack already or will it be integrated when most items have been named?

that´s why i will give you a patchnotes for version 0.0.7.5 (and in a vid you showed so) Okay - if German was maybe only for settings ?! - then it doesn't matter otherwise? Why eliminated? and a 2GB game with no chance to save - looks ambitious to me Of course - the biggest part will be the engine! - but the game itself ? I'm going to take up the challenge and definitely : I'm going to have a lot of fun ( sure : it's not just "girls that want to have fun" ) CU ! Edit (24.04) Ohhh : I see (no save needed)

He thanks for the nice words! Alot going on! Delightfyl demo 2 should be in german? Well its abondanware now You do not yet save in project SITN. I will do saving last this time, i want to focus on stability and fun first Make sure to join the discord! https://discord.com/invite/2azhNerAgM

The translation pack has the german string in the base pack rather than in the fm subfolder. I will fix it in the mission database. Edit: Fixed in the mission db Edit 2: Nope. Not exactly fixed. It seems that lang files in the mission string folder need to be "complete" because they fully override the core strings. If I am correct, this was broken in 2.11 when we permitted in-file overrides of core files in missions. Edit 3: Still broken in 2.10, rolling back to 2.07 Edit 4: Still broken in 2.07. Something has gotta be wrong with the translation specific to this mission. Edit 5: The core mission XD files don't use the strings so nothing happens if the lang files are in the strings/fm subfolder. Probably means that the translation packs "never worked" for many missions unless impacted players sought out special editions of the missions on Tels' server. What a mess. Fuzzy recollection time: I think Tels was trying to push the team to mass convert all missions to move XD data into strings/fm/english.lang but nobody wanted to broach it and even mission authors weren't happy about this way of handling things. If the translation pack takes precedence, the best way forward is to include the converted XD file into it. Testing... Edit 6: Couldn't get the XD update to work, so I decided to checkout Darkfate's version. It works flawlessly. I copied their pack into the standard translation pack and the added string files for the other languages worked as well. Darkfate's packs include map files so I'll need to study whether we can avoid that. Otherwise we are basically doubling our mission db or "damaging" our hosted versions to make them translatable. Since this mission is so small and probably will never be edited again we can probably use darkfate's version as-is.

I guess I could try to make it run on this: https://www.notebookcheck.nl/Fujitsu-Siemens-Lifebook-P1620.8269.0.html Not sure if an Intel GMA 950 will be enough..

Well if you go to the mission downloader again, it will show a new update for the mission, which is the translation pack. If I select Germain language and activate The Outpost, TDM will not start anymore (2.13 dev)