peter_spy

The site says it's 32 megs, while the mission is actually 108 megs. That's probably because of intro video which was added later, IIRC. http://www.thedarkmod.com/missiondetails/?id=123

That's good to know, I'll update the video drivers then. (On a completely different note, is it possible to change user names of the forums? I don't want to lose the profile, but I'm kind of tired of this nick, it's misleading and I haven't been using it outside Thief forums for decades.)

Another site with free hi-res materials: https://www.cc0textures.com/tagged/all Edit: whoops, sorry, this seems like a clone of https://3dtextures.me/

My PC is having some weird symptoms lately: suddenly monitor indicates no video signal, and the system just stays like that until powered off or reset, or it shuts down on its own, without any logging off message or anything. Do you know whether that's a sign of RAM or HDD problems, or maybe something with PSU or video card? The CPU / mobo / RAM combo is pretty old by now, HDD isn't super new either.

You mean level streaming? No, the whole level is being loaded. Game uses portals to split map into areas for better performance. There is also an LOD system for selected objects.

Ehh, since this is more like a total conversion project, it will be quite some time before I finish all the assets. I'm sure we'll play your lovely Blackheart Manor first

Actually it 128 on those wall panels looked fine until I started adding AIs, now it looks huge: Simplified proportions make it a lot easier to use texture space, and to design pieces so they snap easily on higher grids. Those babies work even on grid of 32, so making a set of corridors is usually pretty fast. I kinda wish I made them smaller, like 96 maybe. That would require more complex calculations for the number of panels though, and I'd probably would have to go down to the grid of 4. With big arch pieces, I prefer to stick to 16 or higher, as it's super easy to miss something on lower grid.

Setting lower resolution helps a bit, although it's QHD and 4K where the engine really struggles, so you should be safe with HD or Full HD. The game might not look like it's demanding in terms of graphical fidelity, but remember that most things, shadows included, are calculated in real time. Also, most models use multiple materials and tiling textures, which clogs the CPU->GPU pipeline. It probably wouldn't be that big of a problem if we had engine running on more modern version of OpenGL, but for now it's quite likely that it uses like 10% of your hardware capabilities.

Actually, frob can be improved a lot, both in terms of visibility and reach, and tweaked per material and lighting conditions. Some time ago I wrote my own version of frob shader, and it works pretty good.

I never ever used lean forward whether in Thief 1, 2 or in FMs. All keys around WASD are bound to lean sideways, crouching, using items, etc. Also I can't think of a single game that would require you to use it, so I think demanting it from players would be a pretty bad idea.

Thanks I must say I still have problems with scale, things almost always end up bigger than they should. I'm used to heights like 128, 192, 256, because it's easier to match tiling textures (and design tiling meshes for grids like 16 or 32), but with player being 80 units high, that looks way too big.

Modular wall concept for the current location I'm working on:

There is no need to be compatible with other engines just as a principle, but you can see that they build the structure better, and prioritse functions according to users' needs. With light entities, you need to be able to change light properies often, that's a priority. Particles can be attached e.g. to a helper, or just in relation to a static model, and tweaked in particle editor, and that's it, for most cases. The main goal is always speed and ease of use. As you know, mapping is already long and complicated process, so everything that speeds it up, even just a little, is invaluable. That goes for both using the editor/engine and amount of things or parameters to keep in mind while mapping.

IMO it would be consistent with how it's used in other engines, i.e. you want to create a light, first and foremost, right? So you go from a general light class > light with certain properties > certain light with certain model representation. From general to narrow. Not from a func_static to certain particle to certain light. The second approach forced you to create workarounds that make it all more complicated and longer. Don't mean to sound rude, but IMO the whole goal of TDM was to escape from all the quirks and workarounds of Thief Deadly Shadows, not to exchange them to quirks you know and understand, because you created them yourself

Wouldn't it be easier to just offset the position of the light to match the attached particle, and still have the ability to change light properties in DR? And "extinguished" "0" is actually taken from atdm:static_electric_light_lit_base, as that light source was supposed to play similar role.

Nope, I can only move light_center, and it looks weird, as in my previous example (btw. this distinction between light_center and origin also feels confusing).

I'm not 100% sure of that, but for now I believe it's more about the perception, and the way the class tree is used, and not as much a coding problem. At least based on what I did so far. I basically created two simple defs, one is the light source and it inherits the atdm:light_base: entityDef cor_lamp01_white_source { "inherit" "atdm:light_base" "AIUse" "AIUSE_LIGHTSOURCE" "lightType" "AIUSE_LIGHTTYPE_ELECTRIC" "extinguished" "0" "light_radius" "256 256 256" "_color" "0.502 0.502 0.502" "texture" "lights/do/cor_lamp01_pulse" "shaderparm3" "0" "shaderparm4" "0" } And the second is the model, which inherits the cor_lamp01_white_source (not func_static or anything else): entityDef cor_lamp01_white { "inherit" "cor_lamp01_white_source" "model" "models/do/cor_lamp01.ase" "editor_displayFolder" "Lights/Electric" "light_center" "-48 0 -32" "skin" "cor_lamp01_wht" "skin_lit" "cor_lamp01_wht" "skin_unlit" "cor_lamp01_unlit" "shaderparm3" "0" "shaderparm4" "0" }And it works just like in the Unreal class tree. The cor_lamp01_white entity has a light radius, and lets me edit the light properties in the map, even though it's not a light. The whole thing with def_attached seems like overcomplicating things and not using the potential of class tree system.

As for objects, that's kind of mappers choice and taste. I don't like having a thousand insignificant bottles interactive, but there are mappers who think that adds to the world being more realistic. Using chests and drawers is the similar problem. While there was a "lean forward" move in original Thief 1 and 2, the game never forced you to use it. But there are mappers who claim this is as natural as using WASD.

Obs, that's a stock TDM light, you can see it under Create entity>Lights>Model lights, Static>Gas. All I did was selecting Show inherited properties check-box in Entity tab, selecting "texture" and changing it from "lights/biground1" to something else. New value for that spawnarg appeared right under it, but it doesn't work in-game. So my guess was either the class system is borked, or something is inherited in a weird or wrong way. As I said before, using stuff like def_attach with invisible light radius and some intermeriary spawnargs is more like temporary workaround, not a real solution. Let me show you how it should probably work, This is UE 2.x actor (entity) class window: The structure is clear and simple, you go to world objects, choose a torch and place it in the map. Then you check the box to show inherited properties, and they appear on a current level (so in the entity placed in map). Then just change the values as you need, so they change from "grayed-out" to "active", and that's it. No doubled values, no intermediary variables. There's nothing super-speedy about that workflow, it's just... normal. That's why I highly recommend studying other engines, at least from time to time, to blatantly steal their ideas Not from a coding perspective I guess, but in terms of stuff like structure, UX, and interface design. This is all tried-out and already proven stuff. It saves you time, so you don't have to reinvent the wheel. That said, I tried to do something similar to above in DR, and came up with what I expected, the result was similar to Biker's. The light was at the model pivot point, although its properties are editable and the radius is visible, which is good. Using vertex mode or changing the light_center results in an unpredictable effect though, compare the position of the light center in the editor and how it looks in game:

Obs, see the example I posted above. Try changing a light texture in that wall lamp. The spawnarg gets repeated with new value, it isn't greyed out anymore, but the new light texture doesn't work in game. I also tried to make a few entities of my own, in a way it was done in Unreal actor classes. I.e. I created a light source (inherits light_base), and a lamp model (inherits my light source), and now the light shows up in the editor, along with all its spawnargs, and the radius is visible and editable. Edit: vertex mode allows to move the light center slightly, there seem to be a sort of limit here, not sure about exact values. Still, that's better than immovable light source.

I thought using commandline arguments for DR is obsolete, as you can choose your project either at DR startup, or switch to another project later, using the File menu.

Not super interested in the series, but it does look fantastic from a technical standpoint. Attention to detail in all aspects is incredible.

I havent fired up T3ed for quite some time too, but I rememer how it works (it's common for all Unreal 2.x engines and probably further). The workflow implemented in DR is slower and less clear than that. To make things more streamlined, users should be able to bring the inherited (grayed out) properties/spawnargs to the current level. So the stuff like light radius, color, or texture would initially be grayed out, but if user changes the value, it would be "brought to the current level", not sort of doubled, like it is now (and not working anyway).

Hah, the thing there should be a difference in speed, in favor of the entity class structure Have you seen the Actor Class structure in older Unreal engines, Obs? That should give you the idea of what I mean.

One of the most useful features of the entity classes system is ability to use any of the values inherited with parent items and change their values in current entity, whether down the dependency tree, or just the one placed in your map. If you can't do that, and you have to use other intermediary variables, like "set on..", it makes the whole process more complicated and longer. Right now, it's faster just to place a lamp model, a light, and a particle, set their values, and group them in a "staging room" of your map, so you can clone them and ungroup them to tweak the values. It should be the other way around.