Search the Community

I already posted a reply about compiling on linux in this thread http://forums.thedarkmod.com/index.php?showtopic=5574&hl= In short I recommended a unified build system based on bjam ( see http://www.boost.org/tools/build/v1/build_system.htm for more info )

I'd like to get started with the Stim/Response editor in the next few days. From fiddling around with stim/response stuff back in September when setting up the fire-secret in the Bonehoard, I know a thing or two about it, but I'm not an expert on this area. I will certainly play around a bit with the existing system and come up with some designs before I actually start coding. Before I dash ahead and start planning the actual GUI I would also like to post in The Editor's Guild on TTLG and interview a few Dromeders about common Stim/Response tasks, as I haven't any Dromed experience myself. Would that be ok for the team or would you rather leave the planning within these forums?

Was I the only one slightly angry when reading the Book of Revelation? They could have used spoiler tags! However, there's a simple way to disprove the rapture. The Bible says the rapture will come to Earth like a thief in the night - but it's only night on half the Earth at any given time! So Rapture = Incorrect!

The forum isn't allowing me to edit above. Great link, Pinkdot. I'll have to give that a go. Also, I finally found the post I was referring to: http://forums.thedarkmod.com/index.php?s=&am...ost&p=95847 Edit: aha, I think it was another case of "to" + ": " setting off forum alarms.

Okay, I've looked at getting mikebart's ivy into the game. It can either be a simple, done-in-a-few-minutes task, or it can be troublesome and time consuming. I was originally shooting for a balance between the two, but it's looking more like it leans toward the latter if done in the way I intended (separate materials for each). So I'm looking for input on how this should be done. Option 1: See image attached below. This is how the ivy is currently laid out on a single image. They can be rigged up with a material, and boom, they look great in game. Tested and done. Pro: Easy, fast, done. Con: They're all on the same sheet. Makes it harder for a mapper to work with them (see below) Option 2: Cut them all into their own little images. Give them each their own material, and then they're in game. Pro: They're all standalone, easier to work with (see below) Con: more work, resizing will throw off relative scales, resizing to multiples of 2 will cause distortion (or require padding space), etc. If all are on the same sheet, it is a bit harder for the mapper, because each time they want to place a texture, they have to fit and adjust accordingly. E.g., if they want the large patch at the base of the wall, and then want some of the smaller patches sprouting from it, it's not just a matter of placing a patch, texturing it with Fit, and you're done. You must place the patch, figure out the right size you need, seek the texture spot across the surface of the patch, resize if necessary to fit (because auto "Fit" can't be used anymore). The advantage is the scales will all still be fixed relatively, with the same size settings. Edit: Hmm, then again, in DarkRadiant, using the TexTool, this is not a very difficult task...End Edit If they're on separate sheets, laying them out for a mapper is as simple as creating the patch of desired size (same as above) and selecting the texture and hitting Fit. However! The textures will be different sizes, relatively speaking, and possibly even distorted. They don't all have dimensions that conform easily to multiples of 2, and using them would inevitably always involve some cramming or stretching on patches to make them lay right. If that route is avoided by adding "dead space" to cushion the individual textures to multiples of 2 sizes, then they will obviously have dead space - so Fit might not give desired results. So the question: does anyone have "the" definitive word on how this type of thing must be handled and why? Or, is it fine to just go with the quick and dirty option #1, which requires some placement work by mappers, but keeps everything properly sized and proportioned relative to each other?

Dunno if this is for sure, but... http://pc.ign.com/articles/772/772286p1.html If that's not the dumbest name in game history, I don't know what is EDIT - why the dumb forums ruin the all caps in the title? It's S.T.A.L.K.E.R.S as I typed it originally

Both, they can be used as patch meshes or modeled to fit around an object in a modeling app, by adding the 2 new tiling ivy textures it opens up a whole lot more possibilities for covering large surfaces like walls at little cost of polys, the tiling pattern can be broken up by the Ivy leaf textures. I havent added the new textures to the .mtr file so you may need to do that, below is the shader you'l need if you want to paint vertex shadows, I doubt you'l need it for most Ivy situations though. models/skool/bramble_vertexcolour { //DECAL_MACRO noShadows twosided //polygonOffset nonsolid noimpact { blend diffusemap map models/skool/bramble_d.tga alphaTest 0.5 vertexcolor } bumpmap models/skool/bramble_local.tga specularmap models/skool/bramble_s.tga { blend diffusemap map _black inversevertexcolor } } Ive also included the highpoly model of the Ivy, I think it might be useful for generating textures for the vine arrow and you can see how the scene is all set up for lighting and projection. All you have to do is select the lowpoly mesh, open the render to texture dialog and click render. It will render out diffuse, specular and normal .tga's for the alpha you need to render the diffuse again but turn off shadows and lighting, call it "whatever_alpha" then open it in photoshop, select sampled colours and copy the black area onto the origional diffuse alpha channel Im not realy too familiar with PSP, if you're having trouble seeing the alpha working in doom3 it probably the material have a look at the material for the origional ivy

-- add updated music to menu http://forums.thedarkmod.com/index.php?showt...=5206&st=25

General question: should we still keep the old code of the legacy Surface Inspector, Patch Inspector and TexTool? At the moment it's an option in the registry whether the new or the old dialogs should be used. I'd personally prefer removing the old code for the sake of code cleanliness and because they're inferior (IMO), but I'm unsure from the mapper's point of view. SneaksieDave? angua? Beta Mappers? Opinions?

You might be talking about these threads http://forums.thedarkmod.com/index.php?showtopic=4283 http://forums.thedarkmod.com/index.php?showtopic=4283 And the diagram I posted (but everyone also said that inventory objects should jump to inventory, which my diagram doesn't distinguish between) http://forums.thedarkmod.com/index.php?act=A...post&id=981

These are some optoins off the top of my head. Sparhawk might have some ideas also (he is our real programming team lead, someone really needs to change my title so it doesn't mislead people ): Look into how reading key states and button states works in the new SDK (1.3.1). The earlier SDK versions had a problem where they could only detect about 8 keys as "buttons", that is, you could tell if they were held down or not. All the others were "impulses." Since we wanted to add some things with controls that could be held down, we jumped through a lot of hoops trying to put in hooks for mouse and keyboard states. The new SDK just came out a month or so ago, and promises "access to mouse and button states" I believe they're on an object called "common" in the SDK. If you want, you could look into how to get mouse states and key states (held down/not) in the new SDK. Once you've figured it out, you could make a test mod where it just outputs to the screen which keys or mouse buttons are pressed. (Outputting to the screen can be done thru gameLocal->DrawText, I think). If it is actually possible, we can get rid of our low-level hooks and go with what works in the new SDK. This would be very useful if someone could look into it. Relatively simple scripting for player tools We have a lot of player tools that will go in the inventory and be used. "Use item" calls a script on the object, so we have to go through the various player tools and write scripts for them. Usually it will be very simple, add so much health for a health potion, add so much air for the breath potion, spawn a projectile that gives off a flash on detonation for the flashbomb, zoom in and apply a GUI overlay with the telescope, put down an idMoveable with a trigger bound to it for the mine, and so on. We had someone working on the flashbomb but I haven't heard from him in a while. Object manipulation: Stuck objects (requires our codebase) I got the impression from the public forums that you are interested in the object manipulation physics. You could implement a system for momentarily stopping the player from moving when their object gets stuck, then dropping it if they continue to move in the same direction for some time. This requires stuff in our existing codebase (the rest of the object manipulation code, immobilization code for stopping the player and not conflicting with anything else that's immobilizing the player). I was planning to write this, but it's fine if someone else writes it too since there's plenty of stuff for all of us to do. This may not be the best task to start out with though, since it requires our codebase and integrating stuff with a bunch of other code. Let me know if any of those sound interesting. If not we can think of something else.

There is a forum called "Information" with a sticky thread about important mod details. I recommend at least looking once at all the announcements and stickies in the forums, so that you know whats up.

Comp you are team member now, right? So you should rather open this thread in the sound forum. It helps to track it later on if you want to go beack and look for something. If you don't see the other forums then say so, because then you there is a problem with your permissions.

I don't want to belittle sledge's effort on this mission, but Inverted Manse just wasn't my cup of tea, in neither playstyle offered. The architecture is gorgeous and the blue room trickery impressive, the overall DromEd handywork very good as well - but I haven't had much fun playing it. Somehow the gameplay didn't click. I had the same problem with other high-rated missions, like Calandra's Legacy or Deceptive Perceptions. The upside is that the wealth of FMs offers something for every taste - Into The Maelstrom, Equilibrium, Saints and Thieves and Rodamill were right up my alley. Oh, one little gem (if you like puzzles) is Temple of Tides by Nameless Voice, were he shows off what his scripts can do. Just be sure to get the patches or a fixed version and don't look at the spoiler thread on the forums.

Yep, here's the thread: http://forums.thedarkmod.com/index.php?showt...=4283&st=25 Seems like pretty much everyone was in agreement that hitting 'use' when carrying an inventory object that's held in your hands puts it back in your inventory. Hitting use when carrying a junk object that is "useable" (like a body or a chair leg) makes it goes into it's "equiped" position. If it's a junk object that's not useable, nothing happens.

This is no problem, although this will be one. The Light Inspector can't keep track of any other undoable actions that might happen while it's open. Imagine a change from a point to a projected light and the user dragging the vertices around. It could never know how "far" to go back to revert the changes since the time it was first displayed. In my opinion the gnome HIG are nice and clean for most applications, but can't be easily applied 1:1 in an application like DarkRadiant, especially when it comes to using the inspectors. If it was up to me, I'd make all changes in the Light Inspector instantly applied and undoable, and ditch the apply button completely (the Surface Inspector and Patch Inspector) don't have one either. That said, I'm all for making the UI as predictable and easy-to-use as possible, but in the end we can't (and shouldn't) turn it in an Office application. (I guess I got dragged away, sorry.) I'll try to look into the instant-apply stuff first.

The LightInspector changes when clicking on "Apply" are undoable now. Should I go further and make all changes instantly applied? This is of course harder to implement, but from working on the Surface and Patch Inspectors I think I know what to watch out for.

Haven't seen this, must be linux-specific, but it could be possible that I set the modality to MainFrame instead of the parent window. I'll check that. Argh, I knew I forgot something, I'll have to copy over the old infostore population code from the LightTextureSelector. The dialog is behaving now as the Surface Inspector and the Patch Inspector does, they can be floating around while working on the actual map. OK is suggesting that the dialog is closed after clicking, which isn't the case. Similarly, I thought Cancel is not appropriate anymore, but I could re-add it calling it "Reset" instead, triggering a reload of the information from the currently selected light. Should I do that?

I occasionally do a google search; there are a lot of links to discussion on the forums (these ones, TTLG etc), plus SourceForge and various mirror sites, and discussions about GtkRadiant. Many of the forums are in foreign languages but they seem to be Doom 3 news and community sites.

Angua, if you get a chance to add these to our model website, that would be great. http://forums.thedarkmod.com/index.php?showtopic=4402

-- alternate belcher skins -- fix spider so it doesn't call humanoid def -- test Ish's changes to carrying ragdolls -- make second stage spyglass overlay -- look at inventory icon updates http://forums.thedarkmod.com/index.php?showtopic=3531&hl=

There are extensive discussions, recommendations, lists of best of the best, categorization by genres etc, on the ttlg forums.

Hey guys, I've been following the mod for a while now and finally decided to get off my lazy ass and register for the forums. I most likely won't be an active member but I just wanted to tell you that you're all doing an awesome job and I can't wait to see a release! Good luck and keep up the great work

i agree completely with the comments made by sparhawk. yeah i read in the forums that the changes arent going to very noticable other than the shadows so... all my previous comments do apply. one thing that i really enjoyed about T2X, however, were the cutscenes. I feel that these cutscenes were the best part of the game and other mod crews could learn a thing or two from them. and btw Gildoran i think thats probably the case that i played very low quality FMs. so if some people could reccomend the classics/greatest FMs id appreciate it. i just reinstalled thief 2: TMA, so id be able to play some of them.

Belchers: http://forums.thedarkmod.com/index.php?showtopic=5452 (needs AF fix) Spiders: http://forums.thedarkmod.com/index.php?showtopic=5458 (needs AF fix too along with playing the correct animations)