motorsep

Entity count and easier scene managing are the goals. Currently making levels a la UE3/4 is not possible because entity count will skyrocket. For example, if I bring in a segment of a ladder, and use it to create several ladders across the level, I will exceed entity count really fast. Same goes for placing decorative models across the level. With func_static supporting multiple models, I could just "group" segments, decorative models and architectural pieces into less func_statics. That would allow for more efficient and more modern approach in level design.

Would it be easy to add ability to turn several selected func_static models into one? As if you select several brushes and turn them into one func_static. Maybe having an option like "multi_func_static" "1" in a game config file for DR would enable/disable such functionality to avoid messing with Doom 3/TDM games. We are looking into having several models in one func_static, and if we figure it out, it would be nice to be able to select models in DR and turn them into one func_static.

Cool. Is another preview build coming? Btw, what about this:

Well, I have 1 script that isn't map script. So that script should run on any map that uses weather. And then I have actual map scripts unique to each map.

So I loaded my map, tried placing an entity when I realized "model" parm point to non-existent model. So I edited my .def file, clicked on reloadDefs, then on reloadModels, and then right clicked on ortho view, then on Create Entity and bam!: http://i.imgur.com/NFnjqTN.png Also, DR 2.0.0 doesn't remember last folder used in DR. I exported model from Blender, loaded DR, File > Open (or the icon) and ended up in the models folder where I exported my model from Blender a moment ago.

Do you recall how in Doom 3 each map has "call" "blah::main()" in the worldspawn ? (I am sure TDM does that too) Is it possible to call several functions in the worldspawn ? For example: "call" "blah1::main()" "call" "blah1::funcX()" "call" "blah2::main()" Thanks.

Ah, ok. Btw, did you fix the issue with projected lights by chance? I think I posted screenshot earlier showing the issue I got.

Can greebo build those for 2012 / 2013 / 2014 and 2015 ?

Thanks Well, from what I understood, the way ragdoll stuff works is it takes first child of the origin, which suppose to be Body bone (in doom 3) and aligns ragdoll by that bone. In my rig (perhaps Blender sorted it out on export) first child is eyes control bone. So, we implemented an option to specify first child bone in AF file (or if not specified, it falls back to stock behavior and then it just depends on the rig's hierarchy).

Any luck fixing the bug where models in the model viewer are not visible after CAM view mode was switched to Lighting preview and back ?

:-) thanks. As for origin, I did everything like in Doom 3. I am sure somewhere is C++ code setting ragdoll to the entity's origin fails (in reality entity gets removed after death anim starts playing, and posed ragdoll gets shown) If you look at StartRagdoll() code, and follow the trail down to the posing function, you'll see that there is SetWorldOrigin (or something like that) function that suppose to set bones of the ragdoll to the animated model's bones' locations. Not sure why and where it fails :-\

This is what's happening with my experiment: Somehow, while posing ragdoll into animation pose works fine, location doesn't get set by stock Doom 3 StartRagdoll() code. Any ideas where is the issue?

@Obsttorte: My issue is that in Doom 3, when you kill an enemy, AF starts from the pose AI died at. With my AF, ragdoll snaps to where waist is for whatever reason. Looking at it in the AF Editor doesn't really show anything odd. But somehow it seems that origin is set to be on the middle of the body at the time when AI becomes a ragdoll.

Not to be obnoxious, but I am not seeing any tutorials following those links. What I see if reference manual explaining settings, and some tips. But in no way you can call that a tutorials or a guide.

@buck28: AF (ragdolls) are set up in-game, using AF Editor. In DR you make levels and place entities. There is no way to setup ragdoll in DR. Although I always wondered what's with missing heads in DR or DOOMEdit ?

Thanks, but those don't explain how to set it up from scratch. These resources only describe settings of the editor or whad .AF is. That's why I am asking for actual tutorial.

I can not find any tutorials on how to setup ragdolls Are there any available ? Does anyone know how to set .af up using AF Editor? (potentially I can pay for a solid video tutorial)

So last night I added death anim using purely scripting. It works, expect that when ragdoll kicks in, the model snaps from final frame of death anim to ragdoll's initial location (snapping death anim's origin bone to ragdoll's waist bone).

Ah, no problem. Let's wait for programmers to dime in

Well, that still doesn't tell me where in the code of Doom 3 I should look, and what I should look for in order to add death anims preceding ragdolls (without propagating impact - that should somehow correlate to death animation; maybe an extra parameter specifying velocity on the impact)

Doom 3 coding question here! One thing I am wondering about - how do I implement death animation preceding ragdoll kicking in? Has anyone tried implementing it in C++ code? Right now it's death > ragdoll. I want death > death anim > ragdoll. Thanks beforehand!

Arbitrary Transformations floating panel is too short (same as Surface Inspector was).

I tried it again today, and I don't any differences between 1.8.1 and 2.0.0 Might stayed up working too late into the night

I looking into Sketchup with some modules that allow this kind of workflow I think the only (that I've seen/heard of) software that does this kind of procedurality/parametric modeling is Solid Works. So I am not really sure if game dev will ever go for such procedurality as the tools will cost a a lot. But it would be a massive time saver. Another example would be real-time CSG. You'd place subtraction brush in the doorway or window and if you don't like it, simply adjust position of it and when map is saved, CSG would apply. In the CAM view you wouldn't see subtraction brush, you'd see the result of CSG. Non-destructive mapping, if you will. In the mean time layers and grouping would be the thing for DR. I don't know if real-time CSG is achievable, but it definitely sounds less complex than parametric modeling / mapping.

Found interesting issue - 1.8.1 has brushes in the .map file and then orderly entities. In 2.0.0 pre10 everything is mixed up inside .map file.