Search the Community

Moving here http://forums.thedarkmod.com/index.php?showtopic=5298

There's about seven pages of it here: http://forums.thedarkmod.com/index.php?showtopic=5099 Starts going off-track about half way down the first page.

I always assumed that water arrows ability to magically clean up blood stains in Thief had to do with the fact that they were in fact magical crystals of water, and not a glorified liquid fire extinguisher, a la TDM. Water crystals were seen all over the place in ways suggesting that they either formed overnight in standing pools of water or made for excellent water purifiers. This latter possibility is perfectly consistent with water arrows cleaning up blood stains ("purifying" the blood). I've always disliked the way T:DS handled trick arrows. In the first two games, water, fire, and gas arrows were all elemental crystals (although they could believably be treated as thin glass shells containing water, yellow phosphorous and knock-out gas respectively). The moss arrows (and vine arrows) were simply genetically engineered plants attached to wooden shafts; moss arrows were probably the brainchild of Viktoria. Rope arrows, noisemaker arrows and broadhead arrows were all technological. It was all fairly logical. With T:DS, they screwed up the moss arrow. Now it was an elemental crystal that you could shoot at a guard's face to receive a comical knockout. When I first read the description of what a moss arrow would do in a preview (grow inside their mouths and down their throats, suffocating them), I thought it would be a wholly awesome, and quite gruesome way of killing guards. I thought that if you scored a hit in the lower half of their faces, they would slowly suffocate to death, vainly clawing at the expanding moss in their mouths, unable to scream, perhaps even seizuring just before death claims them. Instead, apparently, having moss growing in your lungs knocks you out Loony Toons-style. I would love to see moss arrows be able to kill people with a straight shot to the face and vine arrows entangle guards. It'd make a nice reminder that a thief's tools are always dangerous. As for water arrows, why not have them clean up blood stains, but require 2-3 to clean up larger stains? At the highest difficulties and securities, guards should notice water puddles and stains that haven't dried up yet. Speaking of blood stains, I would love to see large blood pools from particularly violent kills in a similar manner to Clive Barker's Undying. Killing is always supposed to be a last resort for a thief, so why not portray some of those consequences? While dismemberment is by and large a distraction from the mod (although I'd love to see it in a later release), seeing pools of blood, not to mention blood trails and bloody footprints is a great way to make killing far less palatable for the player. Furthermore, proper implementation can make a violent killing a nightmare to clean up with water arrows, requiring as much as 2-3 arrows for the blood pool, and arrows only able to clear up a certain area (say, .5 m) of blood trails and footprints. Personally, anything that makes killing seem more violent and distasteful is a great way to encourage me to avoid it in the first place. Let's be honest, blood (and potentially water puddles) would make a great way to have a serious replacement for T:DS' oil flasks. As long as the animations aren't too comical, guards sliding and slipping on blood (although, only on slick floors like marble and metal plating) add a dark and admittedly somewhat twisted touch to something that might otherwise seem cartoonish. It would also grant the less scrupulous players a chance to do some truly evil things (making a guard slip into a furnace or off a cliff from a pool of his own brother's blood, for example). Anyways, I thought water arrows always made moss patches grow, so why would they wash them away? Wouldn't fire arrows make a better choice for that task, burning the moss away? Plus, it would bring an extra tactical level to removing moss patches; should you burn it away with a fire arrow, and risk alerting the guards with the explosion, or should you leave the patch alone and pray they don't discover it? At most, moss patch would be a low level alert, and the moss patch might allow you to sneak up to a guard to knock him out, thereby allowing you to burn out the moss patch. Properly implemented, it mostly affects ghosters negatively, but in a way that adds realism (ghosters shouldn't be leaving incriminating evidence like moss patches behind anyways). Ninja edit : No, almost none of this stuff would be worthwhile implementing into the first release. It's my honest hope that TDM eventually outgrows its Thief roots and expands into new areas (such as new playstyles offered by characters other than nameless, mute clones of Garrett). In the long run, I'd love to see game mechanics befitting assassins, hitmen, guards, and even adventurers, but now is not the time. Now is the time for just the basics.

While we're on the subject, how are moss arrows going to be implemented? I did a search on the subject and nothing came up. I always thought that it was kind of stupid that a guard wouldn't notice a newly grown patch of moss under his feet, especially when it was in the middle of a bank. Are there any plans to change the way they work?

Not knowing how much work goes into one little suggestion, I feel a concept artist should be entitled to propose an artistic thought on something. If the coders, mappers and other departments who are "in the know" say, "no way. too much work," then fine... we'll drop it. From my ignorant viewpoint, though, applying a fisheye or blur effect seems like it would hardly be difficult so it's worth mentioning/proposing. If I were to throw up a retarded moss patch with a simplistic (lame) moss sprouting animation on CVS, does the team have to accept it just because it's "done" and "checked off our To-Do list"? No, I'd hope there would be some conversation in an effort to make it better, especially if it's felt simple tweaks could make it more polished.

What the hell, might as well ask. We've generally gone the photo route for textures, and there are still more to be had, so I'm not proclaiming that we've run out. Just thought I'd post this general request and see if anything comes of it. Even if it's a trickle, a good new texture now and then, cool. Not all of our textures are photos (for example blocks_008-14 are hand painted by David Gurrea from RebelAct Studios/Blade of Darkness), so our artists shouldn't feel that they can't submit handmade textures for use. And handmade textures are often (usually?) better, because they are specialized to fit exact needs, instead of having to hunt around for a perfect photo, of which almost none exist. Finally, remember that virtually all of Doom3 was handmade. So, artists, if you've the desire, make some pictures! That's all you have to do, if you don't want to do the rest of the steps. I'll be happy to do my best to take what I can and normalmap, specularmap, and prep them for use in TDM. Need suggestions? 1. Wood. Planks, beams, reinforced beams!, raw wood and fancy. You name it. 2. Stone. Stuff that's interesting and appealing. We have plenty of stones in the repository, but let's face it, not too many of them are pretty to look at. They're usually plain and dull (some are downright ugly), because the reality they're taken from is often plain and dull (and ugly). 3. Metal. Reinforced machinery parts. Girders. Rusted, new, damaged. 4. Windows. You could go nuts with decorative, fancy, stained glass, plain, broken. Needed! 5. Skyboxes. Backdrops, wispy clouds, starry skies, mountain scenes, city scenes. We need 'em! We currently have two choices with our missions - a horizonless starry night sky, or Mars. 6. Arches. Needed less (thanks to patch texturing), but useful anyway (especially for facades) 7. Trims of all materials - needed! From the fancy to the mundane. Also stair fronts. 8. Doors. Reinforced, iron, gated, scratched, decorative, plain 9. Decorative scrollwork. A few of our woods hint and what could be done with this. Liven it up! 10. Decals. Cracks!, burns, dirt, grafitti, snow, spiderwebs All - add more as you think of them.

I'm looking for people who are able/willing to take on the following tasks: Particle Effects - hand-held torch flame (that moves as AI moves like TDS?) - magic arc-light particle (to go with existing model) - buzzing flies particle effect (for dead bodies, garbage, etc) Improve candle flame particle (flicker needs to be increased) -- http://forums.thedarkmod.com/index.php?showt...hl=candle+flame I know nothing about particle effects and doubt I'll have time to learn any time soon.

No, you can use a single material that uses your image (in alphatest mode, presumably) and the twosided keyword on a patch in Doom 3. It will be visible from both sides of the patch.

Feature requests should have severity "feature" unless they are serious -- for example the missing "feature" of being able to save your map would be quite a serious bug. I am not altogether convinced that Patch Thickening is a "major" bug however, even though it may be "important" as a feature: a major bug is something that actually stops you from working, such as the problem with entity inspector not displaying or rendermode changes giving an assertion failure.

Added builder priest: http://forums.thedarkmod.com/index.php?showtopic=5264 Needs some rigging fixes & complete normal maps.

Played with DR a bit more tonight, and came across some stuff that either isn't implemented, or I'm just missing them (it is getting late). I'd feel bad tracking these if they're already there, so can someone fill me in first? - multi-entity objects (not sure what else to call them): in DoomEd, make three brushes. Select them all, and make them func static. Now, they're all as the same func_static - selecting one selects any of them. They can all be copied together, moved around together, etc. In DR, I am able to make several separate brushes as parts of a func static (all named the same), however there doesn't seem to be any smart group selection. You must select them all, and then can work with them (that'd be quite tough with Dram's banisters...) - tab to move between the parts of such objects: when the above object is selected, hitting tab will cycle through each entity piece individually. This is also good for toggling through the sides of a patch. Neither seem to be in DR. Necessary if the smart group selection above works. - revert to worldspawn: shift-g in DoomEd, the objects above will revert back to plain brushes - patch thicken: vital - surely this must exist; am I just missing it? Can't find menu item or hotkey for it. - rotation modes: ctrl-r in DoomEd to cycle between axis flat (center), axis, axis flat (rot origin)

You have now beta mapper status *AAAHHHHHHH*! You should see now the internal forums for beta mappers, so you can download the latest build. *OOOHHHHH* You might consider to wait a few days though. We are planning to release a new build in a few days, we are just waiting for one fix that should go into the release first. I expect by mid of next week that we will upload the new release. Since it is more than a gig, it's probably not worth to start downloading right now.

DarkRadiant 0.8.0 is available here: http://sourceforge.net/project/showfiles.php?group_id=161727 (Previous Sendmefile links: Installer ZIP) New features * Draggable projected lights (like DoomEdit) * Light Inspector dialog, allows easy switching between pointlight and projected light status, selection of colour and texture and various options: * Vastly improved patch texturing, textures can now be copied from brushes to patches while maintaining their alignment (crucial for archways etc.), plus an entirely new "Natural" texture projection which makes the texture follow the curve of the patch without stretching or distortion. * Generic skin chooser for models, allows ascottk's excellent "gen" skin set to be applied to appropriate models. Accessed through the "skin" property in the Entity Inspector. * Entities can now be arranged in a hierarchical tree, based on a keyvalue set in the DEF file. * Configurable keyboard shortcuts (Help -> Shortcuts list) * Multiple XY views can be created, for flexibility of layout. Bugfixes * Fixed disappearing geometry in large maps. * Fixed failure to load many of the texture due to invalid mtr parsing. * Fixed bug with save code causing leaks in certain maps when reopened in DoomEdit.

Hi, just to say that im still around, i came here every day lurking the forums but dont have the time to work on my map, please dont give up me. regards

I might have an idea for a way to do the bubbles with a texture... I'll go see if I can bang something out. The effect will be similar to Thief, except instead of a line of bubbles, it'll be a patch of bubbles where there's fewer and fewer as your air drops. Edit: Unfortunately, apparently alphatest only works if you have a depth buffer, which isn't the case with GUIs, so my idea didn't work. I'll see if I can come up with anything else. Edit 2: It occured to me that I may still be able to achieve this idea with the modelrender def...

--Go through the eye-height settings in the AI def files. Scratch that--save until later http://forums.thedarkmod.com/index.php?showt...opid=96927& --check out drumple's loading screen --What's needed to get weapon icons in-game? Check drumple's old hud.gui. - ok, names already in but need to be repositioned - after timedelay, names should transition off - after timedelay, icons should slide down to where text was and/or shrink Go ahead and put some concepts together for this, the code can be touched up later. --http://forums.thedarkmod.com/index.php?showtopic=4966 Actually there's an offset in weapon_arrow.def:

This is really hard to accomplish, as the click in the 3D view reflects a line and not a point as in the Orthoview. So, it's really ambiguous where you want to put the camera. I can't think of a good solution right now, but it would be possible to place the camera in the surrounding or the center of the brush/patch/object that has been clicked on.

I put another drive in, formatted and reinstalled windows. Installing visual studio now. I thought about something after I did most of this already.... I wonder if I could have just setup another user and had it working again ? Man wish I had thought of that sooner sigh. Probably would work. I should be able to work again on the mod by tomorrow, still have to finish the install, install msdn, patch up windows and vs, reinstall tortoise.

Chi Haotian, are most certainly on drugs? Regardless...I will further address your comments, as wacky as they may be. I'm not sure what you think TDM is, but we ARE a fan mission project of sorts. We're creating a toolset to make fan missions. We have beta mappers and internal test maps. How this would make our project more like TDS...I really have no idea how you would come to that conclusion, it makes no sense. Thief 2 had new people come on board...and that didn't ruin the game. It's just a matter of the companies being different and different leaders. I'm sure the team could have put out a much better game if circumstances had been different. Mods like this would never see the light of day if they didn't advertise for help. There is usually a small core group that sticks around, but then other members come and go. This turn over requires a lot of work to keep the level of productivity up. If we never recruited new members, the project would have been dead within months. We have plenty of people who have not been here from the beginning. It was certainly not a similar thing that ruined Deadly Shadows. Being made by a different company, making the game cross platform, poor management, that is what cursed TDS. We're not only trying to attract players, we need to attract Mappers more than anything, which is why we have beta mappers. There are also many people who have played Thief and have never visited TTLG. Aside from that, it doesn't take a Thief fan to make appropriate looking textures, it doesn't take a Thief fan to model a wooden chair....nor does it take a Thief fan to write the code for menus and much more. What it takes, is someone who is interested and dedicated enough to learn about the Thief series, and then put the time and effort into making these assets work within our design. We don't just accept any Sam or Sally off the street, we have an interview process where we evaluate whether or not their skills/style will work within the mod. I highly doubt it. We're constantly seeing people sign up who have only now heard about Dark Mod. Every person who has ever played Thief doesn't hang around message forums all the time.

But if publicity does attract people willing to help out, wouldn't accepting them make the TDM more like an FM project, or more like TDS? By accepting people thus attracted, TDM team risks getting people who haven't been there from the beginning and haven't grasped the depth of ideas that inspired the project from the start. Wasn't it a similar thing that ruined Thief: Deadly Shadows for so many who do not like it? As for attracting players for when the Mod is finished -- most of them are on TTLG forums, so making an announcement there on the day of release would be enough. As for gaining audience that would let the developers know that their work is appreciated and its results anticipated -- most of it is on these forums.

I just saw this on D3World forums, it's a mod for D3 inspired by Descent (for those who don't know, 6 degree of freedom ship-to-ship combat, but more focussed on enclosed environments than wide-open games like wing commander). Good to know that more D3 mods are still alive, and it's got a public beta for download, too: http://www.chmodoplusr.com/IntoCerberon/

Ah, here's were I explained that already. But I didn't have the part about pose tweaking, so I just added that. It's a stickied tutorial thread in the modelling forum. I should really Wiki-tize that. http://forums.thedarkmod.com/index.php?showtopic=3563

http://forums.thedarkmod.com/index.php?s=&am...ost&p=93484 & download the latest fbx importer. It might be on alias' site.

Ok, first things first. Here is a „small“ UML-diagramm showing the overall structure that I imagined for the renderer. Please note that this diagramm is incomplete and should be seen as a rought "sketch" of the final product. Most of the classes in this diagramm don't have all the needed Get/Set-Methods, you have to imagine them . Furthermore are all objects passed with call by reference, I omited the & and * chars for readability. CLICK ME As you can see it consits of 3 parts or modules: Cullsystem, does Culling and converts nodes to rendable objects Frontend, sorting and batching Backend, GL-state managment Some rules to make everything more solid: neither frontend nor cullsystem contain actual rendering commands, all rendering commands are done by the backend the backend is the only, i repeat ONLY part where OpenGL statechanges are allowed to happen neither frontend or backend have anything to do with classes like Brush, Patch etc. front- and backend only work with dataclasses that store triangles or represent a rendable mesh, nothing more. all openglresources are created by the backend Ok, lets get started: The Problem: The current renderer uses an outdated codepath to send geometry to the card (vertexarrays). Vertexarrays create very high cpu load and lots of pipeline delays. Everytime you do a glDraw call the driver has to loop over the arrays to check if the data has changed. Since we have to draw every object n+1 times when it gets hit by n lights, the workload sums up very quickly. The second problem is batching. Every draw call, even without the slow vertexarrays, is cpu intensive. This is an extreme problem in dx9 where a switch between kernel and userspace is done for each call and a moderate problem in opengl which stays in userspace all the time. The rule of thumb is that every draw call should atleast send 200 or more triangles down the pipe, the more the better. This is a realistic value for games which deal with optimized that but very utopic for radiant. The suggested solution: Switch to vertex buffer objects and/or displaylists for vertexstorage. Vertex buffer objects are a state of the art OpenGL extension and enables the application to store any data (not just vertices) on the graphicscard. VBOs support multiple usage patterns, including „change once, draw many times“, „change multiple times, but draw many times for each change“, „one draw for each change“ etc. Displaylists are an alternative, kind of old school way to store static vertexdata. When dealing with static meshes both solutions are equivalent. I would suggest to create a static VBO or displaylist for each static mesh and create a reference to this VBO for each instance, no vertexdata needs to be stored in sys memory then. Ok, that was easy, time to deal with the real problem: number of draw calls / batching. This is the part where the frontend kicks in, the frontend does the overall optimizations whereas the backend filters redundant state changes. The first thing the frontend should do is sort all static objects (meshes) by renderstate. This reduces the overall costs of uneccessary shader and texture switches. The next and more complicated job would be to fill a dynamic VBO with all brush and patch triangles needed for the current frame. The VBO should be filled in a „intelligent“ way, meaning that faces which use the same shader and get hit by at least one shared light get stored next to each other in the buffer. With this method all brush/patch-triangles still get send to the card each frame, but they only get send once and not for each draw call. Small example: Lets say we have 3 brushes and we render in textured-mode. All brushes have 2 faces with shader A, 2 with shader B and 2 with shader C. A „per brush“ drawmechanism would do this: foreach brush Switch to shader A Draw 4 triangles Switch to shader B Draw 4 triangles Switch to shader C Draw 4 triangles 9 draw calls and state changes My mechanism instead: Switch to shader A Draw 12 triangles Switch to shader B Draw 12 triangles Switch to shader C Draw 12 triangles 3 draw calls and state changes For lighting-mode things get a bit more ugly: The Depth-pass can ge done very quick, since this shader does not require any textures, the renderer can send the complete dynamicVBO to the card in one call, very fast. The problems start with the actual lighting of the scene. In order to do batching, faces with the same shader and the same lightinteraction (they get lit by this light) must lie next to each other in the dynamic VBO. Thats close to impossible to do in reallife scenes for all faces. However it could be done if the vertexdata is stored multiple times in the buffer, but I doubt that this waste of memory is worth the effort. The second way to avoid this would be a renderer that uses a hybrid approach of doom3-style and deferrered rendering. I won't go into details here since I haven't thought this through to the end, but I'm very optimistic. Ok, still have many more things to say (concerings shader handling for example) but my fingers hurt

Now that the search animation is relative to the origin bone, I have a problem with foot slipping, that I've been trying to sort out for 3 hours... The foot makes contact with the ground. You put a key frame on it. You want it to stay there while the body moves forward. So when the hips move forward (taking the foot with it, since it's a child) you move it back where it made contact with the ground, and put a key frame on it. So it should stay on the ground in the same spot whilst the body moves forward, right? Fucking NO. It does some weird arse slide forward and backward again between the two points, still starting and finishing in the same spot, but with a wierd slip forward and backwards in between... Adding "correctional" key frames to keep it still, winds up with you pretty much putting a key frame on every frame, and yet it still seems to wobble unsteadily, and this is a brutal, hacky, messy solution, that will be a nightmare to edit if I ever want to change the animation. Opening the FCurves window to see if the bezier curves are causing some problems doesn't seem to help. I've set those keyframes to be flat (no curves for the movement, for translation and rotation) and they still do it! There has got to be an easy solution to get feet to stop slipping. I've been reading about some arcane solution involving override clips or something, that I can't quite understand yet... surely there's some easy way to say "between these two keyframes, keep the foot HERE no matter what"? I'm going to post on CG Talk... *edit* http://forums.cgsociety.org/showthread.php...472#post4141472 I also posted links to example anims there.