[0.90.0] Fine Print vSTOCK'D - BETA RELEASE!!! (December 15)

[Arsonide]

A suggestion to fix the over-sensitivity to LAN in equatorial orbits: Rather than testing if the craft's LAN is within x% of the target orbit, test whether it is within something like 90*(cos(2*target_inc)+1)+180*x%.

What this does: When the target is an equatorial orbit, retorgrade or prograde, then the expression is just over 180 degrees, meaning you can be at any LAN. When the target is a polar orbit, the expression is 180*x%, which I assume is your current test. The expression smoothly transitions between the two like a cosine curve (graphed for 7% as an example).

These make sense because in an equatorial orbit the LAN is irrelevant, and in a polar orbit it is critical.

I'm not certain whether this is the optimal expression, but I do think it's a pretty good one and much better than doing the basic direct comparison.

Edit, more info on that expression: If the margin of error (x) is 3%, then my test would allow any LAN if the target inclination is < 10 deg or > 170 deg, and if 7% then < 15.5 deg, > 164.7 deg

Edit2: Actually maybe we want the restriction to kick in a bit quicker than that cosine allows. You can use higher powers of the cos + 1 term and rescale to make it sharper.

Right now it ignores LAN checks for inclinations under 1, which I found to be pretty visible, it also ignores argument of periapsis checks for low eccentricities. A smooth ramp might be better, I'll look into it when I finish configuration. Thanks for the math!

[Renegrade]

Renegrade's Quick and Dirty Orbital Tutorial!

For those having trouble matching strange orbits, I've created a basic tutorial:

Here's our target orbit. It's actually a retrograde orbit, rther inclined, with some eccentricity:

By launching at the correct time and with the correct angle, you can launch directly into a matching orbit. That's a bit complicated and not easy to pull off for people new to precision orbiting, so I'm going to go with a more basic/easier/less efficient technique. Here I've established a normal (retrograde) orbit:

(don't worry about Precise Node)

I'm changing the view to be above, and burning prograde (green thingie) until my AP is at roughly the same altitude as one part of the orbit:

Once my orbit has been extended, I burn normal/anti-normal (the purple/pink triangles) until my inclination is the same as the target orbit.

Now I adjust the normal/anti-normal and prograde/retrograde (green again) controls until the orbit is matched:

And that's it! If done correctly, green marks will appear on the contract for all points except for "take hands off of controls". Turn off trim (alt-x) and SAS (t), and wait 10 seconds, and the contract should complete.

If the coordinates aren't close enough, some additional corrections may be needed.

These skills can also be used for intercepting planets, or other ships too.

[JeffreyCor]

Not sure if this is intended or a bug, but why would there be a check for the ascending node on an orbit with an inclination of 0? I would think being that there in no inclination there is no assent or decent, any position of it will always be passed over during the orbit. Shouldn't this not be a check for a flat equatorial orbit?

[Arsonide]

Not sure if this is intended or a bug, but why would there be a check for the ascending node on an orbit with an inclination of 0? I would think being that there in no inclination there is no assent or decent, any position of it will always be passed over during the orbit. Shouldn't this not be a check for a flat equatorial orbit?

Right now it ignores LAN checks for inclinations under 1, which I found to be pretty visible, it also ignores argument of periapsis checks for low eccentricities.

LAN means longitude of the ascending node. I don't check it on equatorial orbits. The contract will throw a number at you, but it isn't important. I was thinking of replacing the number with "Irrelevant".

Here is an exciting screenshot of my progress with configuration! I'm going to try and hook as many options as I can into this, so people can balance to their hearts content. Don't like solar ejection ARM missions? Disable them. Like them but want a bigger reward? Add a reward multiplier or reward additive to them.

Edited August 21, 2014 by Arsonide

[Renegrade]

http://puu.sh/b1Bn0/386fb8fb49.jpg

Here is an exciting screenshot of my progress with configuration! I'm going to try and hook as many options as I can into this, so people can balance to their hearts content. Don't like solar ejection ARM missions? Disable them. Like them but want a bigger reward? Add a reward multiplier or reward additive to them.

Ooh nice, that is exciting! I'm getting stoked for the next release.

Will we be able to control science multipliers separately, by the way?

[Silpion]

I don't check it on equatorial orbits.

Well that's strange, because last night I had an equatorial sun orbit contract and it just wouldn't complete. I was better than 0.1% in all parameters other than LAN, and I had to open up the save file to find out what my craft's LAN was. I used my RCS thrusters to puff it into place (didn't take much, my inclination was like 0.001 or something), and then the contract completed.

[JeffreyCor]

LAN means longitude of the ascending node. I don't check it on equatorial orbits. The contract will throw a number at you, but it isn't important. I was thinking of replacing the number with "Irrelevant".

http://puu.sh/b1Bn0/386fb8fb49.jpg

Here is an exciting screenshot of my progress with configuration! I'm going to try and hook as many options as I can into this, so people can balance to their hearts content. Don't like solar ejection ARM missions? Disable them. Like them but want a bigger reward? Add a reward multiplier or reward additive to them.

Had an equatorial contract and all other parameters matched except assenting node and contract wouldn't complete, so it appears the check is being made unintended.

[juanml82]

Here is an exciting screenshot of my progress with configuration! I'm going to try and hook as many options as I can into this, so people can balance to their hearts content. Don't like solar ejection ARM missions? Disable them. Like them but want a bigger reward? Add a reward multiplier or reward additive to them.

Great! (10 characters limit)

[AdmiralTigerclaw]

Arsonide: Is it possible to have sub-catagories designating contracts for specific mission types? For example, I'm not really interested in aerial survey missions over Duna, Laythe, or Eve, but Kerbin's fine.

Also, a few thoughts on Aerial survey missions in general.

Can you designate missions for lower and slower aircraft for lower payouts? In example, I build a Cessna-like aircraft (Single Engine Prop). It's not going to reach 12,000 meters and half way around Kerbin. (I built a business jet that strained to maintain altitude for that one.)

Essentially, having flown enough designs I've got a feel for the flight regimes of aircraft classes. Here's a general idea for how I would split them up. Numbers are approximate.

Specified Altitudes include the following:

A:

0 - 12,000 feet EA (Earth Equivalent)

Single Engine Prop General Aviation

B:

12,000 - 18,000 ft EA

Higher Performance GA

**Transition Altitude for IFR flight rules requirement by the FAA is 18,000 feet.

C:

18,000 - 30,000 ft EA

High Performance Commercial Prop/ Turboprop

D:

30,000 - 45,000 ft EA

Commercial and military Turbofan and Turbojet

E:

45,000 - 85,000 ft EA (and above)

High Performance Military jet/turbojet/turboramjet (SR-71)

Now, to convert to Kerbin metric, my calculation is feet MSL at STP converted to meters, divided by 8.5 and then multiplied by 5 for all altitude conversions, utilizing the top of each regime. The following are the Altitudes on Kerbin which are equal to the altitudes expressed on Earth above.

A: 2,151m

B: 3,227m

C: 5,379m

D: 8,068m

E: 15,240m

You could break Aerial Survey missions into these five altitude sub-catagories.and then both limit the payout, and when they show up on the tech tree. Instead of throwing the player a class E survey mission when they don't even have supersonic flight, they get a class A or B. Maybe a C designated for higher difficulty.

Also, for each mission class, the range/location from KSC would be constrained. An SEP, for example, is not going to fly antipodal to the other side of Kerbin. 500 km might be the maximum radius I would put for such a flight. (Though I WOULD make the minimum 40 to 60 km out, just so the player actually has to fly somewhere.

[Arsonide]

Had an equatorial contract and all other parameters matched except assenting node and contract wouldn't complete, so it appears the check is being made unintended.

How do you know that you had all parameters matched but ascending node? I check a lot more things than are in the briefing text, but equatorial orbits do not check LAN. If they are checking LAN, then they have an inclination greater than one, in which case it should be visible to the naked eye as a slight tilt, and the longitude of the ascending node should be obvious.

Did you have more than one orbit contract accepted? Are you sure you had the right one open in the tracker? Were you going retrograde to the orbit? Was your argument of periapsis lined up? There are many other variables that might have caused it to not match.

Due to the procedural nature of the contracts I generate, it is hard for me to recreate every situation, and I need many more details to diagnose an issue. If anybody is positive that they are encountering this, and that none of the above situations are true, please zip up your save and send it to me in a private message so that I can figure out exactly what is going on with it, and fix it in the next release. Ensure that the vessel you are using is stock, or I will not be able to load it.

Great ideas

This is a truly nice idea. I would want to extend it to all the planets though, with height classifications. Would you have any rough estimates for Duna, Eve, and Laythe? If you came up with some estimates, I might be able to find patterns in them, and correlate it to the atmosphere height or something, to make it more reusable.

This would also have to be an overhaul that comes after configuration, cause that is my main focus at the moment.

Edited August 21, 2014 by Arsonide

[AdmiralTigerclaw]

This is a truly nice idea. I would want to extend it to all the planets though, with height classifications. Would you have any rough estimates for Duna, Eve, and Laythe? If you came up with some estimates, I might be able to find patterns in them, and correlate it to the atmosphere height or something, to make it more reusable.

I based them off Scale Height. Each Planet with an atmosphere has one. (Wiki it to learn more.) Earth's atmosphere scale height is 8.5 km, Kerbin's is 5.

So I simply divided the earth reference altitude by the scale height of earth to get a unit value, then multiplied it by the new scale height.

Also, I have an idea here that goes with your contract styles, but would require extra work, and might do better as side mod.

http://forum.kerbalspaceprogram.com/threads/91320-Kerbal-Commercial-Passenger-Contracts

[Arsonide]

Also, I have an idea here that goes with your contract styles, but would require extra work, and might do better as side mod.

http://forum.kerbalspaceprogram.com/threads/91320-Kerbal-Commercial-Passenger-Contracts

Nice. I've seen the Geeforce passenger idea before, and I've been considering it, but my plate's been pretty full. (Also, we weren't sure what to do about geeforces during take off and landing.)

[webkilla]

Nice. I've seen the Geeforce passenger idea before, and I've been considering it, but my plate's been pretty full. (Also, we weren't sure what to do about geeforces during take off and landing.)

include an altitude requirement, and add that it has to be on a space-plane.

Most high G-force experiences for rockets are right at takeoff and during the initial atmospheric part of the launch, and while in orbit if you use a powerful engine. Add a height requirement that puts the high-G experience around 20-40K height-wise, along with a stipulation that you have to have been up in space as well (possibly with a bonus for achieving orbit) - bam, zero-G and high-G funride experience

[JeffreyCor]

How do you know that you had all parameters matched but ascending node? I check a lot more things than are in the briefing text, but equatorial orbits do not check LAN. If they are checking LAN, then they have an inclination greater than one, in which case it should be visible to the naked eye as a slight tilt, and the longitude of the ascending node should be obvious.

Did you have more than one orbit contract accepted? Are you sure you had the right one open in the tracker? Were you going retrograde to the orbit? Was your argument of periapsis lined up? There are many other variables that might have caused it to not match.

Due to the procedural nature of the contracts I generate, it is hard for me to recreate every situation, and I need many more details to diagnose an issue. If anybody is positive that they are encountering this, and that none of the above situations are true, please zip up your save and send it to me in a private message so that I can figure out exactly what is going on with it, and fix it in the next release. Ensure that the vessel you are using is stock, or I will not be able to load it.

This is a truly nice idea. I would want to extend it to all the planets though, with height classifications. Would you have any rough estimates for Duna, Eve, and Laythe? If you came up with some estimates, I might be able to find patterns in them, and correlate it to the atmosphere height or something, to make it more reusable.

This would also have to be an overhaul that comes after configuration, cause that is my main focus at the moment.

Every single one apart from the equatorial ones work perfectly every time. As the number are provided along with the graphical representation it doesn't take much to figure out if the orbit matches what is assigned as part of the contract. The only other orbital contract at the time was a polar orbit which had no problems completing. And as Silpion stated above mine he had a similar problem with all but LAN matching and the contract not completing until LAN matched. Also, in .55a there was no problem with they type of contract, it only began as of .56a and remains present in .57b.

[Arsonide]

Every single one apart from the equatorial ones work perfectly every time. As the number are provided along with the graphical representation it doesn't take much to figure out if the orbit matches what is assigned as part of the contract. The only other orbital contract at the time was a polar orbit which had no problems completing. And as Silpion stated above mine he had a similar problem with all but LAN matching and the contract not completing until LAN matched. Also, in .55a there was no problem with they type of contract, it only began as of .56a and remains present in .57b.

I noticed the equatorial issue with .56a, but I figured it was the argument of periapsis, which I fixed with .57b. (That was still a big issue, and I'm glad I put something in for it.) I apologize but I am not experiencing this issue. If you encounter it again, could you please zip up your save and send it to me so that I can check it out? This has helped me tremendously in the past, and I of course want my stuff to work flawlessly in all circumstances.

I apologize if it's caused you any inconvenience, but remember, if you are positive you have matched it, you can use the debug menu to force the contract complete for the moment. (Send me a save first though, before completion.)

Also remember that if you're curious about how I'm doing something, my source is always available for scrutiny on GitHub. The lines involving the LANMatch for instance, are available. Here is where I check if the orbit is horizontal, and here is the block that gets skipped if it is true.

Edited August 22, 2014 by Arsonide

[juanml82]

So I got a contract to put a satellite in a keliostationary orbit around the sun... and the conditions require me to equip the probe with a barometer

You might want to look into it and filter the science parts so only parts that can actually conduct the experiment are required. And on that matter, how about if the aerial recon mission require the atmospheric sensor cone thing?

[AdmiralTigerclaw]

Nice. I've seen the Geeforce passenger idea before, and I've been considering it, but my plate's been pretty full. (Also, we weren't sure what to do about geeforces during take off and landing.)

Don't land hard?

Easy as it sounds in theory, handling civilian passengers and their fickle ways is extremely HARD. But the world's airline pilots handle that issue daily.

Though you can make it timer based.

IF ( Gs >= 2.1 && Timer >= 1.1 sec)

{

Passengers upset from G Forces! Mission FAILED!

}

else

{

Whatever.

}

[Arsonide]

So I got a contract to put a satellite in a keliostationary orbit around the sun... and the conditions require me to equip the probe with a barometer

You might want to look into it and filter the science parts so only parts that can actually conduct the experiment are required. And on that matter, how about if the aerial recon mission require the atmospheric sensor cone thing?

I know that some satellites require barometers. This is not an issue so much as a design decision. You are being paid by an agency to do something, their motives are unclear to you, nor are they particularly keen on explaining them to you. Maybe they want to see how fast a barometer melts.

[vardicd]

I know that some satellites require barometers. This is not an issue so much as a design decision. You are being paid by an agency to do something, their motives are unclear to you, nor are they particularly keen on explaining them to you. Maybe they want to see how fast a barometer melts.

Or maybe some secretary was having a bad day and typed the wrong thing on the contract and no one caught it. Imagine any situation you want.

[sreinmann]

I'm currently running .55a (worried about upgrading since I have two contracts active and I don't want to cheat them complete or lose them - if that's a possibility), and I have my first two orbit contracts that I'm working toward. The craft are as matched as I can see them by the naked eye. I haven't tried all the back and forth steps to neutralized controls yet, but how do I know if I am within the 5% / 3% orbit requirements? The contracts don't specify the PE, AP, inclination, eccentricities for me to reference via EngineerRedux so I'm at a bit of a loss.

[JeffreyCor]

In .55a you have to eyeball it by matching what is shown as the required orbit with your actual orbit. Using manual nodes to adjust your orbit to get the prediction lines to overlap is the best way so you can fine tune the node and then readjust if it doesn't quite match.

[m_j_lyons]

Without digging into the source code - does anyone know how Fineprint checks to see if a satellite is "new" - can we resuse the same design? I launched a satellite that had the same design as a previous launch and nothing was green when the satellite was in space. To be complete, I'm not done with it yet - it's just in a holding orbit until I have time to get it into a 13K km polar orbit w/90 inclination.

That said - what kind of customer would put a satellite into such a large polar orbit? Mapping? Intelligence eavesdropping?

Fly safe.

[undercoveryankee]

Without digging into the source code - does anyone know how Fineprint checks to see if a satellite is "new" - can we resuse the same design? I launched a satellite that had the same design as a previous launch and nothing was green when the satellite was in space. To be complete, I'm not done with it yet - it's just in a holding orbit until I have time to get it into a 13K km polar orbit w/90 inclination.

That said - what kind of customer would put a satellite into such a large polar orbit? Mapping? Intelligence eavesdropping?

Fly safe.

The code that I can find simply requires the vessel's launch time to be after the contract was accepted. So you can't launch a satellite for a contract that's available to accept, then go back and accept the contract.

For me, just doing any unmanned launch is typically enough to get that parameter to show green. There should be no reason you couldn't reuse a craft file if it had all of the instruments that the new contract called for. Check the contract's notes for the list of everything that the customer wants you to have.

If you have everything, and that parameter is still showing incomplete after you've reached the required orbit and gotten the "orbital elements" and "neutralize controls" parameters green, share a save file so we can check the numbers. Make note of any mods that change or remove functionality from parts that the contract requires.

[m_j_lyons]

Thanks Undercoveryankee - I figured that was the case.

I installed another MOD (DMagic Orbit Science: New Science Parts) that I've got this sneaking suspicion is causing some "interference" with the contracting 'subsystem' in KSP. I also installed ModManager...but I can't see that causing the random crashes when trying to do science or the increased lag that was introduced or the odd problems capturing satellite orbits or satisfying basic parts requirements. Oh well...I'll remove both and see if that fixes the problem and then add one back at a time to isolate. It was working fine before those two installs.

[Marclev]

Just playing around with this. Looking a contract to place a satellite in keliostationary orbit of the Sun. One of the conditions is "keep line of sight with Dawton's Emitter". What's a "Dawton's Emitter"?!