Bikerdude: - questions

[grayman]

Who do you reckon would know about the " replace_anim_ " instructions..?

 

Examine the "atdm:moveable_base_carry_l" definition in def/tdm_prop_items.def. You'll find a number of replacement animations there, to serve as examples.

 

If an attachable entity has "replace_anim_*" definitions, those animations override the AI's default animations when that item is attached to an AI.

 

An example is

 

"replace_anim_idle"					"idle_torch"

 

This says to replace the AI's "idle" animation with "idle_torch" when the torch is attached to the AI.

 

Hope that helps.

 

Springheel helped me understand how replacements work when we were working on the AI relight feature.

 

Edit: I reread what you're trying to do, and it doesn't look like you'll be attaching an object to trigger the anim replacements. You might have to copy the basic AI definition with the default anims into a new AI definition ("drunk sob") and redefine the animations to reflect drunkenness. This is a different approach than using the replace_anim method.

[Springheel]

The sit-2-sleep animation is just the one where the AI sits on a bed before lying down to sleep. It's not what you want.

 

I'm not sure what you're trying to do is possible, since there is code involved in sleeping, but you can try swapping the animations for sitting and sleeping and see what happens.

 

You'll need to make a new model def for your AI and do the following:

 

(using the citywatch model_def as an example)

 

model tdm_ai_citywatch {

inherit tdm_ai_proguard

mesh models/md5/chars/guards/citywatch/tdm_ai_citywatch.md5mesh

channel torso ( *Spine_Dummy)

channel legs ( origin Pelvis Pelvis2 *Hips)

 

//these are the new lines you would add:

 

anim sit_2_sleep_lft models/md5/chars/guards/proguard/sit_down.md5anim

{

frame 1 disableWalkIK

 

}

 

anim sit_2_sleep_rgt models/md5/chars/guards/proguard/sit_down.md5anim

{

frame 1 disableWalkIK

}

 

anim sleep_2_sit_lft models/md5/chars/guards/proguard/sit_up.md5anim

{

frame 40 enableWalkIK

 

}

 

anim sleep_2_sit_rgt models/md5/chars/guards/proguard/sit_up.md5anim

{

frame 40 enableWalkIK

}

 

anim sleep_idle_lft models/md5/chars/guards/proguard/sit_idle.md5anim

anim sleep_idle_rgt models/md5/chars/guards/proguard/sit_idle.md5anim

 

 

 

 

 

 

}

 

I can't guarantee that would work, but it's worth a shot.

[Bikerdude]

Question:

 

How are rats able to round around on the inside of the FS model (in this case a cave & tunnels).

[Shadowhide]

AI cant see FS,but i can walk on it

 

You can create test map with FS floor brush and place AI on it,AI will be able attack and run for you

 

 

[Bikerdude]

You say that, but there there has been a gap in WS geom, Ai wank walk over the gap. And, in regards my cave there is a slight incline so bigger Ai (spider) cant walk up it..

[nbohr1more]

I know that Grayman's AI movement changes granted AI (including rats) some additional awareness of FS for pathing fixes...

 

Not sure how robust Spider pathing is though...

[Mortem Desino]

AI only "see" the virtual 3d map in the AAS files. AAS is generated only from solid worldspawn. That's how they determine accessible or not-accessible. But it doesn't at all determine their actual IK and physical reactions to the world (for the most part, that's taken care of in the map's collision model .cm)

[grayman]

Since AI pathing pays no attention to func_statics, rats don't care about the f_s cave patches. If they have world or monster_clip brushes beneath the floor, they use the AAS areas generated off of those to do their pathing.

 

The only caveat is that the patch can be no more than 16 off the underlying brushes. If you have a flat world brush floor and lay a sloping patch hill over the top of it (f_s or not), the rats will stay near the bottom of the slope and won't go up. If you change the flat floor to a series of steps ascending beneath the sloping patch, keeping the separation under 16, they'll climb the hill. A sloping world brush beneath the sloping patch works fine, also.

 

If the rat happens to bump into a f_s cave wall that wasn't monster_clipped, he becomes aware of it, and treats it like an obstacle. Pathing should then take him away from or around it. That was part of the movement changes in 1.04 to reduce treadmilling.

[grayman]

I know that Grayman's AI movement changes granted AI (including rats) some additional awareness of FS for pathing fixes...

 

Not sure how robust Spider pathing is though...

 

 

The changes weren't rat-specific. (Well, some were, but not this.) Spiders should have no problem with a f_s cave.

 

 

[grayman]

AI cant see FS,but i can walk on it

 

You can create test map with FS floor brush and place AI on it,AI will be able attack and run for you

 

 

For pathing purposes, AI don't 'see' f_s brushes. (See above.)

 

For collision purposes, they have to, otherwise, they'll walk through f_s objects.

 

If there's a f_s floor brush, it needs a world brush above or below it for passage. The world brushes are providing the AAS areas, which define where the AI is allowed to go. This is why you have to provide invisible monster_clip or tdm_nodraw_solid brushes over f_s stairs, for instance. The AI is walking in their AAS areas, and not the f_s stair, which provides no AAS, and which he can't 'see'.

 

 

[Bikerdude]

The changes weren't rat-specific. (Well, some were, but not this.) Spiders should have no problem with a f_s cave.

Well in this case is a F_S patch based cave and the rat are whizzing around just fine, but the spider cant move unless I provide some m_c brush etc.

[grayman]

Which spider?

 

Do you have it (them) using path nodes?

 

The rat and the tiny spider have "animal_patrol" set to "1", which should get them moving randomly w/o path nodes. They both use the aas_rat AAS areas, and have the same requirement of the patch being no more than 25 above the AAS area below it. (It used to be 16, but I changed it to 25 at some point to give them more running room.)

 

The other spiders don't have "animal_patrol" set, so if you're not using path nodes, they'll just sit there.

[Bikerdude]

I dint have AP set on either the rats or the spider, the cave they were in was a F_S object 1000's on units above any brush surface.

 

anyway moving on.

[Bikerdude]

Water:

 

Can some one remind me what cause of fps drop is when the player enters water..?

[Shadowhide]

Water:

 

Can some one remind me what cause of fps drop is when the player enters water..?

gui,particles,shaders

[Bikerdude]

eh..?

[Fidcal]

The only problem I've heard of is fixed by setting g_doubleVision to 0 in the console. See http://wiki.thedarkmod.com/index.php?title=FAQ#Underwater_performance_poor

 

But I guess there might be any number of map-specific problems too, for instance if the surface is controlled by a visportal or there is a complex view into an underwater cave not visible above water for instance.

[Bikerdude]

Hmmm, will have to compare my bau map version because in the original I could have sworn there was little or no fps drop..

[nbohr1more]

The new Post Process shader makes any water post process shaders much heavier than before. Though your version of the water may have been lighter because it had no murk? (I think STiFU saw that...)

[grayman]

They're just patches, you... put them along the edge. That said I'm writing up a really easy guide to doing the blend method which is ~super easy~. So I'd give me a week and see what comes of that

 

Did this ever happen? I'm tired of sharp-edged snow.

[Bikerdude]

what now..?

[Serpentine]

Did this ever happen? I'm tired of sharp-edged snow.

If that's re:vertex colors, nope.

 

I got it working, but it resulted in the meshes being dull... I cant really explain it, they were like half lit, and when I asked doom to show me the vertex colors, sometimes it would act correctly and other times random other meshes would get recolored with random colors on different verts, serious polka-dots of all colors. I got annoyed at that point and left it. However I'll see what I can do tomorrow, I want to look at the new exporter functionality in assimp and possibly write an ASE exporter, which would make all of this trivial - instead of using a script to write it from the data-structures indirectly; that is if I can remember some ol C++

 

Pretty much the workflow was : patch -> obj -> meshlab -> paint with the paint tools which are pretty simple -> export -> convert to ASE. I think I was using stl, which might have been where the mesh strangeness came in, mmm.

[Flanders]

If that's re:vertex colors, nope.

 

I got it working, but it resulted in the meshes being dull... I cant really explain it, they were like half lit, and when I asked doom to show me the vertex colors, sometimes it would act correctly and other times random other meshes would get recolored with random colors on different verts, serious polka-dots of all colors. I got annoyed at that point and left it. However I'll see what I can do tomorrow, I want to look at the new exporter functionality in assimp and possibly write an ASE exporter, which would make all of this trivial - instead of using a script to write it from the data-structures indirectly; that is if I can remember some ol C++

 

Pretty much the workflow was : patch -> obj -> meshlab -> paint with the paint tools which are pretty simple -> export -> convert to ASE. I think I was using stl, which might have been where the mesh strangeness came in, mmm.

 

I've had something similar in the past. When I exported models with a plugin for Maya 7 I never noticed anything odd about my models until I exported a model with multiple materials, all materials beyond the first weren't showing up correctly. A bit later I discovered that this was because the plugin didn't export the normal data and d3 makes his own normals for models but only for the first material. When I tried the same with rich is bored export script for blender there was no such problem.