Search the Community

RE Glitches with the Stone (aka Stone Print) font. Probably the minor artifacts with this font - mentioned in the bugtracker - are due to the fact that this file is missing from the distribution: tdm_fonts01\fonts\english\stone\fontimage_12.dat <== MISSING which I surmise causes the 24pt font to be used instead and scaled down. There is some reason to believe the missing file was present at one time, because the corresponding .dds file is present: tdm_fonts01\dds\fonts\english\stone\stone_0_12.dds And the russian paths have both the .dat and .dds files (2 of the latter in the case of russian) for this font. (I think trying to copy the russian version of .dat to the english branch would fail big time.) If someone with access to an archive of very early TDM full distributions can check to see if it is available, that would be great. That would be the best way to go, because that file may contain hand-tweaks to the font spacing. Otherwise, it could be regenerated from the .ttf file and tweaked, a somewhat fraught endeavor (at least if I were to attempt it).

Nice knowing you are looking at this. Btw when I made my own version of "namedEvent" gui cmd, I just copied the convention of other gui cmds like the "localSound" cmd, what I found is that it made the usage of simple nameEvents in GUI's very fast, with no need to mess with c++ and compile the engine. I think exactly the same reason quake 4 developers said they implemented it, thou like you said we don't know how they made their version. Perhaps is why I had some issues with my implementation when trying to call more complex onNamedEvents, so is something that needs to be well tested. Simple example of usage (the following code is untested and should be looked as "pseudo" code) windowDef Desktop { rect 0,0,640,480 backcolor 0,0,0,1 menugui 1 float "text_state" 0 onInit { // just in case ... if("Desktop::text_state" != 0) { set "Desktop::text_state" "0"; } } //*************** Events ************************* onNamedEvent ClearText { set "Text::text" ""; set "Desktop::text_state" "0"; } onNamedEvent SetText { set "Text::text" "Hello world"; set "Desktop::text_state" "1"; } //************************************************ windowDef Text { rect 240,41,165,110 visible 1 forecolor 1,1,1,1 text "" textscale 0.5 font "fonts/micro" textalign 1 } windowDef back_btn { rect (320-55),(240-35),50,30 visible 1 text "Click Me" textalign 1 textscale 0.3 font "fonts/an" onActionRelease { if("Desktop::text_state" == 1){ namedEvent "ClearText"; } else { namedEvent "SetText"; } } } }

id Studio did a poor job in defining its categorization of variable nomenclature, so in subsequent documentation and discussions there are divergent views (or just slop). In my series, I had to choose something, and went with what I thought would be clearest for the GUI programmer: Properties, which are either Registers (like true variables) Non-registers (like tags) User Variables (also true variables) I see that your view is more along these lines (which perhaps reflects C++ internals?): Flags (like my non-registers) Properties, which are either Built-in (like my registers) Custom (like user Variables) Also, elsewhere, you refer to "registers" as temporaries. I am willing to consider that there could be temporary registers during expression evaluation, but by my interpretation those would be in addition to named property registers. I'm not sure where to go next with this particular aspect, but at least can state it.

Thanks for all the feedback. My original post was the short version of a long story. So, just to clarify, I always create my account details separately in my password file first and only then copy it into the real log in. My password file is on a flash drive with a back up of the entire drive in a separate room in case of fire or theft. But in this case I couldn't access my main password file on the pc because, of course, it wasn't set up yet So I plugged it in my laptop. Guess what? The laptop doesn't like that drive for some reason. So I plugged in the backup drive and created my details there then copied them into the Win11 setup. Once setup there's a million things to configure how I want Windows and I'm still working on that two weeks later. At some point during this period I became aware my password backup drive was still at hand so I stupidly thought I might as well do a backup before I put it away in the other room! I backedup the main password file over the backup file (which had the only copy of my new Win11 details!) I can't believe I did that because I'm paranoid and really meticulous about organising and backing up account details. Just shows no matter how careful one tries to be one can still make a mistake. Next thing is I've always had problems with Microsoft Accounts. I've set up four or five over the years because every one gives wierd errors without explaining what the problem was. I once had a long session direct with M$oft where I gave them so many personal details to sort it all out and yet they still couldn't fix it! So here I set up yet another new one. So I'm reluctant to reset the password in Win11 in case it conflicts with the same password in the Microsoft Account. (Does that matter?) Or I could reset the password in the M$ account log in and then reset the password in Win11 using the same password. Would that work? As far as that hack, how long is 'ages' to crack it? Hours? Also, what would happen if I create a new user in Win11. I'd probably have to re-install software that is not public user I guess. But would I still be able to set admin privileges where needed? Not sure I'd gain anything. It would still conflict with the Microsoft Account. I can't get my head round all this crap; drives me nuts. Or I could do nothing until there is a problem. Odds are with my luck a pc only lasts two or three years. My previous one won't boot but might be recoverable if I can create a portable Win11 disk and fix the boot sector thing. Life is so bloody complicated. 200 years ago, the only tool I'd have to worry about is my spade which would last a lifetime of labouring on a farm 14 hours a day.

oh boy, i realise this is an old post from a decade ago, and maybe i should start with asking what the default keybindings are on keyboard and mouse for this game is and then go and maky my own keybindings, i'm using a program called controller companion which makes the bindings work, and it's probably better than this old tutorial when it comes to having alternate bindings to fully grasp what's needed. but i'm having trouble with the default bindings not quite being as accurate with the current updated version of the dark mod, and it's basically making anything i bind not properly work which makes the game impossible to play, yes i know i could play on keyboard but the whole reason for the controller is simply due to a disibility i have in my hands which makes long term gaming on keyboard and mouse a real strain on my arms and wrists and fingers and i would rather play with my controller.

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!

DarkRadiant 3.4.0 is ready for download. What's new: Feature: Allow Layers to be arranged into a Tree Fixed: Readable Editor displays "shader not found" in view Fixed: Undoing snap to grid with prefabs causes crash Fixed: Include doc in building instructions Fixed: Decal textures causes DR to crash - (textures/darkmod/decals/dirt/long_drip_pattern01) Fixed: Skin chooser: double click on materials list closes window Fixed: Selecting and deselecting a filtered child brush through layers leaves the brush selected Fixed: Material editor re-sorts stages on pasting image map resulting in wrong material stages list and wrong selected stage Fixed: Crash on start if engine path is choosen (Doom 3) Feature: Layers can now be arranged to form a hierarchy Windows and Mac Downloads are available on Github: https://github.com/codereader/DarkRadiant/releases/tag/3.4.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!

Thanks, I can also recommend gog galaxy. The idea of the custom tags is really nice, I'll have to try this out too!

Hello again TDMers. I am using Text entities to make notes on the map of things I need to do. However, I constantly need to manually add the TEXT property every time I add one. The Text is the basic reason I am adding these things. Is there a way to make the TEXT property show up by default when I create the Text entity? Maybe also the Force property (defaulted to 0) and playerOriented (defaulted to 0)? I use these three properties regularly, but they are not present by default. Appreciated. Clint

DarkRadiant 3.5.0 is ready for download. What's new: Feature: More customisable layout, all windows and panes can be dragged and arranged Layouts like Embedded, Regular and Splitpane are superseded and have been removed Tweak: The LayerControlPanel's tooltip popup is now less annoying Tweak: Clarify distinction between Shadow render mode and other render modes Fixed: Show/hide Light Volumes for combined entities inconsistent Fixed: Currently applied particleDef not selected in Particle Selector Fixed: Layer visibility checkbox not reacting to double-clicks Fixed: Cannot toggle visibility of layers in Linux Fixed: Drag-and-dropping layers is not working in Linux Feature: Customisable Layout (click to see the videos) Windows and Mac Downloads are available on Github: https://github.com/codereader/DarkRadiant/releases/tag/3.5.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!

YOU TAFFERS! Happy new year! Deadeye is a small/tiny assassination mission recommended for TDM newcomers and veterans alike. Briefing: Download link: https://drive.google.com/file/d/1JWslTAC3Ai9kkl1VCvJb14ZlVxWMmkUj/view?usp=sharing Enjoy! EDIT: I promised to someone to write something about the design of the map. This is in spoiler tags below. Possibly useful to new mappers or players interested in developer commentary.

The *DOOM3* shaders are ARB2 ('cause of old GeForce support) carmack plan + arb2 - OpenGL / OpenGL: Advanced Coding - Khronos Forums

Personally, for this kind of game, double-clicking and double-tapping are the kind of things that instantly get a sour taste in my mouth as soon as I hear it, because I already know from experience that it not reliable enough and it's more prone to human error. You said it yourself: It may also happen accidentally if your fingers twitch, or if your mouse misregisters an extra click, or when you think you didn't hit the target and immediately click again, but it so happens that you did hit the target the first time; or when you're hasting to perform the same task multiples times in quick succession (not very relevant here, but I couldn't count how many times I died in minecraft tapping keys to adjust my position and accidentally double-tapping forward and sprinting off a cliff). Also, given that we're talking about the right mouse button, I'm feeling even less inclined. I can double-right-click, but it doesn't feel very comfortable. It's really not something I'm used to, so it requires a degree of effort (and I suppose it will get my hand tired, as @Wellingtoncrabmentioned). Yup. I like ghosting. To be fair, I play with my own lax rules, but I still feel bothered if I have to tamper with the natural order of things, if I think it's unnecessary or that I shouldn't be forced to. It might seem petty, but it's part of what makes the challenge interesting. You never know, the candle owner might have noticed before bed that the candle was about an inch away from a spec of dust, and in the morning he might realize that that distance has changed. So, from a ghosting perspective, when you tamper with things without needing to, you've introduced a point of failure. If the game requires it, that's another story -- it turns into "I can't work around it, so I have to bend the rules because of it". But as far as I'm concerned it still bothers me and kind of ruins the challenge. For example, TDM has been leaving a really sour taste in my mouth when it comes to dropping keys, because lots of missions don't allow it (because unfortunately they're not droppable by default in DR, and for no good reason, afaik). After Snatcher's post about the delay interfering with manipulating bodies, I was growing tempted to agree with reversing it, but then I realized both ways have issues of the same kind. If you can click to shoulder, then you can't click to drag body -- you always have to hold button, which is not great if you're dragging a body a long distance. If you can click to drag a body, then you can't hold to drag a body. You always have to click to drag and then click to release, which is also not great when you're dragging limbs for a pose or something. (I suppose this might be even more annoying than the other.) Maybe I should posting this in that thread.

Keep in mind also that mission size, and complexity have increased dramatically since the beginning. For a lot of veteran mappers, it can take over a year to get a map made and released. The last dozen missions have for the most part been pretty massive, with new textures, sounds, scripts, models etc. We seem to be long past the point of people loading up the tools, and banging out a mission in a few weeks that's very barebones. We still do see some of those, but I noticed in the beta mapper forums and on Discord, that mappers seem to make these maps, but don't release them, and instead use the knowledge gained to make something even better. Could just be bias on my part scrolling through the forums and discord server though.

Thanks everyone for the kind words and feedback! Version 1.1 - https://drive.google.com/file/d/1IiHuD293mIb-kQL_t5dJzKnsnkXl4IN_/view This version has better performance, thanks to b1k3rdude (@Bikerdude - it's not tagging for some reason?) who redid the visportaling in the outdoors area (as well as monster clipping the outdoors, and some decoration on the flat rooftop) - can't thank you enough! This has major impact on the outdoors FPS. I also replaced most of the faux-skybox models with their lowest LODs. Other fixes: Unfortunately still unsure about freezes related to the bridge moving...

Hope I'm not being too off-topic for this thread, but I was playing a lovely new FM and something I saw reminded me of another reason why I hate MSAA apart from bad performance: It doesn't even always do the job right, including (but not limited to) to fixing pixel-sharp patterns on textures. Zoomed in for a close look and to catch a good example, see at full res. Seems to be the bumpmap in this case. Possibly caused by the texture being so high-res it surpasses the screen resolution so there's no blurring any more? I set MSAA to 4x and it didn't affect it. Which makes sense since I'm sure it only handles geometry and has no concept of textures. It would further be great if we had an alternative form of AA, which weren't just cheaper than MSAA but also handled sharp pixels on textures including alpha edges alongside geometry edges: Right now I think we have no fix to that grain.

I stopped playing because it lowers performance to a slideshow over time. I'm using proton (Linux), so maybe that's the reason. Here somebody explains it: https://hardforum.com/threads/dark-messiah-framerate-drops-after-in-game-loads.1429977/

Sorry that I cannot provide a more meaningful feedback: the current lean feels good to me and your new lean feels good to me as well. I must have low standards in this regard and both approaches are perfectly serviceable. You have my support for this change if it is perceived as an improvement. Something that's bothered me from day one though is that the left/right (and forward to a lesser relevance) lean buttons seem to have their own agenda. Freedom of movement is handicapped and you cannot lean left or right incrementally or left-to-right and right-to-left dynamically. For some reason you have to go back to straight every time before the next move. I don't know how to explain myself but just launch TDM and lean left/right repeatedly, you should understand what I mean.

I did something similar by improving the description of some of the key binding. Everybody is going over them and might pick up additional info about e.g. the use key. This is one reason why, escpecially if we can't agree on a frob behaviour, there should be an option button to switch it, which automatically will make people aware that the feature exists!

Ok so the original reason I came up with this question is that I was looking at Sotha's Button Controlled Animated Briefing To make that work, you have to edit a gui file and put the text blocks in it. Wouldn't it be easier if you can use text from xdata instead? Then the gui file is just for the looks and operation, like a template that you snap onto your mission, while you create the text in the xdata file. I wondered if that's possible. The normal text based briefing also uses a gui (obviously), which then includes the xdata file. At that point I was thinking of a broader aproach for other gui's, but I probably should've keep it simple.

This just isn’t a true description of the scope as lined out in the original post. Why is it that you feel there is reason enough that you get to decide to just change this? Why is a change which is completely backwards compatible with the existing control scheme “radical”? It is clear in this thread there are players that want this, and anyone who doesn’t doesn’t have to use it. Why at a minimum can’t it go out for testing with more players in a proper dev build like the frob highlight did?

This, just like click again to drop a body, is already included in the patch. If a switch, button or door are highlighted you will interact with them without dropping the body. There are probably more objects this would need to cover which will come up with more testing (readables maybe?) Seems like elements of the patched executable aren’t working with your install for some reason?

Well, I think I found the likely reason. The movable was sunk into the floor by a single grid so I bet that is the reason. Scout's honor that I designed it right at the floor. Must have accidentally shifted it down during all the keyboard/mouse action. Thanks. Clint