Sinking through patches

[Springheel]

Anyone know of reasons why an AI might sink into patches? I've got a fairly typical patch on a section of ground and a patrolling AI sinks into it nearly up to his ankles. Yet a nearby one he walks on properly. Both have monsterclip under them. The one he's sinking into is a func_static (so I could turn shadows off). Is this a known problem with func_statics?

[nbohr1more]

I'm pretty sure that func_static is not treated as part of AI path geometry. It has the same problems as using models for terrain as I recall.

[Springheel]

I thought they'd path on them as long as there was monsterclip underneath?

[AluminumHaste]

They see the monsterclip but not the patch or func_statics. Func_statics and patches are solid so AI will walk on them, it's just that they don't know that they're walking on it. Not sure what is wrong with that AI though. Maybe make sure all the vertices of the patch are grid aligned?

 

That being said, I haven't had any issues with func_statics and AI myself.

[grayman]

I thought they'd path on them as long as there was monsterclip underneath?

 

Yes, they will. I can't think of any reason why they wouldn't if the monsterclip is just underneath the patch. If they couldn't traverse the func_static, they'd stop moving. Sinking is a new phenomenon.

[ERH+]

" AI walking over a lone monster_clip brush that has no entity core will sink into it by about 28 units. This means that if you make an invisible AI-only bridge of monster_clip then it needs to be 28 units higher than where you want the AI's feet to touch. So a channel with side walls with top surfaces at 100 will need a bridge whose top surface is at 128 in order for the AI to walk smoothly across flush with the side walls. Because 14 to 16 is the maximum step height for an AI you will need a short step of monster_clip at the entrance and exit for the AI to get on. So this step might be 14 units high but can and should be very shallow - even one unit deep is enough for the AI to pass smoothly on to the main bridge. "

http://wiki.thedarkm...zontal_Surfaces

 

I had similar problem with func_static stairs, monster_clip somehow override func_static collision model (for AI legs). I don't remember it well but changing monster_clip to NoDraw_Solid may change it?

Edited March 15, 2014 by ERH+

[SteveL]

Yet a nearby one he walks on properly. Both have monsterclip under them.

Is the texture the same? You won't have set solid 0 on the FS, but it could be in the material file.

 

It's definitely not a general problem. *All* my exterior floors are fs noshadows patches with monsterclip or nds under them and I have test ai exploring every corner.

Edited March 15, 2014 by SteveL

[grayman]

Mayhaps a test map showing the problem is in order, so we can see the details.

[Lux]

I was thinking because one AI exibits the behavior and another doesn't that it has to do with their origin and initial placement. Are they both placed the same height above/contacting the ground surface in DR?

[Springheel]

Only one AI paths over it atm, so I'm not sure if the behaviour is consistent.

[Springheel]

After playing around trying to fit monsterclip underneath them to keep AI from sinking, I discovered that the problem is not just limited to AI. See image.

 

The patch is acting as if it is completely nonsolid, even though it is worldspawn and should be solid by default. I thought it was just a cosmetic issue, but now it could actually affect gameplay as well.

 

I've noticed several patches that work this way in my map, though not all of them, and I can't see any obvious difference between them.

 

Any ideas?

[grayman]

What happens if you change the texture?

 

And are those moveables? Did you place them above the patch in DR and let TDM drop them to the ground for you, or did you place them exactly on the ground and they ended up sunk in?

[Springheel]

These are movables that I just drop onto the patch. They sink right in as if the patch wasn't there. Walking AI do the same thing in the same places.

 

I just tried copying the patch, texturing the copy with nodraw_solid_stone and moving it a few units above the visible patch, but that had no affect either.

 

I haven't tried changing the texture, but there are patches with other textures doing the same thing, and patches with the same stone texture without the problem.

 

Will AI walk properly on func_static patches? I could try that.

[grayman]

These are movables that I just drop onto the patch.

 

You move them onto the patch in DR, or you hover them above the patch and let TDM do it?

[Springheel]

I'm doing it in game.

[grayman]

Very odd. Sounds like the *.cm file is messed up.

[Springheel]

I'm deleting it before each dmap to make sure there's nothing out of date.

[Springheel]

Tried copying the patches, raising them a few units above the visible one, texturing them with nodraw_solid_stone, and turned them into func_statics.

 

No change. Movables still fall through the surface.

[grayman]

Can you create a small test map showing the problem? Objects are dropped to the ground at spawn time by tracing down and seeing how far the object needs to fall. I could look at the code to see why it's letting them fall farther than they should.

[AluminumHaste]

I wonder, is it possible that the placed objects are inside the patch bounding box when game starts, and objects are stopping when their origin hits the patch instead of the edge of the collision mesh?

[Lux]

I'm doing it in game.

 

He's talking about not placing the objects isn't he? Just picking up a moveable off a table or something and dropping it from hands on to the floor. It doesn't have anything to do necessarily with the object placement at map start.

[grayman]

He's talking about not placing the objects isn't he? Just picking up a moveable off a table or something and dropping it from hands on to the floor. It doesn't have anything to do necessarily with the object placement at map start.

 

@Spring,

 

Is Lux correct? Or are we talking about where the objects are at the start of the mission?

[Bikerdude]

Can you create a small test map showing the problem? Objects are dropped to the ground at spawn time by tracing down and seeing how far the object needs to fall. I could look at the code to see why it's letting them fall farther than they should.

Hmm, that shouln't happen. @Gman, I have the map and can PM the whole map or just that section.

[Lux]

I actually notice this in RJFerrets new one, Inn Business, as well. There are patchy grass textures around the street areas and I picked up the doll and carried it over to a corner and when I dropped it (I did this a couple times and it was repeatable) on the patch grass, it would sometimes sink a bit in the ground. It wasn't consistent but it always clipped and sometimes would come back up like the engine recognized it and tried to fix the situation but never did a very good job of it curious enough.

 

I thought maybe it was the doll model at the time, but now I'm thinking maybe not.

 

Also of note, I think this has been introduced lately (v2.01?) because my initial mapping effort that has all patch walkways (v1.08), I had a test guard running around on it (severe angled hill slope) and there was never any clipping I noticed in multiple times testing it.

Edited April 13, 2014 by Lux

[grayman]

If we're talking about touching a moveable and having it disappear into a patch (are we, Spring?), then this behavior has been around for a long long time. I had to compensate for it back in SATC when we had the vertical contest (2010).

 

I suspect that the engine doesn't do a proper job of keeping small moveables on top of patches when objects sitting on them are touched.

 

But I don't know if this is what Spring's experiencing. I thought his problem was all about what these objects did at spawn time.