Prospero

Greetings all, I am pleased to say that my ProSphere Controller Lite software is now available. I have just sent it to OFP Info, so hopefully they'll have it on their site sometime today. Take control... Prospero

Hi all, First off, I do realise that we all have a favourite function mapped to the right mouse button (in my case, optics). But forget about that for now... (ha!). Assume, if you will, that the right mouse button is free. In OFP and FPSs in general, one never really feels in control of one's body - yes, one can walk, run, look around etc, but one can't actually lean out round a corner or peep over some sandbags with the same degree of speed and agility. One always has to fumble for keys to do these things. My idea is to use the right hand mouse button for what I guess I'll call "Pose Control". Simply put, whether static or on the move, by pressing and holding down the right mouse button you can change your pose. Forward/backward mouse motion would then control whether one is standing, crouched, or prone (and ESSENTIALLY one would have _continuous_ control, not just "step" control between predefined poses). Side to side mouse motion would be for peering round corners - and again, _continuous_ sharp control would be the ticket here. Speed and intuitiveness is everything - just like "mouse look" was a revelation back in the days of Quake 1. This way you could literally take a snap look round that corner, or over that sandbag, or contrarily, a very slow, considered peek ;) Just like, well... reality. Prospero EDIT: Just a quick edit... I meant to include this in my original post: Maximum speed of movement would then be determined by pose adopted. Let's face it, we always move as fast as possible (always run!) - there are exceptions, but such matters could be easily overcome - speed (max speed obviously pose dependent) set by middle mouse wheel button a la Splinter Cell and H&D2 perhaps (although I don't like this particularly)? EDIT: As Gameer points out later in the thread, the point is to have the up/down and side to side "pose changing" working together coherently and simultaneously - ie just pop up and round the edge of that window and fire a few aimed shots;) Yum:) Then duck back down! The right hand mouse button + associated mouse movements can be thought of as "dragging" one's pose around in the plane perpendicular to the direction one is facing. (Although some degree of of "turn" might work well too)?

Decently implemented, boxing (hand to hand combat or whatever) would also be rather fun with "pose control" Prospero

This is one thing I've been thinking about for a while. When roads are created in real life, they are often (in fact almost always) lower than the surrounding landscape, simply because earth is removed to make the road. They are not just "laid onto" the top of a terrain mesh. Therefore the edge of the road (the curb or cutting) can often offer cover from fire. It would be great to see this sort of feature integrated into the landscape creation tool (if there is one) for OFP2. How is another matter entirely. I suppose one might think a road = a bit like a trench. It is. Prospero

Call me stupid, but when we create roads we don't ship in soil to level everything up. We dig, and we dig till the surface upon which we lay the road can be smooth and level. If we need to go through a hill we dig it out and create a cutting. Errrr... maybe it's just my part of the world. I can honestly say that I don't know of a road in my area (which is rural) where the tarmac is higher than the surrounding fields. Roads are like trenches. Just shallow ones. Trivial point... those Colin Mcrae rally games. Prospero EDIT: Yes, we are talking rural, like most of OFP. OK? EDIT: Negative camber is to be avoided. Capiche? EDIT: For anyone who doesn't believe it, I suggest you download a high-res laser scanned terrain mesh of the "real world" to see it for yourself. There are some such files available on the net.

A long time ago I wrote a script to do this (which I never released because it was a little too complex and slow for realtime execution, scripts being the slow things they are). But it worked pretty well. The bomb (which was just a black spherical object), once placed on a surface on the vehicle, would stay precisely at that point as the vehicle moved and changed its orientation in space. It was great fun to place one on a helicopter, wait for it to take off and then trigger the bomb. I'd love to see this implemented in OFP2. Prospero

I think a compromise solution might be good - providing, having gone prone, one would still be able to peek up over things. One method to achieve this could be to treat the crouch to prone and prone to crouch (i.e. the two directions) differently: Example: the change from crouch to prone happens step fashion, but on the way back from prone to crouch, continuous "pose control" changing would be available. This could solve some of the trickier animation problems, whilst still preserving the flexibility potentially offered by pose control. Prospero

Actually I quite like that - It hadn't occured to me that it's entirely feasible to have a climbing-type function without a jump function. Yet still, I would prefer to jump too. But anyway, I don't want to stray too far from the thread. Prospero

Yup, which is why I suggested sensing mouse velocity to solve the "unintended" crouch to prone issue. I.e. if you pull down sharply enough on the mouse while in "pose control", it means "drop prone ASAP". Animation aside, this would be very simple to implement. But one of the problems here, rather awkwardly, is that the pose changing idea (at least for multiplayer) needs to be rendered in a third person view, rather than just (unseen) in first person. Unrelated to this thread is the matter of jumping, but I've had a few vodka & cokes, so I thought I'd mention it here since we are talking about the way in which one navigates around a 3D world. In my view, one of the greatest failings of OFP (which I still regard as the best PC wargame ever written), is the lack of a jump function. Now, I don't want to get into a "bunny hopping" discussion (and besides, I wrote a very simple jump script ages ago which can be found in these forums). My point is just this: if OFP2 includes more indoor/CQB combat (with collision detection/handling to suit), jumping becomes necessary. The alternative (particularly with large static structures or aircraft carriers) is to modify what will be very complex 3D models such that all walkable surfaces are ramped for player access. This is very time consuming, not to mention completely unrealistic. In short, jumping needs to happen (and I'd favour the spacebar as default). EDIT: We could go further - if the player walks right up against a step that is too high to jump, but still low enough to climb, the jump key automatically makes him climb up it. EDIT: Oooh just thought - pose control on ladders... so one could peek up and see what's in store... Hmmm that's going to need some thought. Prospero

Gameer, if the side to side pose was centered on releasing the RMB, the following scenario wouldn't be possible: 1) Approach and get into position at corner of building (using WSAD). 2) Hold down RMB. 3) Dynamcially lean out round corner + adjust vertical pose if necessary (i.e. one is in pose control mode now, using mouse movement to "drag" one's pose around). 4) Release RMB. 5) Now, still leaned out, aim and shoot using normal "mouse look". 6) Hold down RMB again to lean/sidestep back behind corner (or simply use WSAD). Prospero

Messed up post... hang on.

Just had a thought. Not only would one be able to lean out and aim/shoot round corners, but one would also be able to throw grenades. Throwing grenades from relative cover does sound nice. Exposing oneself completely for the whole duration of the throw is, now I think about it, why I rarely use them. Slightly unrelated to topic: I'd also halve the time it takes to throw a grenade. EDIT: Gameer, just to clear up something I probably didn't express very well: when I said a WSAD keypress should override pose control, I meant that it would only reset the side to side pose to center. One could still use pose control for vertical adjustment whilst on the move (with any of the WSAD keys pressed). Furthermore, one could just drag the mouse further to the side to begin sidestepping if one had reached the limit of lean (with the pose control button depressed) - but obviously not whilst pressing WSAD. But you have a good point - it _would_ be much nicer to remove this limitation. As I've mentioned before, perhaps a solution could be that quick dabs of WSAD wouldn't reset side to side pose, but any prolonged press would. Prospero

Yup I agree with you. I'm completely 50/50 about the way it should be done. From my point of view, I only suggest this scheme in order to get the side to side self-centering working. There _does_ need to be side to side self-centering - the only question is how best to do it... Prospero

Just so that pose control doesn't "make one stick" rooted to the spot when one wants to quickly move out of the way, and as I mentioned, so that WSAD can be used as the trigger to recenter side to side pose. Yeah, I thought Splinter Cell over-complicated the issue of forward speed (as did H&D2). For any pose there really only have to be two speeds - max (by default), and a slower stealthier speed should the "slow" key be pressed (either hold down or toggle). With continuous pose changing implemented, this still amounts to every possible speed under the sun - i.e. lower = slower. Prospero

Hehe I've just thought of a problem - but it isn't actually a problem. Handedness - i.e. when side to side leaning, it makes a difference which way you lean and in which hand you hold your weapon. But it's not too much of an issue since all BIS would have to do is ensure they allow plenty of leaning range. EDIT: One thing we haven't talked about yet is how much to roll the "camera" during a lean. I have to say my own view is very little, if at all. Any roll (regardless of vertical pose) should be there to give the player visual feedback that he is indeed leaning, rather than sidestepping (or sidecrawling) - and in this way, some measure of roll is important. But further, it's also a matter of testing to determine whether mouse aiming during a lean should either be aligned to the head lean axes or remain aligned to body axes. EDIT: Should such a scheme as I've outlined be adopted, I also believe that any WSAD keypress should override the "pose control" button (and mode), should it be depressed at the time. This way one would be able to "draw back" quickly and intuitively from any hostile nastiness using the familiar WSAD keys (accompanied by an immediate straightening of pose if one happened to be "leaned out" at the time). EDIT: Regarding speed of movement, I think it's pretty simple (as far as GAMES go) - default should be as fast as possible (according to vertical pose), with some kind of modifier for slow stealth. This is much simpler than a whole range of speeds which, in all honesty, no-one will ever use. Besides, owing to the adopted vertical pose + fast/slow modifier, there would be a whole range of speeds/stealth available. EDIT: Almost a trivial point, but since "amount of lean" should properly be dependent on vertical pose, I would say that standing lean and crouching lean should lean identically, with a slight reduction in lean for prone (this is a playability compromise, but still realistic). Actually no, keep it simple - max lean displacement same for all vertical poses. Prospero (the edit king)

I'm quoting myself, but I wanted to make a point: The second edit (above) could well provide a solution to the problem mentioned in the first edit (i.e. the self-centering of side to side posture). I.e: If the "dragging the mouse further to start sidestepping" idea were implemented, the side to side pose could simply be centered as soon as a WSAD keypress is detected. The beauty of this is that one could still maintain a leaning pose (for shooting around corners) + move side to side (for adjustment) + move up and down --- all without having the side to side pose suddenly reset itself to center (which would be awful and totally spoil the kind of careful sniping (or CQB - ha!) scenario I'm envisaging here). I just can't imagine that many scenarios where one would want to be able to move forward/backward whilst leaning... at least I don't think it's critical. Then again, I could be wrong. It might be more intuitive the other way. It's a suck it and see kinda thing. I do hope that makes sense. EDIT: It should be noted that releasing the "pose control" button (right mouse button or whatever - it really could be any key at all - Q, for example) must of course NOT recenter the side to side pose, and nor must subsequent mouse aiming motion. This would render the whole exercise entirely pointless. EDIT: And yes, the Baron seems to be actually reading the thread rather than just scanning through it. Prospero

Yep, I like your proposed scheme too. The prob is still though, to achieve it all seamlessly with _just_ one button (i.e. the right mouse button). Otherwise it severely compromises the elegance. I'm sure it is possible, it's just a matter of thinking deeply (never my strong point) ;) By the way, ever wished they made mice with a stiffer spring for the middle wheel button so that you can turn the wheel without pushing the button? Or is it just me? Prospero

I've been thinking more about this (since there's been a bit of positive feedback), and I guess the hardest thing to work round (in terms of both animation and just straightforward playability) is the disjuncture between standing/crouched posture, and prone posture. There's a point where it becomes tricky to implement these two "modes" of movement in a truly _continuous_ manner. A practical example: Let's say it were implemented as a truly _continuous_ change of posture - i.e. all the way from standing to prone (and back again). In this case one might find that one had moved the mouse too far, and had gone prone accidentally when one had only meant to crouch down as far as possible. This would spoil the whole thing completely, as one would suddenly find oneself moving at crawling speed rather than crouch speed (huge difference). This said, one wants to be able to go from standing to prone in some situations (i.e. "diving for cover"). I don't really have a solution at the moment, but hey, I guess I'll keep on thinking. There would need to be some extra control (or feedback) for the player to deal with the crouch to prone posture change? EDIT: One idea: to "unlock" the ability to go beyond full crouch and to prone, one would signal one's intent to do so by holding down right & left buttons (together). On the way back up from prone to standing, just right mouse button would be necessary (though you could also keep both buttons pressed, if you wanted). Shame to complicate things though... EDIT: Regarding side to side posture change (for peeking round corners): I'd exaggerate it as far as possible (the human body is very flexible!). Plus there's the issue of self-centering (or resuming a straight pose), but I think this could be dealt with relatively easily: Any prolonged movement (i.e. WSAD crawling/walking/running movement) would quickly but smoothly reset the side to side pose to its central position. Only way to figure out how prolonged would be through testing, but I wouldn't imagine more than a second...;) EDIT: Of course, the truly elegant thing to do regarding side to side posture change would be that if the player reaches the limit of the peeking posture but finds he's not quite round the corner, he automatically begins sidestepping (or sidecrawling) in the direction of the peek without the need for WSAD movement - i.e. simply by dragging the mouse further in the intended direction. EDIT: Another way to deal with the "unintended" crouch to prone problem might be to simply detect velocity (and/or acceleration) of vertical axis mouse motion: I.e. only if the player gives a really fast tug downwards on the mouse does it mean, "Go prone! (dive for cover!!)" And hence no need for the left mouse button. There would have to be an option to determine the rate in Options however, to suit different people's tastes. I should note here that most of the problems exist from standing to prone, which often needs to be fast, but not from prone to standing, which can be a slower, more considered affair. Prospero

1) Compiling of scripts, and some limited form of scheduling. 2) A setAttitude command (passed three arguments - yaw, pitch and roll) and a setAngularVelocity command (passed the three rates). 3) Objects able to stick to other objects (aircraft on moving carrier, for example). 4) Shadows of objects being cast on other objects - not just the ground. Prospero

Another thing I like about it is you can lean side to side AND move at the same time. This overcomes the problem whereby you try to lean round a corner but aren't quite close enough to the apex to see round it - which is very annoying! (And which is why I never bother to lean round corners in FPSs). Prospero

But the movement is very smooth, and it's ideal for poking your gun around a corner and popping a tango. OFP doesn't need this unless BI wants to seriously improve CQB in OFP2. Some people just aren't with the program. CQB must be a military term;) Prospero

Hehe. I've never played Raven Shield. Well(!) at least someone else is considering it. In Raven Shield is the pose controlled directly by mouse? I.e. quick fluid torso movement? Prospero

Hi all, I just played a demo of (shoot me) a sailing simulation called Virtual Skipper 3. Now, it really is a terribly boring game, but by golly, the sea/water effects are stunning. These, combined with great use of maritime sounds, transform an otherwise dull experience. Admittedly there are some clipping issues, but if OFP2 includes proper swimming/shipping etc, I can only hope the sea looks (and sounds) as good as in Virtual Skipper 3 ;) By the way, VS3 is seriously worth the download just to see the sea effects Sod the sailing. You can use the numeric keypad to pan around and zoom. Have a look. You will be charmed. Prospero

Just seen this thread. Accurate determination of absolute height is not as simple as it should be, but it has been addressed at considerable length. It's highly likely that a search on "absolute AND height" will provide you with what you need (providing I wrote what you end up reading). Prospero

For those wanting to get a little more involved in flight-model scripting, I posted some info in a thread in this forum a while back. The message subject line to search for is: "Calculating air resistance, Needed for an arty script" (Type "Calculating AND air AND resistance" in the search box and you should find it). Note that until compiling scripts becomes an option (and indeed, a few other things), it remains a curiosity rather than a practical proposition. Roll on OFP2 perhaps. Prospero