meyerweb

Okay, I came up with another question: is there a way to check if cargo is on board the craft? Not just having a cargo bay via PartValidation, but some sort of cargo inside the bay during flight? (I suspect the answer is no, but want to be sure.)

You’re the greatest, Nightingale—thank you again! I made the changes—thanks for the heads-up on ReachSpace—and I think it works a lot better now. I rebalanced the rewards a bit, and I’ll ponder the hideChildren tradeoffs. But for now, I need to actually complete that contract to make sure it’s achievable! I always crash spectacularly on touchdown, and that’s with the Kramax Autopilot bringing me in. I’m starting to suspect I need something sturdier than the LY-10 Small Landing Gear…

Thanks, Nightingale! My next question is about the formatting of objectives. Mine look like this: Any idea why the Vessel says “Spaceplane (new)” when I only defined “Spaceplane” as the value? Or, for that matters, why it shows up as an Objective at all? And why the sub-objectives show up under the first real objective? What I’d really like to see is something like this: Is that possible? I’m okay with losing the double-line spacing, but I’d really like to see just those things.

Cool, thanks! I’ll start with my first-flight contract, which is basically “Get your spaceplane from the KSC to space and back again.” I want those to be completed in order, so the player can’t take off, land, and THEN boost to orbit in order to get the completion. Here’s how I set up my parameters: PARAMETER { name = VesselParameterGroup type = VesselParameterGroup define = Spaceplane PARAMETER { name = Launch type = ReachState situation = FLYING title = Take off from the KSC runway completeInSequence = true disableOnStateChange = true } PARAMETER { name = Spaaaaace type = ReachSpace title = Reach space, however briefly completeInSequence = true disableOnStateChange = true } PARAMETER { name = Land type = ReachState situation = LANDED biome = Runway title = Land on the KSC runway completeInSequence = true } } The question here is, am I using completeInSequence and disableOnStateChange correctly, or redundantly, or Just Plain Wrong™? If I’ve made the structure weird, let me know that too. I read the documentation and looked at the source for a number of contract packs, and I saw a bunch of different approaches to structuring the parameters. I wasn’t sure if there was a meaningful difference between what I did above and something like this: PARAMETER { name = VesselParameterGroup1 type = VesselParameterGroup define = Spaceplane PARAMETER { // first step parameters in here } } PARAMETER { name = VesselParameterGroup2 type = VesselParameterGroup define = Spaceplane PARAMETER { // second step parameters in here } } PARAMETER { name = VesselParameterGroup3 type = VesselParameterGroup define = Spaceplane PARAMETER { // third step parameters in here } } Thanks!

I decided to write some SSTO/spaceplane contracts, and have had some initial (apparent) success, but I still have questions about the syntax and its results. Is this still the best place to ask, or has the discussion moved elsewhere?

I finally got some time to mess around with this, and I love it even more in practice than I did in theory. Since I’m still running Pilot Assistant, I got confused by both this and PA having the same icons, so I cleaned up some cruftiness around the plane’s silhouette and added “KA”. Since I thought there might be others in my situation, I created a pull request over on Github to merge in my icons, if you like them. If not, no worries. I also created some short approaches for KSC, meant more for atmospheric jets than spaceplanes. If you’d like, I could also create a pull request to bring that in, if you’d like to have an example `FlightPlans.cfg` for others to look at and work with. Again, if not, not worries, but let me know. Thanks!

Heh. I think you’ve captured some great ideas here that didn’t come up in the earlier proposal, and your UI has some enhancements that are much better, in my opinion. I hope this gets enough traction that someone takes it on! It would make adjusting course-correction nodes much simpler when trying for close encounters with moons (and planets).

I loved this idea when funk proposed it, and I love it still. +100 to making it happen (I wish I could help!).

This looks fantastic, Kramer! Quick question: does the threshold adjust for the different runway lengths in career mode, specifically the shorter ones? I ask because past auto-landers I’ve used didn’t, and crashed my planes short of the runway.

I love this idea—especially the challenges of landing on it!

Fair enough, but any idea how long it usually takes for a CKAN-flagged mod to actually be accepted and show up in CKAN? Because it still doesn’t seem to be there.

There’s been a request to have them added to http://forum.kerbalspaceprogram.com/threads/129947-RoboBrakes-v0-3-1-Now-compatible-with-FAR-RealChute but I don’t know how that’s going.

Thanks for adding it to CKAN! Much appreciated.

Sorry, I meant the obligatory request to make the add-on available via CKAN. I searched for it but didn’t find it.

I’ll make the ObCKANrequest. Also, it would be extra-fabulous if you could implicitly simulate thrust reversers (https://en.wikipedia.org/wiki/Thrust_reversal) during braking. I mean, if you wanted to add some kind of overlays to the engine models to make it look like thrust-reversal ports were opening, that would be fantastic, but I think just allowing for thrust redirection without the visual froofraw would be dandy.

I love this idea. I wish I could help make it happen!

I think that’s a reasonable default. Glad it will also be configurable, since I can see players with gaming keyboards assigning it to one of their dedicated script keys. WOOOHOOO!

Adding my vote for CKAN support.

In addition to adding my vote for Blizzy’s support, I’d love to have a preference to assign a hotkey combo to bring up the Commander window. (If it’s there and I missed it, my apologies and a request for a quick pointer to where to find it.)

This is one of my favorite additions to the game. Any progress on CKAN and other updates?

I like this idea quite a bit—as it stands now, airplanes are mostly pointless in career. In my latest career game, in fact, I’ve literally only ever used the runway as a launching point for science jalopies to run around KSC harvesting science points. If you put the base text for your mod up on Github, I could provide spell- and grammar-check services. It looks like you might need them (“safly” should be “safely” in the screenshot above). - - - Updated - - - Ideas, suggested with absolutely zero idea whether it’s possible to implement them: - Circumnavigate Kerbin - Overflight (set 2-4 zones that must be overflown, possibly in a specific order, below a certain altitude) - Plane crew reports (like the existing crew reports, except always below 2,500 meters [more for mountains]) - Short takeoff records (get off the runway in less than n meters) - VTOL trial (have a VTOL-capable craft that can land in a nearby zone, then take off again and return) - Part trials (like part contracts for rockets, except require them to be part of a plane) - Science contracts that require instruments to be carried by plane

I had a somewhat similar idea, which I posted in a ForScience! thread a while back: I know it seems like cheating, but seriously—slowly wandering around KSC for a few hours trying to figure out if you’ve done the right experiments in the right places? So pointlessly grindtastic that I’d happily cheat my way around it.

I don’t think that’s a stated goal of PlanetShine, but I seem to recall Squad saying they’d like to do this. I wonder if it’s something a mod could do.

Here’s a question, which I ask here because of the conceptual proximity: how hard would it be to create a mod that does all the experiments at KSC as science parts are unlocked, without having to actually drive around vacuuming them up? Here’s an example of what I mean: when you unlock the materials bay, you open the “KSC Junior Science Team” mod button in the toolbar and click a now-active button for the SC-9001. You then get all the materials-bay-experiment science points from all 30+ KSC biomes, plus all those experiments are marked as done in the Science archive. Ditto when you unlock the Gravioli, barometer, etc. The idea being that you’re assigning a team of junior scientists to go out and run a bunch of experiments at KSC with the new instruments. I know that ForScience! makes that surface-grind at KSC a whole lot easier, and I’ll probably use it for that soon, but I feel like the Jr. Science Team approach would be even easier on the player. Whether or not it’s easy to implement is less clear to me—thus my question here.

This is actually about the surface-level science grind, not the flyover. Like r4pt0r , I dislike the grind, but was wondering what the total payoff might be. Thanks to LittleBlueGaming, I know the answer is “A LOT”. I still won’t do the actual grind, but what I may do is install ForScience!, drive around KSC for half an hour vacuuming up points, and then uninstall ForScience! If I ever decide to get into mod authoring, my trainer will probably be called something like “KSC Science Team”, which will run all those surface-level experiments for you as you obtain each relevant science part and mark the science activities as done. Or else I’ll get lazy and submit a mod request over on the add-on forums. Actually, let’s be honest, it’ll probably be that.