Baythan

I've just been doing some return from the Mun, trying to Aero-brake into orbit rather than come down all at once, and Trajectories says I should pass through atmo 3-4 times before slowing down too much and coming in to land, but the first pass drops my velocity so much with FAR that I impact without ever leaving atmo again on the first pass. This leads me to believe that the current version of Trajectories with the current version of FAR (now that they don't crash the game together) is inaccurate. I suspect changes to the drag model in FAR have not been accounted for in Trajectories, but thats just my guess.

The biggest problem I see with implementing something like this is that decoupling has ejection force. The farther you are from the KSC, the greater effect the decoupling will have on your final trajectory and landing. If you point prograde or retrograde when you decouple, you'll end up with two different results, and more different results for every single other direction you can point. The best thing to do is plan for that extra force of decoupling or save it for just above atmosphere.

I loaded up Trajectories 1.1.1.0-pre1 and FAR 0.14.6 in which ferram fixed the bug causing trajectories to lock up the game and now I get a repeating error from Trajectories whenever it tries to run in atmosphere. It also doesn't seem to know what aero model is being used. Here's my output.log for this error. Errors start at line 40365 and stop at line 311580 with 12,364 of the same error. Anyone else getting this, or have they managed to get Trajectories and FAR to work together? I have a lot of other mods, so there may be some other conflict. No crash, game keeps running, but the errors just start racking up quickly and trajectories fails to show anything on the map.

I might have some suggestions for the wings, mostly in that it looks like you've put ALL the canards into the same node as well as splitting tailfins and rudders across two nodes (mixing some of them with canards). Given that one of the canards is called the 'advanced canard' I would think it should go one node over to the right after regular/basic canard. But then I STILL haven't unlocked canards in my current career mode, so I don't know how different they are. I'm not entirely sure the lift surfaces need to go very far across the tech tree anyway, as its not the wings that will get a spaceplane into orbit, its the engines and fuel tanks. All the different types of wings are mostly for aesthetics rather than functionality until you install FAR or the aero model gets updated for stock. Once we get the new aero model, the whole wing section will probably change.

Okay, all these complaints about how hideous/ugly the barn WAS are completely ignoring the fact that SQUAD already said it was unfinished. They KNEW it was not finished, they PLANNED to finish it, they just wanted to show off the idea before the models got finished. Was it a mistake to show unfinished models to the public? Apparently yes, because you people won't shut up about how ugly and unfinished it was. You're acting like that was the final model and how it would have looked in the 0.90 patch. The whole point behind this thread is those of use that were NOT bitching about it (because we liked the idea and/or never saw the unfinished product) want to have our voices heard too. All the naysayers bitched and complained and the barn got pulled before it got finished and now we have boring buildings at our space center. It's time for the rest of us to be heard. #FinishtheBarnandBringitBack

Mod Author is on vacation and won't be back until Jan. In the meantime, from experience, he'd prefer FULL output_log.txt for diagnosing errors.

Ferram4 said his next version of FAR will have the fix, but I have not yet seen anything about how long before he releases that fix. I guess it's not a hotfix priority or anything.

It does seem a very Kerbal thing to take some weird goo from an unknown source and run crazy tests on it before you bother gathering weather data. Who cares if its hot, cold, windy, rainy, high pressure or low pressure when you launch a rocket? It's not like O-rings do funny stuff in cold weather.

@ghpstage: The problem with this point is that there's no way to make even a rudimentary airplane WITHOUT the basic jet engine. Strapping wings onto liquid rockets is NOT the way I would do my starting career mode. As I've said, I want to do things the "Wright Way" with airplanes first instead of rockets. I wouldn't mind prop engines instead, from something like the Firespitter mod, as a stock starting point for airplanes. Until we get something like that, basic air intakes and a basic jet engine should be available from the beginning. @sherkaner: I don't think the jet engine is a good engine to use for a rockets as it's efficiency drops quickly above 5km.

This I agree with. I still like the idea of the farm/barn because its amusing and makes a bit of sense. Not that these all don't make sense either: mine (any sort, even open-pit), junkyard (my #2 vote), railyard, industrial plant, abandoned mall, etc. Pretty much anything with an open layout and lots of flat ground combined with large empty buildings to convert into VAB and SPH. Farm is still my #1 vote because I prefer to start with airplanes and some farms have their own crop dusters, so a landing strip would be readily available. Also, farm vehicles can be used to haul rocket parts out to the launchpad. Junkyard gets my #2 vote because its got the bits to make all out rockets/planes and has large vehicles for moving stuff, and a dirt road can make a decent landing strip. Again, I never saw this barn that was shown, so I'm not arguing for what was seen. I'm arguing for the IDEA, because I like it. The current buildings in all iterations are rather bland and uninspiring. Even the top tier stuff is rather plain on the outside, it doesn't feel KERBAL.

I like it! I might move the mobile processing lab into the science branch rather than the habitat/command pod branch. Also, I think the QBE probe might be too early, but I don't know what pilot skill level it has programmed in. Next would be balancing the research cost of each node/part.

Awesome! Fun implications and more compatibility are always good things.

I'd love to have a look at what you work out. Almost anything that anyone would find enjoyable would be better than what we have now.

Okay, so its most likely a KSP issue causing things to get recovered in weird locations. Trajectories has an API for integration with other mods, but as I'm not a modder/coder I don't know if it will help you much.

Not sure how I clarified any issue with the stack chute. I've only just unlocked it in my career mode and haven't really messed with it. My guess is that only double chute can do both drogue and main chutes from the same compartment, and the stack chute can only do one chute from each compartment, so you'd have to set it to have a drogue come from one and the main from the other... which would cause the vessel to twist over as they change. It would be cool to have the stack chute set up with two drogues and two mains, allowing it to drop station section on planets upright (again, still haven't messed with it, so I don't know that it can or can't do this or if there's another part that can).

Agreed. There are a number of parts that are useful for all craft types that currently end up 3-5 tiers into the tech tree, like the cubic octagonal strut, small hardpoint and all nosecones, any of which could be put much earlier. If we get that Drag model revamp soon we'll really want those nosecones early and possibly some fairings introduced into stock.

For space plane landings, the better your plane flies in atmosphere, the farther from the runway you want your projected impact location. Currently Trajectories does not account for glide paths/wings, so if you place it directly on the KSC you'll be gliding right over the top of it. I suck at plane design, despite how much I like flying them, so I'm not sure how early you want your impact location. If your plane flies REALLY well, and not like a gliding brick, you can probably just put the X on KSC and dive towards the surface until you are close enough to the ground to glide in.

But what about plane parts? I don't want to start with manned/unmanned rockets.

I don't see why there has to be a starting node with anything in it to begin with. Either have an option when you set up the career game where you select one of three starting trees, or you start career mode with a science/funds budget that lets you buy parts. The buying parts option would work best if fewer parts were in each node and each node cost less, but there would be MANY more nodes. The option for mods to add nodes attached to pre-existing nodes would also be great. Of course, this makes the tech tree a lot more complex and would probably mean an extensive re-write of that section of the game... but that's pretty much what's needed in the end I believe. Again, the overall consensus is: More choice when it comes to advancing in career mode.

Yes, the radial layout is the more space-efficient one, and I happen to like it. The point behind saying it doesn't have to be a circle is because any way you shape it, it does the same thing. At least, it does until you start requiring certain parts of one tech line before you can get parts of another tech line like the current tree does (gotta have one or both 'these two' researched before you can research 'this one').

The flat launchpad isn't long enough for a plane to take off or land. All we need is a dirt road/field where the current runway is for tier 1, and the current tier 1 can be tier 2. I'm a big proponent of a revision to the tech tree that allows at minimum three styles of career start because I want to play 'The Wright Way,' and therefore I need a runway in Tier 1. Some people don't see a need for it, but if we get what we want (the ability to play Career OUR way rather than as dictated by the current tech tree) then we need access to runway, launchpad, AND tracking station at start.

When you are selecting # of parachutes used, you need to input the number of chutes you placed on the vessel. If you use a single nosecone, you input 1 chute. if you use 3 radial chutes, you input 3 chutes used. This is so that the weight of the vessel can be divided by the number of chutes used and decrease the individual size of each chute(and therefore the price of each chute). If you use 3 chutes and say 1, each chute will be big enough to slow the entire vessel(or will hit max size), with three chutes designed to save the entire vessel it will drift VERY slowly to the ground. If you use 1 chute and say 3 are used, the single chute you placed will be 1/3 the size required to save the vessel and it will crash.[Edit: The vessel, not the game] As for the stack chute, I don't have access to it yet in my career save, so I can't help with that yet.

I think it makes a lot of sense to restrict KAS to engineers. As for making all 'restrictive changes' optional, Squad didn't make the Engineer limitations to repairs optional, so why should KAS?

I know that things on rails get deleted in atmosphere, around 30-40 km up, but the location of that last debris when it got recovered was MUCH closer than 300km, probably only about 150km(max)(using KER I discovered it was more like 60km). It seems like the distance calculations for objects moving really fast across the surface is messed up. I have no idea if its a KSP issue or a SR issue because I have no idea how either one decided where something is when it gets deleted.

Awesome! Great work! As far as the weird distances reported by SR when orbital debris re-enters, I've had problems with debris reporting as if it was 700+km away on two occasions, both from the same type of vessel but with two different projected landing zones. I use the Trajectories mod to calculate true landing areas so I can get the most from recovery. So the two instances: First landing was projected to impact right on top of KSC by Trajectories, which means the orbital line passed overhead and entered Kerbin about 2/3 of the way to the next continent to the east. What I didn't consider when creating this deorbit path for the debris is that if left on rails to deorbit then atmospheric calculations are not done the same way and the object was 'deleted' somewhere east of KSC, probably 1/4 of the way to that next continent. Distance was reported by SR as ~870 km. Second landing was after a reversion to assembly to modify the upper stage of the rocket, deorbit stage was the same as before. This time I put the orbital path to enter Kerbin about 50km east of KSC and Trajectories projected impact on the western side of the mountains short of KSC. Left on rails, the debris was deleted somewhere over the mountain range or just east of them. Distance was reported as over 600 km from KSC. I'll be dropping more debris from LKO and trying to hit KSC with it as I play, so I'll try to remember to grab some screenshots and more accurate numbers. I want to see if I can get a ~90% recovery on rails that isn't dropped from directly above. Edit: Here's a test I just did. The white and red lines are Trajectories predicted travel path dues to air resistance and planet rotation. The red X is the projected impact point. Red dot at KSC is from RT2. Theres also a flag at KSC so I could target it with Trajectories at night (before RT2 was updated and gave me back the red dot). Left on rails, the debris was deleted just west of KSC between it and the mountains. SR reported it as recovered 370 km away. Without rails the debris landed 3km from the flag. These tests were all done with SR 1.5.2. I have blizzy's toolbar and SCANSat if those cause the issue.