diomedea

Indeed better if moved where this thread belongs, believe the discussion can be spotted by a few more interested users there. Please continue .

Now that the news is public: heartfelt congratulations, Porkjet !

Ships with different TWR and Delta-V at each stage will perform differently, so you can't use one ascent profile for all. The gravity turn may more steep with one, but better if more smooth with another. But probably the single thing you should improve is with the timing for the circularization burn. The initial burn during ascent must be enough to reach apoapsis at the set altitude (e.g., at 100 Km), but once the apoapsis is obtained, you should stop the engines (or, burn almost horizontal). Of course, to know the apoapsis, you have to look at the marker with the map view. So, stop the engines, and set a maneuver node at apoapsis for the circularization: just burn prograde until periapsis is at the same level. If you move the burn too early or too late, you see that the trajectory will turn elliptical; the only correct one is when the burn is exactly at apoapsis. With the node set, try to compute the amount of time needed to perform the burn, and begin burning about half the burn duration before reaching the node. But, keep following the blue node marker for all the burn until all the required Delta-V is done, and you should have a perfect orbit.

You need fuel to perform maneuvers, or your ships are stuck in the orbit they are in at the moment (unless, by chance, that orbit intersects the sphere of influence of another body, but even then it almost never can bring to a landing without making a maneuver). I would advise to use your current situation as an example of how not to go into space, and rather learn form this experience to plan for the maneuvers you need to perform until the end of a mission, therefore to keep fuel for those. I understand both your ships are orbiting Sun, so you spent quite a large amount of Delta-V to exit Kerbin's sphere of Influence: with the same amount of Delta-V, you could certainly go around Mun and back to Kerbin, and such a mission would be very useful to make clear what is required to get back. If you had not yet, start following the training missions provided with the stock KSP game, those should give a better understanding of some basic principles required to go around in this game.

I would suggest to use precision mode (activated by pressing Shift-Lock) if the commands are too rough. But I agree, too big control surfaces on the wings is the cause of your issue. About building a plane, better to place the CoM slightly in front of the Center of Lift, it helps to recover from a stall.

There is no specific rule stating a time for moderated posts to be approved (or rejected). The moderation team acts on them collectively, so the first moderator who has time to check, will process those posts. In the specific case, you may note that one post you made was approved to reside in the correct section (Stock Craft Repository v.0.24), another post you made wasn't approved, because identical to the first and posted in a wrong section. It takes some time to check, evaluate if posts are correct, move them where they belong (like this one). But certainly you waited that much just because nobody had time to check for a few hours. A good advice for newcomers to this forum should be, don't expect all your posts to be approved, and not to be approved in a short time.

Notwithstanding someone, I totally agree with the OP. Best community here for sure of any I ever met. And that is reason to be proud to be serving here.

Yes, the format for the new tables is neat, effective. Much more user-friendly, values are quite understandable now . BTW, as a previous user of ISA MapSat, as such with some knowledge of what the original algorithm by Psawhn was for, what you reported earlier makes sense. Thanks for sharing your thoughts, instead of just giving the conclusions. Some of the values you have removed were meaningless to me as well, though probably all were tabled to check how the algorithm worked (therefore, not all useful for final users).

In KSP, FAR is the shortcut for "Ferram's Aerospace Research" mod. SSTO in aerospace stands for "Single Stage To Orbit", so any vehicle capable of attaining orbit without staging (detaching parts).

Many thanks for asking feedback and making an effort at describing the system, that's how to go. Absolutely happy with the opt-in system. I'm enticed to accept just because it asks the right way. About the 2 flavours, happy you allow for both so to better suit with users preferences. My one is to go with the separate KSP-AVC, as more and more mods I have installed are going to use it, so best if the feature is consistent across all.

Happy to see the return of HayStack, thanks Qberticus to bring it back. I used the previous one up to KSP 0.23 - then had to switch to Targetron. But only HayStack allowed to target planetary bodies on the fly, something I was missing all this time.

Tables and plot images are properly tied to this thread, so I hope you are not considering to move them out, but rather to show them on both threads. This one thread is worth keeping open at least for now, all the technical details about the optimal orbits are given here (and certainly would not fit elsewhere). IMHO, fine if your intent is to "advertize" SCANsat users about what is discussed here; anyway for future reference it may be worth to link some of your posts here with the OP in SCANsat, it will be much easier for users to find.

My take is the Initial State can't really be considered before making orbit. Once in orbit, there is a fixed relation between time and true anomaly/mean anomaly (always tied to an Epoch time), so time can be used instead of true anomaly to define the position of the ship for a burn. Once in orbit, it is possible to input the orbit parameters with the inital state; all parameters are fixed, but for true/mean anomaly that keeps changing with time, so it has to be input with the exact time (in KSP TOT, by using the Epoch entry). It should be identical for the Initial Elliptical Orbit with a Transfer and for the Initial State with Mission Architect; using the Initial Elliptical Orbit (and checking the Use? checkmark with Mean Anom. and Epoch) the result will actually show the burn time for the manuever changes when changing those parameters, so reflecting the different initial position of the vessel along its orbit.

Antenna arrays are used in reality to improve gain, therefore range, but no array is omnidirectional. Any increase in gain would in reality translate in a square root increase in range. But also, more antennas in game are equivalent to using more power in transmission, and that again provides for a square root increase in range. Therefore, doubling the number of antennas would result in reality in double the effective range, though at the expense of omnidirectionality. If needed, can show the math behind this, but is a pretty boring part. When antennas are not connected into an array, they definitely can interfere with each other (if using the same frequency band) unless they have different polarisation.

To back up sumghai, the new add-on posting rules @ 7. Legal boundaries are specific about allowing content of (only) the GameData folder be decompiled. Previous rules were not specific, and though Squad developers had given permission in the past, that remained a grey area, in particular with new KSP versions.

Definitely the above. No need to let further necro on this thread, and quite unprobable something new on this subject may be brought here, therefore best if closed.

Sorry if I am late to answer. Ferram4 provided a very good scenario with post #42, about impersonation. It actually helps with my considerations about the user status, because we would have no way to differentiate - once a user received such a status, we would have no way to state about what mod(s). Only the modder can actively make that evident (in the way he considers best) with his mod. A user who wanted to boast any competence with a mod may choose to show something with his custom user title or his signature (or other custom profile settings), as those are the only fields a user may directly change. If modders would like to allow for such visible signs of recognition, fine; but in case they weren't awarded, the staff may edit them from a user's profile. Also, if modders do like other ways to improve support with their mods, all the better.

The current situation is that already users answer to other users, trying to provide help within their possibilities. I did so a number of times, many others do more than me. Quite often, such help is useful with basic issues. I won't say the "malicious user" can't exist, but the KSP community is extremely helpful and positive: if anybody was to try and willingly provoke damage to others, somebody would intervene to warn in-thread, and most probably the wrong-doer would be reported to the staff. To this day, never heard of anybody giving bad advice on purpose, that proves this community and this system work (though, improvements are always possible). I would not worry much if an "expert" is shown on the OP by a modder. First, modders have no obligation to designate anybody; if they do, it is because thay already had some experience with those users and can feel they will do the right thing acting in a support role. But, in case, modders will hold no responsibility if issues are not solved (or worse), as there is no obligation at all to provide help with mods. Yes, I note (again) you would like some evident form of recognition be given, like with the status of a user (so, color-coding the username). Please, note I am not ruling it out, but have to make clear user statuses and groupings are only managed at the top level of authority with this forum, so the implementation of such a system may prove to be impossible. And even if it wasn't, we would need to implement a whole new set of rules, in some ways more complex than they are now. Not everybody is happy with too many or too complex rules. At the very least, we should first provide a recognition to the modders (but, anybody can become a modder just by publishing an add-on, the staff has nothing to do about that role now, and probably better so). Then we should configure what form of authority is tied to modders and experts, and that would certainly limit the choices of those who really should be helped with this system (the modders).

No such field currently exists, though it could be possible to make one. But then it would require an admin to manage that field (quite cumbersome if those experts are changing frequently), and it would not distinguish among the specific mods an user is to be considered an "expert" with. No, my idea is to actually have the modders establish who are to be the "experts" with a mod, and they themselves can provide recognition with that mod OP. So, there would be no action required from the staff to make anybody an "expert". But, if anybody was to self-proclaim an expert with a mod, and the modder asked the staff, we would consider action to keep things true to the modder intent. Still, this is new ground, no specific rules are set yet. It is my opinion that, if some form of improvement of the services to the community are possible within our grasp, sure we would like to consider them.

I am very much in favor of the idea of a select few "volunteers" who could alleviate the real modders from the daily task of supporting users, in particular with usual repetitive issues that cost a lot of time to address and were already dealt with. Some form of support from users to users is already visible, in particular with some well established mod with a large enough userbase. While not required to make this form of support in any way "formal", it may help if those users who are considered "experts" with the blessing of the modder, were also recognised as such, as new users may find more easy to distinguish their advice. Also, such "experts" may be more willing to keep an eye with that mod threads (and possibly with the general "Add-on Requests and Support" subforum) if being recognized. Each modder can decide on his own how to make for that, I believe an effective way could be to publish the nicks of the "experts" with the OP of that mod. Such experts may also serve to actually filter the "real issues" and present them to the modders, possibly in such a way to really help with bughunting and even with testing the new versions.

Hi and welcome . Getting to Mun is actually easier if your trouble is with the maneuvers: it is so big and near to be almost impossible to miss. You just need to achieve an acceptable Low Kerbin Orbit (LKO) almost circular and equatorial (0° inclination), and set a maneuver node on it so that Mun is seen at a relative angle from Kerbin of about 120° ahead of the node. With that node, place a burn prograde of about 800 m/s and you will see your trajectory elongate, its projected apoapsis to reach an altitude about 11400 Km (same as the distance Kerbin-Mun). If the node position is about right, the projected apoapsis will be where Mun will arrive, and you will see the trajectory change when entering Mun's Sphere of Influence (SoI). With Minmus the basic procedure is similar, but you have to also correct for Minmus inclination, and that may require an additional maneuver. The angle from the node to Minmus position is 114.9° and the burn prograde is 907 m/s for a LKO of 100 Km altitude. You should also set your target to the desired body first, from the map view, so to be presented with markers about your vessel and your target future positions at closest encounters. In case the above is not yet enough, you can certainly PM for "private KSP lessons".

Some good sugggestions were already given. But I feel something still missing. 1) RCS. Those are your friend when you need to make precision maneuvers, and docking certainly qualifies as such. Is it possible to dock without RCS? Yes, but requires a lot more skill, a vessel able to turn fast and with engine able to deliver very tiny amounts of thrust. RCS must be properly positioned, when used in translation mode their collective thrust vector has to be the closest as possible to the Center of Mass of the vessel, if used in rotation mode the pivot point closest to CoM. 2) Closure speed. No need to ram your target. Docking ports only work correctly at low relative speed, the claw works with some more umph but still will grab if touching the target at just the slightest of speed. A high speed will most probably make you bounce, and send your target spinning. Better to avoid. 3) Claw: it grabs if the surface to be grabbed on the target is at a low angle to the claw axis (best if perpendicular). Won't grab if angled too much. So, choose you approach so to come at a perpendicular angle to your target. Also good to aim for the center of mass of the target, but that is required only to maintain mass aligned with your vessel main axis (e.g. in case you want to push your target afterwards).

Nice improvements, as always . So much to make me give KSP 0.24.2 a go just to see VOID 0.14 in action (still playing on 0.23.5, and can't port my main game to 0.24.2 due to some required mod in it "breaking game" with the new version).

With the orbit tables you find a column "Inc." giving the correct inclination, as in "(00.00°)". To note, Inc. is an absolute value, is possible to use both positive and negative values with just the same effect on the scan coverage. All scans require highly inclined orbits (though sometimes the inclination is not that close to +/- 90.00° to qualify as "polar"), any point on a body surface at a latitude higher than the inclination + Eff. FOV/2 will never be scanned. To note, some orbits in a few of the tables show Inc. of 0° or close, therefore "equatorial" (most notable with Gilly, due to its very fast rotation): that because of the way they are computed, but such orbits are close to useless with scanning, one should always use highly inclined orbits for the reason given above.

Excellent, many thanks PK, looking forward to the new info . I know you are very precise on these values, so had to wait the new TAC to make those correct. Certainly one more reason to use US.