vossiewulf

Any known issues with Landing Guidance in the latest version? I've tried it a few times lately and he hasn't come close to anything approaching a landing. All of them were attempts from a MJ-circularized orbit of >20km. I've used it in the past with those parameters, it used to nail landings, right now it looks like MJ is chugging a fifth of mechano-whiskey before giving it a go. If it's not a known issue I'll pull together the required info.

I still can't explain the difference between the dead on and the missed by a little results, but I went back and looked at the one that missed by quite a bit, and found the answer. It was a two-part ship, a booster built in space docked to a forward section lifted from the ground, the reason being that my station frequently krakens when releasing large, long ships. The booster sections are designed to handle all Dv requirements of getting the forward section into the target orbit. The downside is the game thinks the docked ships are a ship and a random mass attached, it doesn't see the engines and fuel on the forward section. And in the case of the one that missed, I miscalculated the Dv requirements so using all of its Dv it was falling somewhat short of Duna. So that's a game issue, not an Astrogator issue. When I activate the decoupler that drops the booster section along with both halves of the docking couplers that held them together, the forward section will know nothing about maneuver nodes set for the booster section.

I have been wondering why Astrogator sometimes nails the SOI of the target, but usually misses by a little, and sometimes (rarely) by a lot. Note I'm talking about vehicles all launched from LKOish (no higher than 200k) orbits that have been circularized by MJ- I always make sure the starting conditions are optimal for the calc. For example I just launched a five-ship fleet to Duna, one was SOI on first maneuver set, three were close enough that some mid-course burn fiddling got them to SOI without difficulty, but one was just wrong, falling visibly short of Duna's orbit and killing the node and resetting it made no difference, he required some significant node surgery. So I'm wondering if there's something I'm missing or something I can do to make the accuracy more consistently, well, accurate. At the moment I can't see the difference in the starting conditions that would lead to the variability, but maybe this is also just as accurate as it gets within this game engine and there's nothing else I can do. Even with that niggle though, Astrogator is extremely useful and I wouldn't enter a KSP game without it.

Hey LG, I just upgraded to 1.4.5, running x64 KSP on Win 10, and all used decals have exploded to like 10,000% size, much bigger than the rockets they're on. And they're causing collider krakening that is destroying said rockets. I seem to be running the latest version: [LOG 21:04:56.209] MiniAVC -> Identical remote version found: Using remote version information only. [LOG 21:04:56.209] MiniAVC -> https://raw.githubusercontent.com/linuxgurugamer/NEBULA_Decals/master/NEBULA_Decals.version NAME: NEBULA_DecalsContinued URL: https://raw.githubusercontent.com/linuxgurugamer/NEBULA_Decals/master/NEBULA_Decals.version DOWNLOAD: http://spacedock.info/mod/613/NEBULA_Decals GITHUB: linuxgurugamer/NEBULA_Decals LatestRelease: 0.1.2 AllowPreRelease: False VERSION: 0.1.2 KSP_VERSION: 1.3.1 KSP_VERSION_MIN: 1.3.1 KSP_VERSION_MAX: 1.4.99 CompatibleKspVersion: False CompatibleKspVersionMin: True Only errors I see are these: [LOG 21:12:41.771] PartLoader: Compiling Part 'NEBULA/decals/config1x2/Long decal 1x2' [ERR 21:12:41.774] PartCompiler: Cannot replace texture as cannot find texture 'decal' to replace At the same time I upgraded to 1.4.5, I installed Scatterer/EVE/Kopernicus/SVT. Is there any incompatibility with those mods? Not sure how, since they're just decals, but something made them way the hell bigger. As you can see from the editor screenshot below, the default size is now 20m.

Thanks, I'll look at SmartRCS. And the idea of using MJ to stabilize the station is something I've never thought of, I've always just left RCS and SAS on, and I've never looked at SmartASS for alignment. And yes the Rendezvous Autopilot very rarely if ever leaves the relative velocity at zero, and it certainly doesn't help when you want to move the docking ship to a specific location and then park it relative to the station. I just had a need to expand my station by adding a 2.5m docking hub and because I can't ever do anything the easy way that meant lining up a 150 ton ship with an existing module and then parking it exactly 3m from the existing module with absolutely zero relative motion, so an engineer could EVA and take a 2,5m docking port off the front of the ship and attach it to the existing module. I did it on the first try, but it really wasn't easy and was only possible because I've spent a bunch of time manually docking big things in orbit. Newer players wouldn't have a chance of doing something like that.

When using the docking autopilot, one of the things I wish I had was a button that paused the docking and left the docking ship at zero relative motion to the target ship. I've had cases where I need to have engineers EVA and do some things before docking, and cases where I just wanted to park a ship near the station for a while (like a case where I built half of a mission vehicle in orbit and lifted the lighter half, and docked them once the orbital building was done). A nice zero relative motion button would be something I think many people would find useful.

And the answer is yes, yes you can replace the DOS LAB core of an 11-module, 229 ton space station with a DOS HAB unit. I took it as a challenge. The only problem was that I didn't notice that those jerks Jeb and Bob and Bill had snuck aboard the HAB when I wasn't looking. The DOS modules I had to manual dock, the rest I just got close and then turned over to MJ to make sure of the rotation. I have no issues docking manually, but I have a hard time getting that lined up and getting the rotation right.

You're right, it works when it knows it has data. I did a crew report which was 0 value but apparently processing it offered 30 science points so I did that and they are now sciencing on that data. So the question would be why do the guys in the science lab not know they have science data when it's transmitted to them. It's not like that transmission fails, it's received and can be retransmitted to KSC so some part of the LAB knows that data is there.

If you mean did I run regular science experiments like magnetometer data, no, sending up science bits on a station in LKO where I've already scienced space to death doesn't result in any useful science data. The plan was simply to transmit data to it from experiments run elsewhere, I've done that in the past with the Station Science mod, its basic science module can process data from local experiments or those transmitted to it. Honestly I thought there was no difference from the science module's standpoint, they have a data queue and they shouldn't care where the data came from.

Thanks for the clarification, I understand now.

Not sure where you saw a particular experiment, the ones I was trying to run were all orbital as an option; this module just doesn't work at all because WBI won't talk to it as it's not on the parts whitelist. I'll go back and try the additional config changes to see if that fixes it for the sake of other people who may need a workaround, but I solved it by skipping back to before I launched the Holukani OWS and switched it out for a Bigby OWS, which is basically identical in size and function. However there's yet another problem in that there seems to be a general issue with finalizing WBI experiments, as in you can't. The Review Data button does nothing, have tested it with the Bigby as well as the Pathfinder Doc Science. So I need to report that in the WBI thread but am still stuck.

Researchkits are part of WBI's science system that is closely integrated with the WBI Extraplanetary Launchpads functionality. I forgot that your LAB doesn't use them. I have a different science workshop on the station that does. But to be clear, all I did with the LAB was hit the Start Research button, and it was manned with one two-star and two one-star scientists, and in a few weeks in orbit they've produced zero science. WBI's science workshops all require researchkits, and since I have one of those on the station also I have a few thousand researchkits available. Also 22k rocketparts with the EL orbital workshop and an orbital building dock. Here's the mod ecosystem, I think it's pretty mainstream and I've tried to cut much back on where I was before.

The mod is DMagic's Science Relay, one of his modlets. It seems required to me if you're going to have orbital/Mun-Minmus-other planets bases with mobile processing labs, they need data to work and this is the only method I know of being able to choose whether you transmit data to KSC or to a lab for processing into much more science. You could be right. But the reason I think it's the LAB is that none of the science functions are working. I have plenty of researchkits on hand, and turned on research as soon as it was in orbit, and it's produced exactly zero science, there has been no science to transmit at all. It's WBI that hard codes a valid parts list, if you ever decide to try to integrate with his science APIs, be aware that your stuff won't work unless he modifies his configs to accept your parts as valid WBI workshops. I found this out when I sent up BDB's Holukani-OWS Orbital Workshop only to find that nothing worked and when I looked in WBI's configs I found this hard-coded list and that part wasn't listed. I had to go back in time quite a bit and replace that with the nearly identical Bigby Orbital Workshop that does exist in the WBI hard-coded list.

Back again, this problem is a real problem for me at the moment What happens is the LAB intercepts all data sent to the station, and some part of it knows it has data because that data can be retransmitted to KSC, but the science part of the lab thinks there is no data. Further, the WBI workshops that have a "grab data" function say that the LAB has no data even though it does- I was hoping that by adding a Bigby workshop I could just have it grab the data from the LAB but no go. The problem is that I made the LAB the core of the station, with a 1.25 hub on one end and a 2.5m hub on the other. To fix this myself, my only option is to detach 8 modules that are attached to the LAB and then reattach them all to say a HAB unit with the proper hubs on each end. It's technically feasible, but detaching 8 modules, three of which weigh 30t+, getting them to stop at relative rest to each other, and then redocking all of them to a new central hub is probably not going to be fun.

I've built and rebuilt entire Buffalo rovers on the Mun and Minmus. It's not super fun, it's tricky and I decided this time around I was going to seriously avoid on-site assembly. Once you get rocketparts production online there's no real reason not to build completed versions via your pad.

I forgot this forum auto-resizes images, here's a link to the full size version on Imgur. https://i.imgur.com/g7FBF90.png This miraculously cleared up on its own. I went back to KSC, came back to Mun base and suddenly the EL pad says we have a productivity of 5.97. Since I never moved the engineer Kerbals from the Hacienda workshop, I have no idea why it showed zero until I left and came back, something not initializing correctly I assume. A test would be to put a couple engineers in a Hacienda and then inflate a Pathfinder disposable launchpad, then open the pad's UI right away and see what the productivity says. If it's zero, time to start looking for what required variable isn't getting told there's a Kerbaled workshop attached to the pad.

FYI, the Hokulani-OWS Orbital Workshop is not recognized as a valid workshop by Wild Blue and therefore can't run the experiments and functions it was designed to run. I'm having to replace it in orbit now as even adding it to the Wild Blue configs doesn't seem to fix it. From Wild Blue Industries/MOLE/ExperimentResults/BaseandStationBuilding.cfg: //Percent chance that an experiment will be successful. //The dice are rolled after all other conditions are met. // chanceOfSuccess = 65 //Cost of the experiment (does not include resource costs) // cost = //Parts required to run the experiment requiredPart = Mark One Habitat requiredPart = Mark One Botany Lab requiredPart = Ponderosa IHM requiredPart = Casa IHM requiredPart = Chuckwagon IMW requiredPart = M.O.L.E. requiredPart = LDEF Science Processor requiredPart = Bigby Orbital Workshop requiredPart = D2 Centrifuge requiredPart = D2 Science Module requiredPart = GondoLab requiredPart = Doc Science Lab requiredPart = Tranquility Mk2 Habitat

Mage, I'm having a problem with the science part of the DOS LAB. I'm using that mod that allows you to send science data to any existing mobile processing lab, and I sent a bunch of science data to the DOS LAB, and a bunch went to my Mun Pathfinder base where I have a Doc Science lab. In the latter case, it worked fine, turn on research and they're churning away on turning that science data into more science data. However when I checked the DOS LAB, even though research was turned on, the UI said that the lab had 0 data and 0 science, but when I hit the Transmit Data button, all that science I had sent to the station was sent to KSC. So it received the data and some part of it knew it had data, but the science lab didn't see that data and didn't do any research on it. Can you check to see if there is a problem there?

Did you see this one Angel? I think this is Buffalo, not EL - the Buffalo ISRU seems broken, no matter what I do it says there are no converters for the Universal Converter configuration. I've looked through the log, I don't see anything that looks linked to this. Demonstration:

Ok, I didn't know if this was behavior you set up for the disposable launchpad. I've canceled builds on regular EL launchpads before without a problem. I'll ask over there, although not seeing many answers in that thread.

Sorry Angel, using this all right now and keep hitting problems. Building my mining rover went fine (except for the ISRU issue) until I realized that in a moment of inspired genius I had installed the Buffalo drills upside down. I must have been going for those newfangled atmospheric mining techniques. Anyway I skipped back to a save while the build was in progress, and hit cancel in the build UI. Something then exploded and my viewpoint shifted to underground (all I could see is sky) and the camera wouldn't move at all. So I went back to a save even earlier in the build, when it had just started. I hit cancel again, same explosion, same stuck camera position. You'll forgive me if I avoid canceling a build with the disposable launchpad. Does the launchpad destroy itself if you cancel the build? If so it seems there is some collateral damage.

I came back a day or two later and it said they had a productivity of 5.76. I have no clue why it was zero or why it's 5.76 now. Next issue - I built my Buffalo mining vehicle, and am trying to configure the ISRU. First thing that looked unusual was that the three buttons were blank, no graphic on them for the different configuration options. I choose Universal Converter and click Reconfigure twice to confirm, and nothing happens. Clicking on Converters says this configuration has no converters. I've done this before quite a few times so I don't think I'm forgetting anything, this looks like a bug. That said I don't see any exceptions or errors in the log that look relevant.

And after a few years, we spin off to Seaquest: Enceladus where we find that 500 million years ago, a long-lost race of advanced and peaceful sentient invertebrates on Europa somehow found a way to send an colony expedition to Enceladus, where they discovered a whole new global aquatic ecosystem. But something in that ocean changed them, and like Spock with a goatee they became the evil twins, ruling the life in Enceladus' ocean with an iron tentacle. And our arrival teaches them what machines are needed to travel through space to find new oceans. And that's how the First Interplanetary Oceanic War started, with the sentient species of Europa and Earth vs. the invasion of ravenous oceanic super-predators from Enceladus. You think Megaladon is scary? Wait until you see the horrors that the incredibly skilled genetic manipulation of the Enceladusians can set free...

What somebody needs to make is a series called Seaquest: Europa. With good creative minds behind it that could be very spiffy.

I'm not saying it's Pathfinder as I just don't know what the scoop is, but if you're saying the engineers are too stupid, well, one is pretty stupid but the other is competent. And compare that to the one competent two-star and one stupid zero-star I have in my space station EL workshop, they have a reasonable productivity. It seems to me the two on the Mun are roughly equivalent to the space station duo, so I'm not seeing this as the cause. Are you sure no recent changes could have resulted in the Hacienda not registering properly as a fully-equipped EL workshop? As far as I know, it's the Hacienda I need to staff for EL building.