diomedea

What you mean, you did the calculation wrong and are trying to demonstrate what is a physical impossibility?

Yes, the question was: That question arises to me as you wrote that KSPTOT uses infinitesimal SoI radius. Now, that may mean what I put in the question (true multibody computation along the trajectory, that makes the SoI not relevant) or the opposite, discard any other body (solving for 2-body only) as those infinitesimal SoI are never entered along the trajectory. The question is, really, about the correctness of KSPTOT solution in the case of a third body along the trajectory.

Actionable checklists! Sounds really nice, hope to see these soon. And, these may be really of help with child ships, what undocks from a mothership has no set actions.

I found what could be an issue with the ProgCom IC part. Unfortunately, I wasn't able to find exactly why. So, I can only report my finding, you probably know how to solve that. I use A LOT of mods with KSP. One of those is Ferram's Aerospace Research (FAR). So, I use to check while in the VAB how a ship would handle with aerodynamics, thanks to the analysis system that FAR provides. So, I build a ship with the ProgCom IC, and now that FAR analysis doesn't work right any more. As soon as I take the ProgCOm IC out, FAR works fine as usual. In KSP debug window, the LOG shows a "NullReference Exception" everytime I run the analysis with ProgCom IC, instead of some nice data from FAR as it happens without the IC. Therefore, I am 100% sure this IC is responsible for this issue. I tried to see if there was anything in the part.config file clearly out, but couldn't tell. I am sure you know better, so please check it. Below, if that may come useful, is the excerpt from the log that appears everytime FAR can't complete the analysis. NullReferenceException: Object reference not set to an instance of an object at ferram4.FAREditorGUI.CalculateStabilityDerivs (Single u0, Single q, Single M, Single alpha, Single beta, Single phi) [0x00000] in <filename unknown>:0 at ferram4.FAREditorGUI.StabilityDerivativeGUI (Boolean tmp) [0x00000] in <filename unknown>:0 at ferram4.FAREditorGUI.ActualGUI (Int32 windowID) [0x00000] in <filename unknown>:0 at UnityEngine.GUILayout+LayoutedWindow.DoWindow (Int32 windowID) [0x00000] in <filename unknown>:0 at UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style) [0x00000] in <filename unknown>:0

Actually, most if not all you said, I already know. You don't actually answer the question, that is about other centers of mass along a trajectory, not the source or target bodies. Orbiter and its navigation tools I used for quite a long time, so those are known as well. From what I wrote before, you may note that I put a clear distance in the way Orbiter and KSP compute SoI influence. About astrodynamics, it depends. KSP computes SoI exactly the same as the formula in that Wikipedia page (I do use that formula in my own calculations, and found already it matches with KSP); I can't say if that is different in Orbiter as I never checked the accuracy, but the results with the SoI in Orbiter are impressively realistic. Anyway, the following sentence I believe is a mismatch: If the gravitational field of the sun was really greater than Earth's at the Moon - Earth distance, Moon would escape from Earth's gravity and become another "planet" orbiting Sun. The SoI limit, as really defined in astrodynamics, is where the gravitational field is greater from the body at its center than from any other. That is the reason why no satellites exist outside of the SoI of any of the planets in reality. To give crude numbers, Earth's SoI at 925,000 Km easily includes the Moon, orbiting at a distance between 363,295 and 405,503 Km from Earth (though, more correctly, both Earth and Moon orbit around their common center of mass).

Thanks for getting and propagating this info. Useful, as always. "Spoilers are intended to reduce lift" is perfectly right, and works correctly with surfaces that can act on the craft pitch axis. Then, my issue is because KSP assigns the spoilers function to the "brake" button. What it means, "brake" with a plane? That is why I am using "spoilers" as aerobrakes, and my intent is to have them produce high drag, rather than reduce lift (placing aerobrakes on the vertical plane works just as fine, and the vertical winglets have, if any, a very tiny lift component if paired on both up and down sides of a wing, that is intended in my design). Thinking of that, maybe control surfaces should be given one further action: besides pitch/roll/yaw axis, flaps and spoilers, also aerobrakes? While looking at that tweakable, could that be a feasible and better solution?

Yep, thanks for explaining that. Very interesting as always. About SoI radius, agreed. I know they are just an assumption, if true multi-body gravitational fields computing was feasible, we would treat SoI just as an indicator of the relative gravitation force. That was the approach with the Orbiter Space Sim, at least that had 3-body computing and SoI was given with a percentage of the relative strength. With the limit of 2-body computing that KSP has, a SoI is really an artificial boundary, suddenly the gravity a craft is subject to wholly changes from one to another center of mass. But then, you mean KSPTOT, instead of using SoI to switch to a different center of gravity, is using true newtonian gravity with all the centers of mass along a trajectory?

So, I finally had to use the folder feature with the toolbar (thanks Trueborn for overpopulating it with all those nice Steamgauges buttons). It was time, you may say! Problem: the folder icon is nice in itself, though not much representing its contents. And, it is the same icon for any number of folders created. Would it be possible, if at least one button is moved within a folder, to have the icon of the first button (in the order they are put in the folder) to replace the standard icon for the folder?

Just out of curiosity, are the two facts with SoI radius related? I got some doubts () while reading the first sentence, that some issues may come from that assumption. While I am certain the correct SoI is used with the main bodies at the extremes of a transfer, eventual other bodies along the trajectory, whose SoI is intersected, would not be considered having influence. Of course that would prevent accidental slingshots to be found and computed (I believe planned slingshot are, by setting the relevant body in both the incoming and outgoing parts of the slingshot trajectory).

I have one request (no, not about less frequent updates of your mod ). Sometimes I fly and dock together very large ships, and have to transfer resources from one to the other. Let's say, perfect job for ship manifest. However, having something like 20 tanks on each ship and setting the transfer for each one is tedious work. How would be great, is there was the possibility to group parts together (automatically, of course). At the very least, tanks/batteries/lifesupport built with simmetry on; and then a group with all parts of a ship in it. Then, a single transfer command with the group would be enough.

@ toadicus: thanks for all that information about how control surfaces work. Interesting, though that just confirms there is something wrong (with the transforms?). Anyway, about your questions: - in the pictures posted above the only command given was to the spoilers ("brake"); - that ship is just an example to show what I mean, I am not trying to make it fly (it handles very bad, actually). No worry if those winglets would not provide axial control in any coherent way, they were placed just to show what happens while using spoilers. But, they actually reproduce correctly what I observed with other ships, and with those I need some control surfaces to double as spoilers; - the behaviour of the two winglets on opposite wings both turned left, to me really show the problem. The fact that both choose left because they are both forward of the center of mass "thinking they should act on their pitch axis", shows a gross misconception in the control algorithm. There was no command to act on any axis, so no torque to be generated, therefore those surfaces should not try to act on pitch. Doing do they actually generate torque, and that is exactly what I don't want to have while using spoilers; - also, the control surfaces aligned with the wings (ailerons) are all deflected to the same side (up). I put 4 of these surfaces, instead of 2, just to show that in KSP there is no method to balance the forces generated by spoilers. If there was any, the ailerons on the same wing would have deflected to opposite sides, to cancel most of the torque. And that is one of the tweaks I want to use, so to make spoilers close to each other to act on opposite sides. Just in case: all those control surfaces were placed using simmetry. But I would not care, if need be to balance spoilers, to place them one by one, so to choose which one to reverse of a "pair".

Certainly. But I must say, I always use FAR, too. Though, I don't think FAR changes anything in the way control surfaces move. Actually, my need to tweak control surfaces is tied to spaceships, rather than planes. The control surfaces behaviour is mostly similar for both, but while right/left simmetry is enough for planes, then is often not the case for spaceships: up/down simmetry is required as well. To show what I mean, please look at the winged spaceship on the pad. I have set the spoilers to max deflection (75°) to better show. All control surfaces move in the same direction, both on wings and tail. The only exception, the upside-down winglets below the wings. But, both winglets on the "up" side of the wings have turned left (on both the right and left wing). The winglets on the "down" side have turned opposite, instead (that is more in line with what I would). The issue is (far more with FAR then in stock KSP) that using spoilers that way will generate asymetric forces. So, I want to be able to choose (as KSP can't do so correctly) the direction each control surface will move as a spoiler, and so doing keep aerodynamic forces balanced

Mi sa che sia necessario un chiarimento. Sul thread principale di RT2, di tanto in tanto, trovi indicazioni circa la necessitàdi attivare le SPU (ovvero, che la non attivazione sia causa di mancata connessione). Però va anche detto che, fino alla versione precedente di RT2 (per KSP 0.22), le SPU erano parti distinte dai ProbeCore, quindi avevano proprie caratteristiche. Tra cui l'attivazione. Ora le SPU sono state integrate, per cui potrebbe anche essere che non richiedano più attivazione (dovrei provare a disattivarle apposta, io per ora ho tenuto l'impostazione che per me ha sempre funzionato, di fare in modo che siano sempre sicuramente attive prima del rilascio. Non si sa mai, se la funzionalitàa cui è stata agganciata l'attivazione della SPU sia proprio la reaction wheel). Non sarei sorpreso più di tanto se, nonostante nel box della parte ti riporti che la SPU sia attivata, in realtànon si comporti così e, non appena distante più dei 3 Km dell'antenna integrata, perda il segnale: lo riterrei un errore nella programmazione del mod, ma di errori simili se ne sono visti molti. Per me, la questione non è particolarmente rilevante: si tratta di una delle molteplici azioni preparatorie che comunque devo svolgere per mettere in funzione una sonda, quindi metterla o meno non cambia molto.

Happy to know about your progress, this is fast becoming a usable feature (and joy, everything would be run faster in TOT after compiling and parallel optimizer code are done). Actually, 24 seconds for each iteration don't seem too much, believe in reality space mission parameters took much longer to be computed.

Yes, that is exactly the proposal some of us have advanced since 0.23 came out. That would only be simulating reality, with a mod like RT2 that takes reality to its finest with KSP. However, I still can see somebody in love with the idea that, should a connection be lost, no way out should be provided. Let me wish the kraken eats all their "carefully" (??) placed relays, so they'll discover at last that in KSP the issue is not only about good planning. I have never lost a probe since I began using RemoteTech (the only ones lost were launched before I first installed RT, so they weren't fitted for it), so I could easily agree all it takes is to carefully plan your comms network. But that wouldn't be fair, nor right given that KSP is far from perfect. And neither reality is perfect in this regard: things break, and you must have some sort of backup to avoid catastrophic loss. So much, that no probe in reality would be sent to space without a preprogrammed scan mode to be activated, was the main communication link severed.

Now I have no more excuses, I have to dust off my ASM skills . Impressive work. A lot of documentation with the download. Happy to see some example programs, really needed, and references. Lots of material to read carefully. And then try in practice. EDIT: I would suggest to repack the files for ease while installing. Now the package installable files are nested in "ProgCom/GameData/Parts" and "ProgCom/GameData/Plugins"; if reversed in "GameData/ProgCom/Parts" and "GameData/ProgCom/Plugins" it would take just one step to install and have everything in order in its own subfolder (and, automatic mod installers would also work better).

Bene, sono contento che hai risolto. RT2 è uno dei mod di cui io non potrei fare a meno, ma ti costringe a pianificare accuratamente oppure ci si ritrova con delle sorprese quando ormai è tardi - proprio come per questi collegamenti con active vessel, che non può fare da relay. Per l'attivazione delle SPU, cerco di essere più chiaro perchè evidentemente non lo sono stato abbastanza. Nel VAB (e nel SPH) hai i tre tasti in alto a sinistra del nome della nave; quello centrale è per l'impostazione degli action groups, quando selezionato non puoi aggiungere o togliere parti, ma la parte selezionata viene evidenziata e le possibili azioni da associare agli action groups elencate. Io non faccio altro, con i moduli di controllo (di probe che pianifico di rilasciare) che associare l'azione "activate" ad uno degli action groups (anche non in esclusiva, l'importante è che venga attivata l'azione prima del rilascio). Talvolta, per comodità, associo anche altre azioni, tipo "control from here" se mi rendo conto che l'azione è importante nel corso della missione.

Usi altri mod, oltre a RT2? (aggiornato alla versione 1.3.3, naturalmente). Ho provato a lanciare un semplicissimo probe con lo stesso modulo (RC-L01) che si vede nella tua immagine, come vedi a me il collegamento lo da senza problemi. Ovviamente l'ho prima attivato, come pure le antenne. Nel caso servisse farlo notare, il probe dispone di accumulatore e pannelli solari, non si sa mai una mancanza di collegamento per black-out. <a href="http://imgur.com/W0Q4AYI"><img src="http://i.imgur.com/W0Q4AYI.png" title="Hosted by imgur.com" /></a> Circa l'attivazione, è una delle azioni che vanno selezionate nel VAB ed assegnate ad un action group. Altre azioni sono attivabili anche cliccando sopra la parte (tipo: toggle torque) ma in questo caso no, forse una dimenticanza. Giusto per verifica, la mancanza di collegamento si verifica subito (quando ancora la Mun Eye I è ancora prossima, entro la portata dell'antenna interna del modulo) oppure avviene successivamente? Perchè nel primo caso è un problema interno al probe (modulo, antenne, elettricità), nel secondo ai collegamenti esterni.

@ Toadicus: I would like to see a "tweakable" with aerodynamic control surfaces. Though plenty of settings from the stock KSP version, there is one feature with control surfaces I sorely miss: to choose which way they move when used as flaps or spoilers. It seems like KSP has a way to choose which way they should move, but often that goes contrary to what I would and results in asymmetrical forces being applied. Could you consider the feasibility of the above?

La prima domanda, si vede chiaramente dalla prima immagine che il satellite su cui hai impostato il collegamento con MunEye (Cyclope C ?) non ha connessione con Mission Control. Quando diventa attivo (seconda immagine), la connessione viene stabilita, evidentemente con le antenne settate per "Active Vessel" sugli altri satelliti della costellazione. Quindi gli altri satelliti (Cyclope A e Cyclope hanno antenne che li collegano, ma nessuna antenna permanentemente puntato su Cyclope C. La seconda domanda, dalle immagini non si può capire, ma la causa più frequente di mancato collegamento quando si rilascia un veicolo secondario, è che non è stato in precedenza attivato il modulo di controllo (Probecore..). Con RemoteTech2 questi moduli portano la SPU, in pratica l'unitàdi elaborazione dei segnali: quando i moduli sono spenti è come se non fosse ricevuto alcun segnale. Per comodità, io assegno sempre l'attivazione dei moduli su un action group, per poterli attivare prima del rilascio (purtroppo non so se si possa farlo con staging, sarebbe molto più comodo).

What about including a mention of the original kOS thread and his author? Being this a derivative work, even taking the same parts of the original mod and the same graphical feel of the original thread, I would strongly consider doing so. Apart from the above, congrats and thanks for your contribution in keeping kOS alive these days.

Want to share this little thing, somebody may find useful. The Kerb-I External Camera can be watched in IVA using RPM by Mihara, all it takes beyond having both mods installed is to have the following lines with a config file in gamedata (I put those with one of the example config files in RPM): // Part Kerb-I from L-tech @PART[externalcamera] { MODULE { name = JSIExternalCameraSelector cameraContainer = RCSthruster rotateCamera = -90,0,0 translateCamera = 0, 0.05, 0 cameraIDPrefix = ExtCam } }

Stupendo e spassoso . Bravissimi.

Yes, perfectly. And I really like how this tool will work.

If you're interested, I will show you the math I use to compute the longitude where to burn while in LKO to put a craft in KSO at a desired longitude; that was one improvement I already asked to see with MJ, and answers the second one of bk2w requests. PM me in case.