Jump to content
The Dark Mod Forums

Search the Community

Showing results for tags 'patch'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • General Discussion
    • News & Announcements
    • The Dark Mod
    • Fan Missions
    • Off-Topic
  • Feedback and Support
    • TDM Tech Support
    • DarkRadiant Feedback and Development
    • I want to Help
  • Editing and Design
    • TDM Editors Guild
    • Art Assets
    • Music & SFX

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start





Website URL







Found 7 results

  1. Hello, I'm not familiar with darkmod, but using darkradiant has been a blessing for me. I have a problem with texturing inverted endcaps, I can't seem to normalise the UV on the patch. I try everything in surface inspector but I keep ending up with "overstretched" texture. What am I missing?
  2. http://www.computerweekly.com/news/450418770/Businesses-urged-to-apply-Windows-patch-to-avert-WannaCry-attacks OK this is aimed at businesses but I doubt wannacry cares who owns the system it encrypts If you are at all concerned the tl;dr is you need the MS17-010 patch on your system, if you use windows update you should get it automatically, not everyone keeps their systems up to date though You can check the details on the Microsoft site here https://technet.microsoft.com/en-us/library/security/ms17-010.aspx
  3. Hate to beat a dead horse and all that jazz, but for some reason the letters are screwed again. Is it possible if in one of the updates something got changed? The last working thing is supposed to be here with "tdm_base01.pk4" https://drive.google...iew?usp=sharing Maybe something got messed up in 2.04 or 2.05? Or in the recent hotfixes? This tdm_base01.pk4 has the only working romanian character set that exists. What we have now messes up again ș, ț, ă. The updater downloads the wrong version of tdm_base01.pk4. Bug tracker listing: http://bugs.thedarkmod.com/view.php?id=4523
  4. It occurred to me that I should submit this patch now, especially since I see evidence of others (like 'Crinkelite') compiling TDM under Linux. Based on replies to my post in my other recent thread, I realize that it has no chance for 2.05 inclusion, but I want others to have access to it now, so I'm asking that it be added to latest SVN, please. Problem/Fix Description: There is some sort of anomaly with the SCons build system (which is used only for Linux builds, not Windows builds) whereby all items get needlessly rebuilt, every time, when doing TDM builds. In fact, this was encountered by 'NagaHuntress' back in this Aug 2015 post. But, for this and various other reasons while investigating a 64-bit Linux build, she chose to completely switch from SCons to CMake, conveniently side-stepping the problem. The issue fixed by my patch has to do with the SCons (MD5) 'signature' file, which is used to decide when input files used in the build have changed. It's not 100% clear what the cause is, but it may be due to the use of the 'VariantDir()' directives in the 'SConstruct' file. Regardless of the reason, credit for the solution comes from Victor Gaydov's webpage: Both Doom3 and, therefore, TDM use a method of specifying the SCons signature file which causes this serious problem. The solution is quite simple, just as Victor stated: specify the signature file using a full path. The attached patch provides this improvement. It was tested under 32-bit Slackware 13.1 running SCons version 2.5.1 and under 32-bit Slackware 14.2 running SCons version 2.4.1, both against latest SVN (6720) and against the TDM 2.04 release. The fix means that now when you're building TDM under Linux, SCons won't (annoyingly!) rebuild the whole tree every time. This change also nicely allows the removal of a hack in the Linux build script file which was used to force the existence of a SCons signature file. Prior to this patch, if SCons was run without a signature file of the expected name already existing, it would report a long error message that began with this: OSError: [Errno 2] No such file or directory: 'scons.signatures.dblite':And, worse, it would fail to create the proper signature file ('scons.signatures.dblite'), instead creating an unwanted 'scons.signatures.tmp' file, and thereby causing ongoing grief with every successive run of SCons. This simple patch fixes both problems while also removing the inelegant work-around in the Linux build script file. Please apply to latest SVN. prevent-scons-from-rebuilding-everything-every-time.patch.txt
  5. Hi there, I'm new to this forum so I take the occasion to say hello to everyone. This morning I've tried to download the Doom 3 patch v1.3.1 but the link didn't take me anywhere. Is there someone who can help me out? Thanks
  6. Hi, I've made a patch for 0003304: "add scripting events to get mission statistics". http://bugs.thedarkm...iew.php?id=3304 The kind of events needed is something that maybe needs discussing, so consider this patch a proposal. Some things to consider: I've added those events to the "sys" entity. But maybe they should be on player or other entity? I've added events for all statistics used in UpdateStatisticsGUI(). But maybe there should be more flexible events, like getMissionStatistic(COMP_ALERT, BY_TEAM, 1, EAgitatedSearching)? Are the names of the events ok? getStatGamePlayTime() returns time in seconds, while getStatTotalTimePlayerSeen() in milliseconds. Normalize? Here is the list of script events I've added (getDifficultyLevel() should be there already): // Scripting events to get mission statistics, #3304 scriptEvent float getDifficultyLevel(); scriptEvent string getDifficultyName(float difficultyLevel); scriptEvent float getStatGamePlayTime(); scriptEvent float getStatDamageDealt(); scriptEvent float getStatDamageReceived(); scriptEvent float getStatHealthReceived(); scriptEvent float getStatPocketsPicked(); scriptEvent float getStatFoundLoot(); scriptEvent float getStatMissionLoot(); scriptEvent float getStatTotalTimePlayerSeen(); scriptEvent float getStatNumberTimesPlayerSeen(); scriptEvent float getStatNumberTimesAISuspicious(); scriptEvent float getStatNumberTimesAISearched(); scriptEvent float getStatSightingScore(); scriptEvent float getStatStealthScore(); scriptEvent float getStatKilledByPlayer(); scriptEvent float getStatKnockedOutByPlayer(); scriptEvent float getStatBodiesFound(); (Those lines are not included in the patch as I don't have access to current data files.) Changes: Fixed bug in checking bounds for AIAlerts in CMissionData::GetStat*() methods. Sorted methods in MissionData.h to group stat functions together. Added accessor functions to all values that are used in UpdateStatisticsGUI() - so that this function and script events use consistent interface. Added mission stats events to "sys" entity. Added event descriptions to tdm_events.script (not included in patch). Changed MAX_AICOMP in MissionStatistics.h to be equal to COMP_COUNT. Added include "../AI/Memory.h" in MissionStatistics.h to use EAlertState enum in MAX_ALERTLEVELS and CMissionData. Changed hard coded values to EAlertState enum values in MissionData.cpp. While testing those events I've found some issues: 1. A bug that causes pickpocketting to be counted twice. InventoryCallback() is called twice: Code in CInventory::PutItem(idEntity * ent, idEntity * owner) PutItem(item, category); // <-- InventoryCallback() is already called here! // We added a new inventory item gameLocal.m_MissionData->InventoryCallback(...); // <-- second call - double COMP_PICKPOCKET counting! 2. A bug that causes enemies killed by player to not be counted as player's kills. In idPhysics_AF::Rest() there's a line: // grayman #3075 - set m_MovedByActor to NULL here self->m_MovedByActor = NULL; This causes bodies killed by the player to not count as player's kills as soon as their bodies come to rest! I understand this code is needed for props, but should be disabled for dead bodies. I couldn't find those in the bugtracker. If they are not known I can create issues for them. MissionStats.patch.txt
  7. This is a bug that occurs on current (29 Jan 2013, rev. 5694) SVN code. Proposed solutions are in this post. It's probably related to: 0002811: Font loading does not fall back to English http://bugs.angua.at/view.php?id=2811 Reproduction: After changing language to polish and restarting TDM, the following happens: SetupFonts() in idDeviceContext::Init() can't find fonts for polish language. It does not fall back to loading english fonts. Lack of ANY fonts loaded causes a crash while loading GUI (in idDeviceContext::SetFontByScale() exactly). I've attached the stack trace. I have three solutions for this problem: 1. I've attaches a patch (I18N.cpp.patch.txt). However: - it uses a hard coded value "fonts/english", - it requires #str_04127 to be translated properly for all languages with their own fonts - this is actually an advantage, IMHO. 2. I've also attached an alternative patch (DeviceContext.cpp.patch.txt) that solves this problem. It also uses a hard coded value "fonts/english", and is not as good as the first one. 3. Third solution is to require for translation of #str_04127 to be present in all languages that do not have their own fonts. Translations such as Polish have to be fixed. I actually think that the first solution is the best one, because it's the most bullet-proof (no risk of crashes, ever). (I wanted to edit the original issue, but I don't have permission.) stacktrace.txt DeviceContext.cpp.patch.txt I18N.cpp.patch.txt
  • Create New...