Search the Community

Let me make a few clarifications, I am not calling for unbridled realism at the expense of every other factor. What my key example was intended to describe was how a very simple thing like the treatment of keys could inject just a dash of realism in a scene and my ultimate point was that lots of little details like that, made with lots of gradual little tweaks that aren't necessarily that time consuming when picked off one by one, can raise the bottom line of realism without massive overhauling of AI or textures or whatever the heck. Its true that real realism is impossible, but then my goal was never realism for its own sake. Rather, I look to good video games for what I call "cinematic moments" when my actions, the AI and/or environment, and my sense of suspended belief all come together to produce that magic that makes gaming truly addictive to me. Realism adds to these moments, never to a sense that the whole thing is real. Realism requires a level of suspended belief and it collapses when too much is asked of it. The difference for me is whether I finish the game or not. By addressing lots of "little realisms" I think that a lot of pressure can be taken off of the player to judge a game experience in terms of realism. Then, along with other things like action, strategy, using the environment, and especially storyline you get into the game easier, the unavoidable unrealities are mitigated a bit by the absence of a lot of smaller ones. Small stuff like food that tumbles off the plate when you steal it, plants that shake when you brush through them, are things I'm looking into. AI interactions, wonderfully adaptable in the Mod, can be tweaked to represent this as well. I'm sure there are limits due to practical matters of processor power and such but there has to be a lot of gray area too that can be "filled in" with details that aren't going to run down FPS or utterly fracture gameplay. Thats what I'm interested in.

Welcome to the Forums! I'm looking forward to hearing your visions about Radiant and your project. Ah, that surprises me a bit, but then again, I haven't been observing the GtkRadiant community a lot. Weren't there two more developers working on GtkRadiant lately? What about Shaderman? Wow, that sucks. I'm surprised that GtkRadiant 1.5 was even released under the GPL when no one seems to really care about the project. Not that I'd object... Sounds cool, I'm looking forward to hearing those. Well, that's nice! I actively started coding last September (after reading some tutorials), so there's a lot to learn for me, especially when it comes to OpenGL.

Sounds like there's a lot of things we can help each other with, even if our interests aren't completely identical. Hey, I've seen STiFU around... I think he's even on these forums occasionally. I'm supposedly part of The Cabal but I mostly just lurk nowadays. The Dark Mod has stolen me. Actually there's a bit of cross-pollination there - ascottk (who is currently our most prolific animator by far) made some AI models for The Cabal. We Thief fans are a tight-knit bunch. Glad to have you around!

Can someone point me to some good tutorials for drawing and rendering vegetation transparencies? I'd like to start working on the hedgerows idea I mentioned but I can't find much about making 2D plant images for LW8. BTW here is a cool link that was posted in the forums a long while back, its a great breakdown of LightWaves tool and some other links to plug ins and stuff. Thanks to oDDIty IIRC. http://www.suture.net/tutorials/modeling/index.php

Fix for sword joint distorting mesh: http://forums.thedarkmod.com/index.php?s=&am...ost&p=94397 original thread: http://forums.thedarkmod.com/index.php?s=&showtopic=5109

Don't worry about the water for now. There's actually a separate water physics mod by LLoyd that we incorporated into our codebase, so you can't do much without that. I think it's publicly available for download if you want to look, but again I wouldn't worry about it for now. Were some of your posts moved from somewhere else by any chance? I can't quite follow the last few posts or understand why you don't want to do this part anymore. It's fairly easy to test it using only the D3 SDK with the g_dragentity method. Just go to a map with a long drop or a high ceiling, make sure it does not have a brush that automatically kills anything at the bottom (some of the D3 maps have this to fake falling damage, but it's really just a kill-brush at the bottom). noclip and drag the AI up, drop it down, and see what happens.

I can't speak for anyone else, but I did look at the win32 program, and commented to that effect. I didn't elaborate because there's not much to elaborate on. The code looks fine to me. (Didn't test it.) I didn't look at the other one very much because I'm not familiar with the game or its plugin interface. As for testing your changes... I understand it's difficult without CVS access. The problem is that the team has been burned before by a "contributor" joining up, gaining access to all of the resources, and then stealing copies, leaving without actually contributing anything, and posting the files on the internet. So now it's a matter of policy that contributors don't get full access until they've submitted something. Nothing personal. This is why I suggested a scripting task to start off with, since you don't need CVS access for that - you can just use the beta mapper's alpha. Doing SDK work without CVS access is a bit of a pain. The beta mapper's alpha is here if you're interested, though it won't help you with the SDK since it contains no code apart from scripts: http://forums.thedarkmod.com/index.php?act=a...p;f=31&id=7 (I think you should be able to access that forum?) Still, you should be able to test this in vanilla D3. Make a simple room in the Doom 3 editor (there are a bunch of tutorials around on the internet - doom3world.org is a good place to start) with a really high roof. Start it up, press Ctrl-Alt-~ to display the console, type noclip, and toggle the console off again. Then fly up to the ceiling. Spawn a zombie (using the console, see http://au.gamespot.com/pc/action/doom3/hints.html for instructions) so that he falls down to the ground below. In vanilla D3, he will land there without taking damage. Your task is then to modify the SDK so that he dies if he falls from a great height. BTW, as for using your compiling SDK: I find that the easiest way is to take your compiled gamex86.dll file (should be in the releasedll or debugdll folder) and copy it to the root D3 directory (where DOOM3.EXE is). That way it overrides the DLL for *all* mods you have installed, so be sure to delete it if you install a mod - the Dark Mod, or any other mod.

The public forums are slow, sure - but the private ones are a buzz of activity, so there are people around. Personally I don't use IRC. I know from experience that if I do enter a chatroom, my productivity immediately drops to zero and stays there. Same with instant messaging. It's a distraction which I can't afford. Forums suck up a lot of my time too, but at least they don't interrupt!

Noblewoman: Female mitten hands New legs New AF http://forums.thedarkmod.com/index.php?showtopic=5050 Citywatch: Legs rigs fixed (not on cvs yet) - the lower legs needed to be weighted into the upper legs in the back.

I noticed about the .cdtproject files, and I know and swear that I removed them from the list of files to be committed, this has to be some TortoiseSVN weirdness. Anyways, now that the files are ignored, this should not happen again, sorry for that. I recently moved nearly all of the clipper-related functions into a ClipperManager class, afterwards it was easy to extract the methods that need to be defined in the interface, so it was more or less from scratch. However, there is one part of the clipper code (namely that doing the actual clipping using scene::walkers), that is not yet in the module because the brush/face interface classes aren't written so far. There are some BrushNode creations and face operations that I could not define them without changing many parts of the existing brush system (although admittedly, I tried to do this, ended up with changing almost every file in the brush/ folder but in the end I failed and reverted the changes). Ah, and one more thing: I didn't have a lucky hand naming the interface, global module and module implementation classes, so feel free to suggest some naming convention. At the moment the clipper interface is called "Clipper", the inlined accessor function "GlobalClipper()", and the actual implementation in the module is called "BrushClipper". Do we have some guidelines about this?

Just as a note, here is a link to a website trying to create a bank of common creative license sound effects. We may qualify for usage of some of the sounds. Also, the creators are attributed so we could track them down. Also, the forums have tons of discussions on the issues we are talking about here, with input from copyright attorneys etc... http://freesound.iua.upf.edu/

Having worked for companies that have seen patent and trademark lawsuits, this is not a small deal. If anyone with a lawyer thinks they can convince a jury in the US that their copyright was infringed, they will bring a suit to garnish wages from whomever of us have jobs. There are district courts in Texas that are very amenable to such cases, and they will be filed there. Note that all they have to do is convince a jury that their revenues may have been diminished... not that the party breaking copyright actually made any revenue. Also keep in mind that if any materials or planning related to copyright infringement were hosted on a service, such as these forums, they could go after them as well, so long as the country they are in has a copyright treaty with the US, which most countries do. Basically they will go after whomever has the deepest pockets. Please be careful about this as I don't want to have to drop off of the project for legal reasons. Yes, usually this just begins as a cease and desist letter, but you never know where it will go from there. What I would reccommend doing is using the collections of sounds as a basis for getting ideas on what types of things can be recorded. Sometimes you can listen to a sound effect and say.. ah, they are hitting a slinky with a ruler! (not that the sound is good if you do that). Also, as many of the people here do, I've got considerable experience with making sounds using combinations of synthesizers, trackers, filters, and effects in Buzz. If there are particular sounds we want, I may be able to make some using some simple samples and a bunch of effects.

Sounds good! Thanks! I would suggest placing pivot point in the opposite corner (or centre of edge) to the one you start dragging. And if you start in the middle of brush then the centre would be the pivot point. I'm not sure about the third dimension - usually in 3D applications you can have 2D and 3D scaling as separate tools (or tool variations).

I could think of a solution for this, which requires calculating the winding vertices of the brush and the proportional scaling applied to them instead to the face planes. During the drag operation the computed vertices can be used to calculate the actual face planes of the brush. The only difficulty would be to determine the direction of the scaling and its pivot point (don't know if that's the correct term), which may be ambiguous in some situation, but it should work.

Much sooner. 1.0 is the point at which DarkRadiant is considered "sufficient", although there is still plenty more to do after this. Possibly not, this will require investigation. These other shapes should ideally be drag resizable like any other brush.

I was chatting with namespace and Shaderman last night on IRC, I think they are basically Doom 3 which is good. We are so far ahead of GtkR for Doom 3 support that I don't think there will be much code worth merging, although namespace has written a new version of the OBJ export plugin which might be of interest. Shaderman also has an interesting feature which allows tagging of textures, so you can search for "all of the red textures" irrespective of how they are organised in the VFS tree (provided you have added the correct tags, there is no automated identification). I didn't ask what the precise political issues were, particularly in a public GtkRadiant channel, but I am fairly sure we will learn sooner or later.

You may want to look at this thread: http://forums.thedarkmod.com/index.php?showtopic=5035 There are new rigs for animations with heads & weapons for Maya & Motion Builder. Full body IK too.

All of the current AI now have full body ik for animation purposes. Included in the rar archive are files for maya (mb) and motion builder (fbx). There's a maya binary with no ik for fbx importing. Each character has their own folder with 3 files each. Original files: http://208.49.149.118/TheDarkMod/models/In...ask_animref.rar Updated citywatch (stand alone): http://208.49.149.118/TheDarkMod/models/In...tch_AnimRef.rar Files (AnimRef_idles are posed in the idle position): AnimRef_idle.mb (maya binary with full body ik - fbik) AnimRef_idle.fbx (motion builder with ik ready for animation) fbx_import.mb (af_posed ready for fbx importing with no ik) All character have their weapons & heads attached via parent constraints. The Maya version with fbik has floor contacts for the feet. Known Issues: When importing an fbx, the origin might be resized. Follow these directions in Maya: http://forums.thedarkmod.com/index.php?s=&am...ost&p=93477 The head & sword mesh might be off their original position in Motion Builder if exported from Maya. In Motion Builder use the Navigator window & double click the constraints. Uncheck "Active" then click the "Snap" button: This will align the mesh to their proper position. The head & sword mesh might be off in Maya. Delete the parent constraints in Maya, reposition meshes then reconstrain. You may also want to look at oDDity's Motion Builder tutorial: http://www.pixelwerks.be/pictures/MB_tut_01.avi The full body ik (humanIK1) in Maya is parented under the skeleton so if we need to move the origin for walking/running then the fbik will move with the whole thing:

Thanks! That's even better this way. I couldn't find them anywhere. Yes, it definitely would be better to have buttons for them. In most cases that's true but you can't scale prism and cones in any way... And converting brushes to cones gives them unpredictable size... Not to mention the case when you decide to scale some prism or cone brush after a while. So that's why I find scale tool necessary. Not a priority, but if it's easy to do then why not to do it while polishing the editor for first release...? ---- Another 2 questions: 1) is there any method of grouping brushes and/or entities? And operating on them together (like resizing etc...)? 2) on some video tutorial I heard about Shift+MMB shortcut for pasting copied texture without changing the texture alingment (unlike CTRL+Shift+MMB does). Is there any similiar function for that in Dark Radiant?

I just received a PM on TTLG from namespace, one of the GtkRadiant developers, who said that they have some issues (of the political variety) with the administration of the project and that he and a couple of other developers (Topsun and Shaderman) are going to be leaving. Namespace was very positive about the development (and documentation) of DarkRadiant and expressed an interest in working together to continue the Radiant legacy. I suggested that he register on these forums, and could perhaps get set up with permissions to view this forum so that discussion and cooperation could take place. What form such cooperation will take remains to be seen -- although namespace wishes to support older games, including a personal project, I mentioned our goals for modularising DarkRadiant so that other games could be supported via different plugins (rather than different code paths in the main executable).

Where can I find those selecting tools which are located on the icon bar in DoomEdit? Actually not only they are missing compared to Doomedit icon bar (Regions also and several more) - is it going to change or not? But those multiple selecting tools are very useful and I can't get access to them via any menu option... BTW - why does in model preview window camera is over the model by default instead of being in front of? This way I have to turn every model to see what it looks like... Also - I've noticed that scaling doesn't work. Wheter I use scale tool or arbitrary scaling the brush disappears...

It's a forum with an off-topic section and a thriving community (even if the community is mostly made up of members that hold most of their conversations in private forums - it's thriving behind the scenes!). These things will happen.

As the thread already exists, I can explain what the RegistryConnector class is about anyways: I extended the preferencesystem with some methods that allow the adding of widgets to the preference pages and connecting their values to the XMLRegistry values (by passing the according key). This way I moved the camera and the brush preferences into the registry. For example, one calls page.addEntry(, ); and the preference system does the rest. To actually connect the widgets I introduced the registryconnector which accepts the GtkObject* and the registryKey as argument. It internally maintains a list of all connected objects/widgets and loads/saves the values on demand. On calling "importValues()" the registry values are loaded into the widgets and converted where appropriate, on "exportValues()" they are saved back into the XMLRegistry. The import and export methods are called by Radiant's Dialog class, where I added such an RegistryConnector object as member variable. So, each dialog has such a RegistryConnector built-in and also provides the according methods to add connected widgets to the dialog. Before the modal dialog is shown, the importValues() method is called, and in the PostModal() function the values are exported into the registry (if the user pressed OK, that is, but this is a virtual method if I recall correctly, so this behaviour is customisable). I thought I post this here, as this could come in handy for general dialogs as well (one could add widgets that reflect preference settings in other dialogs than just the preference dialog window). Currently, text fields, checkboxes, sliders and dropdown lists are recognized, but this can easily be extended if anything else is needed.

Just to drop a note here: I messed something up with my recent brush changes. (I noticed too late that brushes aren't showing up anymore.) It has something to do with the brushmodule and I'm working on it, but it will take some time, because I'm too tired now. Sorry if this causes any problems, just be careful with revision 653. I tried to revert the committed changes, but somehow this doesn't work for all the files, just for a part of them. edit: Fixed. I confused min and max while copying and pasting...

Menu Issues: --check out updated fog swirl on mission_success and mission_failure. Possibly add an extra layer to the material -- replace 'back' text with Main Menu button -- add parchment for load/save screen -- sort out credit screen (low priority) -- create overlay for up/down arrows -- modify colour of text highlight -- explore Carelton scale--possibly need bold version -- confer with Ish about control functionality --look at mouseover effect for input 'box' http://forums.thedarkmod.com/index.php?showt...amp;#entry94984 As well: -- work on design of New Game screen