Kiwa

In between, released fist public version (v0.5). Instead of sorting, todays update includes a new feature: SOI-based filtering, available in-flight and in the tracking station. This actually reduces the vessel list so much that sorting probably will not be needed for now and I can focus on the resource selection, and maybe finally getting the GUI style problems sorted. Or have any of you a strong preference to go for sorting first?

Frequently, I've been looking for a list of my vessels and their fuel status, for example to quickly find a place to dump excess fuel, drop-off excess kerbals, or to pick up some more fuel... and since there wasn't anything obvious, I made my own. It's still work in progress, but the basic functionality is already there. For detailed information on the development progress and plans, and internal workings, please visit the development thread. Usage: Download and install the plugin from github. Release 0.10-beta works for KSP 1.3.1 and 1.2.2, 0.9-beta works for KSP 1.2, 0.8-beta works for KSP 1.1, release 0.7-beta and earlier works for all versions from 0.23.5 to 1.0.5. Old versions up to 0.8 need the Toolbar installed. The archive also contains a debug-version of the DLL: in case you run into trouble (hopefully not!), this will produce more output in the debug console. Just copy it over the regular version. License: GPLv2; with permission includes some code derived strongly from aviveys Switch Vessel Plugin, which is BSD-2 licensed; source code on github. Screenshots:

Filtering is basically functional and commited to github (v0.4). Only downside is it requires the ship list window to be opened once from the map view, otherwise the icons are not loaded/available :/ Code looks stable so far. Continuing with the plan, probably sorting will be next.

Github now has v0.3 commited. Cleaned out all the vessel loading code, and actually got to test it. Didn't have any bad things in the debug console, so it looks stable enough for now. Next planned feature will be the filtering of the list by vessel type, then the sorting, and possibly an option to ignore remove individual vessels from the list; but unlikely to happen this weekend.

Well that's embarrassing. I totally assumed the ProtoVessel would only contain the "prototype", as in the VAB-design. If that lets me get rid of the loading... would be cool. Will definitely try it next.

Well - it already does search the list of registered resources (PartResourceLibrary.Instance.resourceDefinitions) and just filter the three I am interested in (by name). The only thing that is missing is a way to enable users to select the list of resources *they* are interested in, as opposed to *me*. Which means adding a GUI for this, with a list of resource check-boxes, or a config file. It might also lead to a requirement for persistent storage for this selection :/ Guess I will wait to see if there is actually any interest in this. And I was actually more looking at the AlternateResourcePanel because it sports nice icons for the fuels, instead of my crude short two-letter labels, and also nice bar-graphs in addition to the raw numbers.

Hi, a typical question I encounter about every time I play the game is: which of my stations or ships in orbit has some room to dump excess fuel. When one doesn't have many stations in orbit, this may be a simple matter of switching through each of them and checking, but I have grown tired of all the switching back and forth between the vessels and the Space Station/Tracking Station/Map. Loading times on the notebook aren't so funny, nevermind the lag on some of the larger objects. All I really wanted was a simple list of the relevant ships and their fuel status. So I pondered the idea of just writing an external script which quickly parses the persistent.sfs file to collect the information, but then decided to try to write an in-game plugin. After all, this is as good an excuse as any to install Unity and learn yet another language (C#). So, the simple goal is: have a window with the list of ships, showing their fuel status, ideally both in the Space Center and also which in flight. It should not require saving any extra data - no files, no blocks in the (already seriously large) save games. Optional goal: allow direct switching to the ships from the Space Center (like one can switch to the relevant vessel in Kerbal Alarm Clock). Current status: basic GUI window established (You will note at once I'm not a GUI person. The last time I did any GUI work was ... (probably) a control panel for OS/2. Yes, that long ago. I do write code for a living, if they let me out of meetings, but either the devices have no UI at all, or it is all happily ncurses based.) infrastructure to acquire, keep and display the ship data is in place it will by default only show vessels which it knows anything useful about. click the "Show Empty" button to show all vessels ship list can be filtered by vessel type ship list can be filtered by SOI: in flight, relative to the active vessel; in the tracking station, relative to the selected object How it acquires the data: while in space, if the GUI is closed, it will collect the fuel data from the active vessel about every 10 seconds otherwise, if the GUI is open, it will acquire data from all available vessels Which data does it acquire: the name of the ship the number of crew aboard and maximum number of crew and a currently hard-coded subset of the fuels (LiquidFuel, Oxidizer, MonoProp); the infrastructure is there to allow easily changing this, so it will work with any other resource, e.g. life support things etc.; if anybody is interested, this just requires some appropriate GUI work no persistent storage; as soon as you return to the Main Menu, or exit the game, it's all discarded Obligatory screenshots: Dependencies: old versions (until 0.8) have a hard dependency on the Toolbar (http://forum.kerbalspaceprogram.com/threads/60863); I don't see a reason to make this soft, as there would be no way to open the GUI window Release status: [thread=82996]release thread[/thread]. License: GPLv2; includes some code derived strongly from aviveys Switch Vessel Plugin, which is BSD-2 licensed. Now, I'm posting this here because I also do have questions which maybe some of you might be able to answer: is there a more elegant way to load the vessels (to be able to fetch the resources) without actually activating their PartModules? because I think this is what leads to some NREs solved how would I go about re-using the vessel-type selection icons for my own settings/filter menu, and is this actually permitted (by Squad) ? using the recommendation by avivey yet; only downside so far is that it the icons are only loaded after switching (once) to the map view something is weird with the GUI style in the Tracking Station, but I'm not too concerned about this right now any ideas for the GUI? I know it would need a settings menu to select which resources it acquires, and also some filter options to improve the selection of which vessels it force-loads (ideally by individual vessel type, but see my question regarding the icons above); also some select to filter the output list; and it might be useful to sort the ship list by name (currently it is just the same order as your vessels appear elsewhere in the game, e.g. in the tracking station) Cheers Didgey @ http://forum.kerbalspaceprogram.com/threads/82996-0-23-5-WIP-Ship-List-v0-6?p=1214627&viewfull=1#post1214627 : Could you make it so that you can select the SOI from a list instead of selecting it based on the ship you are controlling?

Not sure if it helps you, but I found with EE it is often a question of activating/disabling the various snapping options, sometimes in counter-intuitive ways, to get a good attachment. Angle snap in particular did cause unexpected results a few times.

So, here are some more pictures, of a small proof of concept test mission from today. Discovered a minor issue with the 2.5m Astropad (see below). Part one: the ship, launch, intercept and arrival at the asteroid. It follows the "pods" concept I talked about previously, just this time with fewer welded parts (actually only one, the cone/RTG power generator combo) and all combined into one ship instead of one for the drive section/drop tanks and one support ship as shown yesterday. The images show the top section with a Philly to probe for water; then a stock gyro pod using the 2.5m Astropad grabber from this mod, the SAS modules are disabled at the start (or else = wobbly); then a refinery with more RTG power; and finally a drive section, again using my downsized 2.5m variant of the z-pinch-fusion. I really like the ZPF model, but you can just replace it with any Nuke or other engine if you prefer those... the ZPFs are a little overpowered with their ISP of 1200+, but for me it's just a matter of "getting there" with fewer parts and less hassle, especially for these tests For the same reason I let MechJeb handle most of the flying. Part two: operations at the asteroid, deployment of all the pods, and finally disposal of the delivery stage (de-orbit into Kerbin using the remaining fuel). This is a lot of rinse and repeat: arm grabber, attach module, activate SAS/tanks where required, and decouple pod from ship. During this phase I discovered a minor issue with the grabber part: the control direction of the 2.5m part (and possibly of the Philly as well) is inverted. To reproduce, just put it on top of your rocket and right on the launched pad select "control from here"... you'll see what I mean. Apart from that no issues, once or twice the grabber took a while to lock but that's just the same as for docking ports. Part three: plotting to bring the asteroid into orbit around Kerbin and testing the refinery. The 4 gyro-pods are way more SAS power than required for a C-class, so it turns really well. And here we learn why I probably will not be using the refinery in my regular (career mode) game: it makes capturing E-class asteroids very easy. If this were not a 110t C-class but instead a 3000t E-class, my tiny drive section would only have fuel for about 69 m/s. For those I usually bring another two drop-tanks (stock 3.75m medium tanks, each with a grabber to attach them separately to the asteroid), for a total of about 330 m/s available delta-V. This is usually enough to adjust the approach to enter a prograde orbit and capture, but far from being able to circularize (I do not aerobreak asteroids, period). Extrapolating from the amount of water in the C-class (15k water at 110t, which should refine to 2250 units of LiquidFuel if I read the description correctly, an E-class would probably have over 61k of LF (!) which might even be enough for a powered descent into KSC ;-) And that's it. I really like the parts and will probably be using the grabbers to replace the stock grabber (variants). It is very nice that they have nodes on top to stack, and the performance was also outstanding, hardly any "yellow" timestamps even though I am playing on a notebook On the other hand, if I ever start a TAC-LS game, then I will totally be using the water resources from the plugin to replenish life-support. In my regular game I have a small ion-powered ship hopping from asteroid to asteroid to collect samples, and that could totally benefit if it did not have to carry too much life-support.

I was afraid they would be upside down. So maybe a redesign of the generator block in the power/lighting towers is in order (the cone with the 8 embedded RTGs); but I do want to keep it close to the grabber for the weight balance, as some of my earlier attempts at asteroid control/utility pods ended up oscillating a lot, even when I tried to strut them to the asteroid using KAS struts. Or I could keep using stock grabbers for those, hmm... but the lag of even two of those is actually noticeable. (Also added a screenshot of one of those early, wobbly pods - sorry if they're a bit small in the image.)

I previously played around a bit with the stock grabber, upscaling it to 2.5m (x,z only) for my purposes. While doing so I was under the impression that the ModuleGrappleNode:nodeType parameter follows the sizing of the docking ports (I might be totally wrong there!); if that's the case, then the small grabber would probably be a size0 and the large one size2. I changed it to size2 for my upscaled part and it was working well and appeared to be less wobbly - but again, really only guessing there. So anyway, about those stock grabbers - they are actually the reason why I got interested in your mod. I have a support vessel for capturing D/E class asteroids, and it has 15 functional "pods" which I attach to the asteroid (12 "gyros" for rotation, 2 power/lighting towers to provide power to the SAS modules, and 1 general purpose large docking port). It went through several iterations, because I have experienced terrible lag with that craft, maybe 3 fps in the VAB as seen in the first image. First I thought it was due to the number of parts (~200 in the first version), so I created a welded part for the gyros and optimized some other areas, but still no luck. Eventually I found out it is just the ** stock grabbers - removed them, and I am back to 20+ fps. And now replaced them with your parts and fps are still good :-) (Showing just the craft without the launcher; the other parts are from RLA stockalike, and a 2.5m downscaled z-pinch-fusion engine; launch boosters are attached at the sides where there is nothing attached now...) So even without having flown this version into space yet, just the FPS improvement is already a big success. And I am sure the parts will work

Downloaded this (won't get to try it out until the weekend), but had a brief look at your part.cfg files. I am wondering whether you for some reason intentionally left most of the node sizes at 1, both for the grapples and the regular nodes even though the parts are either size0 (0.625m) or size2 (2.5m) ? Still looking forward to trying it soon though

Just wanted to say I very much enjoy reading this thread