Search the Community

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.

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

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/

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.

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.

Yes, definitely needs to be distinguishable. Clear glass with light bulb visible would be the best way: You know that if you see clear glass and the bulb inside you can shoot it. The distinction isn't always possible to make without first trying it out though... paintings are the best example, you always need to get close to see if a painting can be looted. As for players learning about this, we should add those lights to the tutorial level where the basics of TDM are taught: In one of the hallways we'd have examples with the message "solid lights can't be shot, but ones with fragile glass and a lightbulb can be broken with broadhead arrows", the player is given arrows and can shoot at different lamps to compare. As for explosive barrels those would be cool to have too! In their case they should already be doable with a script, just that no one's ever done them: Remove the barrel, spawn the same explosion as the fire arrow or mine, and some temporary lasting physical debris if possible. Breakable lights would need support added to the builtin spawnfunc.

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.

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

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)?

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.

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.

@snatcher I understand that when you feel your work doesn't live up to your goals that you don't want it out in the wild advertising your own perceived shortcomings but that leads to a troubling dilemma of authors who are never satisfied with their work offering fleeting access to their in-progress designs then rescinding them or allowing them to be lost. When I was a member of Doom3world forums, I would often see members do interesting experiments and sometimes that work would languish until someone new would examine it and pickup the torch. This seemed like a perfectly viable system until Doom3world was killed by spambots and countless projects and conceptual works were lost. I guess what I am trying to say is that mods don't need to be perfect to be valuable. If they contain some grain of a useable feature they might be adapted by mission authors in custom scenarios. They might offer instructive details that others trying to achieve the same results can examine. It would be great if known compelling works were kept somewhere safe other than via forum attachments and temporary file sharing sites. I suppose we used to collect such things in our internal SVN for safe keeping but even that isn't always viable. If folks would rather not post beta or incomplete mods to TDM's Moddb page, perhaps they would consider creating their own Moddb page or allow them to be added to my page for safe keeping. Please don't look at this as some sort of pressure campaign or anything. I fully understand anyone not willing to put their name next to something they aren't fully happy with. As a general proviso, ( if possible \ permitted ) I just want to prevent the loss of some valuable investigations and formative works. The end of Doom3world was a digital apocalypse similar to the death of photobucket. It is one of my greatest fears that TDM will become a digital memory with only the skeletons of old forum threads at the wayback archive site.

Complaint From Players The player must pick up candles before extinguishing them, and then the player must remember to drop the candle. The player must drag a body before shouldering it (picking it up), and the player must remember to frob again to stop dragging the body. The player finds this annoying or easy to make mistakes. For players who ghost, some of them have the goal of returning objects back to their original positions. With the current "pick up, use item, and drop" system, the item might not return easily or at all to its original position. For example, a candlestick might bounce off its holder. (See player quotes at the bottom.) Bug Tracker https://bugs.thedarkmod.com/view.php?id=6316 Problems to Solve How can the "pick up" step be eliminated so that the player can directly use or interact with the item where it is in the game world? How can so much key pressing and mouse clicking be eliminated when the player wants to directly use an item? How can candles be extinguished and lanterns toggled off/on without first picking them up? How can bodies be shouldered without first dragging them? Solution Design Goals Make TDM easier for new players while also improving it for longtime players. Reduce tedious steps for common frob interactions. Make it intuitive so that menu settings are unnecessary. Do not introduce bugs or break the game. Terms frob -- the frob button action happens instantly. hold frob -- the frob button is held for 200ms before the action happens. (This can be changed via cvar: 200ms by default.) Proposed Solution Note: Some issues have been struckthrough to show changes since the patch has been updated. Change how frobbing works for bodies, candles, and lanterns. For bodies: Frob to shoulder (pick up) a body. Second frob to drop shouldered body, while allowing frob on doors, switches, etc. Hold frob (key down) to start drag, continue to hold frob (key down) to drag body, and then release frob (key up) to stop dragging body. Also, a body can be dragged immediately by holding frob and moving the mouse. For candles/lanterns: Frob to extinguish candles and toggle off/on lanterns. Hold frob to pick it up, and then frob again to drop. Frob to pick it up, and then frob again to drop. Hold frob to extinguish candles and toggle off/on lanterns. For food: Frob to pick it up, and then frob again to drop. Hold frob to eat food. For other items: No change. New cvar "tdm_frobhold_delay", default:"200" The frob hold delay (in ms) before drag or extinguish. Set to 0 for TDM v2.11 (and prior) behavior. Solution Benefits Bodies: New players will have less to learn to get started moving knocked out guards. With TDM v2.11 and earlier, some players have played several missions before realizing that they could shoulder a body instead of dragging it long distances. Frob to shoulder body matches Thief, so longtime Thief players will find it familiar. Second frob drops a shouldered body. Players still have the ability to both shoulder and drag bodies. Compatible with the new auto-search bodies feature. Dragging feels more natural -- just grab, hold, and drop with a single button press. There is no longer the need to press the button twice. Also, it's no longer possible to walk away from a body while unintentionally dragging it. Set "tdm_frobhold_delay" cvar to delay of 0 to restore TDM v2.11 (and prior) behavior. Candles: New players will have less to learn to get started extinguishing candles. With TDM v2.11 and earlier, some players didn't know they could extinguish candles by picking them up and using them. Instead, they resorted to throwing them to extinguish them or hiding them. Hold frob to extinguish a candle feels like "pinching" it out. Once a candle is picked up, players still have the ability to manipulate and use them the same way they are used to in TDM v2.11 and earlier. For players who ghost and have the goal of putting objects back to their original positions, they'll have an easier time and not have to deal with candles popping off their holders when trying to place them back carefully. Set "tdm_frobhold_delay" cvar to delay of 0 to restore TDM v2.11 (and prior) behavior. Solution Issues Bodies: Frob does not drop a shouldered body, so that might be unexpected for new players. This is also different than Thief where a second frob will drop a body. "Use Inv. Item" or "Drop Inv. Item" drops the body. This is the same as TDM v2.11 and earlier. This is the price to pay for being able to frob (open/close) doors while shouldering a body. Patch was updated to drop body on second frob, while allowing frob on doors, switches, etc. Candles: Picking up a candle or lantern requires a slight delay, because the player must hold the frob button. The player might unintentionally extinguish a candle while moving it if they hold down frob. The player will need to learn that holding frob will extinguish the candle. The player can change the delay period via the "tdm_frobhold_delay" cvar. Also, when the cvar is set to a delay of 0, the behavior matches TDM v2.11 and earlier, meaning the player would have to first "Frob/Interact" to pick up the candle and then press "Use Inv. Item" to extinguish it. Some players might unintentionally extinguish a candle when they are trying to move it or pick it up. They need to make sure to hold frob to initiate moving the candle. When a candle is unlit, it will highlight but do nothing on frob. That might confuse players. However, the player will likely learn after extinguishing several candles that an unlit candle still highlights. It makes sense that an already-extinguished candle cannot be extinguished on frob. The official "Training Mission" might need to have its instructions updated to correctly guide the player through candle manipulation training. Updating the training mission to include the hold frob to extinguish would probably be helpful. Similar Solutions In Fallout 4, frob uses an item and long-press frob picks it up. Goldwell's mission, "Accountant 2: New In Town", has candles that extinguish on frob without the need of picking them up first. Snatcher's TDM Modpack includes a "Blow / Ignite" item that allows the player to blow out candles Wesp5's Unofficial Patch provides a way to directly extinguish movable candles by frobbing. Demonstration Videos Note: The last two videos don't quite demonstrate the latest patch anymore. But the gist is the same. This feature proposal is best experienced in game, but some demonstration videos are better than nothing. The following videos show either a clear improvement or that the player is not slowed down with the change in controls. For example, "long-press" sounds long, but it really isn't. Video: Body Shouldering and Dragging The purpose of this video is to show that frob to shoulder a body is fast and long-press frob to drag a body is fast enough and accurate. Video: Long-Press Frob to Pick Up Candle The purpose of this video is to show how the long-press frob to pick up a candle isn't really much slower than regular frob. Video: Frob to Extinguish The purpose of this video -- if a bit contrived -- is to show the efficiency and precision of this proposed feature. The task in the video was for the player to as quickly and accurately as possible extinguish candles and put them back in their original positions. On the left, TDM v2.11 is shown. The player has to highlight each candle, press "Frob/Interact" to pick up, press "Use Inv. Item" to extinguish, make sure the candle is back in place, and finally press "Frob/Interact" to drop the candle. The result shows mistakes and candles getting misplaced. On the right, the proposed feature is shown. The player frobs to extinguish the candles. The result shows no mistakes and candles are kept in their original positions. Special Thanks @Wellingtoncrab was instrumental in improving this feature during its early stages. We had many discussions covering varying scenarios, pros, and cons, and how it would affect the gameplay and player experience. Originally, I had a completely different solution that added a special "use modifier" keybinding. He suggested the frob to use and long-press frob to pick up mechanics. I coded it up, gave it a try, and found it to be too good. Without his feedback and patience, this feature wouldn't be as good as it is. Thank you, @Wellingtoncrab! And, of note, @Wellingtoncrab hasn't been able to try it in game yet, because I'm using Linux and can't compile a Windows build for him. So, if this feature isn't good, that's my fault. Code Patch I'll post the code patch in another post below this one so that folks who compile TDM themselves can give this proposal a try in game. And, if you do, I look forward to your feedback! Player Complaints TTLG (2023-01-10) Player 1: TDM Forums (2021-03-13) Player 2: Player 3: TDM Forums (2023-06-17) Player 4: TDM Discord (2021-05-18) Player 5: TDM Discord (2023-02-14) Player 6: Player 7: Player 8:

Congrats on the release! Remember to check ThiefGuild as well as the DarkFate forums (via Google Translate) for additional feedback.

That bash script does not (as far as I can see) "extract all textures with specular maps". It extracts all materials to disk, then locates lines that include the word "specularmap" and blindly injects a couple of new material stages underneath. It does not identify the name of the material at all, and I'm not sure it will correctly handle materials where the specular map is part of a full stage block "{ blend specularmap ... }".

Collect them all in a testmap and then run an automation script that moves trough the map, making screenshots?

I think we can use this script (mod) to extract all textures with specular maps, and if possible, create a map for testing. Unfortunately, I'm not yet familiar with the editor to help with this. I came here because I plan to work on textures more thoroughly, and I'm currently reading the wiki on texturing issues. In general, I'm interested in this topic. Maybe I'm not competent at all, but is it possible to make a texture have a constant reflection (yes/no) and a variable with a setting in the editor/accompanying document (?) that controls the intensity? For example, the same object/texture can behave differently on different maps.

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.

Just curious, based on this discussion: http://forums.thedarkmod.com/topic/19239-soft-r-gamma/?p=427350

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

You can work around this error by putting a completely empty file called tdm_turret_scriptbased.script in your script folder, and temporarily removing all turrets from the map. Would still be interesting to see whether 10518 is the first build where the problem appears, or beta1.

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.

http://k.min.us/jCfGA.jpg "At night, they say, the Builders' hand comes loose from his mighty hammer and creatures wander out from their hiding places while he slumbers. But tis this night, above all others that unholy vapours cloak the land with gloomy curtains and night creatures dance and sing in the twilight. I can't say I'm looking forward to my endeavors this night.... I've been given a job by a Priest to retrieve two holy artifacts from an abandoned cloister in Eldin woods north of the city, simple job I thought, but the priest failed to mention the placed was haunted." Build Time: - version 1.0 was about 5 weeks, but we are now upto version 3.11. Thanks: Respect to the Dark Mod team for putting up with all my questions and knocking up the various updates in short order!. Special thanks to Flanders and Springheel for their models and my testers for helping me squash all the bugs etc. Testers: Flanders, Jaxa, nbohr1more, Aluminumhaste, Baal,l Oldjim, Cookie, Obsttorte, lux, Mat99, AluminumHaste, thebigh Readables: Darkangel/Flanders/b1k3rdude with special thanks to Flanders for his original story.. Resource: Flanders/Springheel - art direction and models. Misc: This is a homage to the original Thief2 mission from 2001 (The Cathedral of the Damned) Download: - The latest version is now available via the in-game downloader. Info: This version has been heavily updated from the original, this came about as a result of need to be compatible with TDM 2.10+ Repeat after me, "Read and explore, Read and explore" The mission is fully l10n ready. (thanks Tels) The mission now has EFX Reverb The mission now has Volumetric Light effects The mission now uses LOD settings for different detail levels There is now a script event related to the "Curse" A few new surprises... Known issues: This mission will have less than optimal fps at a few points on the map, but most of my testers with lowish end rigs (P4/HD4650) are getting 30fps+ at the worst spots) For very low end PCs I recommend the following settings: V-sync is off, AA is off, Aniso is 4x or lower, advanced settings are simple/default & Post processing of disabled and as a last resort the command line arg ' r_skipFogLights 1 ' (turns off the fog)

Type of mission: Mansion/Estate/Horror Story: Lord Blackgrove recently purchased a rare expensive artifact. The whole family has now disappeared leaving the manor empty. Time to check out the manor and see if the artifact can be found. Build time: My first map ever, 300 hours (5 months). Credits: Kingsal - Breaker script for light switches and elevator Dragofer - Ambience Track 'Intent' Springheel and Sotha - Video Tutorials (those videos really helped) Feedback and testing: Cambridge Spy, Dragofer, nbohr1more, Acolytesix, wesp5, Shadow, Zerg Rush, AluminumHaste, prjames The whole community. Download (1.03): https://drive.google.com/file/d/1wZc_nqHoX7kQvzfg08EpoRy2hyuH7mw3/view?usp=sharing Edit: Version 1.02 provides large performance improvements in the outdoor areas. Be sure to set TDM Object Details (LOD) to Normal (or lower) to take advantage of some of the optimizations. Edit: Version 1.03 further improves performance around hedges thanks to HMart's alternative hedge model. I’ve had a mission like this in mind for years. My main influences and inspirations are: Deus Ex - Chateau DuClare (https://youtu.be/9QLT_l8aH78) Clive Barker’s Undying - Main Mansion (https://youtu.be/t8PyXhCQB3Q?t=90) Thief Deadly Shadows - Shalebridge Cradle (Almost everyone should be very familiar with this one) (https://youtu.be/Rw4YZuRUgXA) In case anyone gets stuck and needs help, I’ve listed some questions and answers below that will hopefully help. FAQ