Search the Community

Hmmm, I guess not. I'd take the money, but having my name on the credits would be best, and a written reference is completely useless for my line of work. Good luck with the game though. I love the Master of Orion feel you've sunk into it.

It is unfortunate, but the reason we will not make a v1.0 release at the end of the year is because we are not done just yet - vine arrows are not yet implemented, among other things. Not to mention the hours and hours required of testing and tweaking. But, as we've said on numerous occasions, we will release as soon as it is done. We could release tomorrow or today of course, however, we want v1.0 to be as bug free and complete as possible. We'd like to avoid the scenario of releasing v1.0 and then releasing 15 other patches to fix things, like T3 had to. On the plus side, things are moving at quite a pace right now Greebo is pulling off a ridiculous amount of code work, and is atm by far the most productive team member. He deserves the embarrassment credit

I've heard of that one, OGRE is another popular scenegraph engine. The problem with all of these is that integrating a third-party scenegraph engine into DR would be as much (or more) work than simply rewriting the DR renderer. The end result might possibly be superior though.

Maybe worth a try. Might need to be not in a secret room but rendered out of sight - even one unit by one unit. @greebo : BTW this makes me think the gui cannot know about the title content from the xdata and so that other idea for varying the body top position probably cannot work. Still have Plan B

In no particular order, the well-known shows I watch which are still current are: Doctor Who, Battlestar Galactica, Heroes. Yes there is a pattern here. Last Exile and Noir get standout mentions as far as anime is concerned... plus most of Miyazaki's work (the elder, not the son) if we're counting movies.

Yes, basically. The scale option determines the size of the animation, and the animation dictates the size of the AI *when playing that animation*. It appears that D3 takes the animation data and applies it relative to the origin point, not relative to each individual joint. So if a neck joint is 84 units high in the exported animation file, then that's how high it will be when the animation is played, regardless of how high that joint is in the md5mesh file. Animations don't *have* to be exported to suit a particular AI (as I used to believe). There's no reason why the .def files of all our AI (those using the same skeleton, anyway) couldn't point directly to a single set of md5anim files. The only consequence would be that all our AI would then be the same size. What I'm proposing is a slightly more flexible version of that. Instead of making individual exports for each AI, we make 4 sets of exported animations, each at a slightly different size. We have four folders--"Very Tall", "Tall", "Average", and "Short", and each folder has a full set of exported animation files, using different scale options (eventually I'd like to do the same, separately, for the female characters, when we get that far). Then, we make individual entitydefs for each AI that point to the different folders. We'd have a tdm_ai_citywatch_verytall, tdm_ai_citywatch_short, etc. This way new animations only need to be exported 4 times, rather than once per character. Each character would need 2 or 3 md5mesh files, rather than just 1, but compared to the number of animation files we'd be saving, that's nothing. Additionally, the entire part of the def file that points to animations can be copied and pasted to new AI with no fuss. I'll create a testcase...if it doesn't work for some reason we won't have lost anything. The only difficult part is deciding exactly what scale value results in the right size AI. On that note, can you confirm that all the raw animation files in the citywatch_mb folder are the same scale? In other words, are your new maya animations the same size as the 'old' maya/motionbuilder animations?

Good to know that the work wasn't all in vain. Once any problems with the autotools build script are ironed out, I will retire the scons build system altogether, since it will not be needed and has only ever caused problems.

Nice work. However, in other applications that use this, configure is prebuild, so you can skip the very first step. Is it possible to do the same for darkradiant? On my PC I am missing many packages just to run autogen.sh so I'd be grateful if that could be run and configure just checked into the SVN

Hi, Am looking to get a new computer, not the newest as I can only afford so much, but am wanting a computer that will be able to run the darkmod, which means it needs to run Doom3 I guess. One of the computers I'm looking at has this as video NVIDIA GeForce 6100 and nForce 430 MCP I'm kinda ignorant about this stuff and did not see this geoforce on the side of the Doom3 box. OS is Vista Home Premium Others are: Graphics: Intel Graphics Media Accelerator 950 Graphics Card PNY Geforce FX 5500 (PCI) Hate to bother you about this, but sure could help me. Hate to put out any money and not have it work the game! Thanks!

So sorry to bother you about this but was wondering about this card ATI Radeon X850XT From what I read it seems as if the card takes a AGP slot, but I thought the same name card can apply to different type slots. THe computer I'm looking at is a used dell 9100, 2.8 GHz Intel4 processor; Bus speed 800MHz, RAM 1 GB ( 4GB max),above card - and here is what I think you are saying is most important: as said.. "Expansion slots: 4 Memory, 3 PCI, 1 PCI Express x1, 1 PCI Express x 16,1" - though I am not sure what the "x16, 1" means. I'm a biologist, what can I say! : ) My 15 year old daughter is wanting to do a project this summer while out of school; she loves Theif, and has been fooling around with Dromed, but just begining. I was thinking with the development of the DarkMod, it may be good for her to start trying to learn that, with the tutoring available online. Got the Doom3 game, so just need to get an extra computer. Dont want to put some money out for one, where it cant work the game. Thanks again

Not to sidetrack the issue, but just as a helper: be aware that DR recently got "Save Copy as" which would help here. You work on your map as usual, and then when you reach a revision, you Save Copy as [revision name, e.g., mymap23], and then keep working on the original name [mymap]. No need to change script name.

I'm not convinced I'm going to be able to use the Lightwave Md5Mesh exporter for everything I'd like to do...it just isn't widely used, so support or technical questions generally don't get answered. Additionally, it is incompatible with the Maya method, so any changes I make to things become difficult for anyone else to edit. So, I'm basically going to need to learn how to rig in Maya, and hope that I can do most of the actual modeling in Lightwave. I'm not excited about trying to figure out a totally new modeling program...I feel like I've only just gotten comfortable with Lightwave. I'm going through tutorials and videos, but I'm bound to have a lot of newb questions that they assume people already know. 1. In Lightwave, you can make a weightmap for a mesh even if there is no skeleton present--the weightmap will automatically work with any skeleton you import as long as the names of the joints match the names of the weightmap. Is this also possible with Maya? If so, how do you see what a vert is weighted to when no skeleton is present? 2. Is "model_src/ai_parts_mb svn folder called "tdm_rig_base.mb". (taken from the wiki)" still the default skeleton we are using for TDM AI? 3. And a really newb question...how do you view layers in Maya? 4. Is there a good md5mesh importer for Maya 7.0?

Dude you saved my life. that worked. im working on a map i really like and if i didnt get this to work i was goin to freak. i owe you one man. thanks

Um.... I just noticed that all the new animations were not exported with a "scale" keyword (actually, they look like they were just copied directly from one folder to another). That means that they are the same size as the original citywatch animations. This means that when the Thief plays any of those animations, he becomes the same size as the citywatch. Originally, he was considerably shorter (and he still is, when he plays any of the old animations, like "look_around"). The def file shows a "scale" keyword of from -90 to -94 on several animations. The new animations, however, are not even in the def file. They need to be exported with a scale keyword to work properly. This will also affect the beggar character, who uses the Thief animations. It may also be an issue for the builder priest, who appears to be the same size as the citywatch as well.

I was just reporting an issue about a possible memory leak in texture loading and/or flushing when it occurred to me, "do these numbers make sense?" Rather than assume something's wrong and report it, I wanted to get some feedback first. If you open the issue mentioned above, see that an example run (open Media tab, load all bricks textures, then go to the Textures tab (no need to scroll it)), produces the following typical memory demands (Mb, total): 150 -> 267 -> 330 After the baseline 150, loading all of the bricks textures consumes 117 Mb. Opening the Textures tab then consumes another 63 Mb. Does this make sense? I don't presume to know what's going on behind the scenes, all the file and memory handling, etc., but I only ask because from the outside, I'm guessing there could be something amiss. Here's why: the _ed.jpgs in that folder, numbering 58 in total, are only 1.21 Mb in size, total. If you consider their memory imprint, PSP reports the typical image (256X256) as consuming 192kb of memory. Multiplying 58 files X 192 kb gives a little less than 12Mb total. Does this make sense, considering the 117 Mb result of loading them, and then the 63 Mb more required for the Textures tab? I know DoomEd is a completely different beast, but check this out; it handles the task with much less memory (this is in Kb, because I needed to go down to that resolution; you'll see why): 138,140 -> 139,428 (!) -> 228,920 Admittedly, "loading" (step 2) of the textures could be a completely different action in DoomEd and DR. Whatever it is though, it takes only 1288Kb of memory! Recognize that number? It's very much like the 1.21Mb size on disk. So it's easy to assume DoomEd loads them and leaves them in compressed jpg form. Then, opening the Textures tab takes about 90Mb. So perhaps that much really is necessary to display images (hey, what do I know). But the end result is: Doom3 loaded and displayed them in about 90Mb, while DR did it in double that, 180Mb. That number is very suspicious. Hypotheses 1, 2: Could the images be redundantly doubled in DR's memory handling? Or, could DR be failing to make use of video card memory? Once again, I only raise this because of the disparity in behavior and the suspiciousness of it all. If something is found in the speculation above, and fixed, it may halve DR's memory reqs! Edit: Further info: if I load the images in DR one by one while watching memory, it can be deduced that it sets a few Mb aside, loads some textures into it, sets a few more aside, and repeat (standard stuff). This is because you can load four or so materials in a row with only very small changes in memory. Then, it jumps perhaps 6Mb, and repeats. But sometimes, it jumps 6Mb, then another 4Mb, then a bit more, then goes back to small jumps. I've checked images which were causing this and they do use the small versions, so there's nothing suspicious about them. Hm. I also note that the average diffuse size in that same brick folder is ~1.7Mb. That, times 50 files = almost 90Mb; half of the DR req, and all of the D3 req. If the other crazy notion from above (redundant copy in memory) is completely batty, here's another highly unlikely one, Hypothesis 3: could DR be loading the JPGs as intended, but actually allocating memory for them based on the diffuse sizes? Far out, I know, but it doesn't sound quite so crazy if you think about that DR knows the dimensions of the diffuse image (shown in the Media tab, material description) from somewhere. If it's only loading a low res _ed version (256^2), how does it know the actual diffuse is 1024^2, unless it actually inspects it? And so, the leap: could this be the cause of such a problem, resulting from leftover/legacy/WIP material loading from way back in GTK's development, which was never quite brought up to date? Anyway, just more black box speculation. It has occasionally led to interesting discoveries at work. Edit: Maybe it IS that! After I posted here, I did some stuff with photoshop, firefox was already open, etc., i.e., it screwed with my windows page file. I tabbed back to DR, and noticed that its old memory imprint (~400Mb) was now only ~115Mb. So, I guess windows put it into 'low need' mode. My speculation is that makes DR's memory situation much more... sensitive, to new changes. Most of it is being paged, so if I load new textures, it will have a full, very apparent effect on the memory imprint. And lo and behold, it did! With all of wood/boards and wood/panels loaded (previous experiment), I went to stone/natural. And son of a bitch, every 512^2 material I loaded changed the memory imprint by 1.4Mb! Every 1024^2 material, 4Mb! This is right in line with the size of the full diffuses. What's going on here? If it's only loading a 19kb (disk size) file requiring 192kb of memory, why does it allocate (and use?) 1.4Mb? 4Mb? I have confirmed that it is in fact the _ed versions showing in the editor (I defaced only the _ed version ), but the memory it uses is that of the full sized diffuse! ?!

If it's the same as the non-editor, full version of the file, something's got to be wrong somewhere, or editor versions make no sense / offer no benefit. In fact, they offer detriment, because they look worse, are extra work, and use extra files / HD space. The same files loaded up in DoomEd use a fraction of space too, so that's more evidence something is wrong. Finally, DR behaves sporadically in this matter, sometimes acting just like DoomEd (tiny allocs at a time) and other times, huge spikes in memory for no apparent reason. Anyway, it seems pretty much accepted that something is amiss.

Team members have a "darkmod" folder which is in the root Doom 3 folder. It has the standard layout for a D3 mod; maps are in maps/, textures are in textures/, sounds are in sounds/, etc. This is, I imagine, how we'll distribute the mod when it comes out. Thief's Den is essentially a copy of this folder, but with most of the assets (anything not used in TD) removed and with changes to the GUI to hardcode the starting map and so on. The mission loader code is bypassed since we didn't need it. For example, tdm_launcher.exe is missing, as you've noticed. You probably could create a "mod of a mod" using TD; obviously you'd need to restrict yourself to the assets used in TD since no others are yet available. And the GUI is hardcoded, so you'd have to use the "map" console command to start a map rather than clicking on buttons. But as a proof of concept for the purposes of testing GarrettLoader I don't see why it shouldn't more-or-less work. Just rename the thiefs_den folder to darkmod, and place the FM in its own subdirectory of D3 as I described earlier.

I take it that the tdm_launcher wasn't in the thiefs den demo as I can't find it on my pc. Anyway I did a slight adjustment to the code in GL and it will work now on the thiefs den demo (seen as a mod in itself) and hopefully any future mods of TDM (seen as an expansion pack), using the command details joebarnin mentioned. I'm just finishing off some of the help files in GLs help and then I'll post a link to a download of a test version of GL (it will just be a patch rather than a full install). I'm curious as to the folder structure of TDM. If I was to take thiefs dens files and move them about (obviously not randomly) could I create the same folder structure as TDM uses? If so which files and where should they go? The reason I ask is I would like to see how the actual final version will be laid out and how the FM zips will be structured (I'm guessing that not all the required files were in the TD demo) and indeed if there were any other test FMs available if they could be installable and run via GL.

I made a letter using a handwritten font but not quite enough room so I did a new gui so the body starts at the top and left the title blank. It occurred to me that this might be commonly needed but would double up every gui. Might there be value in doing all the readables guis like this by default? The title space and font still exists but unused. When a title is needed the mapper just puts \n\n\n at the start of his body text. Is it possible to have any font control from the xdata? I've searched the net before for xdata info but I think it is a common variable name in some languages so results get flooded with those. The wiki articles don't give a lot of info and I suspect there is more somewhere. I did find a colour control for about 16 colours but they are one line only and over bright, virtually luminous, for our needs. Wiki down at the moment so can't check what's there. No it's not - I left my firewall locked during an overnight virus scan. Line spacing distance seems to be built into the font unfortunately with a small font size yet wastes line space - almost looks double spaced. Can't recall if I'm using popsie or everett but I'm inclined to increase the font size. Trouble is, it looks so real, like when you try to read real handwriting. That might be good for special cases where you want the player to struggle a minute to make out the whereabouts of a secret crypt but probably not for general use. Can't recall if multi- page readables work yet - fairly sure they do but suit only books. Maybe we need a 'multi-sheets of parchment' model and inventory icon to represent several sheets. Not even tried mixing with graphics yet, would font position vary with screen res? - will be easier to do a custom background like a map and probably the way to go. It's probably not such a big deal to have a few like that in a map zip.

There are a number of things included in our mission launcher which weren't used for Thief's Den--you may find that missions don't work entirely the same way. The biggest issue with missions is making sure that the mission files become the default files--if someone makes an alternate version of a model or texture for their mission, you want to make sure the mission uses their version of the file, not the default TDM version. That's why our built-in loader essentially treats each mission as a separate mod. Just loading the map itself would not be enough.

Will all the FMs contain a darkmod.pk4 or will that be a core install? Just in regards to that, I have got GarrettLoader to extract to the root Doom 3 folder (under the thiefs_den folder in this instance) then it will shell doom3.exe with the following command replacing the install path with whatever it should be and the thiefs_den with the pk4 of the detected FM (GL looks inside the PK4 to find the map file to determine which should be the launch map). This may not work properly for multi map FMs but works fine for single ones.

Now the guards of Bridgeport will receive the recommended acceptable daily intake of Omega-3 and be fitter, healthier and happier! That's some amazing blue tinting there. Is there seriously a type of edible fish that's that blue? (not questioning your work, just expressing amazement ) <--- is clueless about fish

A friend of mine used to live in an house with such an old elevator (they had to keep it, bcause it was under protection because it was so old). When you pressed the button in the middle of nowhere it simple stopped or changed direction. That was because the buttons were actullay the metal contacts, so when you changed them, the electric currency flew different obviously and reacted accordingly. Of course no modern elevator would do this anymore, because they usually are designed in such a way that they finish their current move. For gameplay purposes I don't think it a good idea to allow AI to reverse the direction. It's quite easy for an AI to trap a player in this way, and there is no way out even if the player didn't do anything wrong. Adding an option to allow the mapper to decide this is also not a good idea, because the player should know how the world works. It would be quite inconsistent for no obvious reason if elevators work sometimes this way and sometimes that way. Also if AI could recall an elevator just like that, then the elevators would become essentially useless, because players cant trust them so they would avoid them. And since there is no way a player can observer properly if an AI is about to call an elevator (not even talking about a getaway with it) only beginners would use them until they learn that they are useless.

It's possible for me to add a spawnarg which puts it in the hands of the mapper whether guards can call back elevators or not. I'd have to check again, but I think that's feasible within a reasonable timespan. Also, I could change the elevator code a bit to make the un-interruptable. But this needs a tad more work.

I have no problem with an AI calling back an elevator if the player is stupid enough to run into one in plain sight. One issue that hadn't occurred to me before, however, would be the possibility of players *who haven't alerted any guards* getting into a seemingly unused elevator, get half-way down to the basement, and then have the elevator called up to the top floor where a patrolling guard suddenly wants to use it. The player is essentially trapped and doomed to be discovered without having done anything wrong. You could argue that players should case elevators quite carefully to make sure they aren't being used by a patrolling guard, but that's not easy to do. I'm loathe to suggest changes that would require greebo to do even more work on this, however.