[Dragon]

Recently, Scooby Doo started working on adding landing gear to his ships: http://www.hard-light.net/forums/index.php?topic=82639.new#new
While landings in FSO work, they could use a few improvements. My proposed changes:

1). Changes to collision detection. Right now, for capship to fighter collisions, only the capship's mesh gets checked. Fighter gets only a radius check for performance reasons. This is reasonable in most cases, but may cause strange behavior when landing. It's especially noticeable with fighters that have one dimension disproportional to the others, like most "plane-like" designs. You either experience "phantom" collisions where the ship seems it should fit, or you can make ship's nose sink into the capship's mesh a bit before collision occurs. I've tested it myself, using Scooby's Javelin fighter, which is rather flat and his Enterprise carrier, which has a narrow fighterbay.
There are two possible approaches to fixing this:
-Simple one: Enable mesh to mesh collisions with large objects for the player. Additional restrictions could be made, for instance speed being below either landing or reorient threshold (or maybe a separate speed threshold for this). It's only noticeable when moving at low speeds so this should fix the problem.

-Complicated one: Add some sort of "wheel" subobject type, which would be an additionally checked for collisions with large objects. This could potentially allow for making AI land in a realistic way (it would also require the ability to force AI to roll the ship into correct orientation when approaching a bay path), as well as making working ground units such as tanks, cars and buggies. To save performance, an option could be used to "connect" it to an animation, so a folded landing gear wouldn't be checked for collisions.

2). A precise way to tell the fighter has landed. This might be complicated, as FSO would need to know when the ship has landed and perform an approbate action. num-ships-in-box SEXP might do the trick (it works for Diaspora), but with a lot of ships of different sizes, it'd be a bit too imprecise, or tedious to set up. Basically, a SEXP checking if a ship is touching a subsystem with "allow landing" flag.

3). A key to drop the landing gear. It's SEXPable as of now, but one Antipodes 8 get commited, a separate key for landing gear would be great. It's not a necessity, but all the serious flightsims have it and it'd add to immersion somewhat.

[Zacam]

Like with Diaspora combat landings, any other landing type could be easily handled without requiring much in terms of player interaction.

First, lets not forget that FSO is not a "serious" sim. Doesn't stop it from being able to be one, but it's not there yet.

Secondly, easiest implementation for landings would be an animation type, rather like docking, that could be used to trigger the model animation to take place. The animation would look a lot better once we actually get object translation in place, otherwise it is really just a very clunky hack. Then you can set up conditions/sexps to call to that animation trigger to make landings happen, along with option camera control changes if you wanted it to give some sort of external "end of mission" view for the landing.

3rd: Having "wheels" might be awesome, but it's already technically possible, in so far as having a round rotating sub-object. Having one that only rotates with a static friction to an impacted surface, well, that's not so easy and the means for faking that intelligently are less than easy.

[headdie]

thing is from a concept pov landing gear is a natural next step onwards from the landing code already in place, even just controls for the final resting distance from the landing surface would make sexp controlled landing gear more convincing.

[Sushi]

(it would also require the ability to force AI to roll the ship into correct orientation when approaching a bay path)

This much is already possible (Diaspora does it).


IMO the most important element missing right now is collision detection/response that works well for a "landing" scenario. Unfortunately, this is pretty tricky without rewriting huge chunks of the collision detection and response engine (I should know, I messed around with it for Diaspora). I agree that trying to use mesh-mesh collisions (under the right circumstances, perhaps a SEXP to force mesh-mesh collisions between certain ships?) is a good starting point (or at the very least fighter bounding box vs capship mesh).

[Dragon]

First, lets not forget that FSO is not a "serious" sim. Doesn't stop it from being able to be one, but it's not there yet.

The whole point of this suggestion is getting one step closer.

Secondly, easiest implementation for landings would be an animation type, rather like docking, that could be used to trigger the model animation to take place. The animation would look a lot better once we actually get object translation in place, otherwise it is really just a very clunky hack. Then you can set up conditions/sexps to call to that animation trigger to make landings happen, along with option camera control changes if you wanted it to give some sort of external "end of mission" view for the landing.

For AI, maybe, but I'd really like to have fully controlled landings for players. Scripted animation could be an option (Automatic Carrier Landing or ACL is an option in real planes such as F/A-18), but it shouldn't be the limit.

3rd: Having "wheels" might be awesome, but it's already technically possible, in so far as having a round rotating sub-object. Having one that only rotates with a static friction to an impacted surface, well, that's not so easy and the means for faking that intelligently are less than easy.

For the start, we don't need to actually see the wheels rotate. Unless looking really, really closely or with some sort of fancy "hubcap", the wheel rotation isn't that noticeable. I haven't seen wheels in Starshatter rotating, so I'd say static wheels can look good enough. Basic landing gear can already work, my request concerns improving the support for it to look believable.

(it would also require the ability to force AI to roll the ship into correct orientation when approaching a bay path)

This much is already possible (Diaspora does it).

That's good to hear. Do landing physics already apply to AI fighters?

IMO the most important element missing right now is collision detection/response that works well for a "landing" scenario. Unfortunately, this is pretty tricky without rewriting huge chunks of the collision detection and response engine (I should know, I messed around with it for Diaspora). I agree that trying to use mesh-mesh collisions (under the right circumstances, perhaps a SEXP to force mesh-mesh collisions between certain ships?) is a good starting point (or at the very least fighter bounding box vs capship mesh).

Bounding box approach certainly sounds interesting. If it'd take into account subobject bounding boxes, then we'd essentially get the desired effect. A SEXP implementation would allow switching the collision mode on AI ships at a set distance from the carrier's fighterbay and after the departure cue gets activated, meaning performance doesn't get wasted too much.

Also, I forgot to mention one small thing in OP. The code that manages landings should be made capable of recognizing the gear position and use the "reorient" instead if the ship lands gear up. Perhaps a SEXP like "toggle-smooth-landing" (when set to false, prevents the ships listed from making a "smooth" landing, reorienting them instead).

[jr2]

@Zacam: I think he meant just a static wheel, which could then be used to check collisions, if all subobject types "wheel" are set to be checked vs. capships.   Or somesuch.  He wasn't really going for rotating wheels per se.  Indeed, do any of the "serious" flightsims rotate wheels?  Not sure if they do.

[Sushi]

That's good to hear. Do landing physics already apply to AI fighters?

Yes, players and AI use exactly the same landing physics in Diaspora. The only difference in the SEXPs is that the player landing ends the mission (otherwise they work exactly the same way).

[Kobrar44]

IMO the most important element missing right now is collision detection/response that works well for a "landing" scenario. Unfortunately, this is pretty tricky without rewriting huge chunks of the collision detection and response engine (I should know, I messed around with it for Diaspora). I agree that trying to use mesh-mesh collisions (under the right circumstances, perhaps a SEXP to force mesh-mesh collisions between certain ships?) is a good starting point (or at the very least fighter bounding box vs capship mesh).

Maybe instead of bbox, just few radius checks? You could easily fake wheels this way an there are many things you could do by adding more radius checks, it sound kinda cheap performance-wise compared to collison-collison calculations. But I dunno much about this stuff.

[Nuke]

landing physics are in already, more or less.  though id add a little game logic there where there is a gear down bool somewhere. and if its 1 use one set of landing physics parameters and if its down use another (so that a belly landing is less survivable than a gear down landing). this bool would also indicate whether or not to use a landing gear collision mesh (this could probibly just be a bounding box or sphere) when doing certain collisions. important thing is the wheel and all other bits of the landing gear is marked as no-collidable. and the pof bbox and radius would need to encompass the landing gear bbox/sphere/mesh. the rest of the problem is animation which animation code can do and which scripting (dont get into a tizzy spoon!) can do better if you want a more complex animation.

@Zacam: I think he meant just a static wheel, which could then be used to check collisions, if all subobject types "wheel" are set to be checked vs. capships.   Or somesuch.  He wasn't really going for rotating wheels per se.  Indeed, do any of the "serious" flightsims rotate wheels?  Not sure if they do.

ksp has spinneh wheels, and i think so do most of the other flight sims i play. making the wheel rotate would actually be kind of trivial. just get the relative forward velocity of the ship against the object your landing on and divide by the wheel circumference to get the rate of rotation, animate the wheel so it spins at that rate when in contact with the runway, or spin em down when not. animation code probibly wouldn't be able to pull this off in its current state but scripting can, but if coders want to beef up the animation system to handle this kinda thing that would be fine too.