diomedea

Can't tell what's about your Firefox install, but to me it is working with AdBlock without issues, effectively blocking all unwanted ads. Could your issue be about the settings of AdBlock? E.g. you may not have selected any of the filters that effectively tell AdBlock what elements to stop.

The door animations use Firespitter.dll and you need an updated version compatible with KSP 1.0.x. I tried with the version of Firespitter RoverDude has updated and embedded with his add-ons (e.g. with UKS) and it works fine if copied in the Firespitter folder. Then, most of the config data need updating as well, can see nodes not attaching with those extra tube parts. With KSP 1.0 node directionality was introduced, so they only allow attachment from the correct (e.g. upwards or downwards) direction now, while previously there was no check. Could be just as simple as to reverse the 5th 1.0 to -1.0 in the node definition (seems to me all these parts have the bottom node direction reversed), but I had no time to test. EDIT: did a few tests about the node directionality, however without success yet. Even using the same directions Squad parts show in their configs. Something else to try for sure. EDIT2: talked too early and without seeing many parts had to be tweaked in the same config. The reversed -1.0 5th value for the bottom node is all that is needed. Pls find an updated working config for those extra tubes here.

Care to show what add-ons you're using? And beyond that, could you follow the steps outlined in this guide? With info like what asked above, providing help could be feasible, while now would be just a wild guess.

Marple, believe there is some inaccuracy in the way you maneuver. The ship in the docking tutorial comes with 1562 m/s of DV to start with. If you follow the tutorial, you'll be doing the following burns: - plane alignment (do at the AN, not the DN), for a cost of 335.1 m/s (29s burn duration); - raise apoapsis to intercept the target, for a cost of 285.6 m/s (23s burn duration); - zero the relative speed at the closest approach , for a cost of 226.7 m/s (19s). After zeroing relative speed, you would still have 715 m/s of DV, of course you need only RCS from there to dock. However, Wemb is right that the tutorial isn't giving the most efficient procedure. If you do the following instead (without caring for the tutorial text): - raise apoapsis to intercept target, at a cost of 280.5 m/s (25s burn duration); - plane alignment then costs much less, only 260.5 m/s (22s); - another burn to match the R/V position (or even some correction burns), that took me 91.4 m/s; - zero relative speed at closest approach, for 145.7 m/s (11s); resulting in 786 m/s of DV still available (quite close to the amount saved by making the plane alignment maneuver at a higher altitude). Can't say from what you wrote why those maneuvers cost you so much more. You may not be keeping the maneuver node centered on the navball at all times (get help from the autopilot) or you may be burning not at the node, but too early or too late. For greater efficiency, each burn has to be done starting at "Burn_duration"/2 seconds before the node. And definitely, don't overburn, when you come close to 10m/s DV left with the current burn, cut throttle and proceed only with very small adjustments. Edit: if it could come useful, few pics showing some of the maneuvers I did (and the mandatory end result= docked).

Fine, thanks for checking and showing how it will be implemented . Though I'm a bit surprised to learn determining the Sun location would be expensive, I'd have guessed it could be done with just some reuse of the functions required for computing longitude on the rotating body and right ascension of Sun. However, looking at some raw data (not yet able to conduct extensive thermal data collection on all atmospheric bodies in KSP) I have to concur about the reasonable approximation even leaving the diurnal variation factor out. Temperature diurnal excursion seems to be marked (~ 30-40°C) only at very high altitudes, where density is low enough that its change would minimally affect drag. About the old .mat files format (being not compatible with the new 1.5.0 MA), hope you may soon release newer example mission files also. As it showed even few days ago, I still find your example files very useful. Great job you're doing with the wiki .

You're right about gravity assists (both to accelerate, coming from "behind" the body orbital path, or to decelerate, arriving in front of the body). But about "optimal capture", there is no preference in KSP. Unlike space simulation programs that implement multibody gravitation, KSP uses only a two body gravitation model, so once a vessel enters the SoI of a body, there is no further influence on it from other bodies, therefore no advantage making a capture burn in relation to the position of those other bodies.. You're right instead that, should multibody be used, the side where the gravitation total effect is lower (facing the mainbody that is orbited by the body you plan to make the capture with) makes for lower orbital speed and therefore lower Oberth effect than the opposite side.

A reference frame (RF) is a system of coordinates tied to reference points (like North, Vernal, mainbody center), so the coordinates are uniquely fixed. The origin of the RF can be located with your ship, and that's the case with the navball RF, so angles are given in relation to the ship attitude. Hope that helps, as the idea of the RF as "a point on the surface of a sphere..." implies there is still confusion. About the "inertial navball", what you wish seems to be a different thing. An inertial navball would be tied to an inertial RF, that implies no acceleration of sorts. Rotating RFs are never inertial, so what you're asking is for a RF that has a fixed orientation in space. The RF used in astronomy, that is oriented by the ecliptic plane and the vernal point, is inertial, and KSP also uses a similar RF to keep the position af everything orbiting Sun. Now, your intent is to launch to a specific orbit, therefore to match specific orbital parameters. In particular, you'll want to launch at the correct inclination when the ship is aligned with the plane of the future orbit. Such a plane is univocally identified with two directions, such as the vector to the periapsis and the vector to the ascending node. Those vectors are certainly univocally described in the inertial reference frame (centered on the mainbody of the orbit), but to use them you need to see where they are. The inertial navball would provide the fixed direction in space to define those vectors coordinates (for the ascending node, you just need its longitude, as the latitude is 0 by definition; for the periapsis, it would be simpler to use a point at 90° from the ascending node longitude, so its latitude would be = inclination). By those two directions a unique circle can be drawn over the navball, and your ship position in relation to that circle would give how close it is to launch on the correct orbit. Now, on a "local" navball (like the standard one in KSP) you would observe the circle rotate in relation to your ship "fixed" position; on an inertial navball you would observe your ship location to move (with the body rotation) and the circle stay fixed. In either case, you have to meet the alignment of ship location and circle to launch, and that is trivial only when launching from KSC (almost 0° latitude, and 0° axial tilt), as you launch when aligned with the ascending node. But, when is the ascending node (AN) aligned in the case of KSC? just when the AN longitude (always sidereal) is the same as KSC longitude (sidereal). The longitude at KSC is a linear function of time: 360*(UT/21599.91201454)+(90+74.4) (the latter from the initial rotation at epoch=0 of Kerbin and the geographic longitude of KSC; hope to not have inverted the values as had no time to verify). Ok, so known the time (UT), you can compute the sidereal longitude, and when that matches the AN longitude, that's the correct time. Easier than creating an inertial RF navball and trying to use it.

Don't know if what follows is part of what you considered in the "four correction curves", but temperature sure isn't described by a single curve with altitude, it also depends on the Sun elevation (from what I learned by who worked to make the atmospheric model in KSP), therefore local time at the meridian of the location of interest, and difference among latitude of the location and Sun declination (of course Sun declination is always = 0 for Kerbin, but not for other bodies). I'm assuming you need to have the air density curve for the atmospheric flight profile, so to compute drag (and possibly lift), and sure air density is tied to both temperature and pressure. I'd guess you may include some calculations to account for temperature variance with the location on the body - and those calcs require further data I assume should be fetched from the KSP planetary info as well.

Seems the link you added to the first post, which I understand should show what add-ons you have, is not working for me. I would suggest to show them otherwise. The most effective way, though annoying, still is to make a text list (with version number for each add-on). Some users like to show the subfolders in their KSP GameData thinking that be enough, but many add-ons don't have a dedicated subfolder so they would not be recognized. As the guide I linked above makes clear, there are a number of instructions to be followed to report an issue. Those instructions allow who works in support to try at reproducing your issue, and get an idea of what the cause could be. The list of add-ons is one (very important) item, but also the reproduction steps (either from a brand new game, or with a savegame of yours that you must then provide, you make a list of each single action required to arrive at the issue you experience) and the logs (those alone are often enough to get what's happening under the hood). Finally, you should try on your own to find if the issue is reproducible in a clear environment, or with one specific add-on: please note who provides help here has to spend hours of his own (unpayed) time to find what combination of add-ons would reproduce the issue, so would be the minimum if you also did try to find following those instructions.

ummm, I don't know what you really mean, what you describe isn't clear at all. But, ummmmmmm, best you could do is to read this guide and provide the info it requires. Of course knowing what add-ons you use is the very least to figure the issue. And in case you posted here (modded section) by mistake, let us know, and go check about the unmodded installs support guide too.

Asteroids overheating is a bug known and reported in bug trackers (#4934/#4992, both hidden from public view) since 5/5/15. Didn't get developer time to fix yet. Your findings confirm what already reported (thanks ).

oh, sorry if what I put above made it confusing. Those spikes close to the start and end time visible in the graphs on the right could be seen as a mistake while the spacecraft is still close to KSC (as shows in the first, altitude graph). However those are correct when it is seen they match with the elevation angle from KSC, so that the path goes to include a hop to a probe in munar orbit and another from there back to KSC. It is a situation well known when playing with RT, but could not have been understandable otherwise. Actually, there is no need for one further graph. Transmission time delay (another well known thing in RT) is = Total Path Distance (already on the second graph) divided by speedlight. Being speedlight a constant, the graph would be exactly the same. However could be worth to add another scale (to the right of the graph?) giving delay in seconds.

With KER, I'd suggest in the KER settings to enable the Longitude of AN in the orbital display, it will change while your vessel is in prelaunch as the KSC sidereal direction. Of course we need to launch when that value matches the assigned LAN (or the reverse for a opposite inclination).

All good and nice about the elevation angle, seems working perfectly fine here, and I'm linking a pic showing it (with altitude too): And now, that lets me know what could be the cause for another possible issue: this is the network analysis after prerelease 3 (but same with prerelease 4), where the issue from SoI transition changing max Hop distance was already corrected: I'd like now to put the attention to those spikes in "Total Path Distance" and "Longest Hop Distance" @ 0.15 and 4.95 *10^4 s. By comparing against the graphical analysis charts above, those are synced with the periods the spacecraft went below the horizon (at KSC), before initial burn and after the final injection burn. With the spacecraft unable to have a direct LOS to KSC, the network analysis found another path... that involved a hop to one of the crafts orbiting Mun and from there back to KSC. This is what actually happens in RT too, and shows all too well how good this tool can be .

Eh, my bad. The MAT file is that, but I took a shortcut and instead of changing all ranges to ensure coverage up to Mun, I run the network analysis with additive model and RangeMultiplier =1 (instead of 0.5). Elevation angle fits me perfectly (is exactly the name I use actually due to my studies in artillery, and sure is a useful value as I wrote above calling it "angle-to-the horizon" to make it more clear). The actual antennae on the crafts don't orient to the target in the current RT, but their orientation is simulated when the links are computed. Indeed they act as if slaved to a target (single craft or planetary body), staying oriented with it at all times. The original author of RT (JDP) let me know there was code in the original version to implement the orientation of the craft too, so it had to be actually rotated towards the target. Your code is helpful to show when and where a problem will arise, but sure can't also look at the actual control of the antennae on crafts: if mismanaged, those will actually create more problems (like links dropped when a dish is pointed to another target). I could show pictures of how a communication infrastructure works in RT, but those would probably be even more confusing. If you like to have a look, believe the RT Player's guide is really useful to show the basics.

The updated build is amazing. Those charts really are effective! Anyway, I may have spotted one issue. It shows pretty well on the fourth chart, in the time interval 1.9 - 3.1*10^4 s. That is the time when SoI is switched from Kerbin to Mun in my MAT file. Distance shows to be computed from Mun, instead of being about the longest hop (longest hop should always be about the distance Kerbin-Mun, as the crafts orbiting them remain in proximity of the respective body). CSV works great. Other data could turn useful to play with RT, but isn't really that simple to handle. I'll talk a bit below of something about RT, but have not clear currently what could be made in the CSV to help players there. I've till now focussed on link distance, which is a very well defined limit in RT. But certainly one problem is how to ensure time-above-horizon with communication satellites. The easy and most used answer is to use a stationary orbit (1:1 period with the orbited body), but highly elliptic orbits are also used (like 2:1 Molniya orbit) (thence the time-above-horizon). Or, quite easily, use a constellation of satellites on a same orbit. I have sometimes dealt with computing the angle to the horizon (at KSC) for specific orbiting crafts, as a value to be met for establishing links. A more serious problem players face is with programming the use of dish antennae with each craft: dishes point at other crafts or at planets, and have a limited visibility cone. If too close, the cone would be too thin to cover a whole planet, or the orbits around a planet followed by other crafts to be linked with. So, if beyond the maximum distance is a limit for the hop, being too close would make for only intermittent coverage (unless the dish can be kept pointed at all times at just one craft, instead of using its cone to cover the area around a planet). The bane of RT players is generally with probes that can't be controlled once without a path towards a control station (like KSC), so antennae on them cannot be redirected to reestablish a link towards another node if the one they were pointed at "disappeared" (eclipsed, destroyed, out of EC). Also, each craft can have multiple antennae, each one generally programmed to cover one specific link. Clearly crafts built to act as communication relays have to keep those dish antennae correctly oriented at all times. Now, each antenna has different maximum range and cone, so an improvement would be to model all those antennae. But this may prove excessive, adding a check about the cone coverage of each antenna would probably take too long to compute to be useful. Indeed, I may have to think more about what could turn useful in the CSV. What's above may hint at something but could be too much work.

Thanks for that . Yes, I see and like the improvements. Color isn't really needed, though I was thinking to have it match the 3-D views or analysis charts with those crafts. It's actually very simple (as I used the default Munar mission file and only added a bit with communication crafts/equipment), so simple I didn't think to save it and had to create a similar one to share (here).

Everything in these latest posts shows to me the lift component is not yet correctly accounted (or not at all). Since KSP 1.0 every part has a "bodylift" component. And, wings and control surfaces still have a very peculiar lift in KSP. As should be widely known, lift is a force acting perpendicular to the air flow, Lift = 0.5*ÃÂ*v^2*A* Cl (where ÃÂ= air density; v= speed of the airflow; A= area of the surface exposed to the flow; Cl is the lift coefficient that is mainly function of the Angle of Attack (AoA) for a specific airfoil). Parts where drag remains the dominant force (short cilindrical objects, spheres) will retain a reentry profile defined mainly by drag. But any craft with wings or a longbody (in the air flow direction) will show a marked lift component, that will seriously change the trajectory. Keeping the Angle of Attack =0 along the whole reentry, so to cancel lift, would allow prediction to match what expected (though, keeping AoA =0 is the worst reentry profile for thermal stress). As lift dramatically changes in intensity with AoA (and, its vector can rotate around the air flow direction at will), its cumulated effect during reentry can bring the craft in any point within an elliptic area, its center being the predicted point when only drag is considered. This ability to use vectored lift to modify the reentry path is widely used however. Yes, KSP 1.0.3 changed some of the physics constants that affect drag and lift as they were known in 1.0.2. While those changes have certainly reduced drag somehow, the same would make lift a greater influence compared to drag. To me, that's why "it's gotten worst with 1.0.3", but hope to have made clear where the wrong is. Trajectories can't account for something like AoA during reentry, that is a wild unknown with potential huge effects. If the tool could make a valid guess at the AoA kept during reentry, then lift could be computed.

Computing the network path is very time consuming currently, even a modest scenario with a few nodes takes several minutes. The one below (based on a simple Kerbin-Mun-Kerbin flight), made with 4 crafts (network nodes) beyond the current spacecraft and KSC, required about 450s to be output on my machine (that is not precisely slow, quad-core i7 @3.4GHz, 64bit). However I accept this feature requires time, and I am pleased of the result: I am certainly not (yet) an expert using the graphical analysis tools with KSPTOT. Anyway, the different graphs are quite telling. Few things however I would like to suggest: 1) the first graph is only about existence or not of a valid path (boolean answer). In itself is difficult to read (vertical bars show transitions, but nothing tells the state between those). This graph is not really needed however while the state is readable from the third graph (number of hops). 2) the second graph (Total Path Distance) has the bottom at a negative distance (something that always makes me wander about fractal dimensions in hyperspace)... makes easy to read when the distance is zero, but actually zero distance is lack of a valid path. Indeed to me, the 4th graph (Largest Hop Distance) has that right. 3) the third graph (Number of Hops) shows -1 for when no valid path exists. To me, negative hops is even more subtle than negative distance. I would consider the graph to start at 0 (just let the negative part go outside the chart). Another thing I would like to see, is some color-coding on the charts showing what nodes are active with a path. However, I'm out of ideas now. A rough thing could be to make a chart with all the possible nodes on the y axis, and showing colored horizontal lines in time when those nodes take part with any hop. But, I'd also like to have the actual hops shown (kind of vertical lines connecting the two nodes in each active hop). I'd actually have this kind of chart instead of the first graph shown. All in all, very pleased to see this functionality. It works nicely, allows to enter and correctly use info about the range model. Another great improvement .

Showing the whole output_log.txt (as suggested here) instead of just a snippet of a log would certainly let us understand better what happens, and probably would also give away what are the add-ons you use. As is, you asked for help on this section (for modded installs) but let us no hint about what add-ons you have. Anyway, following all those troubleshooting steps from that thread I linked may already put you on the right track to solve the issue. In case not, provide a report as suggested there.

Wasn't old enough and wasn't closed. And sure no need to have two. Merged in.

Exactly .

Agreed, no need for two threads about the same subject. Closed. Please keep the discussion going (politely) with the first thread opened.

The model used in RT depends on the "RangeModelType" setting, in the RemoteTech_Settings.cfg (of course within the RT folder). It can be set to "standard" (the default one), "additive" or "root" (both for the root model). So, it is up to the user to select the model he likes. Also, the "RangeMultiplier" setting is used in conjunction with the above (=1 by default, should be changed to = 0.5 when using the root model).

Sure, RT shows valid link only when distance is less than the maximum allowed. As shown above, RT uses two alternative models to compute maximum range for a link, in both cases both antennae are considered. Those equations are also shown in the RT page (the function are simply the minimum of the two values for antennae ranges, and the square root of the product of the same), and here I'm not talking about the distance between both vehicles (the current range) but the maximum link range, as the link in RT is only valid when the current range is less than the maximum. Great .