Search the Community

I never used dark radiant before and am currently just trying to get used to it's features. I took a skybox from this site: http://www.custommapmakers.org/skyboxes.php, named and placed the files properly according to the wiki(http://wiki.thedarkmod.com/index.php?title=Skybox_Tutorial) except I also copied the forward facing texture, put it in textures/skies/custom an renamed it to "nightsky.tga"(this was mention on this thread: https://web.archive.org/web/20091206232215/http://www.doom3world.org:80/phpbb2/viewtopic.php?t=3571). I can find the the texture in darkradiant but when I create a skybox with it the info_portalsky always ends up leaking.

Tl;Dr: How can we get to The Quest 2.0? Do Quests in computer games really need to be so dull? Long text: I've been playing computer games recently. The one in progress now is The Long Dark, which I bought years ago and now it got updated with a STORY mode. The SURVIVAL mode is brilliant. Stay alive as long as possible with minimal gear. Resources run out and you must move on and take risks. You need to make good decisions with where to go and what to do. Your situation changes often and you are presented with a new obstacles (nope, you can't go to the place you wanted because there are wolves there. You are running low on food and drink and the weather is getting bad. Go back (and starve), circle around (risk losing your bearings), expend resources to scare wolves away (always low on resources), try to fight them (risk infection&torn clothes[gets even more cold])). Interesting stuff. I really looked forward to the STORY mode because I somehow expected them to do something new to Quests in computer games. I am not sure why I expected that... As you guessed, it turned out there was nothing new. It is a typically quest game with survival mechanisms (food, drink, sleep, cold). The survival mechanisms are in the background, because the player gets plenty of food and drink so those are a-non-issue. Thus it becomes exactly the chore-fest many quest based games are. You know the drill, right? 1) Quest giver says: "Get me STUFF." -> You walk around for a while, collect STUFF and deliver it to the quest giver. -> The quest giver gives a tiny reward. 2) Quest giver says: "Go THERE, investigate and get back." -> You walk THERE, a cutscene plays. and then you return to the quest giver. -> The quest giver gives a moderate reward. 3) Quest giver says :"Get me MORE STUFF!" -> You walk around for a while, collect MORE STUFF and deliver it to the quest giver. -> The quest giver gives THE KEY TO GET OUT OF THIS LOCATION It is linear, and boring. The player does chores and is rewarded with a predefined plotline that progresses. Are computer games doomed to always be this way? Could something more interesting be possible? I am not sure what... maybe the plot line moves onward without the players interaction ("survive as you see fit in the ghost town until spring when snow melts and the way is clear.")? Perhaps the Quest giver actually exploits the player until they end up in jail on the Quest givers behalf (game over) or until the player realizes this on their own and gives the quest giver a punch in the face and takes the KEY to PROGRESS outright? Maybe the quest giver gives a target ("get outta town") and the player is given free form how to do it ("steal car", "trick the dude to ferry you out", "stock up on gear and walk", "take the climbing route", "use dynamite!") You know, how to make the Quest something else than a machine where you put a chore in and you get game progress out... Something new... Something more out-of-the-box... Something more surprising... Something more fun!

In 2.05, it was decided to add a frobbox_size of 10 to purses. See issue #4150. As was just discovered (issue #4573) this prevents a purse in The Creeps from being frobable. The purse isn't frobable because the increased frobbox_size allows the frob controller in the drawer under the purse to think the purse is in the drawer. So when the drawer is closed, the purse is unfrobable. Since the purse has been assigned to the drawer, it isn't assigned to the secret door. When the door is opened, the purse is ignored and it doesn't become frobable. My take on the discussion here is that folks thought it would be nice if purses automatically received a bigger frobbox_size to make it easier for them to be frobbed out of chests. But the bureau is a complex beast full of frob blockers and frob controllers and increasing frobbox sizes amongst that complexity causes problems. I propose reverting the 2.05 +10 frobbox_size on purses and going back to "it's up to the mapper to make sure items inside chests and bureaus and desks are frobable", which is how it's been since day 1. Comments?

Hi all, I have a problem with my layer window. I accidentally gave a new layer the same name as an older layer and now there is a visibility tick box at the top of my layer window that I can't get rid of. It looks like this: https://www.dropbox.com/s/ezs4famcmyqz9wy/Layers.bmp?dl=0 Any suggestions as to what I could do? The problem appears only, when I open this map, others are not affected.

I'm wondering if anyone ever checks new posts in the Fan Missions Forums? I've posted 4 questions asking for help for 4 different missions that I can't finish because I"m stuck, and I don't get any help. I posted a question this morning so I don't expect an answer right away for that one. Its frustrating because I would like to finish them. I've read through the posts for each mission and I'm not getting anything from them. If there's someone who could help me I'd really appreciate it. Thanks I guess I'm spoiled from the TTLG forums.

Hi all, me again Now that I've learned how to take screenies on DM (thanks to Aluminumhaste) I wanted to post one that I took but I got an error saying that the image ext that I used was not allowed in these forums, It was .jpg so I changed it to .png and I got the same error again. They're on Photobucket.

Just noticed this this morning... The dull_opaque01 glass texture is now lit up like Christmas. The mountain_sunset skybox texture is hosed. Here are pics from 2.05 (correct) and SVN (boo!):

Hey Guys, I've been stuck on my new map for awhile now, ever since I decided to use cameras to project a scene to make a canal look like it extends further than it does. I've been trying to nut it out now for over a week, and just can't resolve it. So if anyone has any ideas, I really need them lol https://www.youtube.com/watch?v=K6L9uainqH8

Hello everyone. I recently started to make my own map and it seems I encountered a problem that I can't solve on my own. I made a skin for a default model (it is an outdoor sign with chains). I used the wood texture that also comes with TDM. The skin looks as it should be in the 'Choose Skin' window, but in-game it is completely black. Does it have something to do with the vertex colours? Or is it because the default model uses two textures? (one for chains and another - for the shield itself) Here's my *.skin file: //shield shape// skin sign_shield_lucky_leaf { model models/darkmod/decorative/signs/sign_shieldshape01.lwo tdm_sign_shield01 textures/darkmod/wood/boards/pier_platform }

It started after I implemented Obstorttes security camera technique. He doesn't know what causes it, There's mention of a HOM effect in Doom3 security camera, I don't know if this is the same. My new map is sort of depending on this, and I'm really excited by the map idea, so I'd really love to find a fix. Hall of Mirrors effect https://www.youtube.com/watch?v=Hm6yEG4h5yI Thanks Neon

So I just downloaded The Dark Mod and I can't set my sound to the surround option. It says the game couldn't find a 3D sound device. I use a Logitech gaming headset that uses the Logitech Gaming Software through USB to play surround sound, so its separate from the windows audio driver. Is there a way to make the game detect this, or is there a work around. Thanks!

I kinda ran into that issue before, but the tdm_update.exe doesn't seem to behave properly: it just downloads a file of size 1.5 MB, then asks to restart and repeats this again. I then did the following (now it works, but I don't know which of these steps were necessary): - I deleated all files in the darkmod directory - I downloaded a new version of the updater - When the button asking for a Restart appears, I go to the directory instead and run the file _tdm_update.exe (instead tdm_update.exe) I just thought I let you know about this.

This is another report originating from a GCC warning, in this case the comparison of two different enumerators. This works by converting each of the two enumerators into a numeric value, and comparing them instead. In general, an enumerator is better used in a way that does not depend from its value at all. If the value is needed, constants are generally better suited. The relevant one of the two warnings comes from idAF::Load() in game/AF.cpp (line 910), where a variable of enumerator type declAFConstraintType_t from framework/DeclAF.h: typedef enum { DECLAF_CONSTRAINT_INVALID, DECLAF_CONSTRAINT_FIXED, DECLAF_CONSTRAINT_BALLANDSOCKETJOINT, DECLAF_CONSTRAINT_UNIVERSALJOINT, DECLAF_CONSTRAINT_HINGE, DECLAF_CONSTRAINT_SLIDER, DECLAF_CONSTRAINT_SPRING } declAFConstraintType_t;is compared with a variable of enumerator type constraintType_t from game/physics/Physics_AF.h: typedef enum { CONSTRAINT_INVALID, CONSTRAINT_FIXED, CONSTRAINT_BALLANDSOCKETJOINT, CONSTRAINT_UNIVERSALJOINT, CONSTRAINT_HINGE, CONSTRAINT_HINGESTEERING, CONSTRAINT_SLIDER, CONSTRAINT_CYLINDRICALJOINT, CONSTRAINT_LINE, CONSTRAINT_PLANE, CONSTRAINT_SPRING, CONSTRAINT_CONTACT, CONSTRAINT_FRICTION, CONSTRAINT_CONELIMIT, CONSTRAINT_PYRAMIDLIMIT, CONSTRAINT_SUSPENSION } constraintType_t;The comparison of values from two distinct enumerator types should be avoided because it requires the enumerator modifications to be synchronised, but it's very tempting to add an element to one forgetting about the other. If this comparison is really required, there should be a single enumerator type. Judging from the enumerator names, this departure from synchronisation has already happened (I would except a DECLAF_CONSTRAINT_SLIDER to be equivalent to a CONSTRAINT_SLIDER, and instead it's compared to a CONSTRAINT_HINGESTEERING). The two definitions are in different parts of the code and do not apparently share headers. But more to the point, for what I know these numerical values might be serialised, and changing them would break saved data. My recommended suggestions would be: if possible, manage to have a single enumerator for both usesif not, abandon direct comparison and use a slower multiple-choice comparison function.I provide a patch implementing the latter suggestion, which is expected not to break any serialised data, by not changing the enumerator values. Note that this function relies on the heuristic logic of my brain to match the elements from the two enumerators. Somebody with some understanding should cross check it. The patch also addresses the other enumerator comparison, which is more subtle and is caused by the fact that enumerators defined in a template class yield one different enumerator type for each template instantiation. enumCompare.patch.txt

Last year I raised attention to an issue in 2.02 where unconscious AI were not sustaining fall damage; the Bugtracker code for that issue is 0003699, and Grayman went about resolving the issue. As 2.03 has just been released, I wanted to test out my one map where I first encountered the issue. So I went about knocking out different AI and proceeded to noclip up to various heights and then drop them down to earth. What I have discovered is that while the issue has been "fixed" inasmuch that the unconscious AI do eventually die, the height distances from which this happens and the number of drops required to kill the AI, do vary in unexpected ways. In the first instance, I had to drop an unconscious standard City Watch guard from a height of approximately 670-700 Doom Units (DU) around six times before he died. Contrast this experience with the single drop - from exactly the same height - that it took to kill an unconscious 'Wench.' What was even more strange was that it only took four drops to kill the unconscious standard City Watch guard from a height of around 280-300 DU; but it took around seven to kill an ordinary 'Thug.' Regardless of the fact that it is taking more than a single drop to kill unconscious AI from either a single story or - in the case of 670-700 DU, a three story - building, one would anticipate that it would take less drops from a higher height than a lower one. As I noted at the beginning, the issue is technically solved; however, it would seem that perhaps some variables require tweaking?