Search the Community

I implemented it and are now putting it on CVS. The syntax is: entityDef prop_helmet_test { "inherit" "func_static" "model" "models/darkmod/props/kitchen/chamberpot.lwo" "joint" "Head" "origin" "2 -10 0" "angles" "10 190 80" "origin_atdm:ai_builder_guard" "0 0 20" "angles_atdm:ai_builder_guard" "0 0 0" "remove" "0" } The name must match the "classname" on the entity. // entity 1 { "anim" "idle" "classname" "atdm:ai_builder_guard" "name" "atdm:ai_builder_guard_1" "origin" "192 -456 -376" "angle" "90" "def_attach" "prop_helmet_test" } If no modelspecific value is defined then the default one is used, if present, otherwise it's 0 0 0 in both cases.

It works! I just added a smaller entityDef beneath the builder guard's: entityDef atdm:ai_builder_guard_young { "inherit" "atdm:ai_builder_guard" "ragdoll" "guard_base" "model" "builderguard" "def_head" "tdm_head_young" // "offsetHeadModel" "0 0 0" // defaultvalue if set "head_elitecitywatch" "0 0 5" "tdm_head_young" "-2 0 -8" "head_joint" "Head" "def_attach1" "ai_weapon_hammer" "def_dropDeathItem" "ai_weapon_hammer_drop" "dropDeathItemJoint" "RightHand" "dropDeathItemRotation" "0 0 0" //"def_attach2" "citywatch_helmet" "def_attach2" "elitecitywatch_helmet" } Plopped him into the game & the new builder guard with the head & helmet I wanted

Yeah, it goes into the ai entityDef. In order to have multiple attachments just add a number after def_attach: "def_attach1" "ai_weapon_longsword" "def_dropDeathItem" "ai_weapon_longsword_drop" "dropDeathItemJoint" "RightHand" "dropDeathItemRotation" "0 0 0" "def_attach2" "elitecitywatch_helmet" & here's what I have for the helmet entry: entityDef elitecitywatch_helmet { "inherit" "func_static" "model" "models/darkmod/props/wearables/elitecitywatch_helmet.lwo" "joint" "Head" "origin" "1.5 -4 0" "angles" "0 0 90" "remove" "0" } Just be sure to have a def_head with no helmet built in . . .

The rotations work correct, because the offset is directly applied to the origin. It's not really an offset to the model itself.

Any reason not to leave it full-sized? I would think the AI deserve a little more disk space for the extra detail. Btw, what do you think about adding the chainmail to the citywatch helmet? Is that feasible? It would certainly look better, and more consistant with the default head. Might cause some problem with collisions though, since it's either 100% protection or 0%. I don't know if an attached model can be part solid and part nonsolid or not.

Sixty? Try six thousand. The computer would need to know and understand so many things that it's not funny... natural language processing to understand the command, complex reasoning to deal with all the guiding principles sof game design and level design, modules for texture creation, sound creation, model creation, programming... And how does it know what "cool" is? It would need to know about the zeitgeist of the times, and social norms. Not to mention a deep knowledge of history to recreate the era of the game in a fresh way, plus enough creativity to mix in the steampunk elements (and nobody would put in all this work making this thing just to make a Thief game, so it would need to be able to use elements of other genres and perhaps even create its own genres). Speaking of creativity, that's a huge unsolved problem right there - how do you get a computer to be "creative"? At best you design some emergent rule-based system that can produce artwork, but the rules of the system and the input parameters still have to be managed in detail by a human operator. That's just off the top of my head, I'm sure the list could go on for pages; there are dozens of skills involved in creating a game, many of which we hardly pay attention to. And it would need to do all of these things better than humans, because even we get game design wrong a lot of the time.

Maybe I didn't communicate that properly. I meant that we could still have the D3 heads as they are, and since we're removing the helmets..we could also create variations by removing the faces from the current TDM heads and transplanting the doom3 faces into them and exporting them as a new model. That way, we would have d3 heads without chainmail or hoods, d3 heads 'with' chainmail or hoods and all of them would have the possibility of having helmets attached to them. Lots of variety. TDS used the attachment process for hair, jewelery, moustaces...you name it.

I was starting to do that. It shouldn't be hard since the meshes of the helmets were separate from the rest of the model anyway

Yeah, one of my next tasks is to start applying some skins to them to add even more variety and make them look less recognizable. I won't be able to change the length of the hair though. If we can figure out a way to attach helmets so they work with the KO system, then the hair won't matter anyway. Yes, the current def_attach system allows you to set up an entity, like prop_belt_pouch, set a particular joint to attach it to and then use an origin command to offset the model until it's in the position you want. Problem is, while (20, 4, 15) might be perfect for attaching prop_belt_pouch to the citywatch's belt, it needs to be (20, 10, 12) on the builder guard so it doesn't clip into his armour (as an example). At the moment, that would mean we'd have to make two different prop entities. What I'd like to be able to do is something like the same thing we're now doing for heads: prop_belt_pouch "joint" "spine" "origin" "0 0 12" // default "adtm:ai_builder_guard" "origin" "0 12 12" //aligned for builder guard "adtm:ai_citywatch" "origin" "0 10 12" // aligned for citywatch etc.

Actually, I never touched those. There's something to play around with I guess. btw, I'm trying to replace the player model with the thief.

Yeah, I started adding oDD's joints to the defs files: "look_min" "-90 -125 0" "look_max" "25 125 0" "look_joint Spine" "0.4 0.4 0" "look_joint Head" "0.6 0.6 0" "chatter_min" "3" "chatter_max" "4" "chatter_combat_min" "2" "chatter_combat_max" "2" "ik_numLegs" "2" "ik_footSize" "4" "ik_waist" "Hips" "ik_hip1" "LeftUpLeg" "ik_hip2" "RightUpLeg" "ik_knee1" "LeftLeg" "ik_knee2" "RightLeg" "ik_ankle1" "LeftFoot" "ik_ankle2" "RightFoot" "ik_dir1" "LeftLegRoll" "ik_dir2" "RightLegRoll" "ik_foot1" "LeftToeBase" "ik_foot2" "RightToeBase" "def_attach" "ai_weapon_longsword" "def_dropDeathItem" "ai_weapon_longsword_drop" "dropDeathItemJoint" "RightHand" "dropDeathItemRotation" "0 0 0" //"skin_dropDeath" "hammer_drop" "damage_zone chest" "*Spine2 -*Neck" "damage_zone left_arm" "*LeftArm" "damage_zone right_arm" "*RightArm" "damage_zone legs" "*Hips origin Spine" I actually tried "look_joint" "Hips" but that one moved to whole model! So I changed it to Spine.

OK. I see what I can do tonight. Shouldn't be to hard, as this is only a little parsing and a mapping table per model.

I think what we should do is, to modify the offset command, so that it allows to specify a modelname to give it multiple parameters. Something like this: model def head { ... offset ( 0 0 -7 ) // default offset ( 0 0 -10) builder_guard offset ( 0 -1 -6) builder_acolyte offset ... } That would be much cleaner and also easier to maintain, because you just have to add a new entry if it doesn't work for one AI. If none is defined it doesn't use an offset. If no name is given, then it is the default for all AIs where the name is not specifically mentioned and if the AI is named it uses this value.

From what I've seen in some modeling tutorials, the modeler basically imports and front and side view of the character and creates a 3D representation of it from that. That keeps the shape of the previous model, so they can share resources, but it also gives the modeler a bit more freedom since they don't have to try and build off of someone else's foundation. In the end, I would say it would still be less work to use existing lwo's as a template.

We should first look if this effect is rella there when the model is in-game or not. Somehow I don't really believe it, but it might be true. In that case the bigger feet make sense.

The model definitions don't take much room but it'd be nice to separate d3 heads from tdm heads. We could separate them according to factions later if the need arises.

I think that's because this model doesn't have any normal maps yet, to define the detail. You can really see all his low-polygon-ness at the moment.

Elite City Watch -- ascottk - mitten hands added - head cut off - resized - texture reorg The head joint on the body is too low for most heads. I added an offset head model definition which is the default (offset ( 0 0 2)) along with an elitecity head with no offset.

I've discovered that we are going to have to have multiple model definitions for the head after all. While 0 0 -7 looks good on the builder guard, it is way too high for the city watch (which needs to be around -10.5). So I'm going to need to make multiple versions, like a head_young_builder, head_young_city_watch, etc. Would it make sense to put all those into the same tdm_ai_heads.def file, or would it be easier if I made separate files for each? A tdm_ai_heads_builders.def, tdm_heads_citywatch.def, etc?

Well, maybe pink can finish it, so it can used also in other circumstances. Might be usefull, because you can also use the head just lying bloody on the floor or in some forgotten attic rotting. You probably just have to model a small backpart that is cut off anyway.

Do you also rig the model for animation? If yes, then Dom can probably brief you heow they need to be setup with the bones, so they can use our animations and attach items to them. Looking forward to your models.

That makes sense. The templates are the high poly ones. The mittens are for the low poly model, so they're added when you make your low poly version.

Exactly. If we can get the offset into the model definition, that is.

I must look if we have access to the model classes. Alternatively I can create a copy of the offsetmodel key which only acts on the head.

I don't think that this works inside a model definition. Only in an entity definition it will work.