peter_spy

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.

Yup, the "set sth on flame" spawnarg works, although that's more like a workaround, not a solution (i.e. you can't edit the color values with the usual color menu, etc.). It's interesting that this hasn't bothered anyone since... 2008, apparently. I haven't played with other entity classes and their dependencies yet, but if it works like that, then the usability of the whole system is kind of limited.

Usual spawnargs don't seem to work. Also, if the whole "class tree" thing is to make any sense, those light properties should be inherited and editable when you tick the Show inherited properties checkbox, just as it worked in Unreal and T3Ed. Right now it looks like this: As you see stuff like light radius isn't even there, you can't change brightness/color, some things are repeated in active current-level properties, etc. Right now it's pretty confusing.

I thought this is supposed to be a normal thing, and that's why I don't use custom light entities. Light source gets invisible, you can't see its radius and you can't change it via spawnargs.

That's why I offered posting the whole workflow here, just to have better understaning how it works (and in case you wanted to make models yourself). It's not that straightforward in case of .ase models. Btw. you can't apply materials to an .ase model for DR and TDM, if you don't manually edit it in notepad. So the first order of business would be making a material for a model and then pasting it in proper section in .ase model. LWO works in a different manner.

Yup, you need to have a project folder (fms/yourfmname) with DR pointed to that folder as well. Then your folders will generally mimic the folder structure of TDM, or you can have fewer folders for faster access. You need "materials", "models", and "textures" folder inside your fm folder to make it work. Assuming you put everything there and you're using .ase model which was exported correctly with assigned bitmap, you need to edit it with notepad, and look for *MAP_DIFFUSE section. Paste the material path in the BITMAP section, but use "//base/" prefix, e.g. //base/textures/etc.

It depends a bit on your modeling software. You'll probably use .ase models, as .lwo isn't supported in popular modeling apps. For .ase there is actually a particular workflow you should follow, depending on your needs, and for stuff like multiple materials or shadow / collision meshes. I have that in my notes, let me know if you need it, so I'll post it here. Btw. you don't need any defs for just using models. Defs are for more complicated stuff, like assigning lamp model to a light etc.

Btw. that kind of initiative seems perfect for TDM YT channel: http://forums.thedarkmod.com/topic/19392-tdm-mappers-podcast/

R_Soul, I'm not sure if you wanted a chamfer going both ways, but this would be a bit cleaner way to go:

I think pillars are func_statics, but they do have some unnecessary triangles here and there. Nothing super serious though, mostly the base and head could use some cleaning.

I was planning to make at least one of those. Pick a few you like most, I'll model and share them with the community.