Gildoran

Whoops... yeah I mean scrolldef. I didn't bother to check the id SDK site when I said that.

Well, D3 has sliderDefs, and I'm pretty sure GUIs can choose what graphics to use, so we could have TDM themed sliders...

Right now leaning affects the lightgem, but that may change in the future. So far AI can't pick things up, so they throw spawned items. BTW, I like the title. When I first saw it I didn't realize it had to do with TDM.

My understanding is that pk4s are loaded in alphabetical order, so that zed.pk4 overrides alpha.pk4. (hence why the clean declaration packs start with ZZ) Also, any pk4s in the mod directory override any information from the base directory, and information stored directly in the mod directory overrides information stored in any pk4s. (with the exception of gamex86.dll)

It's possible to compile them into the map using the inline keyword, in which case I conjecture that they're treated similarly to patches.

I'd be surprised if monsterclip worked with models or patches. I would imagine that AAS needs to work with 3D shapes that are easy to manipulate - convex polyhedrons (brushes). Arbitrary sets of surfaces (patches and models) seem like they'd would be very difficult to use for any kind of 3D compiling such as AAS.

The usual way is to place the model, then add simplified monsterclip rooms made out of brushes. Keep in mind they don't have to perfectly match the model; I would probably put the floors under the model (so the monster uses the cave floor to determind its height), but place the walls slightly inward. Then again, I don't really have much experience with AIs... this is only what I've read from the Q4 SDK site.

That would be great, especially for patches!

AI can walk on uneven surfaces, but as far as I know, it's the brushes that determine where they can walk. I have no idea if monsterclip is works on models (I doubt it, since I'm under the impression it doesn't work for patches) or if the mapper would end up needing to manually monsterclip the area around the caves.

IMHO, texturing is one of D3ed's biggest weaknesses, and if DarkRadiant had good texturing capabilities that'd probably be enough to get me to (mostly) stop using D3ed... There's a wishlist of things I've wanted... 1. The ability to set the "origin" of transformations. In D3ed, when you scale or rotate, I think it's always around the world origin. This is very inconvenient. It'd be nice if when trying to rotate a texture to fit a wood beam, I could set the origin at a corner vertex (or some other spot) and just rotate it until it fit, instead of having to iteratively rotate it a little, then shift it to see if it lines up with the beam, then rotate it some more, then shift some more, ad infinitum. Similarly, for scaling textures, it'd be nice if I could put the origin at a corner vertex, and then scale the texture until its size matches the beam. (instead of scaling, then shifting to see if the size matches, then scaling again, etc) Preferably, I'd like to be able to set the origin at any location. 2. The ability to undo transformations. At least I should be able to undo them to the state that existed before I opened up the texture window or before copying a texture's orientation. In D3ed, sometimes I'll work for a half-hour, iteratively rotating, scaling and shifting a texture until it matches a brush... then I'll accidentally middle click another brush or some such, and lose all that work. 3. The ability to project a brush-face's texture onto another brush-face that's not co-planar to it. (D3ed lacks this as far as I can tell)

HL2 fans are going to kick me for saying this, but perhaps one of the biggest let-downs for me was the physics... There's been a bug in HL1 physics that always drove me nuts, and when I heard that HL2 would have "realistic" physics, I just assumed they'd fix it, but they didn't... In HL2, when you jump your velocity is set (rather than added to), and when you fall the amount of damage you receive is based entirely off of your velocity (without taking into account the velocity of the surface you hit). This leads to severe problems with fast traveling elevators. When you're traveling up, you're stuck to the floor and can't jump. When you're traveling down, jumping will cause you to shatter your ankles. Even Thief 1 didn't have that bug (and I don't think Doom 3 does either), and they don't even advertise their "realistic" physics.

There is a standard mapping between bitmap size and world-size... it's just that we use higher-resolution images, so our textures are scaled too large. Fortunately, the size of the editor image seems to take precedence.

I've been using editor images to set a reasonable default scale for textures. (without them, you can't just apply a texture and see if it looks good - you have to apply it then scale it down - which makes comparisons and scrolling through a list of textures more of a pain)

It just occurred to me that although DDS files can't be used as texture editor images, JPGs could be... What would people think of that? I imagine D3 would be smart enough not to load editor images for the actual game, so it shouldn't slow down loading. Although I doubt they'd save editor memory, they might be able to save us some disk-space (read: quicker download times).

Ok, I've updated the way inventories are displayed, so each item uses its own GUI. This should make it easier to use models. There's still the problem that models don't fade well, but at least they're possible now.

No, light is additive in D3. Do you know of any engines where it's not?

I think I can create a new version that allows it to be seen from above and below, if the sides are a single color. I'm pretty sure animated materials have almost no effect on performance, especially given given the small icon sizes. Icons that rely on scripting to be animated (such as a compass, even with a model) might have a very slight impact, but the compass is pretty much a worst-case scenario (while selected, its script has to be run every frame), and for me the compass has no noticeable effect on framerate. (though admittedly, I haven't tested it in CPU-bound situations)

I would assume it has to do with bounds checking. D3 only renders a model if its screen bounds intersect with visible screen/portal space. What do the bounding boxes look like? Try checking with r_showViewEntities to see their bounding boxes. I think r_showInteractionScissors is intended to debug shadow culling, but it may also be applicable to whether or not an entity is rendered on screen. I also agree with Solis that a poorly placed origin might have that effect.

Just out of curiosity, why is that? Is it something about grammar/vocabulary, or just a matter of what you associate with English/German?

BTW, I had a question regarding realistic compass models... if we went with one, how would you tell which way it was facing when looking at it from below?

I bought HL2, but soon after decided not to buy any more games from Valve/Steam.

@Ishtvan: I'm under the impression that how much it affects performance mostly depends on how much of the screen it covers, how many layers it has, and how expensive those layers are to render (things using expensive shaders take up more fill-rate) Inventory icons take up a small amount of the screen and don't use expensive shaders, so I'm not particularly worried about their performance. In any case, the reason I was using icons rather than models had nothing to do with performance... (see below) @SneaksieDave: Sorry, I guess I wasn't doing a good job of explaining myself... With D3 GUIs, you cannot change a model at runtime. (you can change the model's position/lighting/etc but not which model is rendered) Any model used by a GUI has to be hand-coded to be in the GUI. If you have a GUI with 10 models, it needs to have 10 windows, one for each model. This is not extensible and it prevents a mapper from just coding an item that uses a given model. However, I think Sparhawk's idea of using the GUI overlay may provide a solution, because it can load up new GUIs on top of the HUD at runtime. (and I think this would also simplify the inventory display code slightly) It would still require a mapper to create a GUI for each model, but it's better than forcing them to replace the HUD with their own version. Edit: Also, there's the issue that models may be difficult/impossible to fade.

Actually, I believe you could blend between more than one texture if you made very careful use of coplanar surfaces: If two triangles have the exact same shape and position (they aren't just coplanar), they don't end up depth fighting and their lighting data gets added together. (the window testmap makes use of this) If you created models that had redundant triangles, you could bend between more than two textures. I've been wanting to test that out for a long time as a way to seamlessly texture oddly shaped things, but I'm unfortunately unable to create vertex-colored models.

The reason I avoided using a model, is because you can't switch models on the fly. The model that's used has to be hard-coded into the GUI. The way Drumple's code works, is the GUI has a renderDef for each item and weapon. It's not modular at all... If a user wants their own item to have a model, they have to add in more special code to the HUD. I'd have to write a bunch of extra special-case GUI code to detect when the compass is selected, and display the compass then, rather than just relying on general purpose item code. Edit: Though maybe the GUI overlay might be usable to solve this problem, because an individual model could reside on a separate GUI that only contains the renderdef, rather than have all the special-case code be built into the HUD.

It depends on if the compass is mostly just a flat surface. Something like compasses 1, 2, 3 and 6 should work, since they're effectively just a disc (or several layers of discs). 4 would be completely unworkable, and I can't load 5.