Search the Community

Thanks for the feedback guys. I will base the real sword drawing anim on #2 then. Sneaksie, this is the thread where I demonstrated the sword is too long. http://forums.thedarkmod.com/index.php?showtopic=3195 We concluded you'd be pulling back the frog to pull it the rest of the way out, but you can't do that with this model. I'm sure in real life you can draw a longer sword, but there are some (quite reasonable) physical restrictions on this rig.

THe player will be able to drop everything. Zylon may remember I had this exact argument on the Ion forums for T3, which turned into a bit of the flamewar. The T3 team were a bunch of worthless cunts, but we aren't, and we'll be doing it the right way this time. FM authors will be able to flag certain iems as undroppable, if they are essential for the mission, at all other times the player will not be forced to carry redundant equipment. THis should rarely be necessary, FM authors should not have to stoop to such hamfisted methods as making tems undroppable, they should make it clear in readables or other clues if a certain widget is needed for a certain door.

Hehe, that issue is a drop in the ocean compared to what is going on in the dev forums right now, on the related issue I mentioned. Not to worry, it'll get sorted soon, it always does.

A major issue is how to code it. When Doom 3 is released under GPL, several things can be recosnidered and made better, but for now it would be pretty timeconsuming (in terms of performance) to do this.

So the biggest loss is due to animated lights? I'm really thinking about the "have to check ALL lights in the level" part, because this means the check will be increasingly slower depending on the size and complexity of the level. This may still be irrelevant, but what if we made our own light entity that inherits a real Doom 3 light, but also provides the additional information we need to cull out the lights that don't affect the player?

The distance check is faster, because otherwise the check is much more complicated. For the actual calculation the distance is irrelevant because I need to calculate the intersection of the lightcone with the player to get the coordinates of the falloff texture. To properly calculate the lightvalue, I would then have to loop over the intersection are of the player, and calculate the average. I didn't implement this anymore though, because it will not work anyway. In order to get the correct values, the animation also would have to be taken into account. Once we have the sourcecode this should be easy, because we could preserve this information somehwere, but currently this information is lost, and we would have to reconstruct it, which means, that we would have to implement the full lightscripting language. So we would need a parser for that, and then we would need to run it in sync with the engine to ensure that it returns the same values as the renderengine would. Of course it is possible, but it would be a lot of overhead. In the end it would not even be faster, because it also would need to do object culling to determine wether parts of the players are in shadow or not. It means that we would have to write our rendercode just to get at the value. And this doesn't even include light effects resulting from particles, so it would get more and more complicated and the endresult would be, that we wont even need Doom 3 anymore, because we already would have rewritten a big chunk of the renderengine.

Well, the problem is that there is no direct keyboard handler in Unix. You are reding data from a terminal. I don't know how it would work if I would start to processes reading from the same terminal, I guess it simply wouldn't work. In Windows this is easier, because the API provides an interface for such a situation, but I'm not aware of such a mechanism on Unix. The code for that part is in the non-accessible area of Doom 3. the one where we have no keycard for. So we probably can't even take it from the keyboard and feed it in. But I have to look at this in more detail, because I'm not THAT good in such deep down Unix programming and usually you don't really need to ensure such hardware access. It might even be needed to write a kernel modul to support what we need. Sounds harder than it is though, because I experimented with that some time ago.

Actually I think the confusion has arisen from a different issue. Changing the default "droppability" of things will only make sense depending on the rules for what can be dropped and when - and judging from some of the posts, this is still unclear between team members. I've raised this issue in the dev forums.

While it has been brought up even before this public thread started, I appreciate your understanding of how separating the lantern from one's person can be useful. It's useful in a variety of situations too, not just a special case in a single FM. Setting the lantern down to do other things while lit could be useful anywhere it's dark. The great majority of FMs contain places that are dark. Why should this use of the lantern be limited to an FM where the author has specifically gone in and toggled droppable on? For that reason, I don't think this statement of yours applies to the lantern: Again, it makes sense anywhere it's dark and the player chooses to do something requiring both hands with more light provided by the lantern. You can't predict where that spot will be. It's up to the player and it could be anywhere. If we did make it an FM author option toggled off by default, how would the player know beforehand whether the author toggled the lantern to droppable? Are they expected to pull out their lantern at the beginning of every FM and test it? Or should they wait until they're executing a plan that relies on setting the lantern down for light, like they have gotten used to doing in other missions, and all of a sudden find it's superglued to their hand? No immersion break there. Or even better, you could let them know in the mission briefing. "I have a simple job planned for this evening... Btw, LANTERN IS DROPPABLE." This is starting to go in circles, but I simply am not convinced that this needs more policing than a simple player option of whether to hit the "drop" key. A rational player stays prepared for the worst; if they don't know whether they'll have to go thru a pitch black area, they'll aim to keep the lantern with them in case they do encounter such an area. We all agree that setting down the lantern is not totally useless, in fact it has practical uses. I just hate to see the usefulness of a tool decreased because we choose to baby the player instead, because they might manage to throw their lantern down a bottomless pit. If LGS had taken that approach with all of their player tools, tools would have been a lot less interesting. Anyway, I'd say vote on it if nothing is being resolved by debating, but internally, we already did decide this issue by majority. If Domarius is really not happy about it he can post a new poll in the development forums and see if anyone's changed their mind. I don't think anyone's going to change their mind by now if they haven't already.

Nice looking gate, Mag. You can continue to email the models to me if you like, or you can check out the information forum for the details of our FTP site and put them there. Either way, if you check this post: http://forums.thedarkmod.com/index.php?showtopic=3147 it will give you the folder structure we use for the models. You can also check the information forum for details of our internal model website, which displays all the models currently in game.

In Doom 3 there are buttons and impulses. impulses can be an unlimited number (i.e. as many as you keyboard has keys), but buttons are limited to eight. Several of them are already used up like ATTACK, MOVE FORWARD, LEFT, RIGHT, BACKWARD so there are only three left. Because of a bug it's actually onlyu two left now, but I think this was fixed in the latest patch. Nevertheless if you want to have leaning reacting properly, instead of a toggle, then we need three directions for leaning already, which leaves no room for other stuff. I implemented a solution that you can make all keys into buttons, and this has to be ported on Linux as well.

Some years ago I planned out an almost totally robot story line, led by humanoid bots, but shelved it as too ambitious for a first T2 mission. Kinda reversal of the T2 story with a few twists. Probably not original now but might look at that again when I see what bots are available in TDM. Stories don't HAVE to be original to be worthwhile so I expect I'll first try a simple, short mansion heist first. Trouble is, as ideas flow it could develop into something more like my present project. Currently racing to finish a T2 3-mission campaign this year while also dabbling with the Doom editor to get the feel of it. I hate empty rooms and corridors where nothing much happens except to pass through so I try to pack in lots of interest everywhere the player goes. I'm especially interested to see how much one can get in a scene in TDM without worrying about frame lag. A very small mission (terrain-wise) choked with stuff at every turn might be a target.

Magnesius: You should be a team-member now and see all the forums. If not, let me know, otherwise, take a look at this thread for current model assignments: http://forums.thedarkmod.com/index.php?showtopic=3315

Pardon, but did mister developer person just say (about 5 mins into the second video) that the realtime soft shadow stuff was something they couldn't end up using and it's gone? That now there are settings for what you want to cast shadows and not? So much for realtime lighting. That's going to go over well. Nice how he understated and obfuscated it. Disappointing also that they say (on the forums, not this video) that implementing mounted combat would take a dedicated team hundreds of man-hours to design and code and test... when Mount & Blade does it from one guy's programming... And damnit Bethesda, love your stuff, but use some interpolation on your animations or something. I've only been on board since Morrowind, but you guys are infamous for choppy animation. All that aside... it's still goddamn exciting.

Has anybody successfully set this up to work yet? I have got Eclipse to compile the D3 SDK code, but for some reason it (or Scons, I don't know which) is not using an incremental build - instead the entire project is rebuilt from scratch even if only a single file has changed. Is there some flag you have to set in either Eclipse or SCons to use an incremental build, or is there some other problem which causes one of the tools to think that an complete rebuild is necessary?

If you would IGNORE Orbweaver and ask the only authorative source, then you would already see that this is WRONG!!! Just try it for yourself. Doom 3 is the final authority on what it can do or not, so stop posting theoritcal considerations and go try it.

Yes, D3 has some persistent info classes for data that exists outside of individual FM's. What do you mean by "this could decimate linear gameplay"? Do you mean you could have a campaign where you complete maps in any order, but things you do in one map effect things in other maps? This isn't really within the scope of TDM, but personally, I've always wished the "city hub" areas of a campaign allowed for more researching of the missions beforehand, and the ability to do stuff in the city hub that effects the mission. I think we talked about this a bit in the public forums. It would be great if one could decide some things about the mission beforehand, like which direction to approach from (set the player spawn / insertion point), time of day to go in (effecting light conditions and guard patrols), etc. You could condense time and wait around in the city for a few days, robbing a few small time flats while you wait for the phase of the moon or the weather to change so you can approach your target mansion undetected, or something like that. Then there's the possibility of finding off-duty guards and servants in city pubs, and pickpocketing, bribing or otherwise convincing them to give you information about timing of guard patrols, lock combinations, or even offer them a percentage of the take to unlock a certain entrance for you or look the other way when you pass their guard post. You'd have to make sure the mission didn't become ridiculously easy as a result of such an "inside job," but you could make it difficult to get to a particular guard, like requiring some sort of intricate blackmail side-quest within the city section.

Upon reading Slash's curious questions, I thought of the object interaction in TDM. Does it work similar to the original Thief games (model brightness)? If so, is it already implemented? On another note, are there some kind of global variables in the Doom 3-engine - variables which can modified and accessed in every map of the whole campaign? This could decimate linear gameplay greatly. edited (typo)

The Thief world is full of people who would like to make a really, really scary FM (myself included). Unfortunately I think it would exceedingly difficult to produce such a mission without resorting to cheap shocks and Doom 3-style scare tactics.

I don't really recall any game EVER where this kind of objective layering was a good idea. Reminds me way too much of keycard hunting in the original doom. Honestly there are plenty of ways to make a map more interesting than adding this sort of pseudo-puzzle. Really, things like swords bashing or prying things will not make any player save for the most nit-picky even bat an eye. This sort of thing is not an immersion breaker. I can recall bashing crates into little splinters with a baton or a knife in Deus Ex, and not even noticing. The case FOR having a crowbar, and I think the reason that so many extra gadgets and tools are being suggested is because variety is good!! For the very same reason that it is important to have more than one kind of guard walking around, or all sorts of readables strewn around, or many different kinds of glasses, etc, it may be important to add more tools for the use of the thief. While adding all sorts of seemingly useless inventory items may seem like a worthless investment, having the OPTION for the player to choose from a big list of items that do similar things with little differences will actually add immersion because it allows a map to be tackled by players with more diverse playing styles. Really the only difference between a crowbar and a sword has to be in programming terms is that it deals blunt damage, is more effective at prying, and makes a different noise when it hits stuff, but it might be nice to have in there just because it's something to CHOOSE. I don't know if the same is true for everyone else, but some of my favorite gaming moments take place in the planning stages, like in rainbow six, before the mission you outfit your squad with different kinds of armours, guns, equipment, etc. TDP and TMA actually kind of deprive players a little bit of this joy...I actually think I skipped the buying stage a lot because it didn't seem like there was anything fun to buy. Just the same old stuff.

Well that would still depend on the layout of the map. Anyway if you are using the rendering engine to check the players visibility wouldn't it already do the culling? And how big can doom 3 maps get? is it a hard limit or a limitation of the hardware? and could you through clever design exceed what would normally be very taxing on a system?

Don't ever decimate a model. EVER. What you need to do is to create a completely new, low-poly model with a new UV-map and then renderbump the high-poly model onto it using either Doom 3's internal renderbump or an external program like ORB. Alternatively you may be able to submit the high-poly model to another modeller and persuade them to do the renderbumping and low-poly model generating for you.

I can give you the co-ords in maya, but I don't know how they relate to the AF bodies in doom.

Wow... I really like that Idea Domarius... If you ever get a screenie of this in action post it :-) would it be more like the "flare items" as in you can use it and drop it or would it be more like a Weapon (like the doom 3 flashlight without the whole bashing part) , and would this be some sort of magic lantern that only you can see the light from? (if that's possible) or will it illuminate you in such a way that you'll be easier to see? Btw Domarius, anything I can do to help, I really want to be a part of this team.

thanks Ombrenuit, I'm an amature game designer myself but i don't think I have much to contribute besides ideas. I'm only an intermeddiate coder and a horrible artist. I've got a little experiance with world design in Worldcraft/hammer back in the Q2 and HL days but i'm very out of practice and what's worse is the Doom editor, I hate the way that Z is manipulated and the general feel and layout, now if somone made a doom 3 ediotr with the same feel of worldcraft i'd be all over it, especially because I do think that conceptually I have alot to give to the dark mod in the way of missions and story, but I may be a picky pain in the butt, I really can't deal with the damn editor. if anyone has any suggestions tho let me know. actually i've been thinking about that gamma increasing effect, and i dunno how much control doom 3 has over it but adjucting the CONTRAST may be a better idea so it doesn't overbrighten the brights and instead increases the dark levels to a higher level of brightness... BTW I don't know if it's been said at all or not... do we get the OH SO LOVELY (meh...) TDS mechanical eye?