peter_spy

IMO saying that making maps for stealth game like TDM is easy makes a good PR line, but nothing is further from the truth From all types of FPP games, making levels for light-based stealth games is the hardest. You have to think about stuff like player jump and mantle height all the time. Lighting isn't there just for aesthetics, it needs to be a part of conscious gameplay design, as it makes player invisible. The mere setting determines available types of surfaces and types of noises player will make while traversing such spaces (e.g. forest and nature maps are typically easier in comparison to levels with more stone, tile, and metal, so you need to find a way to offset that with lighting, AI placement etc.). None of this is easy, especially in comparison to e.g. maps for FPP shooters

In virtually all modelling programs, objects can only exist on one layer, so that's not a problem, as there's no other command like that. Only DR allows objects to be on several layers.

This is only my experience, so please speak up if you have other ideas. What I would do is either: 1. Remove current Add to layer option entirely, and leave Move to layer only. Right now I can't think of a practical situation, where the former would be useful, especially since you can't expand the layer to see what's on it. Typically, objects can exist only on one layer at the time, at least in all other programs I use. Optionally, to make it more consistent with other apps, I'd rename Move to layer to Add to layer. That's how this option is called e.g. in 3dsmax. But then again, this is my experience, other mappers please speak up if this is too confusing. 2. Leave Move to layer as it is, but rename Add to layer to something else, like Clone to layer, maybe? Maybe someone who really needs that function will have a better idea on how to call this.

IMO that would be most annoying, if I had to dismiss a popup window like that every time I want to move stuff to another layer. That said, I think the distinction between Add to layer and Move to layer should be communicated somehow. First option adds selected entities to a defined layer but it also leaves them on the current layer, which is confusing. I bet most people would expect Add to layer to behave like Move to layer.

Actually, from my experience TDM handles higher fidelity surprisingly well, for engine this old. The thing is, and this is actually true for any engine out there, you need to make a whole map with static meshes. And they have to be optimised for your engine, both in terms triangle count and shaders / materials they use (i.e. they should use as few materials as possible). Some things seem to scale with hardware, like triangle or shadow count or texture memory (although we're probably limited to something like 8192px textures by the engine itself). What doesn't change is the drawcall limit, at least in my experience with different hardware. The easiest way to clog your video pipeline is to make static meshes with high number of materials, which a lot of TDM models do, whether it's modules or decoration props. I understand the reason for that was to use as many versatile tiling textures as possible, to make the mod package easier to download. Also that method was widely used around Thief3 era, where textures were 256 or 512px at best, and making UVs in that texture space was less efficient. The thing is, while games like Thief 3 used 2-3 materials per mesh on average, to save on performance. TDM went wild that count, often using 8 or 10 different materials per mesh (15 was the highest value I've seen in the model browser). That's way too excessive. Add complicated, multi-stage materials, and multiple or overlapping lights (something easy to miss, if you're inexperienced mapper), and you have a recipe for disaster. That is what is both the source of performance problems, but it also presents huge opportunity for future improvement. To tackle these problems, you have to take the path basically all post-Doom3/Thief3 games took, and switch to "environment sets" (let's forget about lightmaps for a while ). Usually, such set contains modular architecture pieces, versatile background props/decorations, and unique models ("hero meshes"), along with a few tiling textures, if need be. They are as flexible as possible, and the new props or decorations are modelled along the way, or mixed/taken from other asset packs. They are also fully unwrapped and use as few textures/materials as possible. None of this is easy though. It requires a lot of time, and a knowledgable modeller, something TDM never really had in ample supply (at least that's my impression after a few talks with fellow mappers and TDM team members).

To be on the same page, I don't demand anything. I noticed low framerate in ERH+ screenshots, assumed that he has a machine capable of running the engine in 60 FPS (and I'm aware I can be wrong in this), and pointed out a possible solution. Whatever ERH+ will do, it's his choice. It was Melan's dismissive attitude that triggered the whole heated discussion. It's true that I'm very opinionated about certain things in level design, and I know more about this stuff in theory that I can prove with maps (although they still run in 60 FPS, even on that old crappy TDS engine ). I love this community for its energy and support, but I admit situations like that are bit frustrating for me. Both here (sometimes) and TTLG seem to live in some kind of knowledge bubble. I look like a crazy person, and I feel like that a bit, but only because I have to preach about stuff that is 100% duh-and-obvious everywhere else in modding/level design communities. And, I've never seen such active resistance, hostility almost, to learning this stuff. I don't know, maybe it's me phrasing it in a wrong way.

These are subjective simplifications, to say the least. E.g. I see a huge difference in framerate up to 45 fps. Sure, stealth gameplay is slower, at least until you get caught and have to improvise. So that assumption is pretty risky. Also, the difference will always be noticeable, even with slow gameplay, because player can always turn camera to a view where it's 60 fps. That kind of fast jumping between ranges looks bad. That's also why I proposed an FPS limiter in TDM bugtracker. If you don't care about even framerate, the least you can do is to have an upper limit brought down to e.g. 30 fps. That will make gameplay much smoother than constant jumping between 30 and 60 FPS. For one, I was criticising your models and the Matter of Hours, and there were very good reasons for that.

I just got Xpadder myself, but none of the profiles here is intuitive or in line with controller layouts used in other FPS games. Typically, left stick is for movement, right stick is for moving camera around. B is for cancelling things or crouching (in some games it's RStick button, but it's quite uncomfortable to use frequently). RTrigger is for attack, LTrigger for block/reload (usually). A is for accepting things, using stuff, activating things, or jumping. X is also good for using stuff, activating etc. Y is sometimes used for jumping too. RStick for zooming is ok. D-Pad is fine for selecting weapons and/or inventory stuff, although with X360 controller, especially a new one, you have to press these directions quite hard to get an input. Start button is always the menu button (ESC). Back button is ok for maps, or maybe objectives? I'll try to come up with something of my own, if the time allows

I agree about the question of art style, fortunately DR allows for different methods of world building, from the old-school all-brushes approach to the usual "bsp blockout -> all static mesh" workflow. What I disagree though is on dismissing technical aspects of your work as irrelevant, especially with that kind of "Trust me, I'm an expert, 35 FPS is fine" attitude. Now that's counterproductive. Also, it would be laughed off on virtually every other gaming, modding or dev forum in the world, and the OP would be asked not so politely to go away in any general direction

None of our creations is perfect, ever, and that's fine But, making sensible assumptions and learning about the tech and the tools first is exactly what people do before jumping to anything. It's what both pros and amateurs do, and it's exaclty what I was doing before I started making anything more complex in DR. It's not unrealistic, and it's not some arkane knowledge. TDM engine has all the measuring tools needed for that, and you have learning material on that freely available on the Internet, whather it's TDM wiki, mod wiki, or level design sites or youtube channels. Nothing is stopping you from finding them, except for your own attitude of course. And what is most important, it's good both for you and your players in the long run. For you, because if you maintain constant high fps, minor problems won't matter that much. You have a script that brings performance by 5 FPS, and you can't find what it is? Not a huge problem, if everything else works fine. When you have the same scene running in 15 fps, that is a huge problem. What will you do, delete lights, cut your art or other content to compensate, or just leave it like that? You know well how hard it is to cut content you spend so much time on making. If you leave it like that, players will be frustrated. You release something, ask for their precious free time to play it, and then you waste it with technical problems that could be avoided entirely. Again, stuff like that is not some unachievable goal. These days it's the norm, and there's no use fighting it. (Why would anyone want to anyway?) Learning and practising these things will only lead to you being a better mapper.

I made two TDS missions, although the first one I made was downright terrible, as often first missions are That said, you can indulge yourself in a typical TTLG self-congratulatory fashion, but I don't see why we should pass this toxic atidude to new authors. There's no reason they should be discouraged from making decent things and being technically proficient. And you know, actually learning level desing-related stuff that's really helping them in the long run.

It's a kind of an argument, when you kept making the same spelling or grammar mistake for 10 years, and when someone's calling you on it, you boast on how long you have been writing. The mistake is still a mistake, even if made for 10 years without anyone pointing it out. In this case, all the world of both amateur and professional level design is against what you say. Or, to frame it in another way, it's kind of like making a 4k movie and display it on old 10" CRT. You're not respecting your own work. In this case you also don't respect the players. And you prove that you haven't mastered your craft well enough.

Nope. Unless you run TDM on a 6-year old laptop, this is not fine and never will be. It means the engine is struggling with something. It's also much better to strive for target FPS (so 60, with vsync on) all through your mapping / production process. If you leave it for later, the situation will only get worse, as you'll always run into other problems and won't have time for everything.

Have you tried using LOD system, at least its hide_distance option? Configuring proper LOD sure is time-consuming, but it helps a lot. AFAIR, you can even hide lights this way.

I wonder why the framerate is so low, the geometry doesn't seem complicated.

Yup, it's jerky, like during framerate drop, but the framerate is fine and smooth.

If there's one good remedy for that, it's using as few materials per mesh as possible. It's also very beneficial for performance.

Arcturus lives in Gdansk, that might be a really neglected part of it

The only workaround I know so far is to select a model in perspective view and use Alt + arrow keys to position it. IMO the biggest problem is that you can select some bigger brushes (caulk, skyportals etc) while trying to move smaller stuff. You won't even know that until you get a leak message. That's why I use layers to hide them. I have no idea how hard it would be to change that behavior, but basically every 3D software I know allows objects to be selected in 2D view only by clicking their wireframe. This way you wouldn't select and move anything else by accident.

That's fair I wonder though what's your take on more interesting issues, like the way you select objects in 2D views. I mean, is there a reason DR displays objects by faces, not by wireframe?

*Facepalm* So you're bothering the DR coder to fix a problem just for you, and that won't even result with you contributing something to the mod. Brilliant.

You are looking for problems where there are none (or at least few). Texture memory problems are nothing in comparison to drawcall limit, which you will hit very soon, if you plan to use a lot of brushes and different textures/materials.

I think last time I saw an option to have different sizes of thumbnails in texture browser was back in UT3 editor, maybe? UDK and Unreal4 ditched it, there's only a % (zoom) slider and thumbnail size dropdown menu. Maybe some or most people (myself included) didn't use it, as frankly it makes the browser content look messy and less readable? Bear in mind that UE has a "content browser", so there's everything in it, not only textures or materials.

Typically I want the preview to be small, so I can see and apply as many textures as possible from that browser, without scrolling. Pixel density issue is less relevant when you use models for almost everything, as you have to care about that when you create them (and that's what checker override materials are for). Also, to properly examine the pixel density in-editor, we'd need a dedicated rendering mode for perspective view (with material override). Something like Unreal's "Lighting with texel density" mode:

It's easier to have commands like that bound to keys instead of pulling down console every time you need them. IN TDM root folder, create text file autocommands.cfg and paste this: bind "your_key" "noclip" That will toggle noclip on and off with each key press.