diomedea

Daishi, your models are always great! I really like the work done to bring TAC compatibility, looking forward to be able to use the complete pack. Will have to redesign ships to use US instead of standard TAC parts, sure afterwards they will look a lot better. Is already some info available about the amount of TAC resources with any of the new wedges? Though a number of posts were exchanged about that, I seem to be missing this basic info, and can't find that even with the US site. TAC parts come in 3 sizes, that makes them pretty easy to use to get a specific amount of any resource. Up to now, I can only figure each US wedge has a specific capacity, so there is no option in case only a fraction of that capacity was needed. Are there any plans for US parts of smaller size, mass and capacity (specifically with TAC resources)?

I would have been surprised if this mod still worked, after months of not getting updates while KSP progressed a few versions. After all, it is still rated to work with KSP 0.21, and a lot of new data was added with the later versions. Unfortunately, I can't find any license with this tool (must have escaped our checks), so it must be assumed the author kept all rights, nobody but him can create/publish any updated versions out of it.

I am seeing discussion turrning a bit too harsh at times... time to remind respect for everybody even while your opinion is different?

I would bet you entered in orbit around Mun at an angle (above or below the equatorial plane) so resulting in an inclined Munar orbit. Leaving a highly inclined Munar orbit, you may never have a viable solution for a return trajectory just burning prograde, you also need to correct inclination.

Absolutely correct. Certainly in real life, spacecrafts also need to make corrections because of effects not depicted in KSP (perturbations to the orbit due to the oblateness of Earth, gravitation from other bodies, Earth's gravitational field differences, solar wind, magnetic fields, and drag still present beyond any fixed altitude limit). But one of the main reason for corrections, is the practical impossibility to achieve absolute precision in measuring orbital elements, and then in applying the needed corrections. The longer a spacecraft remains in orbit, the more little errors and perturbations will accumulate, to end with a difference comparable to the maximum allowed, and such to require a correction to minimize errors again. I would actually like to see a mod with KSP able to automatically apply corrections, and certainly MechJeb has all the stuff for that. Don't know if this idea was already suggested. But, could we have an autopilot able to memorize orbital parameters when activated, and when one such parameter is found beyond a set limit, creates and executes a maneuver to bring it back to the original value?

Indeed, better keep this topic going with the previous threads. Closed.

Excellent. Very happy to find you are keeping this mod current, I certainly want to keep using it .

Your proposal is quite accurate, as it correctly considers some of the factors that involve noise in communications. However, please let me also show what I consider a plausible system. The amount of background noise, in reality, can be computed just with the same equation that gives the received signal power (Friis equation). In a different form, that equation provides the actual range of a communication system. Please note RemoteTech currently computes range in a very different way, still some viable mechanic can be introduced to simulate background noise accounting for the following: - the beamwidth of the receiving antenna (or, its gain, as the two are closely tied); - the angular difference between the transmitter and the noise source, as seen by the receiving antenna; - the relative distances of the transmitter-receiver link and noisesource-receiver link, to the power of 2; - the relative power of the trasmitter and the noisesource (currently unknown), multiplied by the respective gain; - the bandwidth, or selectivity, of the receiver (currently not defined in RemoteTech2). The last two factors are not factored in RemoteTech2 currently, so an acceptable value has to be chosen that makes for an acceptable mechanic in game, without introducing further difficulties to players. Many other factors would be considered in reality (carrier frequency, polarization, losses, antenna impedance...) but would only overcomplicate things, so am leaving them out. Knowing the relative amount of signal and noise power provides the S/N ratio, which is one of the most important factors to determine range in reality. But also, S/N ratio is very important to determine the datarate, or the channel capacity of the communication link (Shannon-Hartley theorem). A low S/N ratio limits the channel capacity, and that should bear to a smaller PacketSize (or longer PacketInterval) with the antenna (possibly to be simulated by coding a variable speed of transmission in RT2). Hope the above is of interest; I already have parts of the math behind real communication systems covered, so could help in case developers wanted to consider it.

Welcome . Believe this is a very good place to start finding answers. Even for things you don't yet know you should be asking.

Regole relative agli Add-ons [24 luglio 2014] - entrano in vigore dal 21 agosto 2014! Terminologia: Add-on = qualunque forma di aggiunta al gioco di KSP Plug-In = modulo software che può funzionare solo se direttamente connesso al gioco (KSP) stand-alone app = applicazione esterna a KSP code repository = sito per la conservazione del codice assembly = assiemi di codice eseguibile Regole generali sulla pubblicazione degli Add-on 1. Licenze Tutti gli add-on pubblicati sui servizi resi disponibili da Squad per l'uso da parte della comunità di KSP (tipo il forum ufficiale e Curse) devono essere accompagnati da una licenza che stabilisca cosa gli altri utenti possano fare con il materiale da essa protetto. Questa licenza deve essere resa disponibile sia nel file di download che nel posto da cui l'utente possa scaricare l'aggiunta (tipo un post sul forum o un elenco su Curse). 2. Argomenti vietati Gli add-on non possono violare la sezione in merito agli argomenti vietati delle regole del Forum. Regole specifiche per i plug-in 3. Codice sorgente Tutti i plug-in resi disponibili sui servizi resi disponibili da Squad per l'uso da parte della comunità di KSP devono avere il relativo codice sorgente pubblicamente disponibile. Questo può essere ottenuto pubblicandolo su un sito pubblico di deposito del codice (code repository) e fornendo un link a tale deposito in ogni posto che offra il download del plug-in. Anche l'inclusione del codice sorgente nello stesso file di download soddisfa la regola, al pari della sua pubblicazione. 4. Codice proibito Il vostro plug-in non può: Modificare, cancellare o creare files fuori della directory di installazione di KSP. Includere qualunque sistema nel gioco inteso per profitto (personale). Questo include pubblicità e richieste di donazioni. Rimuovere o modificare il logo e/o le informazioni di copyright di Squad. 5. Collegamenti con altre reti o sistemi computerizzati Gli add-on che stabiliscano collegamenti con altre reti o sistemi computerizzati devono indicare esattamente agli utenti cosa stiano inviando o ricevendo in modo chiaro ed ovvio in ogni posto da cui sia possibile il loro download. 6. Raccolta di informazioni personali identificabili Gli add-on che raccolgano informazioni personali identificabili e le inviino ad altre reti o sistemi computerizzati devono: Fornire all'utente un sistema di sottoscrizione (opt-in) interno al gioco che richieda il consenso esplicito dell'utente in merito alla raccolta delle informazioni ed al loro invio prima che alcuna informazione sia inviata; questo sistema di sottoscrizione deve informare l'utente circa gli scopi e la dimensione della raccolta delle informazioni. Fornire all'utente una opzione con lo AppLauncher (sistema di avvio delle applicazioni interne a KSP) per disabilitare a raccolta di informazioni, che sia visibile almeno dallo Space Center. Permettere all'utente una opzione per rivedere e rimuovere tutte le informazioni personali identificabili da quelle raccolte e sotto controllo da parte di chi ha la gestione dello add-on. Per quanto relativo a questa regola, le informazioni pesonali identificabili non includono quanto inviato al di fuori del controllo dell'autore dell'add-on quando viene stabilito un collegamento ad un'altra rete o sistema di computer, tipo indirizzi IP, sempre che dette informazioni non siano collegate e immagazzinate con le altre informazioni raccolte. Per informazioni personali identificabili si intende qualunque informazione che possa essere ricollegata ad un utente specifico. 7. Limiti legali Non è consentito decompilare, modificare e/o distribuire alcuno dei files .dll né alcuno degli altri files inclusi nelle distribuzioni di KSP al di fuori di quanto contenuto nella cartalla /GameData. Seguite la EULA (End-User License Agreement = Accordo di licenza con gli utenti finali). Circa gli assembly, possono essere utilizzati solo i membri pubblici (public) o protetti (protected) delle classi e non deve essere esaminato il codice interno ad alcun membro. Applicazioni di terze parti 8. Applicazione delle regole per gli add-on Con la sola eccezione della regola 4a, le regole sopra elencate si applicano parimenti a qualsiasi applicazione esterna (stand-alone app) resa disponibile sui servizi mantenuti da Squad per l'uso da parte della comunità di KSP.

Without doing a complete analysis (that may require to see the formulae you used to calculate the velocity), two things may have to be considered: - ISP is variable, the speed of exhaust gases changes with atmosphere density; - atmospheric density is decreasing with altitude, therefore drag (and that is pretty relevant itself).

Unless I have it totally wrong, what you need is just to add the definitions for attachment nodes with your parts.cfg files. Something that is described under "Node definitions" and "Attachment rules" with this page on KSP wiki. If it is so, that is actually a pretty easy thing to do, knowing the size of the mesh and where you want those nodes to appear (at least, so easy I could without trouble add nodes with other custom parts). Of course would be better if you already had the part.cfg, as that includes other important info that has to be in match with the nodes position. If you ask others to create a whole new part.cfg for your meshes, that is another thing, the results may not be exactly what you intend.

I'd certainly like if the list of supported scanners with the OP could be expanded to include all the ones actually supported in SCANsat: beyond the scanner parts from the Kethane mod, to include those from EPL, KSPI, MKS - for which a suitable config exists with SCANsat. Not telling a separate chart should be generated for each one, in particular if best altitudes and swath width is similar, a single chart could do for different scanners of similar characteristics.

Excellent choice to get rid of the MapTraq, while keeping and extending the functionality. Also like the other improvements with the new version .

This is certainly very useful, and personally I want to thank you for the patch. Anyway, I am taking the liberty of providing a link to YOUR source code on Github, as to find it may require a bit of an effort; all the while the rule stands, any plugin published on Squad services must be accompanied by source code. Derivative works are no exception. Also, please let me suggest it would be best if you could upload a zip with the whole folder directory (/GameData/MechJeb2/Plugins/MechJebFARExt.dll) just like the original: makes installing all the easier for the casual user. And, would be great if in the zip you may include a short doco stating the license (has to be the same that Sarbian used, GNU GPL 3.0) and a clear statement about the original author and work it is derived from.

I keep installing both VOID and KER alongside with all my main installs, each version of KSP since 0.22 (back to VOID 0.9.17 and KER 0.6.1.4 for sure, possibly even earlier). I never noticed any incompatibility because of them. If any issue exists, it has to be such a minor one that easily isn't spotted. Many other addons show serious issues while running multiple instances of a plugin (so, of the same code); but VOID and KER have always played nice together for me. It's not my call to say if the two instances of KER code are kept apart, or the variables used are perfectly matched; or else: but both seem to always show the same results for anything displayed in both VOID and KER. To be honest, I never even considered to have two copies of the same code running...(which can only be considered my fault, from a software engineering standpoint ). But then, this brings to one question: @ toadicus: so I understand KER code is pretty much the same in VOID. Would there be any benefit if VOID could recognize the Engineer.dll is running (from KER), and use that directly instead of creating another instance for the same calculations? (If that is worth the effort, as few kB of data and a few CPU cycles at each time interval may not be enough for a change, unless you like it because of other intrinsic benefits, e.g. to only use the most advanced code available among the two).

For "tabs" you mean the menu you opened by right-clicking on the command pod? Just right-click on any empty place. The Crew Report closes as you select one of the options in it.

I have certainly not enough knowledge of how ModuleManager works, but the :FINAL directive is rather exclusive, meaning can be used once only. Mods that don't respect that, and include configs for additional modules with that directive with parts that already have one, inevitably clash. Actually, I can't see why that directive would be needed, RemoteTech does not use it with the stock parts and those work. Instead, I know that at least up to v. 1.3.3 RT2 used to internally number the modules, and referenced them by number instead of by name. Can't say if that changed with v. 1.4.0; but with that directive the number assigned to "ModuleSPU" would increase as other MM configs are parsed and applied to the same parts, and that may make RT2 not work. Please note, I am not a dev with RT2, and if one with more knowledge would like to comment on the above, I will certainly be glad to learn something.

Looking with much interest to this new project, RoverDude. A resource mod matching with MKS is by itself a very interesting thing. Very useful to have a mod that uses ORS for starting a fuel extraction/conversion system. And, a mod offering similar functionality as Kethane, but without the implications and some of the bits it has bundled together. Bookmarked.

800 plugins? and I was thinking to have too many at 85! About your question, RT2 has built-in some moddability. In /GameData/RemoteTech2/RemoteTech_settings.cfg you'll find most of what needed. For a rapid across-the-board increase of communication ranges I would advise to mod the line "RangeMultiplier =" to a number fitting your need. However, I doubt that will make the setup less repetitive. To avoid repetition, you may find a more interesting approach in designing missions that allow to put multiple satellites in orbit together. Try building a vessel able to deploy 3 or 4 sats in KSO, designing an efficient mission profile would make for something interesting (definitely doable).

If you start a brand new game in KSP 0.24 (your reputation being 0 at start), you will be presented with four basic contracts just at the start, visiting the Mission Control building. Reputation is shown in the center display at the top in the space center, and with one of the apps in other modes. No precise number given, but a sliding scale, though not too difficult to figure. More reputation = more contracts, and more difficult and rewarding.

All parts added with mods you installed since your last save are not yet available, but can be "researched" for free by clicking on them in the proper technology node (from the R&D screen). Any tech node that has parts not yet researched has a small circled number on it (with the number of parts available for research, the figure 9 means 9 or more parts).

Putting the mouse over the part in the editor, is exactly what made the issue I was talking about appear. Please find that modulefixer mod (last post in the thread I linked) and try it, it could be your solution. If not, you have to upload the whole output_log.txt on any file sharing site, and provide a link to that. While the bug may come evident just by observing a few lines, I can't anticipate what those lines may be. Anyway, noted you are running KSP 0.24, while KSPI is not yet rated to work with that version. Other mods you installed seem to be. If that is the case, you may have to wait until KSPI next version is published.

In a way, those images remind me of a bug that appeared with KSP 0.23, tied to parts with 3 or more resources but no descriptive modules, and fixed by a little mod: ModuleFixer. But without knowing the real cause, the above is just a guess. If the above issue is the correct one, the issue was with KSP itself, not KSPI. But if you have no other parts from other mods that show the same, understand why you may believe this to be KSPI related. In case the above was not the cause, would be useful if you could state what version of KSP you use, what other mods you have installed, possibly a link to a output_log.txt file of after you had that issue, and a sequence of steps you did that brought to that result.

What, can't you find the "science" option, together with "sandbox" and "career" when you start a new game? That seems to be exactly what you are talking about, and already exists. As per the compatibility of your previous game, no that is not granted, just as stupid_chris already wrote.