Sleepers height rethink needed

[Fidcal]

I'm currently placing sleepers in my FM and getting mixed results. One sinks below the bed; another floats two feet above it. I've improvised several things over the last year or so to get round this - non-solid beds, worldspawn beds, mover beds, teleporting beds, monsterclipped beds, non-monster'd beds, moveable, non-frobable,non-pushable beds. There has to be a better way.

 

What determines the height of the sleeper? I believe sitters take the height from the position of the AI before the sit down animation. That animation defines the height and all else is ignored I think. This seems to work reasonably well. Perhaps sleepers should do the same to be consistent. It is then up to the mapper to set the bed to that height. If necessary put a step next to the bed to raise the AI.

 

A more flexible method might be the above but with a spawnarg sleep_height. This would mean the height the AI is moved to after the animation no matter what. We already have a 'slide' for both sitting and sleeping and this would be the same idea but sliding up or down except I think it might work better as an absolute from the sole of the AI boots before the animation, ie the floor at the side of the bed which is fixed and the bed can be ignored for this calculation. The default setting for sleep_height would be the height of the standard beds. I think one bed model is non-standard as I recall but I think the others are the same.

 

So if the bed is slightly high and the mapper sets sleep_height accordingly then during the animation the AI sits on the bed, sinks into somewhat, lays down (sinking too deep) but at the end rises up to the correct height. Likewise, if the bed is rather low, he would sink down to it after the animation.

 

On arising the AI would have to be raised or lowered by 'standard' minus sleep_height before the get up animation begins.

 

A better method might be if the AI could be raised/lowered during the animation but I don't know if this is possible. Can a 'timed move' be initiated on the AI and the animation take place during it? Like an AI wiping his nose on an elevator?

 

The above would work fine on all average bed heights I think and the sinking and raising look no more odd than the sliding we have now. In theory, the mapper could use this sleep_height to get an AI to sleep on the floor. Not ideal but better than nothing. What you'd see would be the AI sits down in thin air, lays down in the air and sinks to the floor. I would soften this by putting down thick straw sacking and maybe a slight invisible pit in the floor so the AI is already sunk down a couple of units while standing at the side. If the rise/sink could be incremented throughout the animation then what you'd see is the AI sits down in thin air but his boots are slightly sinking into the ground, as he rotates and lays down in thin air he is lowering all the time and by now is almost on the bedding.

 

However, that is less important than having a reliable sleep height that the mapper can control. Currently I have no idea where the sleeper is going to float except by trial and error and improvising specially modified beds. I do not even understand the rule at the moment. It is not the height above the bed surface that defines the height. Nor is it the height above the floor below the bed.

 

Ironically I currently have an AI getting into a top bunk via a step and this is working fine. But two other AI in single bunks are 'floaters'.

[Springheel]

The height AI sleep at is consistent if there is no bed there, I believe (if not, then something weird is going on). But the sleeping figure has to be solid, or you wouldn't be able to hit them. So there is probably some physical interaction between the AI CM and the bed mesh that causes some odd effects. Is there still a problem if the bed is non-solid?

[Fidcal]

I'll have to retest that. I think I've had some success with non-solid beds. But it can't remain non-solid in-game so the mapper has to construct a worldspawn nodraw solid frame to match the bed, head and foot boards etc. Not really ideal. I think I have an early one in my FM like that. My current problem ones are brush func static beds with a model mattress and func_static patch pillow. Perhaps if I make the bed worldspawn, the mattress and pillow non-solid then insert a worldspawn brush into the mattress. Yet the double bunk is the same and that one is working - I just give the AI a couple of steps to get to his start position at the side of the bed as if he were on the floor.

 

So are we saying that the AI does indeed go through the animation and ends at the height defined by that and the sleeping code does not change anything (same as sitting I presume) but its the collision physics which then kicks in? But we do know it's possible for the sleeper to be at the right height sometimes without error.

 

What holds the sleeper in position? Is his bounding box modified or something. I have got one AI floating a foot off the ground below a bed I raised slightly and another floating above one I raised a different height. It's like the bed or mattress is repelling the AI either up or down but away from itself - yet it floats so its fixed in space relative to what? One is fixed one foot above the ground and another is about 4 foot above the ground.

[Springheel]

So are we saying that the AI does indeed go through the animation and ends at the height defined by that and the sleeping code does not change anything (same as sitting I presume) but its the collision physics which then kicks in? But we do know it's possible for the sleeper to be at the right height sometimes without error.

 

I don't know the specifics of the code Angua used, but the above is my understanding, and fits what I've observed when testing sleeping recently.

 

I've noticed AI float above the bed too, but in the cases I've seen there was a footboard in the way, and I assumed the AI was floating above that. I can't answer any of this with real confidence though. I agree it would be nice to polish this up (though the falling through the floor problem is more pressing, IMO).

[grayman]

where is the ai's clip model through all this?

[Fidcal]

This is what it looks like. I raised the bed to try to get it to the height was hovering at before but now she is below it. I see three components but I don't know what each is or their functions: vertical red cylinder, horizontal cyan block, horizontal red simple mesh.

 

[Fidcal]

As a test I set up 5 identical commoners all set to sleep:

 

The first with no bed at all

Next worldspawn brush

func_static brush

Model mattress

Bed

 

All appear to be perfect immediately.

 

So the bed I set up some months ago I think might have been the odd one that is a bit high, I'd have to check. The current ones are brush func_static with model mattress. Just my luck if they are the two types that go wrong.

 

[Fidcal]

Next I add the single bunk bed prefab - identical to the ones in my map - yet it works fine here. He is slightly high but the bed surface is slightly lower than the standard beds so that's OK.

 

The other bed is the 'rogue' bed where the AI is floating high. Looking at the cm I think that's what Spring was saying about it interacting with the footboard.

 

But why is the bunk bed different to in my FM? The only difference is they were female - rogue and wench. I'll try those in the test map.

 

[Springheel]

The other bed is the 'rogue' bed where the AI is floating high. Looking at the cm I think that's what Spring was saying about it interacting with the footboard.

 

Yes, that's the same bed I had problems with. It doesn't look like there is enough room for the AI to fit lengthwise in between the head/footboards. I'd try making a CM that allows more room for the AI, but it's an .ase model so I can't adjust it.

[Fidcal]

OK the female with the dress varies depending where I stand her and I have a theory she has a wider cm because of her dress so it clips the bed and raises her up before the animation. Further out she seems OK but then she is too far out so I'll need to add some serious slide to move her over.

[Fidcal]

[Fidcal]

Now this is starting to make a little sense. The guy on the high bed - I wondered why he floated a little high rather than sinking in a little because the bed is high after all. So I wondered if he was clipping at the start too. I moved him out a little bit and now he is sinking slightly as expected - the bed is too high - fairly easily fixed by lower the bed slightly into the floor I think. So it might not be that footboard at all.

 

So this problem is likely to only affect AI that start as sleepers rather than patrol to a bed where, presumably, the normal physics would prevent them getting too close.

 

[Fidcal]

OK, I think this is significant because you never see it a real game - you'd almost never start the player close to a sleeper. So it's inexplicable when you find a sleeper floating so high. So anyways, I've added it to the wiki article and given said article an upgrade while at it.

[Springheel]

So this problem is likely to only affect AI that start as sleepers rather than patrol to a bed where, presumably, the normal physics would prevent them getting too close.

 

What's the difference between sleepers that patrol and ones that don't? They both start as standing and play the whole sit2sleep animation. I don't see why they would behave differently, unless somehow the mapper puts them so close to the bed that they're clipping into it at map start. Is that what you mean?

[Fidcal]

Yes exactly. Patrollers just get blocked in the normal way from getting too close whereas if you start the AI close to the bed they might be clipping right from the get go. And you can't see it in Dark Radiant. I saw a clear gap between AI and bed but they still clipped. Now I've moved them out a little and increased the slide across to compensate they are at the correct height when sleeping.