Arsonide

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.

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.)

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.

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.

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!

You should be able to delete AerialContract and FlightWaypointParameter, but you'll have to recompile, and make your source code available under the GPL.

If you already have two on the board, and you complete or decline another mission that is not an aerial survey, there is 100% chance that whatever pops up next will not be an aerial survey. If you decline the aerial surveys, dropping the number below two, then my code no longer limits the amount that is on the board. At this point, the (stock) ContractSystem chooses from the available Contract Types totally at random. I used to believe that it tried to keep an even ratio, but it is literally Random.Range from 0 to the number of contract types. This means that your next contract could be an Aerial Survey or not, at random. If it does choose an Aerial Survey, returning the number to two, then no more can pop up. They are not filling your board, because there cannot be more than two. Granted, there can be two aerial surveys and two rover contracts, for a total of four missions you are not interested in, but this happens at random. In testing I've seen boards full of Test Part contracts. I've seen strings of Rescue missions, and yes, I've seen strings of my missions (in groups of two, because I limit mine, unlike stock code). It is RNG. I am currently researching the best way to implement configuration into the plugin to allow people to customize my limits, and at that point, if you want, you could lower the limit from 2 to 0 to auto-snuff any that try to pop up at generation. Also, before 0.56 there was a bug involving rover contracts that may have allowed them to creep over the limit, a typo really, but it was fixed.

Yes, it's showing you a contract that is on the contract board.

This wasn't really a decision of mine. Crew capacity is actually a Squad decision, all I did was check the part configuration, which shows that it has no capacity.

Command chairs have no crew capacity, unfortunately.

I add support for modded parts when I can, but the contract is asking you for specific stock parts for now. For the people saying that more than two contracts can pop up for any particular type of contract in Fine Print, I want screenshots, or it didn't happen. The only time I can think of that this might happen is immediately after a patch when the refresh happens. The refresh leaves "ghost" contracts sometimes, so it may appear as if there are more than two, but there are not. If you see more than two, and can go to the VAB and back, and there are still more than two, that's an issue. Changing scenes clears ghost contracts. As for the lack of rescue contracts, I assure you that they are there, and that they pop up just as frequently as anything else...but the more missions you add to the pool, the less chance you get for any particular one of them to show up. It's RNG, any perceived patterns are coincidences of RNG.

Each contract that Fine Print adds is self contained, and nothing outside of those contracts is modified in Fine Print. I add my own systems (Waypoints, orbital waypoints) that are only used in my contracts. The Contract System is not modified, nor are any base contracts. I can tell you that there are more factors to rewards than are in the briefing, like agency personality, and good old fashioned RNG. As far as how many of my contracts are showing up, again, there can be only two of any given type at a time, and it's not even guaranteed to be that. During testing I have had screens full of Test missions with Fine Print installed. Fine Print does not determine what contracts get chosen to fill the board, but it does limit those choices to two per type specifically to prevent the situations you are describing. I can't speak for the rewards on Explore missions, as those are stock and I have no way of modifying that code at all. As far as the rewards for my contracts, I'm aware that they might be too hardcore in some instances, but that's because of the way the game scales the rewards based on location. Sometimes they pay way too much on the outer planets, and I have to balance the inner planets with that in mind. It's a work in progress, and I'm hoping that once I implement configuration, everybody can tweak this to their own liking and actually help me balance the mod with the values they come up with.

Thanks for the positive feedback. Always nice to hear that things are working smoothly somewhere! The navball waypoints themselves were a convenience factor added because of requests. Showing waypoints in the world is possible but not in my immediate plans. Of course, my plans change with feedback. I mostly have no intention of doing this as of now because the locations themselves are abstractions rather than physical things (for now). They are an excuse to get players out there and actually exploring, but I make no assumptions on what you may find there. In a lot of my testing for aerial missions I did this one mission over a beautiful archipelago I never even knew existed with this river delta sort of thing going on. I never would have found it if not for the contract. Placing physical waypoints hovering in mid air kind of takes away from this, in my opinion. This abstract concept of what is actually at these places. Does that make sense? How are you setting up your command pod (be it manned or unmanned). Which way is it pointing? I hear that orients the navball. If your navball is 90 degrees off it might be advantageous to rotate your command pod 90 degrees.

You can do orbital assembly, this is actually heavily encouraged, as with any station. Also yes, you just need the capacity. The contract is technically to build a station for someone else's usage. (This doesn't actually happen, though.)

This is not getting enough attention! This is awesome, and much more in line with the complexity of the original game. Back to the top of the forums with you.

Even though I wasn't sure exactly what it did, I took no chances with this having overlap: return (this.Root.MissionSeed.ToString() + this.Root.DateAccepted.ToString() + this.ID); This is for a parameter, a contract wouldn't need the third number there. I don't think there's much room for overlap there.

No, as you are not rendezvousing with a specific point, there is no need for this, all the information you need is on the orbit.

Yes there is. I've been busy implementing other things. Speak of the devil, the hotfix is out! ARM contracts doomed for Kerbin will now occasionally ask you to land instead of orbit with the asteroid. Stationary orbits now ask for you to orbit over a specific point with line of sight to it. Be within 45 degrees of that point to accomplish this objective. It will be shown as a new waypoint. To compensate for the added difficulty of stationary orbits, they were raised to exceptional prestige level, which has the added benefits of making them worth more, and making synchronous orbits more plentiful in the lower difficulties. Argument of periapsis checks are now skipped for perfectly round orbits. Ascending and descending nodes now show the proper relative inclination differences. There is currently a known issue with the board reset upon patching. Patching may or may not reset your contracts. If it does, any active contracts will be refreshed on the board upon patching. This is intended. If it does not, you will have goofy contracts for a few days of in game time. This is not intended. If you see any satellite contracts with 400KM apoapsis and periapsis, decline them so that new ones can generate. You should only see them once, if at all.

I fixed that issue, and I fixed the argument of periapsis check, and as a show of insanity I'm sneaking in some extras for the hotfix today.

This appears to be the goofiness caused by not resetting. The auto reset must not be happening with this patch for whatever reason. Anybody having these "default" orbits, just decline them, and good ones should pop up. My apologies for the mixup. I'll see if I can get it fixed. There will also be a hotfix very soon that addresses the argument of periapsis not matching on circular orbits. For now, avoid perfectly round orbits.

Yeah it's the relative ascending node between your orbit and the contract orbit. Also, I replicated stock behavior, which shows these numbers between your target and you as -180 to 180 instead of 0 to 360. That disconnect is probably what's throwing off your expectation. Nowhere else does it use -180 to 180, but here it does for some reason, so I replicated it.

The ascending node tooltip is going to go all over the place when your inclination is similar to the inclination you are matching. Before you matched inclinations, was the ascending node icon in the correct location?

If you guys don't mind, how soon after patching did you get these missions? The matching logic I can see, this is more concerning, because these are default values for orbits, meaning you are not loading the generated values properly. I need to hotfix this pronto.

Those numbers look suspicious. Your briefing says "A specific orbit" around Kerbin, which means this was a randomly generated one, but 0 eccentricity, 0 inclination, and 0 LAN? Buy me a lottery ticket if that was randomly generated. If not, something went wrong. Was this orbit typed into the save file manually? The ascending node and descending node are behaving as they should. They mean less on equatorial orbits, and behave oddly, but they are 180 degrees from each other, which is normal behavior. The stock AN and DN nodes show a range from -180 to 180 instead of 0 to 360, so that is what I did with my nodes. I have some questions: 1. Are you going in the right direction? Is your orbit spinning in the same direction as the spinners? 2. Is this an old contract that you had pre patch by chance? (This should not be possible, but it's always good to cover my bases.) 3. How exactly (be specific) did you accept this orbit, and approach it? Did you close the program at any time between accepting the contract and going into the flight, or do anything else similar to that? 4. Can I see a save file? EDIT: I have a theory...when inclination gets below 1 I autopass LAN checks, because it is hard to see differences in LAN at that low inclination. In this patch I added a check against argument of periapsis into the orbit matching logic, but you have eccentricity of 0, so your argument of periapsis is going to be hard to match, I'd think. Perhaps another automatch is coming to a hotfix near you.

I will kill them for you. There's no need to do anything. The message was just a warning that they will be killed. All contracts get affected.