Obsttorte

Yes. You have to extent the ai's base script. I think Springheel already utilized this as an aberation of my trigger_look script. Probably for "A New Job".

Patches are intented for round surfaces, so edges shared by two tris of the same patch will always have the same Vertex normal and therefore look smooth and round. If you want something edgy-looking, use Brushes.

@MirceaKitsuneLike @Dragofersaid. If lights can have models (can't remember right now as it has been a while) and you use the particle as model, you may even be able to skip the "set _color on flame" part (note that there is a space after set).

You can make the particles use the light color. This way you wouldn't need to have specific entities for each color. Btw.: You may want to start a mapping thread to bundle your ideas instead of creating a new one for everything?!

@wesp5: The general opinion back in the day was that for many players searching the inventory for the correct key was part of the immersion and automizing this process is no good idea, so it will not make it to the core mod unless those opinions have changed. In regards to the files: The video is 6 1/2 years old, I haven't found anything in my mapping thread or the newbie thread. I'll see whether I can find it on my harddrive, but can't promise anything.

That's possible. The only issue is the lack of a proper animation and bark for the ai. You could use the "blinded" animation and letting the ai say "ugh", but it may appear a bit silly. Seems to be doable.

In regards to how implement custom arrows: It's old and lengthy but may still be useful. Regarding the useful/lessness of flash bombs and mines: I don't think that those items are useless per se, but that those, similar to many other items the player has at his disposal, aren't as useful as they could be due to the way most missions are designed. Almost all of them are ghostable, or relatively close to that. There is rarely a situation, where using an item really gives you an advantage, especially for advanced players who are familiar with stealth games. Flash arrows, emp arrows or whatever else will suffer the same issue if mappers using them won't create their missions in a way that encourages their usage. I hardly see this happening, but I may be proven wrong.

As mappers have to add it on purpose and existing maps as well as future map design aren't affected, as you correctly point out, I don't see a reason for you to not create it and upload the requiered files here. Mappers can than choose on whether they want to use it or not. My experience is, though, that it will most likely be forgotten. So it probably makes more sense to either implement it in an own mission or, if you ain't going to do this, simple do nothing until someday someone may stepup to you and say: "Hey Mircy, didn't you had that proposal with the emp back in the day, would be cool to have this in my mission."

@Strunk: The script looks ok so far. However, having to let the poltergeist entities to target each moveable that should be moved by it seems like a tiresome procedure. How long did it take you, as there are over houndret of entities in question? It would also be a good idea to specify the editor appearence in the def [code] "editor_color" "0 .5 .8" "editor_mins" "-8 -8 -8" "editor_maxs" "8 8 8" [/code] Ths way you can see and select the entity in the editor. Change the color so you can differentiate it from other entities. In the future it would be nice if you could boundle your stuff (map, def, script, etc...) as zip and upload it instead of each file individually. There is a certain motivational gap to download each file seperately and to setup the folder structure onself.

You can change the name via the function setName(string newName). getName() returns the name of the entity. So if the trigger entity is the spawning entity the code would look like this [code] entity myEntity = sys.spawn(entityToSpawn); //pass the proper entity def as argument myEntity.setName(getName()); [/code] If the trigger is not the spawning entity but only initiates the spawn (via a global script call or a custom entity) you have to pass the trigger entity (or at least its name) to the function where the spawn is handled.

As VanishedOne already pointed out I think the issue is that your response function "OnOff" does not have any arguments. My interpretation, as the script gets performed anyway, is that the script compiler considers the function to be of "global" scale (in a sense as independent as to what entity it is called on) and ignores the value of the member variable clicks. Note that this variable is defined for all entities of type poltergeist_script, but the compiler can't know that it also has the same value for all of those entities. I can't say, though, why the code behaves like that.

Possible that duzenko changed some stuff, the way I described it was as it worked back in the day. I haven't looked at the code for a while, though. If I am not mistaken the skybox is something that was implemented for TDM and not part of the original Doom 3 code. If that is the case, then it was implemented when the team haven't had full access to the complete code, what may cause it to behave a bit different from what other engines do. Either way, the way it is described by AH is how it has worked in the past, and if this isn't the case anymore, it would definetely be a drawback. Whether other engines behave similar is actually nothing we should care about as it doesn't matter.

The skybox texture was pretty much handled like caulk in the past (pre-duzenko era ). On parts of the screen were a caulk or skybox material on worldspawn is closest to the player, it basically leaves a hole there. The difference is that if there was at least on surface with the skybox material on it in the current view, the skybox got rendered first and the current scene than on top of it, and where the holes were the player could see the skybox shine through. Another difference is that caulk does not effect the depth buffer, whereas the skybox material does. That's why it is useful to combine both the skybox texture and caulk to create easy to visportalize outdoor areas (I remember having to explain this to duzenko as he first planned changes to the code that would break this technique). So in short words: AluminumHaste's approach should work as he is expecting it.

One problem is that you would have two additional views, one for each portal, and as far as I remember the engine doesn't like that or isn't really setup for that. You could probably bypass this issue by using sort of a distorting effect at distance and only really render a view through the portal on closeup or by extending the specific pieces in the source code. The other issue is that you will not be able to get the connectiveness the portals in portal had. You can teleport the player or anything moveable once it touches the surface/gets close enough, but you cannot lean through it or say place an ai in it so that the legs are on your side of the portal while the upper body looks out on the other portal. I fairly doubt that this can be easely coded, as their is nothing comparable in the engine this could be build upon. So all in all it is possible to mimic a similar behaviour, but nothing nearly as good and versatile as in portal. And as grayman noticed, the setup would require some work.

That's correct. I meant your assumption that the entrees of the transformation matrix are within said range. The resulting matrix is used afterwards in R_SetLightFrustrum(...). You can take a look at R_ComputePointLightProjectionMatrix(...) (way easier code) and how it is used for the light frustrum for comparision. So the plane equations are setup so that the planes normal vector multiplied by the vector from the light origin to the point we are interested in gives us a value between -0.5 and 0.5 if we are within the light volume, at least for point lights. I'll have to write down the projection matrix for the projected lights to see how the approach is there, but it seams they are transforming the pyramid that is the light volume so that the base sides equal the height (the length of the target vector). What makes things even more complicated is that the up, right and target vector don't neccessarely have to be orthogonal to each other.

In the TDM code the content of the matrix calculated in R_ComputeSpotLightProjectionMatrix() is than used to calculate the boundaries of the light volume, that are represented in world-size coordinates (but relative to the light origin). So the volume is not clamped to [-0.5...0.5] or anything like that, but is the actual volume as defined in the spawnargs.

Oops. It's not really convenient to use 4 dimensions to describe a transformation in 3 dimensions, imho, so I tend to expect the transformation matrix to be 3x3. My bad.

I think you are missing the translation Vector in your calculations. P•(0,0,0) = (0,0,0) for any matrix P. So the structure of the transformation is P•x+(0,0,0.5)=y, where x denotes the world coordinates and y the texture coordinates. I haven't looked at the DR code, but in idTech4 code it actually works like that, although it is not visible without examining the steps of the calculation as the developers haven't utilized c++ classes to replicate the mathematical notation (I've once read an interview with John Carmack where he stated, that they shifted from C to C++ during the development of Doom 3 and therefore had to familiarize with the new concepts themselves during the development, causing them to not make use of all the possibilities C++ provided).

Don't know if this helps, but when I was using those type of lights I always rotated them directly instead of changing the light_target etc. spawnargs. That always worked for me. EDIT: Just noticed that you were talking about an issue in DR, not TDM. Should've read more carefully. Nevertheless, the preview takes the rotation into account. So maybe it still proves useful on narrowing down the issue.

I can help you with the maths, too. Just in case.

I guess he meant that both players are thiefs, hence he called it coop On of the old Splinter Cell games had coop missions. Played them with a friend who never played Splinter Cell before - very funny.

Church/Experimental

I am a first world person either, but I can guarantee you that here in germany high speed internet is nothing you can always expect everywhere, even in major cities. However, compared to other modern games The Dark Mod is comparable small, and if madtaffer can still remember the time when TDM weighs only 1.2 GB his memory is definetely better then mine, cuz I cannot

Nice and thank you for the hard word that definetely went into this. One note, though: You categorized my FM "Builder Roads" as horror, but it doesn't contain any horror elements. It is intented to be ghosted more or less, so maybe that caused some confusion.