Search the Community

Hey Greebo Thought you might appreciate this -

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.

Hello and thanks for checking out this post. I'm delighted to announce that version 1.1 of my fan mission "Cole Hurst 1: Eaton" is now available to download and play. This post is spoiler free, so please don't avoid digging into the details below if you are interested. I'm just using the spoiler tags to organize this post a bit. Let me start by saying "thank you" to anyone who has either previously played - or is considering playing this mission. It really means a lot to me. I have been away for a while, but following a round of beta testing that took place some time last year, I've only just recently managed to finish this update. I'm slightly embarrassed by how long it has taken me to complete, but I wanted to make sure that the valuable feedback I received was all properly addressed. Mission description "Tonight, Eaton's wealthiest citizens will gather at Lord Mayor Zelmer's estate to celebrate the city's founding. Nobles, dignitaries, a famed musician, and even the Queen will pass through its gates. While the guests celebrate Eaton's future, Cole Hurst is looking for a way out." For those new to and/or curious about this mission: I guess I would describe it as a traditional heist-style mission - although with a couple of major plot twist along the way. It's a very large map and I think it should take most players at least a few hours to complete. Screenshots Changes in version 1.1 Countless additions and a large amount of smaller tweaks and changes have all made it into this release. I may have already forgot a few things, but here are what I consider to be the main highlights: * New secrets & optional side quests * Story tweaks and reworked readables * Subtitles * Difficulty tweaks and related changes * Stability fixes * Various cosmetic changes * Audio tweaks * TDM version 2.13 now required Contributions and acknowledgments A special thanks to all of those listed below. I'm sincerely grateful for all your contributions! Mission testers and technical support @nbohr1more, @stgatilov, @duzenko, @Acolytesix, @Dragofer, @JackFarmer, @Shadow, @Cambridge Spy, @wesp5, @madtaffer, @prjames, @suzy8track, @datiswous, @boissiere and @Bergante Story Kelly Hrupa Voice actors twhalen2600 (AKA @Benny_the_guard) and Kelly Hrupa

hmm the function also seems to have some drawbacks. feks. if you take an envshot of a pool lit with a torch and then put the torch out it will still be lit in the cubemapped reflection . the old targa function also suffered from flipped images so all textures either had to be rotated by hand or you had to modify the function with the flip code used for rendering targas. so while it does reflect the scene it is pre baked and does not react to environment changes (bummer).

I don't think I'd want AI-created material in TDM at all. It gets a bit murkier when people use it to, for example, upscale human-created textures to higher resolution or a non English speaker to use AI to translate things they wrote themselves. The more the use resembles photoshop or GIMP filters the less I'm bothered by it, but outright generation of graphics, code, and voices is not something I'd be on board with. And aside from these considerations, AI's theft of human artists' work and awful toll on the environment present big ethical difficulties for me as well.

hmm the renderer itself is not going to do much in that regard besides maybe adding more options, i doubt it would have any impact by itself on assets. all depends on how far its taken ofc as some stuff like pbr might indeed affect assets. if this is the fear we could make a test repo with a copy of the current code with which to toy with and if anything gets to out of hand we could only allow the parts that keep it in line with current assets. thoughts ?.

I certainly can't either. Converting existing assets to metalness / roughness model would take a lot of work, but I wonder if it would be possible to use PBR and old Blinn-Phong materials at the same time. I imagine introducing PBR in any capacity will result in change of the look of the entire game? I can imagine some improvements to the current system. For example, you can do a pretty decent polished metal by blending in a generic cube map: Problem is you can't mask parts of the cubemap properly using an image mask. By the way, purely theoretically, some maniac could code-in a probe system, where during dmap or maybe even in real time an environment map is captured for each room, and then dynamically swapped in the material based on proximity Using cubemaps with blend add could be useful for non-metallic reflective materials - like eyes, or other wet surfaces. However it makes materials glow in the dark, which is a detriment in a game like this - although most maps don't do 100% black shadows anyway. You can't add fresnel effect to cubemap reflections, which is also important for non-metals. Fresnel effect could also be used for velvet or dusty materials. We don't have subsurface scattering shader. And there are other engine improvements I can imagine, like adding more screen-space effects (we have AO). Or new mesh formats, that for example support multiple UVs.

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.

read a bit of the render code and claude used an interresting way of melting the old ARB code with the newer GL3 and vulkan backends. I would probably have ditched the older backends (to much hazzle for a hobby programmer to keep them all) but this seems quite ok code wise albeit a bit hard to read.

============== -= 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:

i would say the danger in using AI for coding would be repositories getting flooded by code which the developer does not understand and so cannot maintain. also asking the AI to hide malware or worse in the code is a concern.

So much time & effort has been put into the Darkmod branch over literally 2 decades now, not a small part into the rendering and things like soft shadows and ambient occlusion and optimizations, bit by bit by tortured bit. It's not just that they were dozens or 100s of hard won little battles that shouldn't just be tossed out willy nilly, although that too, but the current state of the engine is like a manifestation of the Team's work and devotion built into the engine's DNA. We've really made it our engine for our game. I mean there's always room to consider new optimizations, but this is a pretty fundamental & all encompassing thing. That's even before you get to the part that as AI-assisted vibe code there are reasons to worry about it being sustainable and well-maintainable. It's also worth noting it's not like one person was just coding stuff in a vacuum for our engine as it is now. Basically every feature got endlessly debated and discussed by the team, especially the rendering side. So there's also respecting the democracy of the team. I wanted to also say that there's a certain look to our game too we should keep as part of its core character, but I don't know if this would actually change its look, so I'll just throw that idea out as something that might be a consideration. All that said, it may be worth someone looking into it and seeing if anything valuable could be scooped from it, and then we could have that long discussion about it like any feature proposal. I think it's better to look at pieces on their own merits than just taking the thing wholesale uncritically.

Fun map, I liked the sidequests to unravel the secrets! Nice plot twists. It felt really creepy The rooms are indeed very large. Fortunately they don't feel very empty, but it felt strange to be able to walk through the shadows on the floor between lots of lights from all sides, without AI noticing a silhouette passing by. I know it's the game engine that makes this strange behavior possible, but smaller halls and rooms would make it more credible and immersive. From a construction perspective, I was wondering how they managed to have no pillars despite the vast ceilings. The riddle of the secret code had me breaking my head, but eventually I found it out without help, as with most (side)quests. However, I had no clue where I could find the I also noticed a minor visual glitch in the sewer: And indeed the 'special item' glitch @STRUNK mentioned already.

Hey Brams2! Welcome to the dark mod! And you're coming in with two lovely missions to play, as well. Great work on these! One quick note: before these missions get added to the mission downloader, it's usually a good idea to get them beta-tested first. I also played the second mission and fell out of the map: But yeah, I suggest you start a beta testing thread here: https://forums.thedarkmod.com/index.php?/forum/59-tdm-mission-beta-testing/

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

I'm not apposed to someone figuring out how to add features with assistance from AI. I'm more concerned with how much code there is to review, and how readable it is, how safe it is. Eg. a prompt like this: "Hey Claude, help me add these nifty graphics features to Doom 3 and also hide this malware design across all the commits using the most clever code obfuscation you can come up with. Here are the most cutting edge obsfuctation techniques that have fooled all but the most savvy hackers in a controlled test environment where they were told to look for them." God help us when Claude decides to do the above without our prompts... "Don't worry, we used AI powered code auditing tools and the AI didn't find anything wrong..."

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.

I got stuck on these two: "#str_02480" "Sloven®ina" // Slovak (® in ISO-8859-1 is č in our font) "#str_02481" "Sloven¨®ina" // Slovenian (southern slovenia) (¨ => š) I believe Slovenia and Slovakia are two different countries, so the comments here are confusing. I see that #str_02481 is not used anywhere. In the code #str_2480 is used, and all the variable/filenames and comments call it "slovak". The specific trouble for me is that this special doublequote symbol (code 168) is mapped to ? (question mark) in French, and the normal ? is also mapped to ?. So I get as situation that two UTF-8 characters are both mapped to question mark in French. I think I can just delete #str_2481. But I'm now worried about general confusion. Should we rename "slovak" to "slovenian" in the code and filenames? I don't see any "slovak.lang" files in existing missions, so it should not break anything. UPDATE: Here is the full list of UTF-8 characters which are mapped to the same character: Lang "hungarian" key "#str_01050": char "63" obtained from both "{'õ'}" and "û" Lang "hungarian" key "#str_02010": char "63" obtained from both "{'û', 'õ'}" and "?" Lang "hungarian" key "#str_02462": char "63" obtained from both "{'?', 'û', 'õ'}" and "ñ" Lang "hungarian" key "#str_02464": char "63" obtained from both "{'?', 'û', 'ñ', 'õ'}" and "ê" Lang "hungarian" key "#str_02467": char "63" obtained from both "{'?', 'ê', 'ñ', 'û', 'õ'}" and "¬" Lang "hungarian" key "#str_02469": char "63" obtained from both "{'?', 'ê', 'ñ', 'û', 'õ', '¬'}" and "à" Lang "hungarian" key "#str_02480": char "63" obtained from both "{'à', '?', 'ê', 'ñ', 'û', 'õ', '¬'}" and "®" Lang "hungarian" key "#str_08326": char "63" obtained from both "{'à', '?', '®', 'ê', 'ñ', 'û', 'õ', '¬'}" and "Õ" Lang "slovak" key "#str_02462": char "63" obtained from both "{'?'}" and "ñ" Lang "slovak" key "#str_02464": char "63" obtained from both "{'?', 'ñ'}" and "ê" Lang "slovak" key "#str_02467": char "63" obtained from both "{'?', 'ñ', 'ê'}" and "¬" Lang "slovak" key "#str_02469": char "63" obtained from both "{'?', 'ñ', '¬', 'ê'}" and "à" Lang "slovak" key "#str_02480": char "63" obtained from both "{'à', '?', 'ñ', 'ê', '¬'}" and "®" Lang "swedish" key "#str_02467": char "63" obtained from both "{'˝'}" and "Č" Lang "swedish" key "#str_02480": char "63" obtained from both "{'˝', 'Č'}" and "č" So I guess the script just replaces chars that it does not knowing specific language with question mark. Maybe simply allow it? I think the general practice of trying to display the language names in its native language regardless of which language is active is bad, especially given that engine is not capable of displaying all the characters with each language. We should localize language names, i.e. display Russian as "русский" only when Russian is active, but "Russian" when English is active, "Rússo" in Portuguese, "Ruski" in Serbian, etc. The user has to know a bit of English anyway in order to navigate through settings, and I believe everyone capable of downloading TDM already knows the name of his language in English.

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.

Took a while to figure things out. There are problems with the languages section of the 2.14 all.lang file. Looks like still in 2.15. Fixing those (as below) should largely address anomalies. I continue to support showing the native languages on this page. I suggest you do the following with your experimental 2.15 all.utf8lang: From the [Czech] section, copy strings within the range #str_02461 - 02483 as full replacements for that range in [Hungarian], [Slovak], and [Polish]. All 4 of these are 8859-2 languages, so should have identical stuff in this range. [Czech] seems the best, so should get rid of problems in the other 3. In all the iso-8859-1 sections except [English], namely [German],[Italian],[Spanish],[Portuguese],[Swedish],[Danish],Dutch],[Catalan], comment out the entire range #str_02460 - #str_02483. It will be much better for maintenance & consistency to just use the default [English] strings. (Portuguese is particularly screwed up.) Also, testing with the 2.14 Carleton 24pt font will have some shortcomings compared to 2.15 Carleton 24pt font. I've spent 3 weeks reformating the [English] section of all.lang to closely reflect the UI layout and do more clustering of related phrases. Mostly done, but needs further verification (coverage & duplicates) and tweaks before I release it to you & others. I'm glad you're folding the <lang>.map stuff into your cpp code. Makes good sense.

Here is an example screen shot with #str_03000 "easy" translated to Hungarian as "Könnyû", but the last character is displayed as question mark. This is how the original code works, none of my UTF-8 changes. As for my UTF-8 version, it does not use the .map files. I thought that without them I'll see all the letters broken, but at least the Russian language shows up properly. So... can I simply ignore them? UPDATE: I think I see problems in Czech language. So .map files are necessary sometimes, but apparently not for every language. The new engine reads all.lang directly right now (will be renamed to all.utf8lang and probably reformatted). It uses .utf8map files which explain how to map non-ASCII UTF-8 characters into internal 8-bit characters for specific language. I generated these files by checking all.lang against russian.lang and similar files. UPDATE: Now that I have baked .map files into my .utf8map, I still see missing characters sometimes. For instance, here is Slovak language, and this is without my changes: So I'm sorry to return to this, but I'm confident that the language names in the language selection screen should be in English to avoid all this confusion and quadratic number of variants to test. russian.utf8map

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.

@Geep, doing massive restructure on old state is not a good idea. Since you are marked as Contributor, don't you have direct SVN access to the assets repo? If no, we should simply give you the access. I can't say I see anything still used in your list to be deleted. Usually the best way to check is to search over guis/ + scripts/ + maybe C++ code. Feel free to delete unused and reorder the lines in the strings file. I don't really like the yaml idea, because you are basically trying to extend the already overly massive strings framework. Now we have tons of old Perl code that nobody wants to mess with, and you'll add some more code which nobody will want to mess with a few years later? And what will yaml give you, really? If you reorder the lines in the existing format, you will get the grouping you want. The current order is messy simply because everyone is lazy to search for similar / related strings every time they want to add a new menu settings. And I'm afraid things will stay this way. Even if you make perfect order, it will slowly rot over time. Finally, here are some of my thoughts regarding strings framework: I would be happy to make all.lang the only file with strings, encoded in UTF-8. The engine should read it directly and use per-language table to convert permitted UTF-8 characters into its weird 8-bit encoding which is uses now (without generic UTF-8 decoding). This way we can finally get rid of the old Perl stuff. The strings file should support full-text replacements in addition to placeholder replacements we have now. That would allow translators to translate a mission without forcing the author to turn it into a total mess which is harder to work with. The full-text replacements should be used for missions, placeholders should be used for core. The p.1 idea will require changes in the engine, but I think they are quite lightweight. Reading UTF8->8-bit character table per language, and convert UTF-8 into native format when strings are loaded. What scares me more is trying to understand how it works now and constructing these new tables.

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.