diomedea

I should have brought feedback before, therefore sorry (but, your new version may deserve some more use time before a report ). Anyway, one thing I would like to see with the UI, is the ability to select different skins in the windows (e.g. Unity, Gameskin, KSP window #, default, etc..). Other mods have that ability (MechJeb, VOID to name a few) and it allows the user for a much better UI of his choice.

There is something right in both the posts quoted above. Hope not to fuel disagreement, but rather to help put things correctly (I worked IRL on radio/radar systems, so believe to know something here). AdmiralTigerclaw is correct trasmission and reception are two different functions. When both functions are to be performed at the same time, you can't use the same antenna. Radio systems IRL are classified into Transmitters (TX), Receivers (RX) and Receiver-Transmitters (RTX). Most of the high power systems use totally independent channels (TX + RX), unless your system is designed to transmit only in time bursts, and to receive between bursts. Same for radar systems. But, most used and popular radio sets are RTX. They certainly always use the same antenna for both functions. In radar technology, a couple of internal devices (the TR and ATR switches) protect the receiver when the transmitter is "On Air", and avoid losses of the received radio energy closing the way to the trasmitter. With older RTX radio sets, users had to wait for the frequency to be free before transmitting, or they would not receive anything in the meantime. More modern radio sets (professional ones) use time bursts, so their trasmission cycle is very short and may not be noticed from the user. They receive bursts from other RTX devices, decompress them and the user experiences an almost continuous signal on the receiving end. Some radio networks even sync the timings for each transmitter to send its data (Roll-Call mode) so to ensure no data are lost in a transmission cycle for any of the radio systems in the network (while the normal broadcast mode could leave two or more radio sets transmitting at the same time).

Hey, welcome back home (this thread). Lovely you're enjoying your vacation . Actually, the current version does not seem to me so broken. Just that it is hard-dependent on other plugins.

First off, RT2 is a mandatory mod in all my career games. Being career games, it requires to climb the tech tree to unlock some essential parts so to build my network properly. Early communication is handled with probes I consider temporary, to be replaced as soon as proper communication relay satellites are buildable. My typical "proper" communication relay satellite is what I place in KSO, each of them with one Communotron 32 Omni, two DTS-M1, two Communotron 88-88, one GFX-128 dish. The minimum configuration I use is three such satellites at 120° angles in KSO, and ideally covering longitudes 60°, 180°, 300° more than KSC, or 014°W, 106°E, 134°W. The Comm 32's provide continuous and redundant coverage for all crafts on Kerbin (poles excluded) and orbiting up to altitudes of 5100 Km; the DTS-M1's are pointed at Mun and Minmus; one Comm 88-88 is used to keep contact with another of the relays; the other 88-88 and the GFX-128 used to follow deep space vessels or for interplanetary coverage. As soon as needed I put another similar relay in KSO and tweak orbits to make a square configuration (that way, distances among the relays are just below the range of the Comm 32, and they don't need any dish to link them). The DTS-M1's are then paired between opposite satellites, so two DTS-M1 (from opposite satellites) are pointed at Mun, and two at Minmus. That leaves a total of 4 DTS-M1, 8 Comm 88-88 and 4 GFX-128 available, to be used in pairs (again, coupled from opposite satellites) for each deep space craft or planet I need to connect to (total 8 such connections available). Poles on Kerbin are covered by other probes with just a single Comm 32 in a high-inclined orbit, their primary mission of a different nature (e.g. SCANsat or Kethane scanning). When I start making interplanetary missions, I send probes with communications capability early on, at least two to orbit each body (often on the same orbit, their anomalies at 180° distance, inclination at 90° from the ecliptic). These satellites must have one long-range dish (to connect back to Kerbin), one Comm 32, one DTS-M1 for each moon to be covered. What parts require management? Assigning dishes (in couples from different relays) to cover each specific craft moving between planets or in deep space.

Without having a look at a detailed picture, or the craft file of your lifters, this is an exercise at guessing what you may be missing. Sure there are circumstances where Delta-V alone isn't showing the true performance of a vessel. Quite easy to point the case when you know the vacuum Delta-V, but the true Delta-V you have is curtailed by the vessel flying in atmosphere. A slow ascent, then requiring longer to leave the atmospehre, would certainly impact on Delta-V more than a fast one. Then, a slow ascent also means more gravity losses. So, if the ascent stages have a lower TWR, your craft is going to lose more of its initial Delta-V than if those stages have higher TWR. High TWR (or, better, acceleration) is also required to properly perform some orbital maneuvers. Like ejection or injection burns. Some engines have very high ISP but conversely very low thrust, and they take a long time to provide the Delta-V required in those burns. But to be effective, such burns are to be performed close to periapsis, in a limited amount of time. If it takes too long, some of the energy gain from burning at periapsis (read: Oberth effect) are lost.

From how the opening post has been edited, I get the intention is to have this thread closed for good. So be it (if not, PM me or others in the moderation team).

Probabilmente mi sto ficcando da solo in un mare di guai. Comunque, vorrei provare se possa servire nella nostra comunitànazionale un thread in cui concentrare domande in generale e le relative risposte. Per quanto possibile, se vorrete avanzare domande cercherò di documentarmi e trovare le risposte necessarie (usando anche i superiori poteri da moderatore, se servono). Non sempre le risposte potranno essere rapide, specie se dovrò coinvolgere altri nella ricerca. Ovviamente, molto gradite anche le risposte che altri potrebbero fornire nell'ambito della comunità. Premetto che se alcuni argomenti sono vietati (tipo: a quando l'uscita della prossima versione di KSP?), potrò solo rispondere vagamente o elusivamente. Non me ne vogliate in caso, fa parte delle regole. Bene, allora fatevi sotto, cos'é che avreste sempre voluto sapere?

Not a moron at all. Such things happen (more so if you don't have as much time as me to spend playing KSP), and I'm happy to have been of help . Let us all know when you have your own CactEye telescope in orbit and working.

Just a very minor thing, but believe you may find useful: with the 1.7.3 version, Toolbar.dll still shows version 1.7.2.0 from the file properties.

Must say I am not an expert, but the above left me wondering why then all KSP plugins can work if compiled against a .NET Framework 3.5. So made a bit of research to find that: - Unity does not use (directly) .NET Framework, but Mono. Mono is compliant with .NET Framework, in particular: . Mono 2.0 is in par with .NET 2.0 . Mono 2.8 is in par with .NET 4.0 - The above leaves doubts about what specific version of Mono Unity is based on. Found here that Unity 4.3.3. (version used by KSP 0.23.5) uses a custom version of Mono (2.6.5.) mainly compliant with .NET 3.5 Hope the above may be of help. Can't say if all the functions you need are covered by Mono 2.6.5, but in case those were, you should be fine compiling for .NET 3.5; otherwise, you are right to use .NET 2.0

jamqdlaty, from your previous post I can't see HullCamVDS listed. But, I understand you actually had read that was a required mod for CactEye to work (same as Toolbar and KAS, both listed). Can you confirm you also have HullCam installed and working? If you have it but still have problems, can you confirm you are still having a freeze while loading KSP? A freeze is most probably due to an incompatibility among .dlls The CactEye version 0.1 actually worked with HullCam version 0.2.9.5 (and before); the new CactEyeTelescope.dll that AlbertVDS provided is needed to make it work with the newer HullCam version 0.3

Hi, welcome aboard! Sure the full version of KSP has a lot more features than the demo, but I'm sure you'll get used to them in no time. And find KSP all the more interesting while doing so. About that tutorial, you may have noted the last version of it is for version 0.22 of KSP. It includes a .dll (a plugin) to work, and many plugins from previous versions don't work with the current version of KSP (0.23.5). If you are really interested in that, you may ask the author about an update (blizzy is very good, and always helpful).

Yes (exactly where you can find the original .dll)

Fine. Different settings in the options menu are definitely good to solve such issues. Certainly not the case then to make an automatic "shifter" so to find solutions somewhere else than the ranges allowed in the options. Probably helpful if, when the plot collapses (axes reset to [0,1]), text may be shown over it suggesting the user to increase the settings. Anyway, your suggestion about the number of synodic periods proved useful to make evident another possible improvement. As it is now, the porkchop plot for direct transfers has the arrival time on the y-axis (the multi-flyby porkchop plot instead has time of flight). Using arrival time, half the area (lower-right) of the plot is blank, because arrival can't be less than departure time. Most evident when more than 1 synodic period is shown. My guess is both arrival and flight time could be useful when plotted, and could be switched via another setting in the options.

Actually I could do with KSPTOT as it is now, when I notice that issue shown by Kobymaru, I just tweak the bounds until the plot is centered on a local minimum. But other users may want to see that solved. That plot by Kobymaru is clearly not showing correctly, returning the data from the point at (0,0) because it is where Delta-V is less than any other point in the vicinity. My guess is that KSPTOT can't look for data beyond that point because of the set bound, otherwise would find points requiring less Delta-V. To be a local minimum, a value would be less than what returned by the same function with any other point near the one that originated that value. But when bounded, other points close to that one can't be considered, the derivative of the function in that point is not null (and that may be used to test if we have the issue). But thankfully, when dealing with direct planetary transfers, we know solutions are distant (more or less) one synodic period from each other. So, my suggestion would be to test for local minima (derivative function) in case a bound is reached while searching a solution; if the derivative value is too high, it means KSPTOT is stuck against a bound and should instead try a different point, starting one synodic period beyond the date for the last point considered. Of course, KSPTOT must know to look only for a local minimum solution, instead of searching for the unique best solution (given the eccentricity of Eeloo's orbit, I bet the absolute best is when encounter happens at Eeloo's periastron). Also, I have no idea how actually the size of the date and flight time axis is computed. My guess is normally KSPTOT starts with one synodic period beyond the start date (on the date axis) and at least a duration equal to what required for a Hohmann transfer. And then it changes the size so to have the solution displayed clearly. But when that issue presents, KSPTOT shrinks both axis to 1.0 (days?). Then, size of the axis could be another criterium to detect that issue.

Tested KSPTOT v.1.1.2, for me the issue with MFMS departure dates is solved. Brilliant! I'd like to deal a bit on that. First issue, I know KSPTOT shows Earth Years/days; not (yet) Kerbin ones (Hope a day will come for a setting to switch among the two systems). Of course UT is used internally, and for transfer of time with KSPTOTConnect, so KSPTOT will always use the correct data. Second issue, that is a behaviour I observed as well a number of times with KSPTOT. I want to show a few porkchop plots of that K-Ee transfer shifted in time: Those show 3 solutions for transfer at one synodic period (about 113 Earth days) difference each other. Please note that the optimal departure date (minimum Delta-V) is with the first of the above plots, BEFORE the initial date in Kobymaru's plot. I guess KSPTOT is giving the correct solution when finds a minimum (in Total Delta-V) within the plotted area, but gets confused when the correct solution is outside the allowed bounds. In that case, the minimum shown on Kobymaru's plot is on a slope. It is not a correct solution (and could be filtered out if a check for gradient was implemented) and indeed the Delta-V shown is way too high. The plot axis lenghts degenerate to 1.0 as the correct times are outside of it. So, when I see a similar issue, I change dates in the entry boxes until I put a local minimum within the plot area. With the plots shown above, I first went backwards in time as that was the direction KSPTOT was leaning towards in its search. But if limited by a bound, KSPTOT should actually try to find a valid solution in the other direction (with greater departure dates). The third of the plots above shows one such valid solution is found 92 days after the earliest departure date set in Kobymaru's plot, and I suppose it would have been automatically found and plotted if KSPTOT wasn't instead trying to find the best possible solution (occurring in the past).

Look, you keep using the wrong terms. Lift means to just be able to get higher, but without any knowledge about the performance. TWR gives that. What you mean is what I wrote. You say "they do not contribute to the TWR of the stage". Instead, anything that has mass or thrust conributes to TWR, what you mean is those stages are to be seen as neutral, having the same TWR of the core stage so the total TWR does not change.

I am often amazed at how spectacularly realistic some effects are in KSP (when properly modded). That rocket is very long and has a significant lift in the aft (also because of those winglets), once it takes a significant angle of attack. Too much lift if the speed is high (a TWR of 1.95 certainly gives that high speed early), enough to exceed the structural resistance of the joint that is seen breaking. You should avoid taking any significant angle of attack until at high altitude; that means, fine if you use a proper gravity turn but you can't force the rocket to steer too much. Or, wait until you have at least 20 Km altitude to reduce atmospheric density and therefore generated lift. But probably you don't really need those winglets.

OK, what you mean is each radial stage has enough thrust to provide the required TWR at launch, instead of "to lift itself".

Could be I am missing something? When you say each radial stage should be just able to lift itself, it shows you want to launch from a body surface; in such a case, those radial stages will have TWR = 1.00; then if I get right your Core also has a desired acceleration of 1G, means the whole ship has the same TWR = 1.00; really too low, it will start moving only after having consumed some fuel. Good TWR for a launch are in the range 1.5 - 2.0, so your aim should be to have radial stages able to give that much. Now, each body requires a different ratio boosters/payload, because of gravity and atmosphere density: let me say it takes a ratio of 4 in case (close enough to what required for a launch in LKO). If each of the radial stages had a own TWR of 2.0, the total TWR of the ship would then be: (boosterTWR * ratio + CoreTWR)/(ratio+1) = (2.0 * 4 + 1.0)/5 = 1.8, certainly fitting. If instead you are designing asparagus staging for a ship already in orbit, you can't really tell about lift capability of the radial stages, but their acceleration. In that case, a same acceleration of 1G for each stage would certainly do.

Look at your data on the left of the post, just below your nick. You may later change it, or it will automatically change with more posts. Anyway, "Curious George" is a category for users new to the forum, helps keeping the forum free from bots.

Users that belong to the "Curious George" group can't yet change avatar. Trusted users can: open your user Settings (Top line of page, second to the right); find the "My Settings" panel to the left of the Settings page, under "My Profile" click on "Edit Avatar"; link or upload an image within the limits (64x64 pixels...)

I have a small issue with MFMS, using KSP TOT 1.1.0 but still present with 1.1.1. Can't tell for sure if has to be considered a bug (or another of my mistakes using this tool). If the launch window is set to open later than Year 1, Day 1, solutions are found with departure beyond the Launch Window Close date. Example here: Launch Window Close set at Year 4, Day 1 (UT=94608000); departure date from Kerbin Year 4, Day 233 (UT=114693128.714). Arrowstar: I noticed this while trying to force MFMS to replicate the 7 body solution you showed on another thread (could not get that, and when imposing stricter limit to match your solution found this issue).

Let me say, don't get discouraged by the steep learning curve with this tool. It takes more time than most other things to acquaint with, because of how complex it is; but once done, the satisfaction you get is much higher. I can hardly think of anything more complex to deal with in the KSP universe, and still so much realistic. (Note: was the tutorial you followed about the Kerbin-Laythe transfer? Did that but didn't encounter Vall; instead arrived in the Jool system with a pretty high inclination, so to make any possible encounter with other moons very difficult. Did date/time and Delta-V components with the initial orbit match with the ones in the tutorial?)

@ Arrowstar: yes, MFMS does find one best solution (as DV minimum) in the range of dates/Flight Times allowed (never tried MFMS with more than 5 bodies before, excellent). Actually, the K-E-K-E-K-J-Eeloo was just one example of a more complex trip that a multi-orbit searcher could consider. Those different trips are useful to check in case they provide feasible solutions at different dates than the direct transfer window does. Manually finding solutions for all possible multiple-bodies combinations and all possible dates of interest is part of the problem, where a multi-orbit searcher may come to help if feasible. Those solutions you showed are very interesting to demonstrate how good MFMS actually is, but then I have to see if those solutions may come useful instead of using a direct transfer. In this case (sorry but didn't use Flyby finder, as it can't provide solutions for direct transfers) I used KSP TOT to find a very good solution for direct K-Eeloo transfer (not shown, but arrival DV = 1,81 0Km/s, for a total DV of 3,88 Km/s, and Total Flight time of 469 Earth days): Compared with your first solution, the direct transfer uses less DV and much less time; with the second solution, about 880 m/s more DV but still much less time. The K-E-K-E-K-J-Eeloo was just one example of more complex trips, but in these cases they don't fit my requirements: I would still prefer to use the direct transfer instead (of course, such solutions may still be of interest to find other dates for departures than the windows for direct transfers). What would really be useful (but, I reckon horribly complex) would be a tool able to automatically find those different trips , but show only the ones really useful. I am certainly going to use MFMS to find some of those, though it takes time and I may miss some (as, I must actually state what waypoints to consider, while a multiple-orbit searcher should try all the feasible ones automatically). That is where another tool, showing how different trips compare in Flight Time and DV expended over a wide range of dates, would come useful if it was possible (a very serious problem for what I could see, could be possible but very complex). Was this quest limited to find the single best solution with a specific trip, MFMS is certainly the tool to use. Checking how different trips compare over a wide range of dates, it would require to plot the minimum DV and Flight Time with any trip - a problem you teached me is very difficult to solve.