katateochi

CraftManager just uses the KSP screenshot system, so any screenshots taken by CM should end up in the KSP screenshots folder. And in the image browser in CM you should also see any other pics you've taken in KSP by pressing F1. If you use a custom screenshot program like FRAPS or anything else that puts screenshots in another location, you can tell CM to use that location instead of the default KSP screenshot folder. Click on settings and you'll see the option to change the screenshot path. Hope that helps.

@Kerbalwerks Yes...and no! When you group craft together as versions of each other, only the "most relevant" one is shown on the front page. "Most relevant" being the one with the highest version number (according to how you choose to sort them), which also matches whatever search filters are being used. So say you upload two craft, one stock and one mod, and set the mod one as the latest version. Then if no search filters are used just the mod one will be shown. But if someone is searching for just stock craft then the stock one would become the most relevant and so it will be shown. When someone clicks on any of them, they can then easily get to the other versions, via the link in the header where it says version x of y (and there's another link in the side panel). You can also embed the version list on the page, to make it even more prominent, just add a new text box and put "[version_list]" into it (include the square brackets). (have a look at one of my craft to see how that looks). Part of the reason I added this feature was to cut down on having sets of almost identical craft all appearing on the front page at the same time.

Some things are heavier than others! ok that was badly put, what I mean is; some parts seem to alter the COM of a craft more than other parts of the same mass. I'm working on a tiny science probe and I'm building it so its visually asymmetrical but is still well balanced, so it's quite sensitive to small masses. And I noticed that some parts with a mass of say 0.01t have a big impact to it's COM (and the Torque value shown in the build aid window), while others with the same mass have no effect. For example; If I attach a single KAL-1000 controller (which has a mass of 0.01t) then it doesn't alter the Torque value at all (even if I use the offset tool and drag it way off center). But the Micro Goo Containment Pod (from DMagic Orbital Science, which has the same mass of 0.01t) placed in the same position will alter the Torque value quite a bit (and offsetting it has a big impact). So I'm wondering why this is. Is it something to do with physics-less parts?

The updates to SCANsat look awesome! I'm just trying to get my head around the different parts and what they do...If I have high res scanners in place around a planet, is there any need to have the equivalent low res scanners? Edit: Also, do the scanners that require the surface to be lit, continue to draw power while over the night side?

Do you mean for the new decal parts in 1.10, or just flags in general? I've not had a chance to look at how the decals in 1.10 work yet. I would like to do this, but images can be a bit of an awkward area. If I host them then it costs me, not a lot per image, but it's cumulative (I currently spent about $12 USD on image hosting per month as it is, on top of around $60 USD per month for main hosting costs and donations to the site only just about cover it). The other issue is that I'm effectively creating a place where anyone can put an image....and that becomes a whole can of worms if someone ever decided to put, shall we say, less than appropriate, images (so everything posted would need moderation). The other solution is to push those problems onto an image hosting site like imgur but handle the upload through KX via imgur's API, but that API has usage limits and they get twitchy if they think you're hosting primary content on their site (a while back they blocked KerbalX for that reason because I was using them to store the craft thumbnails). So it's not a straightforward thing.

@Hangdog should be fixed now. (I remembered, I wasn't sure if Squad was going to stick with conventional versioning when they went from 1.9.x to the next, so I'd capped the allow list of versions at 1.9.x. So it wasn't excepting 1.10.0 as an allowed version). Hope that hasn't confused too many folk into trying to load an older version of KXAPI. Thanks for bringing this up! The current version of Craft Manager and KXAPI seem to be working normally in 1.10.0

@Hangdog Ive not had a chance to look at 1.10 yet, it might be fooling it, although I use a versioning library to perform the check so I'd be surprised. I'll sort it out when I'm done with work today.

Any info about changes to the API? Is this going to be a mod killer or mostly a smooth transition for modders. I'm sure the guy above me would like to know!

Thanks dude! That would be a really great addition. Support for all generic resource converters (that only produce EC) would, I think, cover most of the mod power generator options. That would be fab. I did try that, but I got unexpected results, but that might have been because I didn't restart the game after changing the setting in the options UI. I need to try that again.

The tray on my desk labelled "bills to pay", obv with its contents, and preferably at a time when it's at peak capacity! also not a fan of those, but I hear they have interesting aerodynamic properties when loaded into a catapult...but you'll have to do some experiments and report back.

If I'm using mods that have other forms of power generation (like nuclear reactors from MKS), can I make a module manager patch or do some other config tweakery, to have those generators taken into account in the background resource processing? Or...is there a way to completely ignore power as a life support dependency? tbh I'd be quite happy to ignore electricity as a life support resource; as any craft that doesn't have adequate power generation is pretty much doomed anyway. I guess I can uncheck the "unloaded vessel processing" option, but that seems a pity as aside from electricity I've got craft which are setup for life support recycling/production and i'd like those to carry on working.... Actually, what are the implications of switching that option off? If you have a base that produces and recycles life support resources, do you still get those resources calculated when you next visit the base? Does unchecking that option have any impact on ISRU operations on unloaded vessels? EDIT: I tried unchecking "unloaded vessel processing" and the problem I now get is that craft with normally working elec production (ie those with just stock solar panels or RTGs) are now being flagged as running out of power (it seems like power drain is still factored, but not power generation....do I have to restart the game for that setting to work?) So what is the best way to manage power when also using mod power generators? Is there a way to remove power from the equation all together? Thanks! I love this mod, I've tried other LF mods, but in the end I always come back here.

No! Tis I. Maybe perhaps possibly @AlamoVampire?

assuming you're in orbit around Kerbin, at say around 100 or 200 km (doesn't have to be perfectly circular, this isn't rocket sci....oh, but yeah, sloppy orbit is ok) Go into map mode and pan the camera so you are looking side on at Kerbin, now rotate the camera so you're going around Kerbin counter clockwise. As soon as you see Mun appear from behind Kerbin stop. That's the mark where you want to set your node. At the point on Kerbin's horizon where the Mun rises. Now drag the prograde marker out from the node, which will raise the "projected" orbit's Ap. Keep dragging until it intersects with Mun. You'll see a sudden change and your yellow orbit line go from being a complete orbit to a curve that ends in a yellow marker and then changes colour to purple. The purple part is the orbit path around Mun and you should see a purple Pe marker. If you don't then you've probably dragged the prograde marker too far and the orbit actually hits Mun, so just drag the retrograde marker a little bit until you see the Pe marker appear. On the right of the Nav ball there will be a green bar and a value in m/s. That value should be somewhere in the region of 830m/s (depends a bit on your starting orbit, but that's roughly how much dV you need to intersect with Mun). You should now be looking at something like this: Couple tips here: Dragging the node markers can be really inaccurate and it's hard to make slight adjustments. Instead, place your mouse over one of the markers and gently roll the mouse wheel, that will make small adjustments to that marker. You will want to see the altitude value of the Pe marker which is only shown when you hover the mouse over it, but if your right click on the marker then the values will stay when you move the mouse away (this works with all orbital markers). As well as making adjustments to the prograde/retrograde makers on the node, you can also drag the entire node back and forth along the orbit, by clicking and holding in the middle of the node. Don't worry too much about that at first, but that's one way to find the most optimal position for the node. "Fiddle" the pro/retro-grade makers to get the Pe marker to something like 100,000m or whatever height you want your Mun orbit to be. And that's it, you've setup a Mun intercept maneuver. Now to execute it. By the nav ball (bottom right side) will be two values 'Node in T' and 'burn time'. Divide your burn time by 2 and then time warp until the Node in T value reaches that result. ie if your burn time is 2m, then you want to start your burn at T-1m. Fire ze engines! Slam the throttle to max and watch the ...oh wait, make sure your nav-ball cross hair is lined up with the Blue node marker first, then fire the engines! Now watch the green bar on the left of the nav ball decrease and when that hits zero cut the engines. Your orbit should now be the same as your projected orbit. Time warp out to Mun and up to the Pe marker, then face your craft retrograde and fire ze engines again. The fly-by trajectory will close down to become a complete but very elliptical orbit, keep burning to then bring the Ap down to the same value (ish) as your Pe and boom, your're in a circular(ish) stable Mun orbit.

I would also like this. I think it would have been more elegant if they designed it as a single cache file that holds all the metadata for all craft and sfs files in a save.

That's so cool, my vid inspired you and now your mod has inspired me to get back into KSP (I've not played seriously in ages!). I wish I still had time to make vids, I'd love to make something with Spectra as the backdrop. The only thing that I thought was when seeing the sun and lens flare, my first reaction was It took a moment to get used to but now it's actually one of the things that I like about Spectra. It makes the Sun much more...sunny! I've got probes heading out to Laythe and Vall right now. Looking forward to seeing them anew.

Moho is my nemesis. I can never get there on the dV suggested by transfer window planners or what the dV map says. So I always end up building utterly overkill capture stages. Capture is the worst bit, but I also find getting the injection burn right a challenge too....and badly done injection burn means more nightmare with capture. So yeah, if your looking for a lump of rock to make you angry, choose Moho.

It really is a beautiful mod. I think you've got the balance of effect and performance spot on. This is the first time I've used it, and I'm still just derping around Kerbin and moons but so far it's been beautiful, can't wait to get to the other planets (I think my progress is slowed down by having to stop all the time to gaze at the view!) I've run with scatterer and EVE for a long time and always felt that was a nice look, but that always needed tweaking and I was constantly trying to get better performance. I just installed this and haven't wanted to tweak anything. Really great!

Assuming we're talking about an SSTO spaceplane, then here's a few things I've picked up. - DRAG!! drag is extremely important, design your craft to have as little drag as possible. That means having no or very few attachment nodes left without an aerodynamic part to end it. As important on the back of the craft as the front. - Angle of attack. angle the wings on the craft up very slightly, how much depends on the craft, but the aim is that when flying level the lift from the wings should be keeping the prograde marker on the navball crosshair. - The magic number of the Rapier Engine. 450. When you take off, don't try to climb too fast, fly at a slight upward pitch (5-10), the aim is to gain speed. Once you reach 450m/s the Rapiers will be performing optimally, then start to climb. (How you fly your SSTO makes a big difference to it's efficiency, they're much less tolerant of bad piloting than rockets!) Don't be too ambitious at first, just try a single pilot craft to low orbit to start with. You can build a really small LKO capable SSTO and gain a lot of understanding from it before trying something bigger. Grab some craft made by others and pull them apart. Here's a couple of mine: This one is very small and simple, but doesn't have angled wings. This one is also quite simple in design but has a good range, it's a good example of the slightly angled wings (also is a mostly liquid fuelled design). And this one is on the larger side with a 67ton cargo capacity. (my craft are a bit out of date, but should load in the current KSP) Or search for SSTO on KerbalX.com and there are loads of great designs which you can pull apart and see how they're made.

Are there plans to bring the Magnet from the original KAS into this version? That was an insanely useful part, especially for making construction rovers. The ability to pick something up without docking to it (and without having to go EVA and connect cables each time) just has so many applications. Or are there any dirty hacks that could enable using the old KAS magnet along side this version?

Steam says I have 1500+ hours in Fallout 4, a game I've merely dabbled in by comparison to KSP. I don't run KSP from Steam so don't know my hours...but I've been here since 2012, for years it was the only game I played and played every day, prob on ave 4-5 hours a day with many 'proper' sessions of 8-10 hours....I must be pushing 6-7k hours at this point. Had a long break from it, just getting back in, so Jeb help me.

I've simplified the steps to repeat the issue above and created a new issue on the github issue tracker https://github.com/RemoteTechnologiesGroup/RemoteTech/issues/814 Would really appreciate it if any other RT users could see if they can follow the steps in this issue and see if they get the same results.

Has there been some recent news that has brought up this concern?

I've got a very odd issue which I think I've narrowed down to Remote Tech. The short description is that with remote tech installed the behaviour of autostruts is broken/buggy when a craft is launched AND there is another craft nearby. The problem: When a craft is launched AND there is another craft sitting nearby, with RT installed the autostruts on the 2nd craft (maybe other one too, not checked) do not work. Any part which had autostrut enabled in the editor no longer has it enabled, and when looking at the context menu for that part you can't cycle the autostrut setting, it just remains disabled. Other parts which didn't have autostrut enabled in the editor can have autostruts enabled from the context menu like normal once launched. So it only breaks the autostrut functionality on parts which have them enabled in the editor before launch. It also seems that the joint strength between all parts is weakened as the whole craft has a kind of blancmange consistency! This doesn't sound like it could be anything to do with Remote Tech, but I can only make this issue happen with RT installed. Uninstalling RT or just deleting the RT RemoteTech.dll plugin file (but leaving the rest of the mod and module manager present) fixes the issue. Here are the steps which I can reliably recreate the problem with. Start a fresh sandbox save (all default options) in a fresh install of KSP 1.9.1 (no mods or DLCs installed). Then launch a rover on the runway and drive it off the runway to one side. Then launch another craft on the runway and everything is exactly as expected. Then quit KSP and install RT via ckan, relaunch KSP and return to the save, click on the craft icon on the runway and hit fly. At this point all is ok, but if you quick save and reload then as soon as the craft loads, it's apparent that it's more flexible than it should be and the context menu option for autostruts on parts which should have them enabled no longer works. If you then recover the craft, return the SPH and launch it again then as soon as it loads the problem is present. Then quit KSP and either uninstall RT or just delete the plugin .dll file and relaunch and return to the craft on the runway. Autostruts are now working as expected. You can Quicksave and reload and/or recover and relaunch and still everything works normally. What makes this issue more curious is that it's dependent on another craft being present. With remote tech installed, when I launch a craft without another craft nearby, then autostruts behave as normal. The problem seems to require RT AND another craft close by when you launch. Most bizarre! I thought it might be a Module Manager issue, but as just deleting the RemoteTech.dll is enough to fix the issue then I guess not. Here is a zip containing 3 KSP.log files, one from before RT is installed, one with RT installed and one with the RT plugin removed. Zip also contains my KSP settings.cfg (just incase), the two craft I'm using to test this and another zip which is a save folder setup with the two craft launched. If you put that save in a fresh 1.9.1 install, install RT and then load the save and click on the aircraft (CT-8-LR) on the runway, click fly, then do a quick save and reload you should see the issue (on that craft all the fuel tanks on either side of the central tanks should be autostrutted). It might be significant, but the two craft are from older versions of KSP (1.7.x), but they have been re-saved in 1.9.1 and in either a pure stock setup or my modded (55+ mods, just minus RT) install then they work as expected. So i think they are ok. I'm still not convinced this is a RT bug, because....what would RT do that would cause that effect? But as disabling the RT plugin does remove the issue, I can't see what else is causing it. So any help with this would be really appreciated! Thanks!

<deleted, posted too soon, sorry>

Ah, wonderful. Thanks for explaining that! I found the vids on the main Global Construction page seems to require a bit of prior knowledge, but what really helped me understand the basic process was KottabosGames's mod spotlight vid on it. It's for an older version of the mod, but still, it gave me the pointers I needed.