[Snagger]

Except that the AI can't cope with flying down the launch tube. And it certainly can't cope with flying down the launch tube of a moving battlestar.

If it were that easy we'd simply stick the player under AI control for the entire launch and there wouldn't be any problem.

That's what I mean - to the AI and as far as game play is concerned, the new player would be spawned on exiting the tube, having watched a cutsceneof the launch immediately prior to spawning.  The AI would only have to know that a new Viper was about to appear in space t the end of the tube with a preset velocity.  I'm guessing that the technical issue here would be to seamlessly blend the cutscene into game play - I have no idea if that can be done or not.

[karajorma]

You're still in the mindset of thinking this is about the player's launch.

How are you planning to cope with the fact that the player can now quite plainly see any ship being launched from the flight tube suddenly wink into existence? And don't tell me we can put the AI ship far enough into the tube to counter that, if we could, we wouldn't have this problem.


And that's before we get to the numerous difficulties with an animation.

1) On a slowish PC you'll definitely get a delay between animation and going in-game. Which looks ****. How long the delay is on really fast PCs is I don't know.
2) A single animation can't compensate for what is at the end of the tube. If we render the animation with the launch tube facing open space we can't ever do a mission where the tubes face a planet, a nebula or another ship. We'll have to make certain that the battlestar launching the player is always facing open space or render a different animation for each possible outside environment.
3) We have more than one viper and more than one cockpit. So you're basically making the case for having to have a different animation for each different ship class that could possibly be launched out of the tubes. That means a different animation for the Viper II, VII, VIIe, Adder, Blackbird just for R1. Unlike solving the launch tube problem which we only have to do once, we're now forced to sit Lt. Cannonfodder down and render a new cutscene for every single fighter we make which can launch from a tube.
 Not to mention that 3rd party modders are now **** out of luck unless they also have a professional animator.
4) Animations simply won't work in multiplayer. So much for missions where you respawn on the Battlestar and get to launch again.


Finally, a mission where you can sit in the cockpit of a Viper, turn your head and watch the tub wizz by you on either side ****ing rocks. I have no idea why anyone would be trying to talk the team out of doing that.

[Snagger]

Like I said, I don't understand the technical stuff, so was only trying to make suggestions that seemed a possibility.  One thing I know from my career in the services and in aviation is that an outsider can sometimes come up with a solution because they're not constrained by conventions or experience within the field inquestion.  As such, I'll always consider solutions from others, regardless of who they are.  That's the only reason I brought it up - obviously there are technical reasosn that you have already discounted it, and they make sense now that I understand them.  Being able to look around during a launch would be nice, but not as important as finding a timely solution to having any launch at all in game.  Priorities can sometimes need to be assessed or reassessed, just as BTRL proved.

[Demitri]

I've got to say that launching from a battlestar's launch tubes and combat landings(which would turn into combat crashings and dying with big, pretty explosions in my case) would be ****ing sweet, as everyone knows. However I'm not that bothered if it comes included with R1 or have to wait for a later release. There are other things I'm looking forward to more, ie seeing a battlestar in action and crapping my pants if/when flying against one. If the dev team release everything in one go, what is there to look forward to afterwards?

[karajorma]

More ships and more missions.

[Vip]

Just one thing from me - do it good or don't do it at all (AKA don't include in R1, Gods forbid abandoning this completely )

[karajorma]

What makes you think we can't do this properly in R1?

[Vip]

But that means doing several things the engine isn't currently set up to handle. Progress has been made towards fixing this but the question is still open as to whether we'll have it done when everything else is. And if it isn't done we'll face the choice of waiting for it or just releasing with whatever we have and then getting it working for R2.

[newman]

He didn't actually say it won't be in R1 either
Some bridges we don't exactly know when we'll cross until we get to them.

[SGT_R22eR]

Would it be possible to have a sub-object, which can move and is dock able (ie the catapult), be put on the Battlestar. When the viper is docked with the catapult, it would follow it, like docking on a ring of a station. That may point you in a possible solution and you would also be able to integrate this to FRED, since there is already a "docked" starting position, which will be easy for 3rd party FREDders to use.

[karajorma]

It's possible if we can implement sub-object translation. At the moment all we have is sub-object rotation.

[redsniper]

I know I've seen it suggested before that you could just have two large invisible 'arms' hinged together, and then if you get the rotation set up correctly the end of the second arm would translate.

[eps200]

You would need three arms to get it straight some only the third one haveing hit boxes make it like a reverse piston i dont know how much lag it would cause though.

[eps200]

I have been thinking about this and i realised there are plenty of ways to turn rotation into lateral motion asuming you can do hinges simplest would be a crank we all know how that works most acurate but posibly quite laggy would be a lipkin linkage.
http://en.wikipedia.org/wiki/Peaucellier-Lipkin_linkage

It converts rotation into perfect lateral motion this would solve the problem of the viper hitting the sides of the tube

Might be worth looking at other types of linkage depending how acurate it needs to be and what you can do i know you can rotate subsections and hence make hinges.
 can you make guide rails without damaging the ship and can you make subsections not interact with parts they arn't atached to.

[eps200]

I had had another thought the lifts that vipers and raptors land on are they going to be the docking point for non combat landings if they are going to decend you could use this mechanism
http://en.wikipedia.org/wiki/Sarrus_linkage
Could also be the way raptors spawn the lift comes up you fly off the lift being the docking point

Apologies if all this isn't posible but the sarrus linkage sounds like it is quite doable

[Something]

Well, it does sound interesting, but I'd really like to hear a yes or no from the team.

[karajorma]

Or we could just add proper translation to the engine instead of trying to fake it in a number of increasingly more complex manners.

[Thaeris]

Due to my limited understanding, it seems like a solution to launching would come in the form of an "integrated SEXP," which would probably need to be added to the engine. FRED2 already allows for a ship arrival from a launch bay/hangar. Since I've not experimented with doing those operations yet in FRED2, I'm not entirely sure of what the absolute capabilities of that arrival cue are (thankfully you are... why am I talking?).

The problem with the Galactica or any other Battlestar is that it has multiple launch tubes. I assume for a MOVING Battlestar/other ship, the arrival cue (linked to an event in the "events editor" or merely a timed sequence) would have to slave a given ship/wing to the capship in question; these fighters, bombers, etc. would lauch from and appear from the ship the ship in question regardless of where they might be placed in the FRED environment. Next, the launch type would be selected; this would be dependant on the ship class (the carrier vessel and the ship being launched). If "catapult" would be selected in the SEXP, then a further condition to set would be the catapult number (this would be an inherent programming factor in the ship model itself and would determine which catapult the craft in question would launch from). Finally, one would select the "acceleration factor"  I suppose this would take care of the "arrival cue" part of the "integrated SEXP." Note that this is primarily referring to launches from the 'cat as well.

Next, for the second part of this "integrated SEXP," there would be certain factors used in the operator which FRED already is capable of that the user would not be capable of changing. This would be in the form of XYZ-programming, except that the arithmetic would be automatic. From the capship already selected to launch the fighters in question, the speed of the capship in any particular direction would be translated to X, Y, and Z velocites. The fighter would be held as a rigid body along the line of the catapult, unmoving in the capship, perpendicular to the capship's XYZ-velocites. Similar to some training missions, the player as well as the AI would be unable to move the ship until free of the tube (this could be managed by an inherent factor determined by the launch ship). When launched, the "automatic arithmetic" of the operator would use the capship's perpendicular XYZ-velocites (you would have to use rotational velocities as well) along the line of the catapult to accelerate the fighter away from the ship's insides along a straight (though possibly turning) vector. Once the ship was free of the carrier, the player/AI would regain control of the ship. The ship would decelerate as neccesary (if neccessary) and compensate for any sliding movement from the vessel turning. If I could DO something, I think this would be my approach.

Of course, if it is possible to do the same thing with velocites along a pre-determined line (or if the possibility exists for such in the future), it may possibly be more simple to create a line (which is not drawn in-simulator) along a catapult of the capship to which a fighter would adhere from its axis by some offset. The craft would not be able to move until free from the tube and would accelerate along that path until free. This might be that translational movement as implied before...

-Thaeris

[FUBAR-BDHR]

Well caps ships already have arrival paths for ships launching from them so that part is already in the code. 

[Thaeris]

Hate to necro this, but is there a system in place for which we will be able land on/in a ship for R1? Well, besides the mission ending upon reaching a certain proximity to the hangar...

I assume it will take much longer to devise an effective "tube launch."