diomedea

From this mod window, click "Open Settings..", navigate to Settings Section = "Styling/Visuals", under Styling find the "Use Common Toolbar" selector. Of course, with the Toolbar, set the Button Visibility for this tool, or it won't appear.

Let me second this. I am following closely both threads, and actually I suggested to the original author of KCT that it was better to integrate it with KAC. Exactly how you have devised it: to have KCT generate alarms for KAC to display (with all the management features KAC allows, too).

Let me second this idea. Sometimes I need to shift one orbit too, though I still find uses for the +/- 1K buttons. I am a bit puzzled by all of this recent discussion about UT times. Yes, certainly, it would be useful to use *also* a time measure in hours/min/sec. But, it is no big deal (to me) to convert all in UT. In case of a whole orbit shift, I need to convert the orbit period in seconds and add that to the UT for the maneuver. In the end, all of this is about a more easy way to input your node values. I can do that with the buttons and UT (as already in the mod), with specific points (Apo/Peri/AN/DN and now also +/- one orbit), and could do if other ways are devised. But sure Regex is right: all of this can make for an overcomplex GUI with this mod. And space for its window is *real estate* on a KSP screen, so better not to enlarge that window any further than it is now. I don't know how complex this could get, but can't all of these GUI elements be configurable? Some users want UT times, others day/hh:mm.ss; some users like +/- buttons (up to 10K and, let me say, I often find significant a +/- 0.001 that actually doesn't exist, to set my nodes perfectly right) while others want significant points (Peri/Apo/AN/DN and so on). I would like to see, perhaps, a new secondary panel with this mod that allows to use any of the above, and possibly select those for the main panel GUI to show.

Very nice surprise indeed. Thanks a lot!

AWESOME. Sorry I did not find that, all those very nice new features show I must learn again how to properly use this mod.

Hi Trigger Au, may I ask what changed since version "2.0" about the order resources are listed? With version "1.whatever" resources were listed in the same order the standard resources panel works, and in particular electric charge at top, then monoprop, and after other kinds liquid fuel and oxidizer close to each other. Now I believe they are listed in the order resources are defined when files are parsed across GameData. IMHO, electric charge at top (given the variability and importance) and LF -OX close to each other (as they are used together with rockets) is best. BTW, thanks again for making and still improving this wonderful mod.

Thanks for sharing your vision on those improvements!

Understood. Sensible choice, when no other possibilities exist. However, I hope something could be done also to help with all those mods not hosted on Spaceport. I will wait when you can get back on this after your holidays (enjoy ), if you concur on the possibility to make for: 1) the removal of only the xml entry about a mod in the modlist (leaving all files in gamedata, in particular about files with the same name); 2) copying modinfos from one xml entry to another. The above features would allow some easier management for those mods where auto-update will never work, due to them not being distributed via Spaceport. Or, maybe, you have even better ideas.

Not stupid at all. No, I sometimes check what the modbrowser will give, but only to test it works. I always find the most recent versions of the mods myself, looking at the various threads in the forum. I download those new versions myself, and then I fire up KSP MA and add the new downloaded versions to its list. Please consider that A LOT of the mods I use are not hosted on spaceport, anyway: the author often provides a link to each new version, be it with dropbox, google drive, github, or any other file hosting service.

@ blizzy78: what more you have in development for future versions? (that, given your dedication and speed, will probably arrive in a matter of days). I really hope folders will receive some love, as they miss a few configurability options: - changeable icon (not the same for all folders; could use icon of one of the buttons into the folder); - no button ordering within a folder, nor reverting a button out of a folder.

@ Papa_Joe: could you shed some light about your future plans, in particular with the "In Flight Checklists" you mentioned some days ago?

About the different combinations of colors for the time box. I would like to make some tries, if you could hand me the code where you already had the styles defined for those tests. It certainly requires some effort to find combinations appeasing and looking good with anything that KSP may be displaying. About the timezones. If KSC time is all you want, no problem. There are users who actually "colonize" Kerbin, or at least conduct missions in different places over its surface. The very minimum, to have a look at the anomalies at specific points; or to collect science from different biomes. But they have always had to do without any correct clock, so may not miss much not having time for the correct timezone. It was an additional feature that could be made without much effort.

Let me say, there are various things that can possibily go wrong (and I am sure I have not even found them all); but not always that easy to tell what is the problem. Sometimes the optimizer "hangs" after the first iteration. I have this happen consistently if I forget to give a final coast maneuver in the plan that makes sense; e.g., if I set as objective for the optimizer "minimize distance from Eve", I must have a coast after the maneuvers to be optimized, that goes to the periapsis of Eve. I did that mistake a lot of times, as I could not understand what was happening. I am sure other conditions need to be set or the optimizer hangs, but I don't have a firm streak of other cases. Other times, it is the applet drawing trajectories that keeps telling "working" forever and never updating. There were, at times, windows telling something like an "index not found" or what seems like a function not having the correct parameters (something like fmincon ?). I will try to summon those again. I am still trying to enter the SoI of a children (e.g. Eve) after a transfer around the parent body (Sun). Even if the solution found by the optimizer is similar to what I expect, there is not a SoI transition event, nor anything related with the children displayed on the map. If I try to set a plan to coast to next SoI, I will get the warning: Cannot coast to SoI transition (no SoI transition found). Anyway, the above is rather sparse information, and I believe it should be possible to provide something better. Here is the ksptotlog.txt file, I see it includes error reports, though not very much about what was going on at that time. If you can provide me with the proper instructions to get more complete reports, I will do.

Agreed. Very good points. Exploits certainly exist, and even more measures than suggested til now would be needed to further limit them. Though, I am not considering system-wide vulnerabilities that should not be this plugin business to amend. But certainly, if you spot any other measure that would significantly improve security with this plugin, please tell. Understood what is your point with encryption load. Yes, there may be machines running KSP that only have dumb NICs and not multithreading. If I'm right, you're suggesting a different program, outside KSP, handling encryption and traffic to/from kRPC, could be a better solution. It's kind of an interesting sys architecture that should work. I suspect something useful for this purpose may already exist, need not be developed; but you may already have something up your mind?

@ djungelorm: happy about the changes, real good improvements already, and good plans for further. And, even more important, you are telling users what to expect from kRPC, so they can (at least in theory) take their precautions if trying to use it outside the protection offered by their home networks.

Pontiac, it was a very good read. Interesting setup you have at home. Not going here to give details on mine, as my posts have already derailed this thread too much. On the important points, I can confirm the first impression I had. There was that start about thinking encryption on itself (if that was the case, I would totally agree), but hope to have made clear encryption was only the last of four questions about security - the first and most important the client authentication, that I believe is exactly what you also were considering. Those concepts you show about what may happen once an unauthorized client got access are exactly what I was meaning on other posts (but it seems others did not want to believe). I wrote kRPC may allow to send out any data that KSP has access to, and that is exactly the same concept from you. You make a point about the complication security will add to plugin makers. Sure it will, I am not denying. But, there are plugins inherently more secure than others. I really love a lot of those, and feel secure (though I am obsessed with security). Fact is, no plugin to KSP (or any other) can establish a connection if I deny it. I have only two that actually want to connect to the outside world, and both I have checked the sourcecode, and compiled them myself. I check everything for malware behaviour, but then it is enough. So, I don't ask, nor want, other plugins to deal with these complications of security. What is different here, is this application will actually open a port to the outside with the promise to deliver any data from KSP. So, this is a very different business. I can't check what kind of data it will deliver looking at its code (as that is in KSP realm), so I am left with the only option of using security measures. That, I strongly believe, I quite know about, therefore I am suggesting. I may even leave it as is, as I don't really need kRPC. And nobody, who only wants to run kRPC on its internal and well protected network (!), will need all of that added security, either. But other users should at least know what may happen (and you provided very good explanation about) when they think about internet connections thanks to RPC (and I already saw a few jumping for that possibility). After all, what I learned and teached, the first and foremost security dangers come not from technological shortcomings, but human behaviour (both admin and users). Another point of yours is about speed. Certainly, data encryption makes for slower connections (I was at a time in a project about very fast cryptologic machines, then to be used for overall protection of a very large extranet, so I have an idea of what you mean). And again, on the technical side, I concur with you. But there are two or three concepts here I have to make: - data encryption is not a burden for the CPU; it is noticeable slower but at a lower level, that the system delegates to (as I understand) the firmware on the Ethernet port (or, to other firmware on encryption modules, if you use those on your machine). So, KSP will not experience framerate losses as both CPU and GPU will keep going only about their usual business. - It is the remote client (asking for KSP data) that will feel a slower connection and reduced data rate, but here we have not even begun to consider amount and frequency of the data needed to run anything on the client side. Not really the business of kRPC, in my view. - even if it was the CPU to directly handle encryption, it would do in a different thread than KSP. My KSP machine is pretty good (pretty on par with yours), but when KSP really chokes, it is only at 25% load (the biggest load is with the GPU, but still very much lower than max). The problem is with KSP, of course, and multithreading, so that not all the resources of my CPU are used. Unless of some very inappropriate load-sharing method (that system should actually optimize), I can't see why KSP and data encryption would hurt each other. Then, you recommend to avoid burdening the mod with data encryption. And I concur, because what I want is for this mod to use (if that is the choice) data encryption provided by the system. This mod will only have to use the correct calls (something I saw is available, according to some Microsoft papers) and data encryption will be in.

Be sure, I know about ISO/OSI. But again, this all started with a set of questions, all of them connected, about how security would be managed. Others have pointed to specific aspects, but looking at those in isolation, the whole issue was lost (though, on themselves, the specific issues like validity of encryption or firewalling rules they have considered have a lot of importance). One question of mine was about the set of protocols this application was to use, but that doesn't mean it has to handle them directly. Rather, it was to mean what were those that would support it (I even hinted at the possibility some were TCP/HTTP, but as you certainly know, there are other possibilities, and some are better then others). Though the protocols stack is handled by the system, it is in the end the application to make the call for the system to provide a service through those protocols. Hope to have made my intention a bit more clear, sorry if it wasn't before (or if it still is).

@ Pontiac. Your post is really too long, sorry you had to write all that. There is one flaw that inficiates how you start: thinking encryption has no value cause one may establish a connection. The very first of my proposals was about authentication of the client. Security without that is null. About the rest, you put a lot of very valuable concepts. Very long read, will try to when I have time.

Look, you are right, in that NAT can't resolve the internal address for a generic connection (then it is seen as filtering, though it is a very different thing). But the issue here is, if this kRPC works across the internet (as it is stated in the OP) it has to establish a port and listen there. And, for it to work, that port will be translated by NAT into another, valid port, at the router level. The outside client will not have to look for the specific machine at all, the internal IP address is not its business. It will ask for a connection with the router, and then that connection is internally routed to the correct machine. That, or the whole client-server model won't work anymore. Also, about the encryption. Sorry if, because of other discussions on this, it has gone out of where I actually suggested. But if you check back, I suggested to use an already existent protocol to allow for encryption. And, a protocol that is very widely used. Not that this application should directly deal with encryption itself.

I want to find a meaning for that value of 11700. Even if I have begun to call it K (as is called the correction to chronographs, used in navigation), I had to believe it is tied someway to the longitude. Until now we have considered local time as tied to KSC. That is right, but local time (in the astronomical sense) is used for navigation purposes, not in everyday life. What we have on the clock is the time of the timezone we live in. On Earth, 24 hours define 24 timezones; and with a Kerbal day of 24 hours, it should go the same. Each timezone is (unless for geography and state borders) 15° wide in longitude (7.5° Eastward and 7.5° westward of its center meridian). So, KSC, at a longitude of 74.558° W, is almost in the center of the timezone -5 (its time is 5 hours less than at the prime meridian, that is the reference with longitude=0°). Because of the above, it means it will be 11:00:00 (5 hours more) at the prime meridian, when we have sunrise at KSC (06:00:00 on the clocks of that timezone). Now, time is computed from midnight (00:00:00). So, I should rather choose to start not from 11:00:00, but 11 hours before. With Kerbin's rotation period at 21600 sec, 11/24 hours is 9900 sec. Therefore: - the correct value of K, as (now really) a chronograph correction, is 11700-9900 = 1800 (Chronographs are never updated for the timezone, so when used for navigation are generally set on Greenwich Mean Time. K is the error of the chronograph in relation to GMT); - the time difference at KSC (measured on the clock) is -5:00:00 (the reference is the timezone 0 centered on the prime meridian); - the local time at KSC (astronomical) is (-74.558°/360°*21600)= -4473.48 sec (= -4:58:14) different than the local time at the prime meridian; - the value of UT (as "Universal Time") has no implication of locality. It is the same everywhere (KSC, prime meridian, and in outer space). About K. I would have expected from Squad a choice of initial positions matching the notion of midnight at UT=0 for the prime meridian. Instead, that value of K shows a different choice. At UT=0 it is midnight for the timezone +2 (centered on longitude 30° E), if K is assumed = 0. Conclusion. We now have the correct value of the local time at KSC, matching with sunrise. Let we consider them to be astronomers, so they go with local time. But, when we move around Kerbin, we see time differences due to the different longitude (note: as Kerbin has no axial tilt, there is no change in local time due to seasonal changes and latitude). If we want, it could now be possible also to use the local timezone, instead of a local time valid only for KSC. To do so, we better have to use K=1800.0 and subtract the timezone number *900.0 sec to the formula. We set timezone = -5 as default for KSC, but that may be changed to let show the time of other timezones.

NOOO. I can't believe...it was so... simple! (but, damned C language: why it uses integers when we mean otherwise ). Please extend my thanks to your friend. EDIT: BTW, noted you put 9203544.6 for Kerbin's revolution period, rather than 9203545 (as reported by KSP Wiki). The first value is exactly what I have by calculating the orbital period from Kerbin semimajor axis and Kerbol gravitational parameter, so confirm you have it correctly. Now.

I use version 1.4.0 PR3, but any newly downloaded mod, when added to the list is displayed only with the zipfile name. No ModInfos are added, I have to input them all by hand (am I doing something wrong?). Also, is there a safe way to remove an outdated version from the list? the only way I know to remove a mod, is selecting it and clicking the remove button. But I only do so before installing a new version: if I was to first install the new version, then remove the old, I believe I will end removing all the files with the same name, regardless of the version. So, even if to update a mod I would only need to process the new version, I first have to uninstall the old, to remove its entry from the list. Could be possible to add another button, to only remove the entry in the list but not touching files within GameData? (actually, its behaviour the reverse of the Add mod button). And, even better, a button allowing to transfer ModInfos from one list entry to another?

That above is exactly my understanding. Thanks for confirming, data encryption nowadays does not put any burden on the CPU, it is all done by the firmware behind the Ethernet port (that everybody already has). Or, by other highly sophisticathed encryption devices used in secured networks. And yes, you are right also about the firewall and router, one needs to set up rules to allow new connections (unless somebody has actually turned all filtering off). If anybody wants to use kRPC only within his network, before the external firewall/router, that would not be a problem. The problem comes from the prospect that kRPC will allow to connect via Internet, and people already planning to actually do that. Therefore, going to set those rules allowing such connections through their router.

So, 11 days passed and sunrise gets late by 47 min? Pretty close to that rate of 4 min/day you already discovered. And that I would still like to find what it means. But, could you please recheck and tell me about the change to K. 22900 - 23450 = -550 sec., or 9 min 10 sec. (that is way different from 47 min on Earth, but are different also with the rotation in 21600 sec on Kerbin). Each minute on Kerbin, when measured on a 24 hour cycle, is 15 real seconds worth; then those 550 sec / 15 = 36.67 min. Also, I would like to test the precision of that KerbinScaleFactor. However, I don't have much time currently to run that test. As I wrote, from the ratio of rotation and revolution, that factor should be 3,9906399003. As soon as I can, I will use that value with a very long test: given the precision of that factor, if correct it would take 96285 days (or, 903.896 of Kerbin years) to find a slight error. Anyway, in case that is found to be correct, I would actually hardcode it in the plugin. One more question. The correct formula (if worked) would actually allow to compute daytime for any planet or moon in Kerbal's universe (it may be at times sllightly off for bodies with eccentric orbits, like Moho and Eeloo). So, apart from the interest in finding why that formula doesn't work, it would be useful to keep looking at this issue if you plan to implement other bodies, in a future release.

@ Faark. What you wrote is fine only when thinking about the usual way to establish a connection. I thought to have written (but was probably on the previous post) that you may start the connection otherwise, using a well recognized port. Start there, get an answer, modify the address:port and resend the query, then see. If there is a port open listening...(exactly what an RPC server does. A server does not initiate a call, it answers that). So, in case still that isn't clear: when you start a server on your machine, you want to allow it to establish connections with clients calling from the outside. So it is the server itself wanting to open a port , and even if address:port are scrambled by NAT, there will be one port open and valid that allows incoming connections. Your NAT will not filter such connections (it will be the firewall, if so instructed), but instead will translate for the correct machine and port in your private network to be reached. Portscanning is often inhibited by a firewall (absolutely not by NAT), but then it depends on how the firewall rules are set, and you can't say it won't work altogether if not on your own installment (where you are in control of that firewall).