diomedea

I like this way for a basic authentication. That would work. About encryption, don't think it overburdens anything. Your browser can do it all the time, without you ever noticing. It is just a choice of using an already developed and recognized protocol to establish the connection, and is something done at a level lower than running the application (that burdens CPU and GPU - where really goes the load of runnning KSP). What load may come from encryption/decryption of a few data packets, anyway? About the motives for data encryption, it is because I can't think security when leaving clear data in the open. It is not something only banks or governmental organizations should be concerned with, either. As most other people here (including, it is evident, someone who doesn't understand security and has no idea of how NAT works, but likes to write on this thread), it may be you are considering that what you have to protect are only a few data about KSP. Not at all. This kRPC plugin has the ability to query KSP for any data it has available. But, KSP is NOT sandboxed (and I really hope you all can understand what it means). KSP has itself the ability to read information from within our machines. Without, theoretically, any limit. It is only KSP, then, to limit what are the data that can be retrieved; but nobody can see (as the KSP sourcecode is not public) what it really can do. So, allowing a non-secure connection via KSP and kRPC, is potentially giving away whatever you may have on that machine you are running KSP on. Oh, don't think anybody would ask kRPC to provide your passwords directly. But when KSP can find and retrieve files in your machine, and kRPC can transmit them to the outside, it is just a minor step for anybody to ask for *that* systemfile that holds users credentials. And the next step, that file may be updated with a new account... (this is just one of several possibilities)

Yes absolutely. I am concerned with the date (the +/- 1 day) mainly because it is another indicator of what may be wrong in the calculations. The representation of the date in Kerbin's calendar of 106,5 days (of 86400 sec. each) or 406 revolutions/year is another issue completely, it is mostly a flavor thing currently, though I would like to see that covered (using a Earth's year of 365,24.. days to represent Kerbin's calendar is off to me). What is mostly striking for me, is that your plugin works fine with the 3.991 factor you found (or, perhaps, should be 3.99064 as calculated?) and the simplified formula: dblUniversalTime *= dblKerbinTimeScaleFactor; But, it doesn't work if programmed with the complete formula and the correct KerbinTimeScaleFactor = 4: dblUniversalTime = (dblUniversalTime + 11700 - ((21600 / 9203545) * dblUniversalTime)) * dblKerbinTimeScaleFactor; though on a board or a spreadsheet the two formulas would give the same results (a very minor difference due to approximation; if I use the exact factor calculated from the ratio of revolution/rotation periods (4*(1-Tsro/Torv))=3.9906399003, the result is exactly the same). Really seems like I am lost on some basic arithmetic, on paper the two *must* behave the same, as the result is identical. But in practice, once that last formula is written in C#, it gives something different. While I have your attention, may I ask for a minor improvement? I would like if daytime on Kerbin was more evident, and think about having different colors in the Kerbin time box to represent that. Like, light grey text on dark grey background at night; white text on blue background in daytime, and even some purple/pink variations for sunrise/sunset.

Thank you for that. I believe the above is a valid improvement, but even more important is to know what this allows or not (and I am thinking more about users who don't know what computer security really is, and delegate everything to a security suite - if they even do - but then open the floodgates allowing any connection through their firewall). I am sure you will agree, knowing what dangers exist is the most important step with security, as no valid protection can be raised against the unknown. About NAT, there is some misconception about the protection it offers. The protection comes from the firewall, that with the average home netwrok setup also has NAT service. But NAT doesn't make any filtering, any incoming traffic for a valid port will find the target machine: I don't have to find the correct internal address of that machine in its private network, if the NAT service itself provides a way to get to that machine by calling the router address. I am no "network" security expert, either. And I actually know much more about other fields of IT than networking (I will never be able to program a RPC handler). But I had, among other tasks, responsibility for overall security of the IT department of a large organization, therefore my instinct to immediately look for possible issues with this kind of tools. To improve further on this aspect of security, I would ask the following: 1) Is there any authentication mechanism of the client calling the RPC server? In case not, it means that anybody, without effort, will get a valid answer just by sending a call to the correct address:port. It doesn't take much, with a scanner, to find what ports are open on any machine, so if there is no verification mechanism, it takes very little to make a valid connection - without the owner of that machine knowing. 2) Is there any logging of the exchange? So that, at least, it could be possible to find when and how data were moved? 3) Protocols (I may find this by checking through your code, but I'm lazy, sorry). Which ones are used to control and actually make the data transfer, perhaps HTTP? TCP? Each of the above has specific weaknesses that allow unwanted connections to be established. Moreover: 4) Data encryption. Does this use any protocol that include a data-encryption/decryption mechanism? So that nobody else than the client that originated a valid request, can decrypt data (that would otherwise be flowing in clear through the net, for anybody along the way to read). About the last points, I would consider what Microsoft does for RPC security, as in this page.

Either it is me not knowing (yet! ) how to properly use all the features of KSP MA, or it is missing one (probably already in the plans with the auto-update, but). Situation: KSP MA has the mods resident in GameData in its main mod list (that, I understand, is maintained through a XML file). Now, every so often a new version of an existing mod comes out (like, with me having 70+ mods installed, 3 or 4 new versions a day on average!). So, I download the zipped files for these new versions, and let KSP MA find them (Add mod button). So, the list is updated with a new entry for each new version. Now, I want the new version to replace the old one in the list, but keeping all the mod information that was entered before: corrected mod name, author, spaceport link, notes... only the version number to be changed. I know that, if I just instruct KSP MA to proceed with a mod zipfile, it will install its contents where they belong, so updating all files with the same name in the same position already in the previous version of that mod. But that action does nothing to remove one or other of the entries in the list, both actually pointing to the same mod in the same position. Short of editing the KSP MA XML file myself to remove a duplicate key, I am therefore always checking, carefully, to transfer all mod info in the new version entry, before removing the old version and then installing the new one. Only removal of a mod, for what I know, will automatically remove also its entry from the list, so avoiding duplicates.

May you provide some information about the security with this plugin? Anything that allows to read data from my computers and fetch them to the outside, can be considered a potential security breach. The big software houses make a lot of efforts to check that their products are secure, and sometimes fail. Now, I am not suggesting you bring this to an independent certified security lab to have it evaluated and classified according to ITSEC/CC. But I would like to know if you took any steps to avoid potential breaches, as e.g. those that may come from a malformed RPC command. There is some literature around the net, about RPC intrinsic insecurity in some situations, but I believe you already know and probably have dealt with those issues.

Many thanks. I knew you had to know something about how KSP drawing routines work, therefore I asked. And sure it shows, you already have some ideas about how it could be done. I am happy you are going to look at this, though certainly I don't want you to lose time if that requires more than using the tools already available from Unity and KSP.

Yes, absolutely. It is often a pain, in particular if more than one node or other object is in the same "space", to catch the old ones and remove them. It actually helps a bit that PreciseNode allows to edit a node, so it is easier to catch any particular one. Better to have this as an option, sometimes old nodes can have some meaning left. While about editing nodes, I have a request. Something even more weird than my usual (but then, I like to use tools in unforeseen ways - and I know how to burn a node exactly as planned, even if I like how MechJeb does). I would like a tool that allows to compare different navigation plans. As any navigation plan can be defined by nodes linking segments of orbits, I want to see two alternative series of nodes with the orbits they determine. Both the navigation plans to be displayed on the map view at the same time. This feature could be used, e.g., to keep a possible solution for an encounter, while looking at other possibilities (but a lot other uses exist, though I may be the only one using such a feature to see how to maneuver together two spaceships to make them meet). Regex, could you be so kind to tell if such a feature, to have more than one navigation plan displayed at the same time, is even remotely possible within KSP?

Thanks for explaining. You got it perfectly, everything you wrote matches with what I observed. Really hope for that possibility of a look-ahead functionality, it would help immensely. Right now, if it wasn't for your plugin, there would be none allowing to set up nodes for these situations.

There is one feature of PreciseNode I don't use often: the ability to set a node to Apo or Peri. However, this time it seemed the right feature to use, when I needed to set up a split burn and wanted to show it with a series of nodes at the periapsis. However, PreciseNode Peri seems to not like future trajectories, and screwed up the UT of every single node (I stacked 5 or 6), putting them at what seems like random positions (not one of them at periapsis!). Ok, old habit resumed, using the UT controls to move each node where I want: But, what is the correct way to use Peri/Apo? Are there limits/constraints that may have effect on those functions?

Ok, thanks. I did another bunch of tests using your suggestions. At first could not make the optimizer work, generally only receiving errors or nothing better than the initial guess. I won't annoy you with hours worth of tries. In the end, by trial and error, I found the following that made the optimizer provide what appears to be a valid solution (non identical, but close to the initial guess from KSPTOT): - set the objective as you suggested, minimum distance from Eve in the optimizer; no constraints in the right panel; - with the burn event, to be optimized, set the upper bound for DV to a suitable value: the optimizer opens with the bounds for DV set =0 and cancels out any speed change as a result, if those defaults are not tweaked; - have another coast event, before the one set for Eve's periapsis that you suggested, and allow also the first coast event to be optimized (again, removing default bounds). The final coast (to Eve's periapsis) is not available for optimization (I must say, contrary to what I would expect), therefore arrival time can only be optimized because of the previous coast. Ok, I know I am testing a non-finished product, and the amount of features it provides require some knowledge to use correctly. Please consider how important it is to provide detailed instructions, as some potential users can't spend a lot of time trying it to see what works and what not.

Ok, did some tests. Some considerations that may help, though not a solution (yet). To be safe, I not only put the Kerbin factor to 4 in the config window, I hardcoded it to 4 in the plugin. First off, confirm there is this differenc in time for each passing day. Could be about 4 minutes/day. Can't yet say why. Then, checked with a fixed star, how long it takes for Kerbol to make one (apparent) revolution around Kerbin. It is confirmed it takes 9203545 sec. That time makes for 426 sidereal rotations of Kerbin (Torv/Tsro), of course one day less due to the apparent movement of Kerbol in local time, so 425 "kerbin days". With your plugin, the difference in dates in a Kerbin revolution is indeed that (426 days, hope the 1 day difference is due to inaccuracy in the measurement), but of course the representation of the date is not correct, as it is based on the calendar on Earth: 426 days are about 14 months, so the date is shifted of about 2 months for each revolution. If you want to provide a representation of date similar to the Earth calendar, you should invent a year of 425 days (12 months of 35or 36 days each? 14 months of 30 or 31 days each? or just no months, 425 days in all). It seems weird to have a measurement of time, that on Earth is strongly perceived as tied to a year, that instead changes the starting day each passing year (like, if new year's day was moved to 1st March, than 1st May, and so on). Now, I have a suspect (but still must make my mind on it, maybe with your help and your friend's...). It is common knowledge that one Kerbin's year is 106,5 days (of course, Earth days 24 hours long). Indeed 106,5 = 9203545/86400 (that is, the UT difference in one of Kerbin's revolutions, divided by the seconds in one of Earth's days). But if we are to consider 106,5 days a year, while the true ratio of rotations/revolution is 406, we would be missing 300 rotations for revolution. It is not exactly like the 4 minutes a day difference (that would require 360 missing rotations to make, given the 6 hours/rotation period of Kerbin) but is close... So, there is to check if that factor of 106,5 kerbin days is someway coded (also indirectly, as a ratio of other numbers) and used in lieu of the true rotations while computing time. Hope that is not too confusing, it's late (in every sense) and I should better get some sleep rather than writing this... but hope from this may spark the good idea we need to solve this problem.

Thanks for the sourcecode. May I ask, are you using dblKerbinTimeScaleFactor = 3.991 together with the (-(Tsro/Torv)*UT) part of the formula that deals with the revolution effect? Cause with the last, the TimeScaleFactor should return to be = 4. double dblKerbinTimeScaleFactor = 3.991; ..... if (isKerbinTimeScale) { dtKerbinInitial = dtKerbinInitial.Date; dblUniversalTime = (dblUniversalTime + 11700 - ((21600 / 9203545) * dblUniversalTime)) * dblKerbinTimeScaleFactor; } dtKerbinCurrent = dtKerbinInitial.AddSeconds (dblUniversalTime); Fine if you want to involve others. More eyes on this (especially if good ones) the faster this thing will be dealt with. If you like, I will continue to try and see about it, anyway. This is one kind of problem similar to what I have to deal with in my profession.

Ok, I seem to be finding all the weirdest things. I did try one thing, first using KSPTOT to find a transfer window (I am looking for a transfer from Kerbin to Eve), then using the same data that KSPTOT provided as input events for MA (both initial state and burn). I would have expected the final state to be the same, instead the trajectory around the Sun shows to be quite different; of course I don't even expect MA to find Eve at the end of that different trajectory. No optimization run with MA, as it wasn't needed with the transfer trajectory. I took some screenies of KSPTOT and the mission plan from MA, bundled here for you to see. I can't find errors on my part, but clearly I have not enough knowledge with KSPTOT or MA to exclude any.

Short of making simulations myself, I have no idea at the moment what could be wrong now. One thing is, anyway, sure. That factor you found to be working (3.991 instead of 4), is exactly the same that would be found computing the rotation - revolution period against only the rotation period. To show that, first I will show how I compute the apparent time. My procedure for calculating time is (UT= passed time; K= cronograph correction=11700; Tsro=sidereal rotation period=21600; Torv=orbital revolution period=9203545, all in seconds): - Time Angle due to sidereal rotation (Θsro): (UT+K)*360°/Tsro - Time angle due to orbital revolution (Θorv): UT*360°/Torv - Total Time angle (Θt) = Θsro - Θorv - Apparent Time (t) = Θt/360°*(86400/4) (on Kerbin) while the procedure you found working is: - Apparent Time = (UT+K)/Tsro*(86400/3.991) the two procedures give ~ the same results. Infact, your 3.991 factor is found if calculated as 4*(1-Tsro/Torv)=3.99064. That is to show, the issue about that factor IS really the one due to the revolution period. Anyway, I want to think a bit about what you found. It seems time is getting late at a rate of about 4 minutes/Kerbin day, and that rate is 1° a day in our universe (360°*4/(60*24h)), or about the same angular movement the Sun would be seen as moving each day (360°/365.2425 days). A very telling rate for an astronomer. Maybe I will find what that means. In the meantime, if you could make some more extended tests, those will probably allow to find what is wrong. Or, in case, would you provide the C# sourcecode of the version you have in development? So that I may make some tests myself. DateTime.AddSeconds seems really straightforward. But, a thought: does it manage leap years (like 1980 is)? That may be one possible cause for the missing day, if the added seconds make it go beyond a 29th feb boundary.

@ nuclearping: 1) from the picture, and the implementation you did, it seems you got it! 2) I use a different method than your implementation (computing time angles from time elapsed and rotation or revolution periods, and then converting those angles in time) but the end result is the same. With the same data you used, time is 184d 18h 07m 22s. BUT: 3) Just thinking back at my example, with a non-rotating Kerbin: if Kerbol was observed to rise because of the revolution, it would rise from West!! A counterclockwise revolution brings to time elapsing backwards! So, my fault as I did not consider the sign: not add, but subtract the angle due to revolution from the angle due to sidereal rotation. With the same data of your example (UT=3969694) that would give 183d 21h 25m 10s. Time seems to match with Kerbol position in your picture; about the 1 day difference (183 instead of 184) can't say, could it come from how the variable "dtKerbinInitial" is initialized? 4) About the picture showing 07:46:17 in your example. You did yourself the calculation correctly, but what is shown is different. Possibly, there is some hidden conversion not correctly executed (I have no knowledge about functions like .Date and .AddSeconds, so can't say if those may be responsible).

Did the test again, but either I am getting a better feel with MA, or I made some error before. Coasting to a set true anomaly now works. Did not test any possible conditions, so can't exclude some improvements can be done, but so far, really good and promising. Anyway, if some conditions are plain wrong or inapplicable in a given situation, I would like those to be filtered and not allowed: in a sample case, I tried to put a coast to anomaly=0 while the state was already at anomaly=0: that means a "null" maneuver, but there is no warning and it is taken as good. About the drawing, yes, makes sense. Indeed MA can't consider (yet) burns of finite duration instead of instantaneous, also I expected the burns to be shown with the predicted trajectory after the burn (as KSP does), while for me the idea of the coast maneuver was equivalent to letting time pass. But MA is right to show things this way.

I think you will smile after getting it. It is not too difficult. Consider if Kerbin was not rotating. So, KSC zenith would always point to a fixed location in space (think like there is a distant star in that location). That would be, by definition, making Kerbin sidereal rotation speed = 0 (and, conversely, Kerbin rotation period infinite). While Kerbin does not rotate, it still revolves around its star, Kerbol. This revolution period is given (9203545 sec.), of course it is tied to the mean distance D from Kerbol and the gravitational parameter GP of Kerbol (period T = 2 * À * √(D3/GP) ), however we don't need to calculate that. The fact we have to note, instead, is that Kerbol apparent position in the sky will change, exactly the same as if it wasn't Kerbin revolving around the star, but the star around Kerbin. This is the same concept that, on Earth, was at the base of the Ptolemaic (geocentric) system. Because of this revolution, the star is seen as doing one full circle around the planet, in a year on Earth, or in 9203545 sec. on Kerbin. That full circle will make one day long as one revolution: there will be one sunrise and one sunset. Now, on Earth, since the beginning of humanity, there was no knowledge of the planet moving. Because it took some time (apparently) for the Sun to complete one round, that time was used to define the duration of a day. Humanity had no knowledge that time was due to both the rotation of the planet and the revolution. It was observed, however, that the stars (the distant ones, considered fixed in space) actually moved in relation to the Sun, day after day. The length of the year was put not only because of the seasons, but because the stars took that time to complete one full round in relation to the apparent position of the Sun. So, our time reference of 24 hours/day in not due to the planet Earth's rotation, but is tied to its rotation and its revolution, together. And humanity took the sun movement as a fixed reference for time, while observing the fixed stars rotate in relation to it (while the truth is just the opposite). In Kerbin's case, the fact is that Squad, instead of thinking like ancient humans, defined time in relation to the fixed stars (sidereal). And that means we will see Kerbol change its position along one of Kerbin's years, making exactly one more day that what we would expect based on the sidereal rotation period.

I have one possible explanation. Kerbol (the Sun) moves apparently because of Kerbin's revolution around it. Kerbin's sidereal rotation period has been defined = 21600 sec.; please note "sidereal", meaning in relation to fixed stars, not to Kerbol. With our Earth, the 24 h rotation period is defined around the Sun instead: because of the Earth's revolution, there is a difference of one rotation in a year against the sidereal period. So, to correct your "Kerbin time", you should consider it takes 9203545 sec. (accordind to KSP Wiki) to complete a revolution, and compute apparent time (with reference to Kerbol position in the sky) not only for the rotation, but for the revolution period as well.

Perfect. Thank you very much.

Hi Arrowstar, tried your pre-release build (the new version), it works. Fascinating. But, I hope you will provide some more detailed instructions on how to use Mission Architect. I give it some simple events (like a prograde burn), sometimes it updates the final state accordingly, sometimes goes crazy. It seems it expects some conditions, while others don't work (therefore, should be better to restrict input to only the ones valid). E.g., after a prograde burn, if I input to coast until a set true anomaly, it doesn't work; it works if I coast to apoapsis. Also, the graphical display seems to update only with coast maneuvers. About the optimizer (it IS FAST, less than 3 sec. x iteration): sometimes it finds a solution in very few cycles, sometimes it continues forever, with a maximum constraint violation <> 0 and both it and the function value not changing between iterations. Some hints on how to help the optimizer in these cases would be welcome.

Probably I am missing something, anyway, better tell rather than not. Both with Devbuild 5 and Devbuild 6, clicking the "MCE settings" button has no effect. All other buttons open some MCE window; not the settings one. Is this due to the Devbuilds not being complete release versions, or could it be something wrong in my install? Including, possibly, a conflict with one of the other mods I have? If that's the case, any interest to find what may be causing that, and therefore to have some more detailed report on this "issue"?

I am positive you solved that issue. Did exactly the same test as before, with the new version: no problem found. Thank you.

I totally agree with Arrowstar, this discussion has taken out of context. Until it was something related to the SoI dimensions and how they effect computations, it could be fine. Now, you have put it on tidal effects (that are within the same body, due to its mass not being concentrated in a single point, so a very different thing) instead of gravitation applied to a system. Also, my formulas don't have some G=9,81 factor too much. But this discussion must be taken apart. If you like to continue on this subject, better to have it somewhere else. I believe we both can learn something keeping on this, but not here.

Yes, that answered my question perfectly. No third body is considered along the trajectory, and that fits completely with KSP model. Correct enough for most maneuvers, instead of any maneuvers. But certainly the best approach for fast solution and, given the limits of KSP universe, adequate to the task. The real issue is with the KSP model, while ships go "on rails" their trajectories are stored instead of updated, and that is not only in regard of eventual third bodies, there is no aerobraking either when periapsis is lower than the atmospheric height. In KSP (for what I can observe) the trajectory of a ship when loaded diverges from the trajectory stored when the same ship is "on rails". BTW, nice Mission Optimizer mock up.

I see. I suspected you were making that mistake, and now i have that confirmed. You did not consider that Sun gravitation acts on the Earth-Moon as a system. While Sun gravity acts on the Moon, it acts also on Earth, and the two move (fall) towards the sun together. The correct way to calculate Sun gravitation acting on the Moon is as the difference with respect to the gravitation affecting Earth. This difference is greater when Moon is closest to Sun (new moon) than Earth, and the distance Earth-Moon is greatest (405000 Km): the differential gravity is 2.37E+18, against Earth gravity on Moon at that same distance of 1.784E+20