Search the Community

--check D3 zombie heads for useability, and for severed head model --fix reversed normals on revenant --add if (gui::ingame) statement to get resume game/quit game buttons functional http://forums.thedarkmod.com/index.php?showt...opid=95934& --fix the textures on the ghoul

You will need to run Doom 3 under Windows, so you may have to buy a copy. Should be pretty cheap now, I picked mine up for $20 Australian dollars (about $15 US dollars). I wouldn't mind seeing whatever code you do have, even if it's nothing particularly special. Just to establish that you can actually code. As for C++/OpenGL books, I don't know any I'm afraid. I usually look stuff up on the internet if I need to. This post may help with regard to OpenGL books: http://forums.thedarkmod.com/index.php?s=&am...ost&p=94636

I think arrows should be slow enough to be dodged, at least from a distance. As for accuracy, that is indeed a built-in D3 feature for missile weapons (as I discovered in that long long thread about the bottle-throwing ). I'm assuming the intention is for a coder to implement missile combat properly at some point, using an animation to fire the missile (similarly to how bottle-throwing works now), removing the need for the "fake melee" hack.

If you haven't managed to obtain a copy of Doom 3 how are we supposed to continue the application thread? Obviously the point of the application is to evaluate your fitness for the mod, and this means that you will be assigned a task that is stuiable to see if you are willing to work for the mod. And this means that the minimum requirement, for somebody applying as a programmer, is to have a copy of D3. Should be fairly simple to understand, right?

This thread has languished for two weeks now. What did I do wrong? Looking back through the thread, I noticed that Crispy stated that I didn't have any sample code (how did I miss THAT?), which simply isn't true. I have plenty of code from school projects--it's simply that I'm not much proud of them (I'd like to clean them up, minimally). As for the Doom 3 SDK, I haven't been able to find my copy of D3 anywhere. A hallmate of mine has a copy on his external hard drive I could borrow, at least until I find mine or get a new one. As his hard drive is ext2, are there any problems with using Linux for TDM (especially since I don't have a Windows C++ compiler)? Finally, I'm making a trip by the bookstore for textbooks on Friday; can anyone recommend a good C++ and/or OpenGL book I could use?

So I guess this isn't going to happen. Maybe next 'return.' It'd really be nice to be able to get at these without having to download 5G. Yes, you can get at the occasional texture here or there from an individual volume, but 90%+ of them are spanned and can't be opened that way. The majority (edit: reword) aren't very usable from what I've seen, and I'd just as soon look elsewhere (or not do textures) than download 5G (hoping I can even extract the archive at all) just to get at a few gems.

Ok been working on the mouse hook for the last couple of hours. Reason being, it doesn't work! Sigh. I verify that we get a valid handle back as I exit if we don't using Exit of course. Then I tried putting in an Exit call at the start of the callback but it never gets called. I tried the low level one but that doesn't work either. Strange that the keyboard hook gets called but the mouse does not as they are practically exactly the same. I tried setting it to the module instead of the thread and that does not make a difference. I have more stuff to try to get this working, I have to get to bed now but I will try working on it again tomorrow night.

#1. An interior factory scene. Boilers, gears, molten metal being poured from huge tubs, etc. Perhaps some huge gears and clockwork machinery in the background. #2. An exterior of a grand cathedral, with tall towers, stained glass windows and metal buttresses. It should incorporate the builder hammer symbol (second post down) . The perspective should be looking up from near ground level. http://forums.thedarkmod.com/index.php?showt...=3118&st=75 #3. An exterior castle scene. Fairly close and looking up, something like this: http://www.thief-thecircle.com/thief3/show...castle_high.jpg It is easier to position them if there isn't an obvious border at the edges--more like the one in the example I posted above (though I know that may not always work).

I adjusted the feet (try to keep them stationary while the rest of the body moves) according to the origin's movement. Don't you mean the fbik "character" (humanIK, fbik controllers?)? I parented the fbik to the origin for a reason:http://forums.thedarkmod.com/index.php?s=&am...ost&p=94761 If the fbik is unparented from the origin then the whole body will not move if you need AI to move in a walk cycle. They'll walk in place if the origin doesn't move. Stationary animations won't be affected if you want stationary animations (idling, sitting, etc.). What I did in maya, is delete all the keyframes relating to the hips, then moving the origin along the x axis (if you're going forwards or backwards, z axis if you are going sideways).

Actually I think it is my code: Thread [1] (Suspended: Signal 'SIGSEGV' received. Description: Segmentation fault.) 14 visit() at /DarkRadiant/radiant/ui/einspector/EntityInspector.cpp:469 0x08155e7a 13 EntityKeyValues::forEachKeyValue() at /DarkRadiant/libs/entitylib.h:693 0xb6201199 12 ui::EntityInspector::refreshTreeModel() at /DarkRadiant/radiant/ui/einspector/EntityInspector.cpp:477 0x08156f3c 11 ui::EntityInspector::callbackRedraw() at /DarkRadiant/radiant/ui/einspector/EntityInspector.cpp:243 0x08156fce 10 Member<ui::EntityInspector, void, &() at /DarkRadiant/libs/generic/functional.h:13 0x0815803b 9 BindFirstOpaque<Member<ui::EntityInspector, void, &() at /DarkRadiant/libs/generic/callback.h:120 0x08158057 8 Callback0<void>::operator() at /DarkRadiant/libs/generic/callback.h:282 0x08089d1e 7 IdleDraw::draw() at /DarkRadiant/libs/gtkutil/idledraw.h:35 0x08089d35 6 g_child_watch_add() 0xb7e75bf2 5 g_main_context_dispatch() 0xb7e738d6 4 g_main_context_check() 0xb7e76996 3 g_main_loop_run() 0xb7e76cb8 2 gtk_main() 0xb7b76765 1 main() at /DarkRadiant/radiant/main.cpp:546 0x08099721 I may have made a typo when cleaning up, investigating.

I was under the impression that once we release TDM, it'll be ok for anybody to use our assets, so long as they put all their assets under the same license and all their code under the GPL (allowing other people to use their assets/code), which would help the community of modders who share their work, regardless of the engine or genre of their mod. This is the first I've heard of our assets being for "TDM only"... perhaps we should start a discussion thread about it? <continued here>

My contrgratulations! Reading this thread was like thrilling detective story with two detectives and one well hiden criminalist...

I was hoping my post would at least take the thread in a slightly new direction, but so far it appears to have been entirely ignored...

This isn't the first thread on the subject, and I doubt it will be the last.

This thread reminds me of a pack of dogs chasing their own tails. Around, and around, and around, and around, and around... (Seriously, somebody has to do the right thing and stop this or the thread will be 20 pages long and there still won't be any new arguments in it. )

Ok well as soon as i read which animation Springheel assigned me to, i was in the mood to do some animating First draft of Failed KO: http://208.49.149.118/TheDarkMod/movies/anim_FailedKO_00.avi

De-railed. We could move it to that other thread I made. Well, Brian said that animation was one of the most intensive things the engine does. As for the number of frames, I think its the funamental tradeoff between processor time and storage space. If you only stored the keyframes in the anims, the file size would be smaller, but the game would have to interpolate and create the mesh deformations on the fly, which would take more processing power.

Needless to say - for those of us who like to play games that way. We shouldn't have to add that on the end of everything to avoid backlash of some sort. I'd like to think it's pretty obvious by now that this is definetly one of those things that is personal preference, like choosing wether or not to invert the Y axis. Though if people were having fun just pulling apart each others arguments in good fun, they should go right ahead, and we should take the save zone discussion to another thread.

From the other thread: I looked briefly at the md5 importer for Blender, and don't have much hope for it. Even if I did get it to work, I'd be willing to bet it doesn't preserve UV maps. So, to any modelers who might know: is that really so tragic as it sounds? Can the old UV map just be "reapplied" to a modified and exported model?

What would be needed to do this? I believe Blender has a md5 importer, but surely that doesn't include the UV. And I assume, screwing up/losing the UV would set things back so far that it's not worth it. And personally, I'd rather not have to use LW - I don't have it, don't know it, and don't care to learn it - Blender is tricky enough. Any modellers have input on this topic? Should we use a separate thread for this?

I get a segfault with the latest build (checked in today). Here is the stacktrace: Thread [1] (Suspended: Signal 'SIGSEGV' received. Description: Segmentation fault.) 31 std::string::compare() 0xb76059dc 30 std::operator< <char, std::char_traits<char>, std::allocator<char> >() at /usr/include/c++/4.0.3/bits/basic_string.h:2208 0xb710f0ac 29 std::less<std::string const>::operator() at /usr/include/c++/4.0.3/bits/stl_function.h:227 0xb710f0da 28 std::_Rb_tree<std::string const, std::pair<std::string const, unsigned int>, std::_Select1st<std::pair<std::string const, unsigned int> >, std::less<std::string const>, std::allocator<std::pair<std::string const, unsigned int> > >::find() at /usr/include/c++/4.0.3/bits/stl_tree.h:1135 0xb711a65b 27 std::map<std::string const, unsigned int, std::less<std::string const>, std::allocator<std::pair<std::string const, unsigned int> > >::find() at /usr/include/c++/4.0.3/bits/stl_map.h:498 0xb711a753 26 Modifiers::getModifierBitIndex() at DarkRadiant/plugins/eventmanager/Modifiers.cpp:104 0xb7117da7 25 Modifiers::getModifierFlags() at DarkRadiant/plugins/eventmanager/Modifiers.cpp:69 0xb7119159 24 EventManager::addAccelerator() at DarkRadiant/plugins/eventmanager/EventManager.cpp:111 0xb7111c41 23 Brush_registerCommands() at DarkRadiant/radiant/brushmanip.cpp:1166 0x080613a2 22 BrushModuleClass::construct() at DarkRadiant/radiant/brush/BrushModule.cpp:67 0x08210f00 21 BrushDoom3API() at DarkRadiant/radiant/brush/BrushModule.cpp:173 0x082126ed 20 DefaultAPIConstructor<BrushDoom3API, BrushDependencies>::constructAPI() at DarkRadiant/libs/modulesystem/singletonmodule.h:42 0x08212771 19 SingletonModule<BrushDoom3API, BrushDependencies, DefaultAPIConstructor<BrushDoom3API, BrushDependencies> >::capture() at DarkRadiant/libs/modulesystem/singletonmodule.h:124 0x08212d56 18 SingletonModuleRef<BrushCreator>::capture() at DarkRadiant/include/modulesystem.h:204 0xb6fd92a6 17 GlobalModuleRef() at DarkRadiant/include/modulesystem.h:246 0xb6fdb116 16 MapDoom3Dependencies() at DarkRadiant/plugins/mapdoom3/mapdoom3.cpp:58 0xb6fdc6dd 15 SingletonModule<MapDoom3API, MapDoom3Dependencies, DependenciesAPIConstructor<MapDoom3API, MapDoom3Dependencies> >::capture() at DarkRadiant/libs/modulesystem/singletonmodule.h:120 0xb6fdeb23 14 ModulesMap<MapFormat>::insert() at DarkRadiant/libs/modulesystem/modulesmap.h:58 0x080f45d2 13 ModulesRef() at DarkRadiant/libs/modulesystem/modulesmap.h:145 0x080f4804 12 ReferenceDependencies() at DarkRadiant/radiant/referencecache.cpp:818 0x08112539 11 SingletonModule<ReferenceAPI, ReferenceDependencies, DefaultAPIConstructor<ReferenceAPI, ReferenceDependencies> >::capture() at DarkRadiant/libs/modulesystem/singletonmodule.h:120 0x08112a87 10 SingletonModuleRef<ReferenceCache>::capture() at DarkRadiant/include/modulesystem.h:204 0xb628534e 9 GlobalModuleRef() at DarkRadiant/include/modulesystem.h:246 0xb62867f2 8 EntityDependencies() at DarkRadiant/plugins/entity/plugin.cpp:62 0xb62872fa 7 SingletonModule<EntityDoom3API, EntityDependencies, DefaultAPIConstructor<EntityDoom3API, EntityDependencies> >::capture() at DarkRadiant/libs/modulesystem/singletonmodule.h:120 0xb6287557 6 SingletonModuleRef<EntityCreator>::capture() at DarkRadiant/include/modulesystem.h:204 0x080efc00 5 GlobalModuleRef() at DarkRadiant/include/modulesystem.h:246 0x080f26b4 4 RadiantDependencies() at DarkRadiant/radiant/plugin.cpp:227 0x080f4de4 3 Radiant_Construct() at DarkRadiant/radiant/plugin.cpp:326 0x080ed8dc 2 Radiant_Initialise() at DarkRadiant/radiant/mainframe.cpp:669 0x080a4b37 1 main() at DarkRadiant/radiant/main.cpp:529 0x08099294 For some reason there seems to be a gap in the callstack between this in Brush_registerCommands(): GlobalEventManager().addCommand("BrushPrism", BrushPrefab::SetCaller(g_brushprism)); and EventManager::addAccelerator(), which seems to be called with two unitialised strings. I am not sure why this is, as I would expect there to be a stack entry for EventManager::addCommand() which is what is actually being called, but GDB's usefulness does seem to degrade over time so maybe it is just missing stuff out.

It doesn't seem that hard to add a step that tags triangles as transparent--to specifically be ordered from back to front. For the most part, modern engines order polygons front-to-back for culling purposes, although a lot (and I am beginning to suspect D3E) just throw the whole mess at the graphics card for it to work out. By the ways, that picture is fugly--c'mon, ordering isn't that hard, nor is it that resource/time consuming! Every damn frame has to be ordered one way or the other before it can be rendered! Graphics cards order everything front-to-back for culling purposes, and they reorder everything back-to-front (or rather, that which remains) for texturing! It can't be that fucking hard! Edit: As for shadows, probably the best performing way to get a reasonable facsimile of shadowing would be to use a projected texture of the surface, with the alpha map acting as a measure of intensity (transparent for full light, and opaque for none). Well implemented, I don't think that it would look any worse, that is, less realistic, than Doom 3's lighting. I'm a bit fuzzy on how stencil shadows are any different than projected shadows (with the notable exception of the stencil itself), so I don't know how compatible projected textures are with volumetric shadows. Anyways, you can turn off shadowing on the triangles that have that have alpha. Either I'm missing something important, or Carmack is bitching over something that would take a week at most to implement and makes for so much better usability.

Here's some tweaks I did to the model: I thought the legs looked too skinny so I resized the thighs and the lower leg coming out of the boot. (Oops, the legs are clipping out of his tunic . . . ) Don't pay attention to the textures since this is a cheap maya render. Here's the original mesh before the tweaks: http://forums.thedarkmod.com/index.php?act=A...ost&id=1195

Keep track of new AIs to put into game: big thug, diego thug, & houseguard. Diego's thug (needs textures): http://forums.thedarkmod.com/index.php?showtopic=5146 Houseguard (on cvs): http://forums.thedarkmod.com/index.php?showtopic=1455 Big thug (major setback, I deleted his textures ): http://forums.thedarkmod.com/index.php?showtopic=5123

My big thug thread has added two other models & I made a separate thread to discuss Diego's thug. There are no textures for him yet. Model: UVW map: The 3ds max model has two versions: one high poly & one low poly that needs to be triangulated.