Ishtvan

The DoomEdit source is something we don't actually have access to, so we can't directly change the editor in radical ways in that sense. We may be able to add menu items, and we can definitely add new command lines to run inside the editor console (bsp is a shortcut that runs the command "dmap", we will have other editor commands of our own making that hopefully we can also add a gui menu item for). For example, one possible way to implement sound propagation functions is to compile the map the normal way (with bsp/dmap) and then type "buildsound" or something in the editor console to compile the sound propagation information. This is not as nice as a menu item, but I think you people that dealt with DromEd can handle it The other option is Radiant, which is a fully open sourced editor that works with D3; However the version of radiant for D3 is still rather bare-bones and not as fully featured as the D3 editor. If Radiant takes off though and becomes competitive with the editor for ease of use and feature wise, we may switch our custom editor functions over to that, since it is fully open source. Don't see why not. We have the source for all the AI if we need to add anything to the hardcode, but this could probably done with ingame scripting anyway, since it's just a matter of choosing when to play sounds and what sounds to play. Yes, we actually had quite some trouble with porting over "moving" and "walking" from place to place. Due to our tight release date schedule, and the fact that we do not believe players will miss it, we have decided not to include player movement in the game. We believe that a rail-shooter will be a great way to bring the Thief atmosphere to D3! ... just kidding. No, we haven't run into any walls like that yet. We always have to do some fancy footwork to work around stuff that wasn't included in the source (like the renderer or the sound engine), but usually these things have very flexible interface methods, so we do our best. However, we are still very early on in development. So I can't make any guarantees.

Just thought I'd post the token nerdy response about TV technology and holograms: Right now, a lot of the major companies are working on the next gen. 2d display "Field Emission TV." Each pixel is composed of carbon nanotubes. When you put a voltage across a pixel, the nanotube accelerates electrons down its length and basically shoots them out at a standard phosphor screen. The pros are: It's as "flat" as the latest flat panel TV's. It's much lower power than Plasma TV's (so lower electricity cost), and not prone to burn-in like they are. It has a much better refresh rate than LCD TV's, and can be viewed from any angle. It's basically like a regular CRT, but instead of having a single electron gun set way in the back so that it can hit all the pixels, each pixel has an electron gun "component" in it in the form of the nanotube. The down side is: you need a vacuum where the nanotubes are, and it's hard to maintain a vacuum between two lare flat plates with a small separation between them. Samsung actually has a working display model of this, but it will be some time before they get it into mass-producable form (if ever). So anyway, a lot of companies are working on Field Emission TV's as the "next gen" display before they try anything holographic. It's possible they're working on that too though, and you never know when a small startup compnay is going to surprise you with a leap in technology. There was a guy at MIT working on a 3d display via lasers projecting on water vapor. Of course the prototype probably cost hundreds of thousands of dollars to make. I think a startup may have formed around that, but I don't know how they're doing right now. [This has been a token nerdy response]

Are we counting those dungeon explorer games where it would show you the hallway ahead and doors to the left/right, and you could turn in 90 degree increments?

I don't envy you guys that have to work with the editor... at least when something goes wrong with code it's usually my own fault. (Although we do have our share of "systems we can't touch because the source was not included in the SDK" to work around). All the name strings that are assigned by default in the game take the form blah_blah_blah, so I'm not sure what effect putting spaces and slashing in there would have; maybe that is causing problems, but probably not since you said you got it working fine. Also, it might help to use the "signpost on a model" thing for a separate model that always works, (like a D3 crate or something) that you put next to /above the model that you want information on. I don't know about the target_tip entity myself, if it had to do with the frobbing system then you'd best wait for Sparhawk to answer. As far as I know though, we didn't remove any entity definitions, we added our own def file that should only add to the existing D3 definitions, not remove any.

So I was going about creating a new class to display text ingame, when I realized it's not necessary, because you can just put the signpost info in the "name" string of the entity, and use console commands to display entity names. Create a placeholder func_static, if you want you can attach a model to it so it's easier to find ingame, then put the info you want displayed in the "name" string (you may have to use underscores instead of spaces.. not sure) Once you've done that, there are two ways I can see right away to view the name ingame: In the console, type g_showentityinfo 1. This is option is not so good, since it shows the wireframe for EVERY entity and generally clutters up the screen. A better option is "g_dragentity 1" This is used for dragging physics entities by left clicking, but it ALSO displays the name of the entity when you left click over it, even if it's a func_static (you may have to attach a dummy model like a box or something for this method to work). So is that method of displaying the text you want (entity name string) okay, instead of changing the source code?

I bet in the near future, whenever international diplomacy breaks down, we'll all sit down to watch a great episode of "robot wars." I'm betting on whichever country has wedge-shaped robosoldiers.

I heard you have to clone models aftr you place them to get them to display right?

I should be able to add this by the weekend at the latest. It'll basically just be a new entity class that calls GameRenderWorld->DisplayDebugText or whatever it is with text in the entity's key/value information.

I think I may be able to create a quick "signpost" map entity that just displays text in its key/value pair as "debugtext" (the floating red text you see when you have various draw_ debug options on in D3)

Nice! That would be sweet to see ingame with some luster on the metal there.

Damn, very nice. Medieval stealth operative, I like it! So I can't quite tell from looking at the glove/bracers, are the metal clasps going to be on the inside (ie, what the player sees all the time), or are those going on the outside and the leather "X" is on the inside? From the full body shot it looks like X faces outside, clasps face inside, but I couldn't tell from the glove closeup. I'm just curious, either way would probably fine (although I might tire of looking at shiny clasps after a while )

That's true, but it's pretty random. Sometimes people go into shock, sometimes they don't. Interestingly enough, I read an article a while back where a security professional interviewed someone who had been in prison for a while. The interviewee had witnessed and taking part in many "prison assassinations" or shivings. He was saying that the only sure way of really making sure a guy goes down with one stab is to stab him in the armpit (which usually means the attacker has to lift the arm up with the other hand, but that's do-able when people are taken by surprise). The reason was: This immediately collapses a lung and puts the victim into shock. After that, they're much less likely to cry out/continue to fight back. Often the goal of a realistic game / simulator is to reward people for doing the smarter thing. So rather than simulate a random chance of the person screaming out or not, Thief chose to punish us every time we killed by making a lot of noise, because there was usually a better alternative to killing available. Using a flight simulator analogy, you CAN sometimes crash land a plane without deploying the landing gear and walk away, but most of the time you don't. So the simulator punishes you for not putting your landing gear down before you land by killing you every time.

Yeah, I'm sure lots of other people have posted screenshots of AI's with their face in eachothers crotches, but when I got the woman to land on one hand and balance upright like that, I knew I'd better take a shot because that was comedic gold. They're both still alive and unconscious of course. I'm a pornographer, not a murderer. It's too bad T3 didn't implement AI waking up and recongizing that they were in obscene positions. Whoever woke up first would probably quietly extricate themselves from the situation, and then they would act awkward around eachother for the rest of the game.

No takers? Let me ask it this way: How do you guys usually import collision models? With SURF_COLLISION on invisible surfaces in your model, separate models, or some other way entirely?

Ishtvan is the phonetic spelling of the Hungarian name Istvan, which is equivalent to the English name "Steven." (I believe Russian has a very similar name, but I'm not sure) From these two facts, one might infer that I am named Steven and am Hungarian. One would be wrong on both counts. I got the name from that of a minor character in a novel written by Steven (Istvan?) Brust, who is a favorite author of mine. He "imported" a lot of Hungarian names into his universe, and sometimes changed the spelling to the English phonetic spelling. I highly recommend those books and take almost every opportunity to pimp them.

To each their own I guess. I like a lot of realism. You could die from a couple shots or one shot to the head in Max Payne, and also all of Tom Clancy's Rainbow Six series, and I don't think that made those a bad game. If you've read a Clancy book you know the man goes out of his way to do research on how things realistically operate. I was happy to see some of this attention to realistic detail reflected in Rainbow Six, and disappointed at its lack in Splinter Cell.

So this is what the AI's in my appartment complex get up to when I'm not around...

I love how writing sound propagation code leads me to post uninformed questions in so many other development forums... Anyway, I have to load a collision model for doors early on in my code, and I have a choice about whether to let it go ahead and use the rendermodel as the collision model if no .cm file exists for the model, or give an error at this point about the door not having a .cm file. I don't know how you guys make collision model .cm files, maybe they're automatically generated from SURF_COLLISION surface when importing the model? I dunno. I'm inclined to just do what D3 does when it loads collision models, which is try to find the .cm model, and if not, use the rendermodel. Because maybe you guys like to use SURF_COLLISION in your models themselves rather than generating a separate .cm file? I just wanted to check what you modelers' preferences are. As a side note, if I'm reading the code right, for a collision model to be precached on map load, the model files MUST include a .cm file, otherwise it's dynamically loaded from the rendermodel every time an entity using that rendermodel needs a clipModel (which I would think would be bad). So that may be one argument for making .cm files.

Wow, he did work for the Final Fantasy CG movie. I thought that energy dome holdout in the middle of NY looked rather familiar.

Wow, I just lost all respect I may have had for Splintercell 3 after watching the trailers. The first two games at least had a hint of realism with the shooting and takedowns, but those trailers show some of the most unrealistic crap I've ever seen. Features include: doing a shoulder roll in the same direction you were moving to escape BULLETS, killing someone with a single punch to the face or knee to the abdomen, lifting someone of a similar size completely off the ground while in an invented hang from your feet (go out and try that), and, oh yes, when a choke hold is applied, enemies don't struggle at all, they just tense up and then quietly die after 2 seconds (no wonder people think it's possible when they see that crap all the time in movies/games like this). Clancy should be ashamed to put his name on this product for realism issues alone.

Would they have had a version with the keyhole integrated into the handle that you turn in this setting, or is that too modern?

There are several long threads on this issue.

I think glass destroyed sound are stored on a func_breakable or something like that. That sound is played EVERY time the window is broken, so it is better to have two separate sounds, one for fire arrow, one for window breaking. Also, the window breaking is physicalized so that individual pieces fall, it might be a bit weird it the sound is very long and the visual falling of the pieces is very short, so sound length may need tweaking. For ultra-realism, we could probably make each breakable piece make a noise when it hits the floor, but that's a lot of sounds to be playing at the same time. Also speaking of window glass, are we going to have a different sound for walking on broken window glass? (Right now broken glass goes away after a while in vanilla D3, but we could conceivably set it to stay, and make more noise when you walk on it)

Congrats man! Way to go! (we really need a thumbs-up emoticon)

Now everyone who requests third person can be told to go secretly stare at the ass (because we know that's the only reason anyone wants third person)