diomedea

True, true, absolutely. Wasn't for this mod with aggressive settings, my career game (heavily, heavily modded) couldn't be done. And, I don't really use any of the big parts packs, but lots of plugins. But wasn't for the gain with the textures thanks to ATM, I would not have any RAM left even while just starting the game. An issue I always have is RAM usage always increases, particularly every time I switch scenes (e.g. Flight to Space Center to Editor or back). Almost never is RAM let free, thought I expect some to be when modes/scenes change (shouldn't Unity deal with Garbage collection? ). Not something I should expect ATM to deal with, anyway. Would be too good if textures were loaded and unloaded dynamically - that is, only kept in RAM when really useful, so when flying a vessel, only those textures that are in the parts with that vessel (and with the visible scenery) are kept loaded, all other textures that may have been loaded before (e.g. in the editor) unloaded when leaving that scene.

Hi, welcome aboard . Hope you'll find help with your issues, but even more that you'll find this forum appealing your interest.

There was to be a reason why you had not already made for moons or custom parameters. Well, your approach certainly provides solutions very fast, very understandable there are limits for the solutions to be acceptable. Many thanks for having shown a bit how it works under the hood, very interesting . I don't use yet and therefore can't recommend any alternate planetary systems; sure you know the main ones, those are the same I would suggest (and probably would forget some).

Another suggestion, believe will be useful for all players who have installed mods that change planetary data or implement new planets. All planetary parameters are loaded from within procedure LOADPARAMS, defined in the sourcecode (lines 115-201). That effectively prevents use of this tool with the mods mentioned above. Would be nice if all planetary data are instead loaded from an external file (best if plain txt or xml, to allow customization). Same goes for Kerbol Grav constant (line 107). Now, I notice moons are not included. Probably too complicated to include a moon flyby when dealing with interplanetary transfers (must think how a Lambert equation would deal with that); but what about flybys within the Joolian system? Could be done if all parameters are in another external file, and users may choose what parameters file to load at start.

I tried a few different flybys, your tool has always been able to find solutions, and those seem to be consistent (can't yet talk about accuracy, I don't even know how accurate are other tools I could use to verify those solutions). But what is most evident, is how really fast your tool is. I am running it on a i7-3770 CPU, Win 8.1, 16GB RAM. To make an example, for the Kerbin-Duna-Jool flyby, with a search period extended to 1500 days, it provided 31 solutions in 3,5 seconds! Not that I am too surprised for its speed, Pascal is extremely good at crunching numbers. Anyway, till now one single suggestion, about the way Delta-V is shown on the graph: it seems like colors are each coded for a fixed range of DV (@ lines 617-637 in your source), but often most of the solutions are way over the max. Could be possible to first determine the min and max DV found with solutions, and then divide the color cases for the range of DV found?

I am truly happy to find this tool and to be able to compliment you. Probably the reference to that request for a flyby planning tool (example Kerbin-Duna-Jool) was mine, as you see I have a true interest in this feature. I have just tested your tool a bit, and it shows to be working nicely (can't still say about the results accuracy, as that would require quite some time running other tools). I am tempted to already start reporting my inpressions and suggestions, but better to test more accurately before. About links and license, I can confirm that is all right. And to finish, I am also really glad to find you program in Pascal. I am an oldtimer as well, Pascal remains my preferred language .

Hats off to you! While I'm just an amateur, I read something about Lambert solvers, and never came across any in a vectorized form. Hope this new enterprise isn't just because of my insistence, but because you find true interest in it .

Actually, my goal is multi flybys, really looking at a possibility to plan a Voyager-like mission. Glad to know you already considered that, if that's beyond a normal CPU capabilities no reason to deal with that. Anyway, I never tried even the single flyby sequencer till today. Another of the goodies of KSP TOT still unknown to me. Running parallel processes and using some math libraries never called before, and still taking a lot to compute on my PC (about 30 minutes to complete the example Kerbin-Duna-Jool flyby; but then tried other scenarios like Kerbin-Eve-Duna, Kerbin-Eve-Jool, and it took just few minutes). That is making me think what could be wrong with my simplistic approach. Even if not perfect, trying to match dates for each flyby (arrival and departure transfers) should give at least a raw solution, then to be refined tweaking periapsis at each flyby so to make the orbits match (if at all possible; if not, I would just check with another match of dates). A better mathematical approach would probably consider what are the different angles at arrival and departure with each flyby, compute the energy required to change orbits and find how much of that energy can be obtained by gravity assist. It shows I am not an astrodynamicist, glad if you could point at what inconsistencies are in my procedure , but please don't lose your time if it takes too much.

Just thinking aloud, but another solution could be to keep the "normal" SCANsat bitmask at 2^8, to deal with SCANsat sensors and Kethane resources, and add another "ORS resources" bitmask, minimum at 2^8 but you may want to enlarge that. Both bitmasks written in the persistent.sfs for each body, and managed the same way (LZF compression and all, you know that much better than me). That would minimize impact on existing saves, possibly avoiding you to build a conversion method from old to new bitmasks.

Arrowstar, I have a fantasy about one additional feature that could be made possible with KSP TOT. Can't find if anybody ever already proposed that (sorry in case), but would be grateful if you could consider its feasibility. Mission Architect is great trying to achieve goals within set constraints; but when initial conditions are awful, solutions may not be suitable. Now, if I want to schedule a planetary flyby, I am actually trying to set two different transfers right at the same time: before and after the flyby. E.g., I want to transfer from Kerbin to Jool but making a slingshot at Duna. More complex missions may be conceived (like a voyager mission) involving a sequence of transfers. Now, the current approach would be to start KSP TOT, find some transfer windows Kerbin-Duna, then separately transfer windows Duna-Jool, then match the times so that arrival and departure from Duna match for a couple of those transfers. That approach is probably less than ideal, being quite long. Would it be possible to create a "multiple transfer" plot, like KSP TOT already gives for single transfers (the porkchop plot), but showing best solutions with matched transfers?

White Owl, you beated me on this (and I am truly happy you did ), all those little nice mods could be nicely packed together. Bawr, happy to find you are already considering that wonderful idea. I am considering if that idea may also bring to performance improvements. If each of your little utilities is loaded as a separate dll, each dll will have a dedicated memory area of at least one memory page. Given how short and effective your little mods are, I believe most of that space is empty, wasted. If packed together in a single dll, that dll will load in a single memory area, effectively using less pages for best efficiency.

Malkuth, I have to thank you for explaining so clearly (probably, again) about vessel ID's with MCE (thanks Psawhn as well for asking). I had a failed Apollo-style mission because of the very reason you show (MCE mission description actually said to land the CSM, out of a CSM/LM configuration, of course I believed that description to be in error...); then I kept having doubts about running multiple missions at once (believing Vessel ID could be mismatched again). Until now, you finally made it clear .

Hi, welcome aboard. About all those crashes, please send a mail to support@kerbalspaceprogram.com

As rule 5.2 clearly states, license must be both in the post and the download file. The second condition wasn't met. A simple disclaimer in the package telling it was "public domain" would have been enough, sure.

You did it, and fast! Just a few days passed since considering again the need to add resource maps to SCANsat, and it is already here. Thanks DMagic and technogeeky.

Information Technology is filled with solutions that have turned obsolete and, though great efforts were made to keep them alive, ultimately had to be abandoned because new ones performed much better. Notable are MS DOS, parallel ports, floppy disks. Even if very used, ultimately those technologies had to be considered a legacy, and be removed to allow progress. The original kOS is really an example of the above. Its language has so many quirks and shortcomings, it was really needed to improve. But, as often happens with new things in IT, different and sometimes opposite solutions emerge. There is of course the new kOS Scriptable Autopilot System, by Erendrake. Originally started as a maintenance update to kOS, it now implements a revamped kerboscript syntax. But it strictly adheres to the original kOS code in many ways, and as a result it is sometimes even slower to compute. Jebnix is not yet ready for use, therefore you don't see as much of a user base with it yet. But it has some great potential because it completely abandons the kOS code and implements its own (still able to interpret kerboscript, but also to run it in compiled form). Performance gains are expected to be impressive, and further improvements in the language are coming as well.

I know versioning system is a matter of personal preference and totally up to the author to make. However, it is now (if I am correct) the 4th different release still marked as 0.12.2, not really easy for users to check what each release is by looking at datetime stamps with some files. If it isn't too much, could you develop the version number so to uniquely stamp each future release?

That would be a perfect solution for all cases .

It took me quite some time to ponder about what could be best for a Ideal Altitude Calculator, to have it as a separate tool or as a plug-in. The latter would be fascinating, but in the end my conclusion is a separate tool would be better. All plug-ins run in the same KSP main process, using the same globals and memory. Each of them reduce RAM available, making harder to run KSP and other add-ons. Certainly a plug-in is able to use data available to KSP (current orbit, sensors aboard), but this calculator is of more use as a planning tool (so to help set up orbits correctly) rather than to show what the current orbit may provide. If developed as a separate tool, it would not require to fire up KSP to compute those orbits (KSP is not really needed while planning a mission). Now, in case you like to give us the "separate tool" implementation to try, I am to ask if you could generate a compiled version to be run with the MatLab Compiler Runtime (being the MCR free to download, would allow anybody to use this tool for free). Of course, when you feel the code is to your satisfaction.

...missione Overland... davvero italiano Per postare l'album, usa il BBcode (come al post #5) [*imgur]value[*/imgur] (devi togliere quegli asterischi), idem {imgur}value{/imgur} (sostituisci le graffe con parentesi quadre); non ti posso postare i codici così come vanno immessi perchè diventerebbero attivi e non li potresti vedere. Il "value" è quanto appare sulla barra degli indirizzi nel browser quando apri l'album in Imgur (l'indirizzo completo appare come "imgur.com/a/value#0", prendi solo il value, #0 è la singola immagine presentata), forse esistono anche altri metodi...

As a new thread was opened to provide and discuss further updates of SCANsat mod (link here), any further posts about SCANsat should be directed over there. Damny, you did an excellent work with this mod, we miss news about you and what you would have liked this mod to become. If you return and like so, you can PM any mod to have this thread reopened. Thread closed.

In case an error report comes useful, Ship Manifest opened a "debug console" window (with version 0.23.5.3.3 on it) when I began an EVA. Never happened before, and I wasn't using SM at all (window closed, believe working in background). Here the content of the debug window (note: I repeated twice the EVA, both times SM made this, first time I cancelled the log): Info: Log Cleared at 5/17/2014 12:40:58 AM UTC. Error: in drawGui. Error: Operation is not valid due to the current state of the object at System.Linq.Enumerable.Single[KeyValuePair`2] (IEnumerable`1 source, System.Func`2 predicate, Fallback fallback) [0x00000] in <filename unknown>:0 at System.Linq.Enumerable.Single[KeyValuePair`2] (IEnumerable`1 source, System.Func`2 predicate) [0x00000] in <filename unknown>:0 at ShipManifest.ManifestController.get_Vessel () [0x00000] in <filename unknown>:0 at ShipManifest.ManifestController.drawGui () [0x00000] in <filename unknown>:0 SM version is 0.23.5.3.2.3, CLS 1.0.4.1. KSP continued to work apparently unaffected (all portraits correctly drawn), CLS unaffected too (highlighting crewable parts corrrectly), but SM didn't allow to select any resource (or crew) when I opened its window thereafter. Game was using 3.9GB RAM (though that may not imply anything, I often arrive to 3.99 before restarting). Output_log.txt here, in case.

Have you tried just relaunching KSP TOT? On my machine (Win8 64bit) KSP TOT always fails to recognize MCR the first time it is launched since reboot; but it always opens right the second and subsequent tries (I have no idea why, just letting know in case it may come useful).

Purtroppo non l'ho avuto quel libro, quindi non saprei riconoscerlo nemmeno se lo vedessi. Vorrei però segnalarti questo link, forse nell'elenco di libri che produce c'è anche quello che cerchi.

Usa il BBcode [*imgur]value[*/imgur] (togli gli asterischi per farlo funzionare). Tutti i BBcode utilizzabili sul forum sono elencati qui, che è uno dei link permanenti in fondo ad ogni pagina del sito (nel riquadro "Posting Permissions, dove dice "BB code is On"). Nota: abbastanza spesso vengono implementate nuove funzionalitàin BBcode, una al momento in sperimentazione riguarda proprio gli album IMGUR, serviràad evitare di rallentare il caricamento delle pagine (il link ad un album attualmente impone il caricamento dell'intero album ogni volta venga ricaricata la pagina dove è linkato). Occhio perchè la sintassi del BBcode relativo saràlievemente modificata.