Search the Community

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? 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. russian.utf8map

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.

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..."

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.

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.

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 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.

Is this implying I am discouraging you in some way? This isn’t your project, so I am not sure why you would feel any attachment to it, but I am sorry if that is how it came off. It isn’t even the first source port with any of these individual features. Claude can’t actually make anything, so it get’s all this stuff from somewhere. You can say that combining them is novel in someway, but it is inherently not “new” as you graphic would position it. I also don’t even have a problem with people using an LLM to help them solve real problems. But you can just look at this guys commit logs and profile and just tell he’s an “idea guy” letting the computer do his homework for him. Specifically like over 90% are done with Claude, as well as all his planning docs are written with it. Ideas Guys are quite abundant. Compute power is not. Recycling the effort of real programmers over and over again is a waste of compute resources imo, and it ultimately devalues the result, as almost no one if going to sift through the code and chances are high the person who prompted it doesn’t understand it. But anyway I did not intend to make you feel bad for posting it either way. Thanks for bringing it up.

I think that maybe it is legit to use an AI as tool for some subroutines in a bigger project, but not to use it of the whole project with an simple prompt, because even if it works, nobody later knows how, which make it very difficult, even impossible to guarantee a maintance and needed updates, apart of data security, when the own dev don't really know the code made by an AI.

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.

@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 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.

Yes. In my code (gen_lang_plus/UTF8_8859_Convert.cpp) I have screening routines that convert ALL possible UTF8 codes that are not in the target Latin-x to "?". This is defensive programming in case the translator is less aware of restrictions. Let me look into that Slovak/Slovenia a bit.

Speaking of gen_lang_plus, I just recycled some its code to make a visualization tool "pivot_all_lang" for me to see all the translations of a given string together. Basically, it pivots data like... [English] "#str_02001" "Warning" "#str_02000" "Error" // comment with english "#str_02002" "Connection Error." [French] "#str_02001" "Warning French" "#str_02000" "Error French" // comment with french "#str_02002" "Connection Error French." into this form... "#str_02000_english" "Error" // comment with english "#str_02000_french" "Error French" // comment with french "#str_02001_english" "Warning" "#str_02001_french" "Warning French" "#str_02002_english" "Connection Error." "#str_02002_french" "Connection Error French." I've fed this with all.lang of 2.14, and here is the resulting "all_lang_pivot.txt" (about 800 KB). There are some added flags, which you can read about in the file preamble. Eventually I'll post the code + wiki description. For now, the output file: https://drive.google.com/file/d/1BDz-DWe62NTGMA0dxdngnepagi3dwTNQ/view?usp=sharing

@stgatilov, I was NOT proposing renaming all the numbered strings to alphanumeric (even though that would likely slow down the ordering rot you mentioned.) I was just responding to @wesp5 hearing that someone was already planning on doing so, which surprised me. Yes, I do have access to the SVN repo, thanks. I just try to avoid it as much as possible. For the current work, I'm using 2.14 as the stable base line (for .cpp code, all.lang, *.gui*, etc.) , because things are complicated enough as is. The yaml is just an organizing tool that "might" be helpful for my AI translation efforts, because it can formally encode relationships between strings. Not sure about usefulness yet. I'm not proposing that the TDM engine should read it. I could reorganize at least parts of all.lang similarly, if everyone's OK with moving further away from alphanumeric ordering of #str_ids. The two ideas for improving strings I'm also on-board with. Particularly for #1, which I've also floated as a trial balloon in the past. BTW, for that, my gen_lang_plus has related C++ code that might be of some interest (albeit doesn't use the idTech4 class structure and is Windows-based). For #2, I can see some disambiguation problems, but nothing insurmountable. Given that DR will never properly support #str_ids, seems reasonable. What time frame are you thinking about for these?

Hmm, sounds optimistic. The UTF8 to Latin-x conversions may take some time. My code uses some Windows-specific techniques, which probably need something different for your purposes.

Yes, instead of starting with the English text in the prompt, it is better to point it to a file instead, when the amount of text is voluminous (as it will be in my upcoming Group 3 work in https://forums.thedarkmod.com/index.php?/topic/23204-proposed-i18n-improvements-for-tdm-215/ ). Good to know Google Translate supports URL file access. So does ChatGPT (even the basic version without login).

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.

i think i stumbled upon a long standing bug with nblood and demo desyncing and a possible fix. while mucking about with my hd pack for blood i noticed a bug report about nblood having problems with case sensitivity. i had noticed that some of the demos were desyncing so i tried lowercasing the game files with bulkrenamer and lo and behold the demos that desynced previosly now worked. sadly the problem just jumped the queue and now plagues another demo . this also affects mods which have to be in lower case format or things break. so i guess ill have to look at the source code of nblood and find out where this case handling problem is comming from (probably file system related). if anyone wants to try out the HD pack for nblood ill upload it, it is not done yet but in a workable state (demo desyncs not withstanding).

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

some older engines are just not a good fit for raytracing i reckon. even in quake we struggled with just doing old style real time ligting due to the massive ammounts of indirect lights tanking performance, it also looked dreadfull. darkplaces hacked around this by providing code and a set of scripts to place static light sources (rtlight files) and turned off the old ligting code when rtlight was enabled. this helped immensly as you can guess. if you want to know just how fugly it was just try enabling real time lighting without rtlight scripts and see what i mean. it can still calculate realtime lighting without the scripts (the old ligthing code is only disabled if it picks up rtlight scripts for the map) but due to the massive ammount of them it becomes a slideshow and looks like crap.

redhat is one of the oldest players in the linux world which is why i guess most proliferate them. redhat is also the developer who took over cygwin from cygnus solutions and further promoted it as a way to build linux software for use on windows and spawned multiple subprojects like msys and rtems who were used as frontends for building pure windows and other OS based binaries using native compilers (mingw gcc for msys and a mix of both msvc and gcc with rtems). cygwin itself relies on the cygwin dll as a dependency for running linux applications on windows by creating a minimal shim based on a subset of the linux runtime environment via newlib. unfortunatly while it works it is also rather slow because of the emulation so some people created a neutered version of cygwin as a frontend for driving the mingw compiler (msys or minimal system). this allowed users to build software from the linux world as native windows binaries but it did take quite a lot of patching because some of the software relied heavily on the linux api so these parts had to be rewritten to work with the windows api. Rtems was used heavily by the firefox team before they changed the engine. Mostly because of hurdles with gcc's windows incompatible exception models (dwarf and sjlj) C code was still handled by gcc but for C++ they used msvc so that exceptions were still compatible. in the end developers started doing most of the gruntwork to make things work on both but it took close to 30 years before we got that far. the original msys is now dead and replaced with msys2 which collaborates tightly with the cygwin developers and is much closer to the original cygwin code than msys was, in fact you only need to set a few environment varables to turn msys2 into cygwin. it has even been discussed to add X11 like cygwin does but as a real windows based desktop system for applications that only have gui's compatible with the X system like many of the gnome gtk packages. The old msys can still be downloaded and used with both 32 and 64 bit mingw, but it a bit buggy and uses a very old package manager that is incompatible with 64 bit mingw. Might be possible with a lot of work to port the msys2 pacman to it if anyone wanted to. The biggest problem is the instability of the old versions fork implementations and the fact that old msys is 32 bit so it has problems with large memory footprints.

There's now an editable fan mission list on the wiki, for the sake of tracking missions made for The Dark Mod. Please read and follow the guidelines, and help keep the list up to date! Direct link, but also accessible from the wiki title page: http://wiki.thedarkmod.com/index.php?title=Fan_Missions_for_The_Dark_Mod Discussion of changes (format, policies, entries, etc.) can take place in this thread. --------------------------------------- There is also now a wiki page to track upcoming fan missions: http://wiki.thedarkmod.com/index.php?title=Upcoming_Fan_Missions Submissions, progress, and any discussion for missions under construction can take place here: http://forums.thedarkmod.com/topic/11639-upcoming-fan-missions/