Search the Community

Here's my first FM. A small and easy mission, inspired by Thief's Den and The Bakery Job, where you must find and steal a cook's recipe book in order to save a friend from going out of business. Download: Mediafire (sk_cooks.pk4) TDM Website's Mission Page The in-game mission downloader Thanks to: The people who helped me get this far, both in the forums and on Discord. The beta testers: MirceaKitsune, Mat99, Baal, wesp5, Cambridge Spy, jaxa, grodenglaive, Acolytesix ( Per the author in the beta testing thread. ) Skaruts has given permission to the TDM Team to add Subtitles or Localization Strings to this mission. (No EFX Reverb.) If anyone from the Community or TDM team wishes to create these we will gladly test them and update the mission database.

I havent tried in 2.11 yet but I will. Just an update on this. For now I think I fixed it by: - Addressing most of the warning in the log above. Outside common errors like some missing textures and such that are part of the core. - Made sure to give my parallel lights "parallelSky " "1" spawnarg. - Deleted my .aas files and rebuilt them - Dmapped the entire thing Right now I am not getting the load error . It's a very hard problem to nail down because the console isn't giving a specific script name that it's getting hung up on (if that is even the issue similar to Amadeus's problem) AND I am actively working on the mission, creating new errors, fixing other broken things. ect. Its definitely something I fear will pop back up in beta testing though

When I was a teen I used to play a game called Hitman: It was also a 3rd person stealth game focused on assassinations and disguises. Its main gimmick was the player stealing an enemy's clothing and dressing up as them to infiltrate, while disguised you avoid acting suspicious or your enemies would realize you're not one of them and your cover is blown. I've thought about attempting something similar in TDM in the past. Since it's impossible to customize the player model 1st person hands, I realized custom outfits are out of the question. Then it dawned on me that I could go for a simplified version, by implying the player only wears a helmet or large hat to disguise theirself, enough so it makes sense and throws the AI off. So I got to work and after 3 days of tweaking I'm ready to share my latest mod: Working disguises How it works: The player can pick up headwear and equip by using the item, making you a member of the target team when active. While worn a bar appears at the top of the screen indicating the status of your disguise: This bar slowly fills up over time... it will drain when a member or ally of the team you're disguised as sees you the closer you get, further draining if the AI is alert. When the strength reaches 0 the disguise deactivates, you must wait for it to reach 1 again for it to be active again. When the disguise is inactive the bar will be gray and the icon black, when active it's colored and the full icon shown to make that clear. By default only helmets for the Citywatch were included thus far, with the normal Citywatch helmet offering less cover whereas the Elite Citywatch disguise gives you a greater distance and time at the expense of a cumbersome overlay. It even changes the player's person type / gender / rank so AI salute you as one of them... unfortunately this doesn't seem to have an effect in practice, maybe it can be investigated why. Further more the item sets a custom head model and skin, so when the player sees theirself in a mirror the hat accurately reflects the associated head... sadly this functionality had to be disabled due to a crash that occurs if you try to modify the model of the player's head causing a -1 model index, I filed a bug report about it and hopefully it can be resolved soon. If enough people like this to motivate me to continue, my plan for the next release is to allow stealing the helmets off guards. This might be tricky as I need to make the head frobable and have it execute my script action, which must change the model of the AI's head to their non-helmet version: Unless the same crash as the player head risks occurring, this should be doable in theory... this would also allow it to be used as an universal mod (with any FM) as you no longer rely on the items being placed by the mapper. Below is the latest version: If you're a mapper maybe add this to your FM and let me know what you think! I'm eager to hear your thoughts and see a field use case, this was only tested in a simple box map not in a practical scenario. As usual copy everything in your FM except tdm_custom_scripts.script you'll need to mix the include line with your existing one. disguises_1.0.pk4

Hello! I am going through the (painful) process of detaching some custom stuff I've made over the years from the base mod so I am not replacing so many tdm_ core files in my FMs. I'll be posting updates in here as I know a few people have used custom volta stuff in their missions. @Goldwell @Amadeus @Wellingtoncrab If you are using CUSTOM VOLTA arrows please replace this file: tdm_weapon_arrow.script - Ive updated this script with core mod changes - The only thing that's being replaced is: ARROW_ZOOMDELAY 3 // Shortened time from 6 to 3 seconds If you want to use the default 6 second zoom delay, just delete this file and remove it from your custom_scripts.script. If anyone knows a way I can change ARROW_ZOOMDELAY without overriding the entire file, please let me know asap. Thanks everyone

@Petike the Taffer Well that was challenging, but I managed to get it to work with a dummy AI (but with a warning message). Using hide doesn't work on the dummy, as each time it moves it un-hides. You need to use an invisible model. I used the atdm:ai_base, which surprisingly worked with these spawn args so it doesn't interfere with the player position and is inert as possible. Then you just need to trigger a follow script, e.g.: void follow_dummy() { $dummy.setOrigin($player1.getOrigin()); $dummy.hide(); //not sure why this is needed, but it stopped working when I deleted it sys.wait(0.2); //needed to prevent game from hanging thread follow_dummy(); } Alternatively, I tried to just bind the dummy to the player instead, but then the follower ai wouldn't follow me.

Author Note: Shadows of Northdale is a new campaign that takes place in a city called Northdale that is situated up in the mountains of the western empire. Across the campaign the player will traverse through the varying districts of the city with each mission featuring it's own unique location as well as different locations in the city hub to access. ACT I is the first mission which is designed to introduce the player to the city hub area and the new mechanics available to them. During the first night in the city hub section there are a couple of places to explore however this will expand and open up further as you progress through the campaign's missions. This mission features some aspects which are different to the usual dark mod FM experience which are: - Food is an item that is picked up and stored in your inventory, pressing the use key with the food item highlighted will cause the player to eat it and gain 5hp - There is an ingame fence where you can purchase gear using any loot you may have found during the mission, you can visit him as many times as you wish but do be mindful of your loot goals - Also inside the fence's shop are contracts, these are readables which detail tasks that a client wishes you to complete for an agreed sum of gold. Upon completing them you will be rewarded with the designated sum immediately - Because you are not a wanted criminal (yet) the citywatch will only attack you if they catch you breaking the law or find you near the scene of a crime - Candles are pinchable in this mission, frobbing them causes Corbin to pinch them to put them out rather than pick them up The mission was designed and tested on 2.05, if you are playing on any other version there may be bugs present. If you enjoyed the mission please feel free to leave a review, I enjoy reading them and it gives me inspiration for my next projects. Tell me what you felt worked and what you felt could be improved for next time. Have fun taffers! - Goldwell. 2.06 UPDATE INFO: If you are experiencing any path finding issues (AI walking around in circles or getting stuck) on 2.06 then please enter the following console command to resolve these issues cm_backFaceCull 0. Thanks goes to Nbohr1more for solving that! Testers Crowind Epifire Kingsal Random_Taffer Skacky SquadaFroinx Voice Actors AndrosTheOxen Goldwell SlyFoxx Custom assets Andreas Rocha Bentraxx Bob Necro Dragofer Epifire Freesound Kingsal MalachiAD Tannar And a very special thank you to the following people without whom the mission would not exist: Epifire for creating some amazing detailed custom models that help bring a unique layer that wouldn't be possible without it. Seriously go check out his modeling page! Dude is very talented https://sketchfab.com/Epifire Grayman for helping to debug a lot of critical bugs in the mission, without him there wouldnt be a mission Kingsal and Skacky for helping out with excellent tips on level design, flow and lighting Moonbo for lending his writing talents to help optimize the briefing video script Obsttorte for making the majority of the scripts featured in this mission, and for dealing with my constant nagging about issues and bugs, you are awesome! SlyFoxx for lending his vocal talents and making the fence character come to life and sound great SquadaFroinx for providing thorough beta reports (that are equally hilarious as they are useful) And finally a huge thank you to Tannar for drawing the fantastic looking ingame map Available via in-game downloader MIRROR File Size: 295 mb

i use git clone https://github.com/codereader/DarkRadiant.git --recurse-submodules with https instead of git: is that different? since with git: nothing is downloaded at all first conclusion 2 instructions missing in debian10 install libeigen3-dev libgit2-dev second conclusion, some someelse is still missing git clone https://github.com/codereader/DarkRadiant.git --recurse-submodules Cloning into 'DarkRadiant'... remote: Enumerating objects: 162889, done. remote: Counting objects: 100% (33651/33651), done. remote: Compressing objects: 100% (10563/10563), done. remote: Total 162889 (delta 24575), reused 31976 (delta 22932), pack-reused 129238 Receiving objects: 100% (162889/162889), 96.95 MiB | 3.30 MiB/s, done. Resolving deltas: 100% (124371/124371), done. sudo apt-get install git cmake pkg-config gettext zlib1g-dev libjpeg-dev libwxgtk3.0-dev libgtest-dev sudo apt-get install libxml2-dev libsigc++-2.0-dev libpng-dev libftgl-dev libglew-dev libalut-dev libvorbis-dev python3-dev synaptics Installed the following packages: libeigen3-dev (3.3.7-1) libeigen3-doc (3.3.7-1) Installed the following packages: libgit2-27 (0.27.7+dfsg.1-0.2) libgit2-dev (0.27.7+dfsg.1-0.2) libhttp-parser-dev (2.8.1-1+deb10u2) libmbedcrypto3 (2.16.0-1) libmbedtls-dev (2.16.0-1) libmbedtls12 (2.16.0-1) libmbedx509-0 (2.16.0-1) libssh2-1-dev (1.8.0-2.1) cd DarkRadiant ~/DarkRadiant$ cmake . -- The C compiler identification is GNU 8.3.0 -- The CXX compiler identification is GNU 8.3.0 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Found PkgConfig: /usr/bin/pkg-config (found version "0.29") -- Checking for module 'libxml-2.0' -- Found libxml-2.0, version 2.9.4 -- Checking for module 'sigc++-2.0' -- Found sigc++-2.0, version 2.10.1 -- Checking for module 'ftgl' -- Found ftgl, version 2.4.0 -- Checking for module 'freetype2' -- Found freetype2, version 22.1.16 -- Checking for module 'gl' -- Found gl, version 18.3.6 -- Checking for module 'glew' -- Found glew, version 2.1.0 -- Checking for module 'libjpeg' -- Found libjpeg, version 1.5.2 -- Checking for module 'libpng' -- Found libpng, version 1.6.36 -- Checking for module 'openal' -- Found openal, version 1.19.1 -- Checking for module 'ogg' -- Found ogg, version 1.3.2 -- Checking for module 'vorbisfile' -- Found vorbisfile, version 1.3.6 -- Checking for module 'x11' -- Found x11, version 1.6.7 -- Checking for module 'zlib' -- Found zlib, version 1.2.11 -- Checking for module 'glib-2.0' -- Found glib-2.0, version 2.63.5 -- Checking for module 'eigen3' -- Found eigen3, version 3.3.7 -- Found wxWidgets: -L/usr/lib/x86_64-linux-gnu;-pthread;;;-lwx_baseu-3.0;-lwx_gtk2u_core-3.0;-lwx_gtk2u_stc-3.0;-lwx_gtk2u_adv-3.0;-lwx_gtk2u_gl-3.0;-lwx_gtk2u_xrc-3.0;-lwx_gtk2u_aui-3.0 (found version "3.0.4") -- Found Python: /usr/lib/python3.7/config-3.7m-x86_64-linux-gnu/libpython3.7m.so (found version "3.7.3") found components: Development -- Checking for module 'libgit2' -- Found libgit2, version 0.27.7 -- Checking for module 'gtest' -- No package 'gtest' found -- Checking for module 'gtest_main' -- No package 'gtest_main' found -- Configuring done -- Generating done -- Build files have been written to: /home/chris/DarkRadiant NOTE: /usr/include/gtest /usr/include/gtest/gtest-death-test.h /usr/include/gtest/gtest-message.h /usr/include/gtest/gtest-param-test.h /usr/include/gtest/gtest-param-test.h.pump /usr/include/gtest/gtest-printers.h /usr/include/gtest/gtest-spi.h /usr/include/gtest/gtest-test-part.h /usr/include/gtest/gtest-typed-test.h /usr/include/gtest/gtest.h /usr/include/gtest/gtest_pred_impl.h /usr/include/gtest/gtest_prod.h /usr/include/gtest/internal /usr/include/gtest/internal/custom /usr/include/gtest/internal/custom/README.md /usr/include/gtest/internal/custom/gtest-port.h /usr/include/gtest/internal/custom/gtest-printers.h /usr/include/gtest/internal/custom/gtest.h /usr/include/gtest/internal/gtest-death-test-internal.h /usr/include/gtest/internal/gtest-filepath.h /usr/include/gtest/internal/gtest-internal.h /usr/include/gtest/internal/gtest-linked_ptr.h /usr/include/gtest/internal/gtest-param-util-generated.h /usr/include/gtest/internal/gtest-param-util-generated.h.pump /usr/include/gtest/internal/gtest-param-util.h /usr/include/gtest/internal/gtest-port-arch.h /usr/include/gtest/internal/gtest-port.h /usr/include/gtest/internal/gtest-string.h /usr/include/gtest/internal/gtest-tuple.h /usr/include/gtest/internal/gtest-tuple.h.pump /usr/include/gtest/internal/gtest-type-util.h /usr/include/gtest/internal/gtest-type-util.h.pump /usr/lib /usr/lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/libgtest.a /usr/lib/x86_64-linux-gnu/libgtest_main.a /usr/share /usr/share/doc /usr/share/doc/libgtest-dev /usr/share/doc/libgtest-dev/changelog.Debian.gz /usr/share/doc/libgtest-dev/copyright /usr/src /usr/src/gtest ~/DarkRadiant$ make Scanning dependencies of target math [ 0%] Building CXX object libs/math/CMakeFiles/math.dir/AABB.cpp.o [ 0%] Building CXX object libs/math/CMakeFiles/math.dir/Frustum.cpp.o [ 0%] Building CXX object libs/math/CMakeFiles/math.dir/Matrix4.cpp.o [ 0%] Building CXX object libs/math/CMakeFiles/math.dir/Plane3.cpp.o [ 0%] Building CXX object libs/math/CMakeFiles/math.dir/SHA256.cpp.o [ 0%] Linking CXX shared library libmath.so [ 0%] Built target math Scanning dependencies of target xmlutil [ 0%] Building CXX object libs/xmlutil/CMakeFiles/xmlutil.dir/Document.cpp.o [ 0%] Building CXX object libs/xmlutil/CMakeFiles/xmlutil.dir/Node.cpp.o [ 0%] Building CXX object libs/xmlutil/CMakeFiles/xmlutil.dir/XmlModule.cpp.o [ 1%] Linking CXX shared library libxmlutil.so [ 1%] Built target xmlutil Scanning dependencies of target scenegraph [ 1%] Building CXX object libs/scene/CMakeFiles/scenegraph.dir/ChildPrimitives.cpp.o [ 1%] Building CXX object libs/scene/CMakeFiles/scenegraph.dir/InstanceWalkers.cpp.o [ 1%] Building CXX object libs/scene/CMakeFiles/scenegraph.dir/LayerUsageBreakdown.cpp.o [ 1%] Building CXX object libs/scene/CMakeFiles/scenegraph.dir/ModelFinder.cpp.o [ 1%] Building CXX object libs/scene/CMakeFiles/scenegraph.dir/Node.cpp.o [ 1%] Building CXX object libs/scene/CMakeFiles/scenegraph.dir/merge/MergeOperation.cpp.o [ 2%] Building CXX object libs/scene/CMakeFiles/scenegraph.dir/merge/MergeOperationBase.cpp.o [ 2%] Building CXX object libs/scene/CMakeFiles/scenegraph.dir/merge/MergeActionNode.cpp.o [ 2%] Building CXX object libs/scene/CMakeFiles/scenegraph.dir/merge/GraphComparer.cpp.o [ 2%] Building CXX object libs/scene/CMakeFiles/scenegraph.dir/merge/ThreeWayMergeOperation.cpp.o [ 2%] Building CXX object libs/scene/CMakeFiles/scenegraph.dir/SelectableNode.cpp.o [ 2%] Building CXX object libs/scene/CMakeFiles/scenegraph.dir/SelectionIndex.cpp.o [ 2%] Building CXX object libs/scene/CMakeFiles/scenegraph.dir/TraversableNodeSet.cpp.o [ 2%] Building CXX object libs/scene/CMakeFiles/scenegraph.dir/Traverse.cpp.o [ 3%] Linking CXX shared library libscenegraph.so [ 3%] Built target scenegraph Scanning dependencies of target wxutil [ 3%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/ConsoleView.cpp.o [ 3%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/dataview/DeclarationTreeView.cpp.o [ 4%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/dataview/KeyValueTable.cpp.o [ 4%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/dataview/ResourceTreeView.cpp.o [ 4%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/dataview/ResourceTreeViewToolbar.cpp.o [ 4%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/dataview/ThreadedResourceTreePopulator.cpp.o [ 4%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/dataview/TreeModel.cpp.o [ 4%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/dataview/TreeModelFilter.cpp.o [ 4%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/dataview/TreeView.cpp.o [ 5%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/dataview/VFSTreePopulator.cpp.o [ 5%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/decl/DeclarationSelectorDialog.cpp.o [ 5%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/decl/DeclarationSelector.cpp.o [ 5%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/dialog/DialogBase.cpp.o [ 5%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/dialog/Dialog.cpp.o [ 5%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/dialog/MessageBox.cpp.o [ 5%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/fsview/FileSystemView.cpp.o [ 5%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/fsview/Populator.cpp.o [ 6%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/DirChooser.cpp.o [ 6%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/EntityClassChooser.cpp.o [ 6%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/FileChooser.cpp.o [ 6%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/FreezePointer.cpp.o [ 6%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/GLWidget.cpp.o [ 6%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/menu/PopupMenu.cpp.o [ 6%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/menu/FilterPopupMenu.cpp.o [ 7%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/ModalProgressDialog.cpp.o [ 7%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/MouseToolHandler.cpp.o [ 7%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/PanedPosition.cpp.o [ 7%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/PathEntry.cpp.o [ 7%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/preview/GuiRenderer.cpp.o [ 7%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/preview/GuiView.cpp.o [ 7%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/preview/ModelPreview.cpp.o [ 8%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/preview/ParticlePreview.cpp.o [ 8%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/preview/RenderPreview.cpp.o [ 8%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/SerialisableWidgets.cpp.o [ 8%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/sourceview/DeclarationSourceView.cpp.o [ 8%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/sourceview/DefinitionView.cpp.o [ 8%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/sourceview/SourceView.cpp.o [ 8%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/Splitter.cpp.o [ 9%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/WindowPosition.cpp.o [ 9%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/WindowState.cpp.o [ 9%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/window/TransientWindow.cpp.o [ 9%] Linking CXX shared library libwxutil.so [ 9%] Built target wxutil Scanning dependencies of target module [ 9%] Building CXX object libs/module/CMakeFiles/module.dir/ApplicationContextBase.cpp.o [ 10%] Building CXX object libs/module/CMakeFiles/module.dir/CoreModule.cpp.o [ 10%] Building CXX object libs/module/CMakeFiles/module.dir/DynamicLibrary.cpp.o [ 10%] Building CXX object libs/module/CMakeFiles/module.dir/StaticModule.cpp.o [ 10%] Linking CXX static library libmodule.a [ 10%] Built target module Scanning dependencies of target script [ 10%] Building CXX object plugins/script/CMakeFiles/script.dir/interfaces/BrushInterface.cpp.o [ 10%] Building CXX object plugins/script/CMakeFiles/script.dir/interfaces/CameraInterface.cpp.o [ 10%] Building CXX object plugins/script/CMakeFiles/script.dir/interfaces/CommandSystemInterface.cpp.o [ 10%] Building CXX object plugins/script/CMakeFiles/script.dir/interfaces/DeclarationManagerInterface.cpp.o [ 10%] Building CXX object plugins/script/CMakeFiles/script.dir/interfaces/DialogInterface.cpp.o [ 10%] Building CXX object plugins/script/CMakeFiles/script.dir/interfaces/EClassInterface.cpp.o [ 11%] Building CXX object plugins/script/CMakeFiles/script.dir/interfaces/EntityInterface.cpp.o [ 11%] Building CXX object plugins/script/CMakeFiles/script.dir/interfaces/FileSystemInterface.cpp.o [ 11%] Building CXX object plugins/script/CMakeFiles/script.dir/interfaces/FxManagerInterface.cpp.o [ 11%] Building CXX object plugins/script/CMakeFiles/script.dir/interfaces/GameInterface.cpp.o [ 11%] Building CXX object plugins/script/CMakeFiles/script.dir/interfaces/GridInterface.cpp.o [ 11%] Building CXX object plugins/script/CMakeFiles/script.dir/interfaces/LayerInterface.cpp.o [ 11%] Building CXX object plugins/script/CMakeFiles/script.dir/interfaces/MapInterface.cpp.o [ 12%] Building CXX object plugins/script/CMakeFiles/script.dir/interfaces/MathInterface.cpp.o [ 12%] Building CXX object plugins/script/CMakeFiles/script.dir/interfaces/ModelInterface.cpp.o [ 12%] Building CXX object plugins/script/CMakeFiles/script.dir/interfaces/PatchInterface.cpp.o [ 12%] Building CXX object plugins/script/CMakeFiles/script.dir/interfaces/RadiantInterface.cpp.o [ 12%] Building CXX object plugins/script/CMakeFiles/script.dir/interfaces/SceneGraphInterface.cpp.o [ 12%] Building CXX object plugins/script/CMakeFiles/script.dir/interfaces/SelectionGroupInterface.cpp.o In file included from /home/chris/DarkRadiant/include/iselectiongroup.h:4, from /home/chris/DarkRadiant/plugins/script/interfaces/SelectionGroupInterface.h:7, from /home/chris/DarkRadiant/plugins/script/interfaces/SelectionGroupInterface.cpp:1: /home/chris/DarkRadiant/include/iselectable.h: In function ‘void Node_setSelected(const INodePtr&, bool)’: /home/chris/DarkRadiant/include/iselectable.h:31:37: error: ‘node_cast’ is not a member of ‘scene’ ISelectablePtr selectable = scene::node_cast<ISelectable>(node); ^~~~~~~~~ /home/chris/DarkRadiant/include/iselectable.h:31:58: error: expected primary-expression before ‘>’ token ISelectablePtr selectable = scene::node_cast<ISelectable>(node); ^ /home/chris/DarkRadiant/include/iselectable.h: In function ‘bool Node_isSelected(const INodePtr&)’: /home/chris/DarkRadiant/include/iselectable.h:41:37: error: ‘node_cast’ is not a member of ‘scene’ ISelectablePtr selectable = scene::node_cast<ISelectable>(node); ^~~~~~~~~ /home/chris/DarkRadiant/include/iselectable.h:41:58: error: expected primary-expression before ‘>’ token ISelectablePtr selectable = scene::node_cast<ISelectable>(node); ^ make[2]: *** [plugins/script/CMakeFiles/script.dir/build.make:297: plugins/script/CMakeFiles/script.dir/interfaces/SelectionGroupInterface.cpp.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:368: plugins/script/CMakeFiles/script.dir/all] Error 2 make: *** [Makefile:130: all] Error 2

Have you tried loading a quicksave in 2.11? What version of tdm do you use currently? Have you tried disabling all scripts to see if it's script related? I mean I just share some ideas, I'm sure you know much more of tdm.

I tried the script on the core assets, and find an interesting case called textures/darkmod/metal/flat/tiling_1d/gen_smooth_gold01 This material has time-dependent envmap color: { blend add maskalpha cubeMap env/gen1 red sintable[time*0.1] green sintable[time*0.1] blue sintable[time*0.1] texgen reflect } I wonder whether it was intentional or not. Here is how it looks: I suppose it would be worthwhile to manually review the modified materials, because in some cases the color adjustment was actually meaningful...

When talking about a possible libre version of TDM (https://forums.thedarkmod.com/index.php?/topic/22346-libre-version-of-tdm/) it seems we believe all media/gamedata included in TDM is licensed CC-BY-NC-SA. I am not familiar with how the process of adding new media/gamedata works today; I have seen files uploaded to the bugtracker which developers then commit to SVN, but I don't know if there are other ways. It may be a good idea to implement a process that when new components (media/gamedata included in TDM) are added, the contributor is asked to be explicit about the license (a choice which may defaults to their previous preference, for usability). It won't fix the past, but it may help in the future. This will make it easy for contributors to add future data under a more permissive license if they choose. Libre media can be added and its license can be tracked, rather than assumed to be CC-BY-NC-SA. I suggest looking at how Wikimedia Commons has implemented this: the contributor state the source and license at the time the data is uploaded. This can be done either by providing urls or by saying "It's my work and I choose this licsense". The first step could be to add a way to keep track of each filepath in SVN, author, license, sources. Start by setting the value for each file's license to "(default/legacy CC-BY-NC-SA)". Possible implementations for a user interface for new additions are: * Use our own wiki, which runs Mediawiki (same as Wikimedia Commons). I see several benefits of this, but we also need a way to accept uploads of batches, not just single files. * Look at how other open source projects have solved this. There may be more appropriate solutions available. ... but I'll leave the implementation open. Suggestions are very welcome! If the author of each file already in SVN can be tracked, then it may be possible that the author is willing to give a blanket permission for all their past files in one statement, and all their files in SVN can be updated in one commit. A productive contributor willing to release some of their work under a more permissive license could make a big change. If Dark Radiant would support letting mappers search media/gamedata by license (does it already?), it would make it easier for mappers to create a completely libre mission, which would help facilitate a TDM-libre release. If I understand things correctly. This post does not address all details and it may contain misunderstandings or assumptions, but it's a start. Also relevant: * Is there a compiled and maintained list of recommended or deprecated resources for mappers to use? * https://forums.thedarkmod.com/index.php?/topic/20311-external-art-assets-licensing/

Yes, but I used the user_addon_init script inside and this seems to also be in the core files so I got an redeclare error. I renamed that script and weird enough, on my home system it's working fine now :)! Maybe I made a typo earlier...

Changelog of 2.13 development: dev17042-10732 * Restored ability to create cvars dynamically, fixing bow in missions (5600). * Fixed issue where .cfg files were saved every frame (5600). * Added sys.getcvarf script event for getting float value of cvar (6530). * Extracted most of constants from weapon scripts into cvars (6530). dev17035-10724 * Support passing information between game and briefing/debriefing GUI via persistent info. Also changed start map & location selection, added on_mission_complete script callback (6509 thread). * New bumpmapped environment mapping is now default (6354). * New behavior of zero sound spawnarg is not default (6346). * Added sound for "charge post" model (6527). * Major refactoring of cvars system to simplify future changes (5600). Known issues: * Bow does not shoot in some missions (only in this dev build): thread dev17026-10712 * Nested subviews (mirrors, remotes, sky, etc.) now work properly (6434). * Added GUI debriefing state on mission success (6509 thread). * Sound argument override with zero now works properly under cvar (6346 thread). * Environment mapping is same on bumpy and non-bumpy surfaces under cvar (6354 thread). * Default console font size reduced to 5, added lower bound depending on resolution. * Added high-quality versions of panel_carved_rectangles (6515). * Added proper normal map for stainglass_saint_03 (6521). * Fixed DestroyDelay warning when closing objectives. * Fixed the only remaining non-threadsafe cvar (5600). * Minor optimization of depth shader. * Added cm_allocator debug cvar (6505). * Fixed r_lockView when compass is enabled. dev17008-10685 * Enabled shadow features specific to maps implementation (poll). * Auto-detect number of parallel threads to use in jobs system (6503). * Improved parallel images loading, parallelized sounds loading, optimized EAS (6503). * Major improvements in mission loading progress bar (6503). * Core missions are now stored uncompressed in assets SVN (6498). * Deleted a lot of old rendering code under useNewRenderPasses + some cleanup (6271). dev16996-10665 * Environment mapping supports texcoord transforms on bumpmap (6500). * Fully disabled shadows on translucent objects (6490). * Fixed dmap making almost axis-aligned visportals buggy (6480). * com_maxFps no longer quantizes by milliseconds on Windows 8+. * Now Uncapped FPS and Vsync are ON by default. * Supported Vsync control on Linux. * Added set of prototype materials (thread). * Fixes to Stone font to remove stray pixels (post). * Loot candlestick no longer toggle the candle when taken. * Optimized volumetric lights and shadows in the new Training Mission (4352). * Fixed frob_light_holder_toggle_light on entities with both skin_lit and skin_unlit. * Now combination lock supports non-door entities by activating them. * Added low-poly version of hedge model (6481). * Added tiling version of distant_cityscape_01 texture (6487). * Added missing editor image for geometric02_red_end_HD (6492). * Added building_facades/city_district decal material. * Fixed rendering with "r_useScissor 0" (6349). * Added r_lockView debug rendering cvar (thread). * Fixed regression in polygon trace model (5887). * Added a set of lampion light entityDefs.

The first thing you need is to make sure all your script files have inclusion guards so they can only be loaded into the script stack once (these are the #endif lines you see at the start and end of official TDM script files). If you have those, then as long as both your addon and the FM author use the same name for the same .script file there shouldn't be an issue in terms of re-inclusion. Problems can still arise if both the author and you try to initialise the custom script separately, i.e. in this case you would have 2 copies of the stealth statistics scroll. Another issue arises if the FM author overwrites tdm_user_addons.script, which is the case here, because that will overwrite your addons. This is an error that should be corrected by the FM author (they should use tdm_custom_scripts.script, which is designed for mappers to use), and I've already told kingsal about this just now. Ultimately I think it's hard to avoid conflicts if the FM author integrates a user addon into his map. The best thing you can probably do besides what's above is to make sure each of your files and functions has unique names so both copies of the script can run in parallel in peace. Ofc this doesn't help if the author got the addon from your addon pack. We should probably discourage FM authors from integrating addon packs and instead ask them to point players to a download link.

I'll try that: I remember now there's an entity used to call script functions on other entities... show / hide are universal events at the core of the base entity, if that doesn't work something must be very broken. Another option I thought of: What if I teleport the atdm:mover_multistate_position entity instead? However I doubt that will work since to my knowledge, dmap compiles elevator positions to some extent so changing them in realtime will likely not work or break stuff, but just in case let me know if that might be safe.

There was an idea to add two features to GUI scripts (6164). The first one is runScript command, which allows GUI script to call a function from game script. Interestingly, this feature is already supported in the GUI engine, but the game code only processes this command when the player clicks left mouse button on the GUI (i.e. usually it works in onAction handler, but not in namedEvent or onTime handlers). Obviously, ID initially did not envision runScript as a global feature which works the same way everywhere, their idea was that it is context-sensitive, and whoever calls the GUI code can then pull the commands generated by the call and do whatever he wants with them. I'm not sure I really want to change this architecture... Anyway: what are the possible use cases for runScript command? The second feature is namedEvent command, which simply generates/calls a named event with specified name on the whole UI, which can be then handled by matching onNamedEvent handlers. However, this command can be implemented in several ways: Whenever namedEvent command is executed, the named event is processed immediately. The rest of the script (after namedEvent command) is continued only after generated named event is fully processed. Whenever namedEvent command is executed, named event is put into some kind of queue, then the current script continues to execute. The generated named event is executed at some moment later, but surely on the current frame. The point 2 can be further differentiated on the exact order when generated named events are processed. So the first approach is how functions normally behave in normal imperative languages, with a real call stack. The second approach is delayed execution, like what we currently do with "resetTime X; -> X::onTime 0 {...}" combo (at least everywhere in the main menu GUI). My worry with the first approach is that it is an major change for GUI engine with no past experience, and it will probably not match well with the long-established GUI wierdness (I mean e.g. the wierdness that all expressions in GUI script are executed before the script commands start executing). And it would work different both from the "resetTime + onTime 0" combo. On the other hand, the callGui in game scripts do execute named event immediately. And I must admit nested GUI calls could be used to reduce the issues from the GUI weirdness mentioned above. Also, this command exists in Quake 4, but I'm not sure how exactly it works. And it's probably good idea to make TDM work the same way.

Ah, pity I wasn't reading the forums back in February. I'm fond of that game, along with Bugbear's other early title, Rally Trophy. I was never too good at FlatOut, but it was always a hoot to play.

I have an elevator with a button: When the button is pressed it tells the lift move to an atdm:mover_multistate_position entity, which it does by targeting the elevator while having the spawnarg "position atdm_mover_multistate_position_1" to tell it where to go. This works well but I need it to do something special: When an objective is completed, the button needs to make the elevator go to a different position when pressed from that point on. I don't know how to do this: If I target the trigger_relay that runs when the objective is completed to the button, that will only make the button press itself. I can't use an atdm:target_changetarget either since it's not the button's target I need to change but its position spawnarg. I don't want to make a script for something this simple so I'm hoping there's a special entity I can use to get the job done. One solution would be two buttons: Completing the objective makes the first one invisible and unfrobable while making the second one visible and frobable. But I'm not aware of a way to make buttons visible / invisible either. At worst I'll use an atdm:teleport to swap the buttons, that's an ugly solution so making sure there's no better option first.

Dear all, Is there anyway we can maintain backwards compatibility in the scripting system? In example, the below function was introduced in tdm_events.script in TDM 2.11: scriptEvent void removeFrobPeer(entity peer); Is there something such us the below or can you think of any other way? if (funcExists("removeFrobPeer")) { } Many thanks in advance.

I've been trying to finish off a handful of projects and experiments I had started a while ago, and remembered that I ran into a roadblock. I was trying to build some custom entities with slightly complex behavior and had wanted to access a def_attach'd entity from the script on its parent object. These script functions sounded pretty close: scriptEvent entity getAttachment(string attName); Get the attached entity with the given attachment name Will be NULL if the name is invalid or if the entity no longer exists Spawnclasses responding to this event: idActor scriptEvent entity getAttachmentInd(float index); Get the attached entity at the given index. Will be NULL if the index is invalid or the entity no longer exists index: starts at 0 Spawnclasses responding to this event: idActor scriptEvent float getNumAttachments(); Return the number of attachments on an AI. Used to iterate through the attachments if desired. Spawnclasses responding to this event: idActor But as you can see, they only apply to idActors. I dug into the source code and found that the code that handles all 3 of these functions just calls into the idEntity base class to retrieve the attachment, and there does not appear to be anything specific to idActor with those. As such, I'm fairly certain that these script events could be moved to idEntity without breaking any existing usages (assuming script event inheritance works as expected). Are there any downsides to doing this? I can create a bugtracker entry and/or provide a patch if there are no objections.

Similar: My suggestion is getting rid of needing tdm_custom_scripts.script as a requirement. The problem is that unlike every other asset, be it a def or a skin or model or texture, scripts need to be referenced from a core script file for execution: FM's each need to contain a file with that exact name including their custom scripts. The problem with this is that no mods containing scripts can work out-of-the-box as a drag-and-drop pk4, the same way that say a custom character (just AI model or skin) can: Each individual FM needs to integrate it manually, universal mods aren't possible since the last pk4 loaded will override tdm_custom_scripts.script or tdm_user_addons.script breaking all previous mods referencing their own scripts from those files. The ideal solution would be just auto-loading scripts like everything else. But I imagine this may no longer be possible as it could break a lot of existing things like older FM's. One compromise I believe I suggested was allowing a dynamically named script to be auto-loaded by the engine, which would make it so different pk4's don't override the exact same file and conflict with each other: If your mod is named "whatever.pk4" for instance, the engine should auto-execute the script named "scripts/whatever.script" located in that archive... this would provide an elegant and equally sandboxed solution to this long standing issue.

Thanks, Obsttorte. Your riddle, should you chose to accept it. Same set of functions per script but different functionality. In which order the engine reads the scripts and commands and therefore the content? Which script wins, which script gets reloaded and which script gets obviated? In case a script breaks the engine, please discard it and carry on with the exercise. Example with a base script: TDM/tdm_base01.pk4 ~ script/tdm_movers.script TDM/fms/anymission.pk4 ~ script/tdm_movers.script TDM/fms/anymission.pk4 ~ script/tdm_custom_scripts.script ~ #include "script/tdm_movers.script" (let's pretend this happens) TDM/fms/anymission/script/tdm_movers.script TDM/fms/anymission/script/tdm_custom_scripts.script ~ #include "script/tdm_movers.script" (let's pretend this happens) TDM/script/tdm_movers.script TDM/script/tdm_user_addons.script ~ #include "script/tdm_movers.script" (let's pretend this happens) Example with a custom script: TDM/fms/anymission.pk4 ~ script/tdm_nuke.script TDM/fms/anymission.pk4 ~ script/tdm_custom_scripts.script ~ #include "script/tdm_nuke.script" TDM/fms/anymission/script/tdm_nuke.script TDM/fms/anymission/script/tdm_custom_scripts.script ~ #include "script/tdm_nuke.script" TDM/script/tdm_nuke.script TDM/script/tdm_user_addons.script ~ #include "script/tdm_nuke.script" Ready, steady, go

Yeah I guess you could make a script that loads missions, then teleports to different area's and makes screenshots (actually I made a similar script for envshot a while back), but then you have to review all those screenshots? Maybe just a script that changes calc in something else and don't look back (maybe this is dumb)?

I recently saw discussion about PBR materials being added to Doom3BFG with folks also talking about it on Discord. One of the things I always wanted from PBR is proper reflections, especially in a way that works on all FM's new and old without requiring changes (eg: new light entities). Lack of proper reflections is one of the biggest limitations we still have, leaving us with mere boring specular reflections lacking any detail. While currently we can't have things like metallicity or per-pixel roughness, not even the ability to use the skybox or player camera feed as a reflection map, we do have a generic cubemap used only on windows and a few special textures. So the thought itched me: What if we could make every material with a specular map also blend a cubemap reflection? I've done Linux batch scripts for complex tasks before, so after lots of searching (and dealing with DOS era line terminations getting in the way) I managed to create a bash script that will do just that! This 50 line script will detect all materials with a specular map, inject a customized cubemap reflection, then repack everything. It scans every material in TDM thus it changes all map textures models and entities alike, everything gets modified to benefit from this. Modifications are NOT made to the official pk4 files, instead a single pk4 named Z-tdm_materials_cubemap.pk4 is generated to override the old defs, you can revert at any time simply by removing this one file. The cubemaps are subtly blended in without using extra vertex / fragment shaders which should have minimal performance impact, they also respect the bump map of the material and are deformed by it... each cubemap is masked by the specular map which gives it a close feel to PBR, materials without a specularity texture are considered rough and remain unchanged. Simply download the script and use it in your TDM folder, you'll need either Linux or a bash environment on Windows (untested): material_cubemaps.sh #!/bin/bash # Add cubemap reflections to all TheDarkMod materials containing specular maps # Use sub(/\r$/,"") to fix DOS line termination, https://stackoverflow.com/questions/45772525/why-does-my-tool-output-overwrite-itself-and-how-do-i-fix-it # Unpack all materials mkdir "temp" for f in *.pk4; do unzip -o $f "materials/*" -d "temp" done mv "temp/materials" "temp/mtr" mkdir "temp/materials" cd "temp/mtr" # Inject cubemap code into all materials with specular maps, the reflection is masked by specular intensity # First ensure the file contains at least one definition that need to be modified to avoid needless repacking for f in *.mtr; do awk '{ sub(/\r$/,"") if($1 == "specularmap" && $2 != "_black" && $2 != "") exit !f }' "$f" if [ $? == 1 ]; then awk '{ sub(/\r$/,"") print $0 if($1 == "specularmap" && $2 != "_black" && $2 != "") { print "" print " // Cubemap reflection for specularity" print " {" print " maskcolor" print " map makealpha(" $2 ")" print " }" print " {" print " blend gl_dst_alpha, gl_one" print " maskalpha" print " cubeMap env/gen3" print " texgen reflect" print " }" } }' "$f" > "../materials/$f" fi done # Pack modified materials cd ".." zip -r "../Z-tdm_materials_cubemap.pk4" "materials" rm -r "../temp" At the moment I haven't done a full comparison and only tried it out on a map I'm working on: It's possible I might do my next TDM stream with this on which will allow others to see it better. From what I'm noticing it's pretty much perfect: Very subtle and doesn't disrupt visually, it does improve realism in a lot of cases as you move around and see the shine... given the texture is almost always masked and distorted by bump you don't feel the reflection is ugly and fake but it feels natural. Currently this is here as a mod for players that wish to use it... not gonna lie part of me is tempted to suggest it be considered for 2.11, it's definitely an improvement to having no reflections at all until a better method is found. Please try it out and share your own thoughts and images, below are a few screenshots I took during my first test to confirm it works as expected.

Oh wow, that is amazing! It must require a custom script I imagine? Didn't think that was possible even with one and the S/R system, that's very impressive. Definitely curious about a few things: Does it distinguish between collisions with the glass and frame? If the arrow hits a metal part it shouldn't do anything, it should only break if the glass in particular was hit. If the lamp is triggered by a switch, does flipping it no longer turn the light on once it's broken? Can you use a broken skin rather than model? With some lamps it would be easier to only change the skin and replace the glass, of course both should be supported based on what works best for each lamp.