Search the Community

It strongly depends on what the game is designed for. Most games designe for consoles are also designed for controler controls. Replacing them with mouse and keyboard can lead to a worse gaming experience. As an example I played "Ocarina of Time" via emulator with mouse and keyboard, but I had to quit at some point as I could not solve a couple of puzzles that required to point your shield in a certain direction, because the keyboard only knows "hit button", and has no gradual proceeding as the analog stick has. Another example would be Dark Souls, which is basically unplayable with mouse and keyboard (at least from what I have heard). For me, I prefer controler for 3rd person games and platformers, while I prefer mouse and keyboard for 1st person (be it shooter or RPG) and RTS.

Greetings everyone! I recently got into TDM and am already having a lot of fun playing through and ghosting missions. However, coming from Thief, I am mostly relying on the rules and my experience with that game, while there are clearly differences in how TDM works. Right now, there is talk in the ghosting discussion thread on TTLG to amend the ruleset and include clarifications pertaining to TDM. So I wanted to drop by and ask: is there an active TDM ghosting community already and have any rules for this playstyle been developed? I would also like to ask someone to take a look at the draft of this addendum to see whether everything looks correct: https://www.ttlg.com/forums/showthread.php?t=148487&page=16&p=2473352&viewfull=1#post2473352 Thanks!

A Problem Arises I've paused subtitling of the Lady02 vocal set, because of a problem with the voice clips described here: https://forums.thedarkmod.com/index.php?/topic/21741-subtitles-possibilities-beyond-211/&do=findComment&comment=490151 While a way forward is being determined, I'll work on a different vocal set. Maybe manbeast, for which Kingsal just provided me the voice script.

It's a limitation of the wxWidgets AUI framework that there is one "center" or "main" pane that cannot be removed or undocked or moved around. But you can swap out the main view with another one with a shortcut, have a look at the Edit > Keyboard shortcuts and look for the ones starting with ToggleMainControl. You should find one with ToggleMainControl_Camera - this one will replace the main orthoview with a camera view. By repeatedly pressing the shortcut you will keep changing between ortho and camera.

So... What was up with the forums all day yesterday..?

DarkmodPadbinds.cfg contains the bindings. You can compare it with the keybind file and an explanation is given here: https://wiki.thedarkmod.com/index.php?title=Bindings_and_User_Settings EDIT: You can also use JoyToKey to bind joypad input to keyboard bindings. It's a versatile program and may be easier than editing the config.

DarkRadiant 3.7.0 is ready for download. What's new: Feature: Skin Editor Improvement: Script Window usability improvements Fixed: Hitting escape while autosaving crashes to desktop Fixed: Def parsing problem in tdm_playertools_lockpicks.def Fixed: DR hangs if selecting a lot of entities with entity list open Fixed: Float Property Editor's entry box is sticking around after selecting a float key Fixed: Spline entities without model spawnarg are unselectable Fixed: Entity window resets interior sizing forcing resize each time it is opened Fixed: Spline curves should not be created with a model spawnarg Fixed: Newly appended curve control vertices aren't shown at first Fixed: Light entities are zoomed out in preview window Fixed: Entity inspector spawnarg fields not always updated by UI windows such as Model Chooser Feature: Skin Editor (see video) Windows and Mac Downloads are available on Github: https://github.com/codereader/DarkRadiant/releases/tag/3.7.0 and of course linked from the website https://www.darkradiant.net Thanks to all the awesome people who keep using DarkRadiant to create Fan Missions - they are the main reason for me to keep going. Please report any bugs or feature requests here in these forums, following these guidelines: Bugs (including steps for reproduction) can go directly on the tracker. When unsure about a bug/issue, feel free to ask. If you run into a crash, please record a crashdump: Crashdump Instructions Feature requests should be suggested (and possibly discussed) here in these forums before they may be added to the tracker. The list of changes can be found on the our bugtracker changelog. Keep on mapping!

Yes, it does. Which makes it interesting that you yourself explicitly said that it's interesting nobody had complained here on the official forums: I did, which is why it stood out to me so much that even though you yourself had personally been involved you would reply claiming nobody had complained here on the official forums. I'm not colorblind at all. Does that make people pointing out that almost no modern games have proper colorblindness support hyperbole? Just because it doesn't affect you, or you choose not to pay attention to the discussion of something, doesn't make it hyperbole. Pick pretty much any modern FPS and you will find plenty of discussion about the near universal disregard for FOV and camera movement as accessibility issues. Denigrating those as hyperbole because you personally don't feel the affects is as bad of a look as demeaning people who bring up the importance of valid allergen warnings like gluten or colorblindness and deafness support.

I actually had a go at this myself once, but found it far too difficult. Personally I too hate the default input style, particularly the requirement to constantly hold down modifiers just to select things, but changing the defaults just breaks too much stuff because the selection system isn't designed to work that way. In order to allow "normal" selection rules, we would also need: A different method to create a new brush (since left-drag is now a selection or manipulation operation), for example something like Blender's Shift+A shortcut. A different way to resize brushes. Currently dragging anywhere outside the brush performs a resize, but if clicking/dragging on empty space is supposed to define a new selection, this will no longer work. So we would need something like traditional resize handles instead of the planar dragging approach. The selection system to decide what operation is being performed after the initial click or drag starts (as Greebo already mentioned). [Optional but almost certainly necessary] A system for setting up alternative keyboard profiles so people could choose between classic Radiant selection or the new system, since not everybody would agree with the changes.

Black Parade is released ! https://www.ttlg.com/forums/showthread.php?t=152429

Huh. TAB works for me on func_statics that were created from brushes. But it doesn't work for groups. I'm running DR 3.3.0, if that makes a difference. Maybe I'll try an older version. Edit: I tried DR 2.11 and that version doesn't work for me either. I verified that my keyboard shortcuts are setup correctly, GroupCycleForward = TAB. @AluminumHaste, is that your setting as well?

Body awareness please. https://forums.thedarkmod.com/index.php?/topic/20013-are-you-gonna-add-this/

I would like the possibilty of having the properties window be a separate, temporary window. Preferably each subtab could have its own window so it can be sized and placed individually. The information that is displayed (Entity dictionary, media browser, texture view etc.) is not needed most of the time, but when you shrink them to save screen space they are hard to work with. The idea is to quickly open them with a key press, do the work then close them with another key press. I also would like an option to switch the search on key press off that some windows use. It disrupts my workflow by preventing keyboard shortcuts (which I use very often). Thank you for your continuing work on this, by the way. It's much appreciated.

I loved it. Awesome game. I faceplanted at the people who asked for quest markers in the Steam forums there... Herr, lass Hirn regnen. The game is so great, and so true to the original, because it doesn't hold your hand. When is the new breed of gamers gonna learn.

I'm running linux; darkradiant compiled from source (most recent commit of master). In the 'Regular' and 'RegularLeft' window layouts keyboard input doesn't work at all. Some windows (console or media browser) don't open. The layer dialog does not work as supposed. I can't assign a parent layer by drag and drop. Hiding through the checkboxes does nothing. Everything else seems to work. Maybe not a bug: When the media browser is shown (or some other window with a search function) the search field captures keypresses. Which is really, really annoying and disruptive.

The spoiler tags aren't for you, it's for the rest of us reading this thread so WE don't get spoiled. Thanks for spoiling the frobbable book on a shelf for the rest of us. EDIT: I'll be unsubscribing to this thread to avoid further spoilers. Maybe I'll check back after I've finished the mission Amadeus

Could the Keyboard shortcut settings have tabs for different sections like how it is done with the mouse binding settings? Or, they could be placed both inside the preferences screen to unclutter the edit menu? Example:

Old RIVE board has been replaced with a temporary P9X79 LE board. Takes the same cpu and has mostly the same options though only 2 sata 6 ports compared to the 4 on the RIVE and 4 usb 3.0 where the RIVE had 8. As a blast from the past it actually supports both ps/2 keyboard and mouse xD where the RIVE could only take either a ps/2 keyboard or a mouse. At some point ill probably scrounge up the dough for an asus X79 deluxe board, yeah staying with my old cpu seems like a weird decision but an upgrade to something similar new would cost me an arm and both legs and the old cpu still has plenty kick left in it.

What I was trying to get at that there is no real difference. The end result is the same. The biggest drawback to the "theme" thing is that to create multiple themes, you have to visit almost everything mutliple times - or make one grand swep through things and assign the into multiple themes - at which point you might just as well "tag" them. For me this is semantic hair splitting, regardless on wether you use: * theme A: contains element a, b,c, d * theme B: contains element a, b,x, y or: * element a: tags A, B * element b: tags A, B * element c: tags A * element d: tags A * element x: tags B * element y: tags B The result from a point of getting the search result is the same, search for A and you get the same "set" in both cases. Just the storage is a bit different laid out. You are storing the same information in both cases, and with the over 10000 "things" we have in TDM (possible 15..20000), you need some sort of central storage and editing, anyway, because there is NO WAY you are gonna sort 2000 material shaders into themes, or tag them manually, and then repeat the same for sounds, particles, skins etc. Edit: Searching for "A" is a bit easier with the themes, because you can just "take" everything in the theme. But thats a storage algorithgm difference, and needs not to be visible to the user. The idea here is that a theme works good if the users wants anything in the theme, but breaks down if you add search modifiers. Like "give me everything from theme A but no sounds, and then add every entity from theme B". At this point the user might as well say "give me everything tagged with A except sounds, and every entity tagged with B" and there is no difference in output. Just that parts and mixing themes makes no so much sense as just saying "give me a list of things that match these tags", which essentialy is. The "theming" thus leads the user to believe they get something different, which they don't.

I'd add that an impulse is a one-time command in the game, i.e. select the next item in the inventory. A keyboard key can be bound so that it triggers such an event. Slightly confusing that the continuous form of "impulse" is called "button" (i.e. move forward). Both are assigned to keyboard keys. Maybe a list of all available impulses and buttons in the engine can be found somewhere in the source code.

I have this issue since 3.0, still present in 3.2 . When I am in free camera mode (right mouse button in Camera view), I can't zoom in and out with mouse wheel scroll, keyboard arrows do still work. Somebody else (Nort) mentioned he/she couldn't reproduce the issue under Windows, so maybe it's just my (Linux) system and therefore I decided I don't add it to the bugtracker yet.

DarkRadiant 3.6.0 is ready for download. What's new: Feature: Selection Focus (Ctrl-F) Feature: Add Radiant.findEntityByName script method Feature: Media Browser shows a thumbnail preview when selecting folders Feature: Map is remembering layer visibilities between loads Fixed: ModelDefs are shown in T-pose Fixed: Patch vertices are the wrong colour Fixed: Shader Clipboard source gets cleared on 'copy shader' operation Fixed: Nodes of hidden layers are still visible after loading the map Fixed: Can't close properties window Fixed: Merge Action rendering is broken Fixed: After using ToggleMainControl_Camera, the center panel is grey after restart Fixed: When using ToggleMainControl_Camera, arrow keys cannot be used to move the viewer Fixed: Property Panel not remembering undocked/closed tabs Fixed: Texture Tool not updating during manipulation Fixed: Orthoview ignores filters for surfaces in models Fixed: Blue dot when selecting one face removed Tweak: Conversation Editor: double-click opens selected conversation Tweak: Preference option to disable drag select in camera view Tweak: ESC key should clear the resource tree view filter text Tweak: New layers function: tooltip popup getting in the way Feature: Selection Focus (see video) Windows and Mac Downloads are available on Github: https://github.com/codereader/DarkRadiant/releases/tag/3.6.0 and of course linked from the website https://www.darkradiant.net Thanks to all the awesome people who keep using DarkRadiant to create Fan Missions - they are the main reason for me to keep going. Please report any bugs or feature requests here in these forums, following these guidelines: Bugs (including steps for reproduction) can go directly on the tracker. When unsure about a bug/issue, feel free to ask. If you run into a crash, please record a crashdump: Crashdump Instructions Feature requests should be suggested (and possibly discussed) here in these forums before they may be added to the tracker. The list of changes can be found on the our bugtracker changelog. Have fun mapping!

I just tried HL2: VR yesterday and got blown away by the level of quality. Got curious again how this mod is progressing, and imagine my shock - it's the same developer. Now I'm even more hyped for TDM VR. It have the potential to become one of the best VR games. The only other Thief- style game I know is Unknightly. But, ironically, it was abandoned by developer in alpha stage in a completely un-knightly manner. Adding full VR inventory and interactions to TDM will be perfect: - Stealth, horror and atmosphere aspects are greatly enhanced in VR (judging by my recent experience playing Into The Radius, which has all these elements, but is not focused on stealth as much). - This is a popular mod that gets constant updates and improvements with a modern version of Doom engine. So basically, "free" updates. - Constant stream of new missions to play. - Robust, accurate physics engine should be perfect for VR interactions (picking up stuff and bodies). One of the challenges would probably be making sure that the player has full control over his movement and the amount of noise he makes. With keyboard and mouse, it's easy to do precise movements which are needed in missions when you're in a tight spot. With VR, there's issues, like if you physically lean forward, most games will just move invisible player capsule forward (the capsule itself stays upright at all times) and then suddenly your view gets higher as the game registers your movement as if you stepped up on a table. But you want to lean over it. Anyway, it's just a speculation on my part. I'm a game dev myself, but haven't worked on actual VR game yet (too lazy, I guess). Maybe I should get my hands dirty at some point... I have some experience with C++, but not with Doom 3 engine.