darthgently

Ok, that is clear now. In that case, all I have to add is that the concept of an ELEMENT is highly related to the concept of a stage, but goes beyond mere launch and gets into the different logical sections of a craft well into a mission. The idea of being able to assign a label to these ELEMENTs and have that reflected in the staging list (though ELEMENTS aren't necessarily a simple linear stack later in the mission several undockings/dockings later) I really like the idea of labels within the stock staging list. The more I think of it, the concept of labeling ELEMENTs, then be able to assign ELEMENTs to a stage (within logical reason by way of order order of decouplers and dock ports) like multiple radial ELEMENTS in symmetry that would still be in the same stage, for example. Again, an ELEMENT just being all the parts between a given set of decouplers/dockingports, whether the ports were mated in the editor or not an whether they've been undocked/docked in flight or not

A small and very quickly spinning icy moon that is so perfectly smooth that any craft landing on it slides around the planet in a "litho orbit" nearly perpetually. In fact, if a lander perfectly matches the surface velocity and so isn't sliding after landing, the spin rate would hurl it back into space on an escape vector except very near the poles; thankfully the friction is way too low for this to really happen. Current Kerbal theory is that it is possibly not a natural formation. Evidence is inconclusive as every research base built there eventually collides with a mysterious sliding green monolith that has a difficult to predict instantaneous surface location and velocity relative to the base First person to give it a name that doesn't contain "Mc" or "Face" names it. So no "Slicky McSlickFace" for example

This kind of comes under the same concept as ELEMENTs in kOS which *I think* are based on something under the hood in KSP. Basically the docked sections of a "raft-up". But in kOS, and presumable in any underlying KSP mechanism that may exist, docking ports connected in the editor are not considered a valid ELEMENT boundary until undocked and redocked. Which make them far less useful. Anyway, to get to the point, if one divvied up the craft by sections between docking ports and decouplers is that what you mean by "labeled stages"? If so then I'm on board with this, but especially if it takes into account docking ports connected in the editor. And yes, I have set the ports to "enable staging", and while they stage correctly, they don't show up as separated ELEMENTs from a kOS script until undocked/redocked.

I'm curious how close you were to the target when you initiated this because if fairly close, an approach target->coast->kill relative velocity->repeat is what most people do manually when a lowest dv hohmann transfer would be days or weeks away because the target is so nearby. I really don't know but am curious. I typically use kOS for most everything but rover piloting, tedious docking sitations (when I have the RCS dv to spare for MJ to gobble), and when I get lazy in which case MJ gets called up. Also I should add to the previous stipulation that the target is close *and* the target orbit is close to the ship orbit, especially with regards to SMA

Given even the lastest consoles have multiple cores it is way overdue for games to make use of them. A lot of KSP involves switching between craft, and then back again. It would be great if the most recent flight scene were somehow kept alive on another core so that switching back would be nearly instantaneous, along with the Tracking Center being constantly alive on its own core. Background Resource processing could also be running constantly. I think the PS5 and next (or current?) XBox have 8 cores. The limiting factor would likely be RAM

Question: I have a Been There Done That on a rover. The part action window->Scan Sensor reading says Too High. But the rover is on the ground. It is over 2km over sea level but the terrain is higher than that. Are all anomalies below 2km with reference to sea level? If not, I'll submit an issue. Or maybe it will work fine anyway and the "Too High" message is erroneous. In which case it would be a more minor issue

Maybe just need to come up with something that KAS stands for instead of Kerbal Attachment System , lol. How about Kerbals Attaching Ships (together)? ha. Or Konnecting and Associating Ships?

An interesting idea. But if it involves adding adding traits like Lawyer and Insurance Adjuster to the game I think it is a bad idea. I'm also against having Political Officers or Political Commissars aboard ship in the dismal case that the PRC game makers buy up the KSP2 project. That is what airlocks are for

For the record, this is my favorite mod. There are others that I really couldn't play without, and I could play without this one, but this one is the most aesthetically pleasing. Even more the EVE. I really like when I capture into Minmus orbit and I can see glints of dozens of other craft in orbit there; tankers, relays, and craft waiting to depart to other planets. It really adds a lot to the game for the mere price of a few pixels on the screen. And seeing the inner planets from the Jool system is pretty cool also

Ok I found I couldn't do it with kOS after all because the vectors I draw from the part don't track the "ghost" part KIS uses during placement. But here are some images with some descriptive text that may be a mock up of sorts Some screen shots with some more info https://imgur.com/a/25a4mpL

Many parts are nearly useless unless one can attach them in a fairly precise orientation and location: RCS, docking ports, etc. The particular part I was having trouble with is the Extraplanetary Launchpad disposable pad, which allows one to build something that will be attached where the pad is attached once the build is complete. The pad has colored arrows on it that indicate how the built addition will be oriented, but in KIS placement mode the pad is just a green object with no indication of its orientation. If stock construction could work with all parts I wouldn't have posted to be honest, but only KIS can place these pads and stock can't rotate/offset them. The mock-up ideally be would be what you see in stock construction with the rotate and translate tools combined with making the parts details and colors more visible during placement. Even if KIS doesn't do rotate/translate at the level that stock does, being able to see the details and colors on the part would make KIS mostly useable for these purposes. But really, if colors and details of parts during placement are not feasible, then colored arrows indicating the part's +/-TOP, +/-STARBOARD, and +/-FORE vectors from its center would be fine. What is that game setting that shows your craft control point TOP/STAR/FORE axis? I know from kOS that all parts have similarly defined axis and if KIS displayed these vectors during placement it would be enough. I can do it via kOS and I'll make a mock up using that. I've thought about making a kOS library that does all this but then it would only be available to kOS scripters so thought I'd mention the idea here. In kOS I was planning on a tiny gui with checkboxes that would allow displaying the part's axis, the soon-to-be parent part's axis, and the craft's axis. The parent and craft axis would be translated to emit from the center of the placed part so one could easily see any angle difference. I will mock it up in kOS and reply again or add to this post. Addenda... Another approach would be socially engineering these parts in other mods to work with stock construction I suppose, but I find KIS far more stable. I get kraken after stock construction stuff all the time. I've also noticed that if I offset/translate something with stock construction, then even if my kerb is right next to it later I get the message that he is too far away (even if I move him to where the part was prior to the translate).

I wonder if it would be possible to put some orientation information on parts being placed in KIS. Like maybe some fore/top/starboard vector arrows along with numerical labels on the arrows with degrees difference from parent part fore/top/star vectors, or relative to absolute UP, NORTH, etc? Maybe? Would really be a great addition in support of good alignment in general and critical for base building in Extraplanetary Launchpads and similar

Quick FYI, if I have "vessel rendering" on I get a lot of log spam about null objects. Which isn't a big deal for me as I prefer to have it off anyway. But what surprised me is that I was getting these errors, and lag, while in the editor and I couldn't understand why distant object would care or be running while I was in the editor.

I have not installed the companion for KIS. When will all the companions be on CKAN? The stragglers bite me every time

@Lisias, quick FYI, I upgraded TweakScale to the latest and nearly all my craft in my game are getting an error that the craft are missing part KIS.Container1. I downgrade tweakscale and game loads fine.

Given that the loading screens prior to the menu screens take up a lot more time, I'm happy just putting the pictures I want to see in the UserLoadingScreens directory. The menu screens aren't that big of a deal to me and I imagine the makers will keep that their own for more control over the image and branding of the game. That said, I could have sworn I saw a mod that would alter the menu screen images, so doable in KSP1 anyway (i think)

Yes, keep it simple. Though the idea of the dispersing molecules on the hot side affecting trajectory over time is intriguing from more of an RO/RSS POV

I think it would be great if after a crash a kerbal had a bandage on their head for some period of time. And when around other Kerbals they'd point and laugh and he/she would laugh along with

Question: when a disposable pad is placed on a vertical surface what is the proper orientation? In my first use, I went with the yellow arrow up and everything worked out fine. The part built on that pad was oriented just as it was in the VAB. So I did the same thing with the next section but now the new build wants to be upside down from what it is in the VAB. I must be missing something. What other factors other than disposable pad orientation and VAB craft orientation apply? The root part is connecting where the pad was, but the launch clamps are pointing up. Thanks for any suggestions Edit: I did find the following in the PDF manual in ELDisposablePad section, but can't grok how this might apply to purely in-game operations in the VAB and use of the disposable pad, or if it only applies to mucking about in model files directly: The only requirement is the model provides a transform with the up axis (positive Y-axis in KSP/Unity, Z-axis in Blender) pointing away from where the spawned vessel will be as it will be used to align the selected attach node of the vessel’s root part. This is the opposite direction of the transform used by ELLaunchpad. Workaround performed, but still very much interested in any suggestions: I used KIS to rotate the pad around, which is a trial and error process as the there in no real way to completely know which way the arrows are pointing on the pad while placing in KIS, but only after it has been attached. And I have several other pads in place for future building and while I suppose I could turn the craft upside down in the VAB, I'd rather know what is going on and how not to do it the hard way. Here is the new addition: https://imgur.com/a/oEsxHKq

Nevermind, misplaced. Getting this trying to update from CKAN (I'll post in that forum also). Not sure where the files are dished up from so not sure if CKAN or other problem Error downloading StationPartsExpansionRedux 2.0.5: Ssl error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED at /build/mono-6.12.0.107/external/boringssl/ssl/handshake_client.c:1132

How does MJ determine what the control part is? I have a couple of docked vessels that for some reason the control part is changing when I leave it and make it active again. Is there way to tell MJ which part to make the control part prior to a burn within MJ, or do I have to manually (re)set it on the craft every time I make this craft active?

I'm just focused on loaded part count as being the primary limitation in KSP (maybe a tie with spurious physics) and that approaches that would allow some portions of a craft to be simplified. Maybe something like instead of just packed/unpacked (part availability) and loaded/unloaded (basic craft level info availability) something like a 3rd in-between state where resource processing is simulated but interpart physics is not active. So a "resource only" ghost of the semi loaded craft would need to be dealt with. The resource simulation can be merged with a true catch up when the craft becomes active vessel. Yes, you are correct, it is more complicated than I was thinking, but given KSP2 targeting *very* large bases I think it safe to assume they are doing a lot of things very differently so any assumptions based on KSP1 are not as useful. On a related note, I was reading into the Extraplanetary Launchpads docs and taniwha has a great write up on why bases go kraken involving the root part and gravity bending forces from that part to the rest of the base and what happens when the base becomes active and loads/unpacks. The peripheral parts of the base relative to the root part bend down from gravity into the terrain and cause physics issues during the process. It got me thinking that ISRU bases in particular, when they "catch up" the resource levels, might be throwing another wrench into the works as suddenly the catching up of the fuel levels would drastically alter these bending forces very quickly. So maybe they need an "easing" where the catch-up occurs over a longer span of time, or maybe even after the craft is already loaded, unpacked, and "settled". I don't know that it isn't done this way already. But I mention this because ISRU bases often use a lot of KIS/KAS attachments when refueling tankers and such and might be of interest

Yes, the resources on the unloaded craft works that way on unloaded craft, but one gets notifications from TACLS, for example, that water or oxygen is running low on unloaded craft on rails. I think it uses a predictive algorithm and doesn't really do anything on the unloaded vessel of course. For TACLS it depends on whether you have the settings option "Unloaded Vessel Processing" checked or not. If not checked, then it plays catch up when you make the craft active, if checked then it predicts the resource level changes. The same could be done for an ISRU base, which if it had a pipeline to another site, could give cumulative flow values for the other end of the pipeline when it became active. I think some of these mods rely on a mod called Background Resources. It would need to be an entirely new code construct, no doubt. But not as complicated as it would seem. It would be the same as one big base but with no physics connection. So quite a bit simpler. Just subtracting and adding resources to each end predictively for reporting purposes when they aren't active and playing catch up for either one when it becomes active. Not a KSP 1.x.x thing for sure. Well, maybe, but I'm not asking for that. I suggested it for KSP2 in the forum, not KSP1

Only an appearance of working would need to occur. Much like ISRU bases and TACLs do background resource calculations. Pipelines would work in a similar manner merely reducing the flow to and from the pipeline at the active end to predicted flows. But thanks for answering, appreciated

Is it possible, using KAS/KIS using transfer stations and fuel lines to connect 2 bases beyond load range of each other (2 to 3km) using KAS such that when one is active the other is not loaded, and if so will resources flow between them in this situation? I'm thinking not but I'm trying to think of a way to get a constant fuel flow between my ISRU fuel mining base and an extraplanetary launchpad construction facility without having to deal with a huge part count at one time. For the record, I did put in a suggestion that KSP2 incorporate "pipelines" that would allow such a base interconnection scenario in stock. Fingers crossed