Sorry your browser is not supported!

Anyone got any good ideas on how to "auto-crouch"?

Ideally, if a player walks under a slowly lowering ceiling, they should automatically crouch. But if they walk up to a significantly lower ceiling, such as an air vent, they should not.

This is similar to steps, where they should only step up a certain height (which the character controller already does for us nicely), only in reverse.

I'm guessing spherical collision with an angle test to see what angle the sphere hit the ceiling would work, but I wouldn't know where to start even detecting that the player controller has collided, let alone doing a spherical collision test once I find that it has. Any clues?

Another way might be to use two player controllers at the same time, and if the shorter one got further than the tall one, then assume that the player needs to be crouched, and remove and sleep the tall one until the small controller moves somewhere tall enough for it to fit again.

I can see from the sc demos that this is actually rather easy in Sparky's physics, but I'm trying to keep the dependencies down. My suspicion is that there'll be some undocumented command in DP to manage this, though. That seems to have been the answer to most of my other questions, after all!

Using Sparky's Collision DLL... you could do a few raycasts around the player controller (cast upwards) and determine the distance between the cieling and the player. then you have a few options:

-deleting and recreating a smaller character controller to go under the vent (and vice versa when coming out).

-having a big and small character controller and activating/deactivating them when you are in and out of couch mode.

I use the top method and it gives great results.

Instead of deleting and re-creating the character controller you can look at the 1.1 notes and you'll see a command to modify the extents of the controller, in other words resizing it.

TheBulk: You can raycast with DP too, though you need to use less-well-documented commands to do it. The idea of raycasting *around* the player controller is a good one, thank you. Should work so long as the max step up and the max drop down don't overlap. So I can raycast vertically up, a few cm ahead of the character at a height just above the max step up. If the ray hits a "ceiling", this would cause an autocrouch.

Wouldn't work for thin things though, like ropes, branches, planes, cloth, etc. If I could test the player controller for collision, then check what it had collided against, I could deal with those too. But I don't see a way

Airslide: [EDIT: I was wrong!]sadly, using that command (phy set character controller extents) borks the mesh collision detection completely, even after you scale the character controller back to normal size. The command appears to be unusable because of this bug.

[Edit: I was completely wrong about this, the command works fine, I was just making a retarded mistake in calling it, and had the parameters in the wrong order It works fine, and my crouching is smooth as silk now!]

Dewi Morgan can you post a code snip it of the post above,

and if you do can I use it in my game?

I'll give you fall credit for it,

in my code and on my credits,

but can you put it on so I can just copy it in to dbp and run it as a stand alone program wive no media?

just so I can get my head round it striate away.

Sindore: Short answer: "Yes, sure!"

Long answer: I'm posting my progress with this controller here:
http://forum.thegamecreators.com/?m=forum_view&t=124669&b=30

The code (and all code for my WiP) is released into the public domain, so it can be used, modified and redistributed for any purpose by anyone, in any way. You don't need to thank or credit me (though that's always nice!), nor let me know of any cool improvements you make (though I will love you forever if you do!)

At the moment, I've only posted the two main functions and a user-defined type, but they should be *fairly* easy to use. Once I'm done with the last few tweaks, I'll post a fully working, no-media example to that thread, as a "starting point" for people's WASD/Jump/Crouch controllers.

I'll also post a separate "Key mapping" function, so people can define their own keys.

Dewi - I know you're no slouch coding. I just wanted to toss ya an FYI about key mapping. If this is review for you - than let this just be a comment for others to peruse.

Important tip 1 with Keymappers
You are more than likely making a game. You should approach kepmapping in such a way that the list of "keys" to check is only as long as you're going to use in your program! Less Key checks = less overhead!

Important tip 2 with Keymappers (and user input in general)
(This one surprised me but made sense once I got the hang of it)

You DO NOT NEED to check for user input EVERY LOOP. It seems like you would... or at least it made sense to me - but when you're pushing for frame rates... Experiment with a timer. Perhaps your game plays JUST as good testing user input only every half second, or 1/4 second, or 1/10th a second. Sounds Silly - but I notices FPS jump in DBPro in iron infantry by "tweaking" this until I liked it. To slow? Bad! To Much? GREAT - but can hurt FPS a little.

...steps off soapbox...trips...falls... MEDIC!

Gosh I do feel complimented! Thanks for the tips, I appreciate them: I honestly had not considered skipping input for frames. This is mostly because while I know I wouldn't notice, there are "gam3rz" out there who have special keyboards and mice to get the extra milliseconds of responsiveness out of it, and I thought it might bug them.

Given I'm not writing a "twitch" game, though, good call.

More tips:
* I often use the construction:

However, I've no idea if this is faster or slower than using "IF keyState(KEY.Forward)". I suspect it's slower. But I find it faster in programmer time, and so long as I am getting good FPS, that's what I'm optimising for.

* Where keys are exclusive, and you cannot use one and the other at the same time, ideally you would use SELECT to pick between them. But I think in DBP's SELECT requires its CASEs to be static, which means if you use mappable keys, you can't check them with CASE. Testing each key in turn with an "if" is gonna be slow, because you're testing all of them. The fastest is probably a nested IF-ELSE-ladder, with the most often-used keys at the top. These are ugly, but do slightly optimise for speed by ignoring the less common options. If you find this ugly, you can have a non-nested chain, with a goto in each one to take you to the end of the chain.


* If you're writing a game where people can only press one key at a time (so not a FPS where people can circlestrafe and fire while jumping) then it's gonna be a ton faster to just store SCANCODE once than check KEYSTATE once for each key.