diomedea

Assolutamente no, non è mai capitato (durante tutti i test svolti con le versioni precedenti il rilascio della 0.24; e dato che le parti da sottoporre a test sono praticamente sempre le stesse ogni volta che si inizia una carriera, sia il paracadute Mk-16 che il booster RT-10 li ho testati molte, molte volte, come pure tutti gli altri che hanno partecipato ai test). Per realizzare il successo in un contratto, tutte le condizioni richieste devono essere verificate contemporaneamente, e mentre sono verificate, occorre eseguire l'azione richiesta per il test (se ne è prevista una). Alcune parti si attivano facendo stage, per altre c'è una voce "run test" nel menu che si apre cliccando sulla parte col tasto destro mentre si è in "volo". La voce in blu ([+] Note ecc.) sopra alle condizioni di ogni contratto indica l'azione precisa da svolgere. Forse occorre fare attenzione circa i contratti presentati durante il volo, la "app" ha il brutto vizio (che purtroppo non hanno sistemato) di "scrollare" i contratti, e magari ti fa vedere quello del paracadute mentre vorresti vedere quello del booster (così quando fai stage, se non riesci a vedere il titolo del contratto, attivi la parte sbagliata...). Ma la "app" può essere allargata tirando la barra inferiore, così dovresti riuscire a vedere aperti diversi contratti contemporaneamente (forse non tutti, se fai come me e ne hai 15 accettati nello stesso momento). Ma dovrebbe aiutare. Se invece sei certo che si trattasse della parte corretta, è un bel mistero... allora sarebbe il caso di riportarlo come bug, devi avere una versione pulita (senza mod installate), possibilmente fare un video del "fattaccio" mentre accade, e fornire persistent.sfs e output_log.txt presi subito dopo; ed ovviamente il tipo di KSP che hai installato (Win32, Win64, Mac, Linux). Se riesci a prenderli, fammi sapere e ti fornisco ulteriori informazioni per la segnalazione.

Great work as always, with the 1.4.0.12 PR version . My issue is solved.

Blizzy, now that 1.7.4 is out, if I open a KSP 0.23.5 install with Toolbar 1.7.3 I get the "warning" that a new version is available. Of course 1.7.4 is meant to be installed on 0.24, not on 0.23.5 - and quite probably would even tell to be incompatible because of the version checker if I did so. So, I guess the correct behaviour would be to filter those "new version warnings" to only those compatible with the KSP.exe running. (in case anybody wants to know, I keep using 0.23.5 until all the essential mods needed for my career game are proved working with 0.24. And maybe longer).

Now, do you want Squad to bring away the fun from some modders? I would use Kalculator by agises, great for this and other purposes .

Have to confirm (with KSP MA 1.4PR11), it recognizes all 32bit windows versions, but no way to have it handle the 0.24 64bit one. Hope the "Any OS" version will.

Was certainly time. Welcome to the forum .

Site seems to be working nicely with Chrome .

Excellent job, Ezriilc and Moustachauve. Is great to have the Ribbon Generator back, and probably this also opens the way to further functionalities.

Text with the stock game is not accessible (would require decompilation, forbidden by the EULA) and even it it was, changing that would require manipulation of some KSP files (and redistribution of those files, manipulated or not, is again forbidden). The possibility of localisation of the game is however quite interesting for many nationalities where english is not the first language. Squad may make that possible, so that volunteers may do the translation themselves. But certainly anything of that kind won't come before the features of the game are completed, and that is better also because with each new version, the game includes new text.

And I'm glad you are still around and thinking improvements .

If it takes a few seconds to get data from KSP, is the same behaviour I have; I consider that normal.

Thanks for your answer. Yes, seems two of us had the same idea at the same time (I took longer to write about it... ). Indeed KAS does something similar, and wasn't because those cables are attached to winches (that I don't always see as required) and the fact I can't set cables already attached in VAB, I could just use those. Still think such struts would be a great addition with IR, but probably also as a general part usable with other mods .

I used all missions from the Stock pack (Stock.mpkg) and a few from randomMissions.mpkg with a brand new career game with KSP 0.23.5. They work great in career, you just have to follow a logical path to progress as money may become a factor. RandomMissions lets you get some easy money whenever you may need, because of repeatability. I had no need to change the TechTree in any way.

I have to ask if would be possible to implement a new feature (at least, I could not find it already covered, though I may have lost something from the OP). To start, I am using both IR and the Model Rework, the feature I am about is to be used together with both those excellent addons. Struts in KSP have a length defined by the distance of the two points they are attached to. Once the two points are given, the distance is fixed and the strut keeps it (stock struts, KAS, IR Model Rework all do the same). However, I would like to use "extensible" struts, that could allow the distance to change. Not actively (other parts with IR and the Model Rework provide the needed movements) but rather keeping connected the two points af attachment while these points have a relative movement because of other parts moving. The user should be able to select if the strut is "blocked" (as by default, keeping a fixed distance) or "flexible" (allows distance to increase or decrease, within some limits that may become tweakables). Parts that actually can change a distance actively (like pistons or extendatrons) are not allowing the distance to change while other parts move, what these "extensible struts" should do. There are structures in real life that actually have similar characteristics. Extensible bars, cables with tightening systems (of course cables only keep a maximum distance, not a minimum between the attach points). Unlike (for what I can see) what this mod already provides, these "struts" would neither be removed nor created, the attach points remain the ones defined at build time. But the flexibility they provide could be perfect to complement other moving parts.

As the original license allows, here is uploaded the mod as downloaded originally from Spaceport: Modulefixer.

Hope my knowledge on this is still current... The settings for RemoteTech (held in /GameData/RemoteTech2/RemoteTech_settings.cfg) include a line "RangeModelType = ", by default it is set to "Standard" and means the antenna with the lowest range dictates the range of the connection. So, with a KR-7 and a KR-14, the range is dictated by the KR-7 (90 Mm). However, RemoteTech also allows to use the "Additive" model (just change that line to "Additive" where "Standard" was), then the range of connection is given by SQRT(RANT1*RANT2)+MIN(RANT1|RANT2) (where RANT1 and RANT2 are the ranges of the two antennae, MIN is the minimum of the two), or in this case (KR-7 and KR-14) = 2,414 Gm. I consider the Additive model much more realistic (as the range is a function of the gains of both receiving and transmitting antennae), though being much simpler that the true to life equation. Also, at the time the Additive model was introduced (RT2 v. 1.3.3), there was also something about a change in the settings line "RangeMultiplier = " to read "= 10" instead of "= 1". I can't remember what that change was about, but it has the effect of multiplying all ranges of all antennae (something I don't need, so I keep that to 1). You don't have to worry about different SoI unless an antenna is pointed at a body instead of the other antenna (or you use the Active Vessel feature).

Yes, interesting. The state log with Mission Architect indeed provides orbital parameters for every part; it just requires to define a sufficiently long coast maneuver with the initial orbit and see where it brings. About adding bodies, could you tell if adding to the bodies.ini with "arg = LPE" (LPE from persistent.sfs) works? I noticed those two values often match (though, argument and longitude of periapsis are different, so that may mean KSP abbreviation is uncorrect if the value used is actually the argument). Also, when importing data via KSPTOT Connect, you get updated mean anomaly and epoch, and those are certainly different from the ones shown in a savegame, however those just define a different position at a different time along the same orbit. So, I don't expect mean anomaly and epoch to be mistaken, and probably the error is really about the LPE. EDIT: Found it (so I believe). KSP seems to be using values for MNA in radians, not in degrees. All other angular values are given in degrees, why this one is diifferent? Anyway, convert that value from radians in degrees (multiply by 57.2957795) before inputting in bodies.ini as "mean = ".

All staging is done well before making precise orbit for me. But in case, turn your vessel normal/antinormal before staging: you'll have a very small change in inclination, but with no prograde/retrograde component in Delta-V you will not change periapsis/apoapsis.

Now time to land like real pilots do !

My thought, exactly .

Excellent question! KSPTOT computes trajectories with planetary bodies in its "bodies.ini" file, and of course it includes by default the standard planets and moons in KSP (with an option now to make a new file from what bodies are defined in KSP at runtime). Asteroids are not among those bodies, so to compute trajectories with them, their orbital parameters must be inserted (by hand) in the bodies.ini file. Orbital parameters for any "vessel" (including asteroids) are found in all savegames, within the "ORBIT { ...}" section; the parameters shown are: SMA (semi-Major Axis of the orbit), in meters ECC (Eccentricity of the orbit) INC (Inclination of the orbit), in degrees LPE (Longitude of Periapsis), in degrees LAN (Longitude of Ascending Node), in degrees MNA (Mean Anomaly), in degrees EPH (Epoch), Time in seconds (UT) when the above parameters were given (Mean Anomaly changes with time) REF (Reference Body) is the numerical identifier of the parent body the asteroid is orbiting (0 = Sun; 1 = Kerbin...). With the bodies.ini used by KSPTOT, some changes are required to fit those parameters. First, create a new section (or copy another one) within bodies.ini, and change the name of the body to fit our asteroid (e.g. "[Ast_XXX]", beware KSPTOT does not accept spaces); then modify the following lines with the parameters from the savegame: EPH must be copied to "epoch = " SMA must be converted in Km and then copied to "sma = " ECC must be copied to "ecc = " INC must bo copied to "inc = " LAN must be copied to "raan = " (Right Ascension of the Ascending Node, is the same as the LAN when referenced to a geocentric orbit) LAN must be subtracted from LPE, the result (always within 360°) be copied in "arg = " (Argument of Periapsis) MNA must be copied to "mean = " REF must be copied to "parentID = " Also, the name of the parent body (initially, Sun), must be copied in "parent = " the name of the asteroid to be copied with "name = " and a new ID to be created, unique for the planetary system, and copied in "id = " (note: currently Eeloo is the standard body with the highest ID = 16, so any asteroid must have ID > 16) Following fields in bodies.ini are not really relevant with asteroids: "gm = " is the gravitational parameter (practically = 0 for asteroids); "radius = " the radius in Km of the body (any suitable value here, as the size of the asteroid is not defined initially in KSP) "atmoHgt = " the atmospheric Height, = 0 for asteroids "rotperiod = " the rotation period in seconds, any big value here (initially undefined in KSP) "rotini = " the initial rotation angle has no purpose: = 0 "bodycolor = " is used to draw the body and orbit in KSPTOT, "= gray" is generally a good choice "canBeCentral" to be = 0 "canBeArriveDepart" to be = 1 Hope to not have put anything wrong...

I strongly support the use of options, every players likes things differently (and, unfortunately, some even moan if they don't have things implemented their way). Really like this attention you have . BTW, that orbit intersect launch time feature...Excellent! (I would never have found about it wasn't for JWag post).

Can confirm both fixes work on my end. Good job ! Just a minor note, now that asteroids can't be selected anymore, I find with the MCC RTS "Select Vessel" dialog this "Warning: Selecting asteroids may cause issues when using the RTS". Certainly a temporary solution, but now no more required. In the hope that all major bugs are now sorted so you may have time and will to go about minor things again, I'd like to bring attention back on those two I mentioned few days ago (sorry for the self-reference ), possibly lost in the clamor: