darthgently

CKAN told me there was an update available for bleeding edge, when I went to update a new dependency was displayed and I had to install it before the bleeding edge update would install. I'm sorry, I can't recall the new dependency but I'm thinking this is likely what you were up against. Installing via CKAN will likely fix your issue, though it may involve circling back for the dependency as I had to do

Or a more expensive version of the same reactor that has built in capacitors to handle big instantaneous loads. My question would be is how fast can a fission reactor really "throttle"? I think it may be on the order of minutes if not hours, not sure though

Deleting ModuleManager.ConfigCache cured the entire situation for both the CKAN an BETA versions. Sure everyone knew about deleting that. Everyone but me. But now I am an Informed Individual. So the take home for linuxgurugamer is that the next time someone comes on here raving that they are getting protected memory violations on linux he can 3 word them: try deleting ModuleManager.ConfigCache

In the real (future) world the undeployed power tx antenna would have exploded from massive VSWR! You came out of it ok, so be happy, lol [here I am giving Aniruddh ideas of how to handle sending Gigawatts to an undeployed antenna]

.

When I delete all the part configs from the mod but the one I need to load my game, the game loads fine. So my little problem is solved. But in the interest of solving the more general issue I've written a script to delete one cfg at a time from the Parts folder and loop until the game loads. So I should be able to tell you which part is causing the problem. None of the odd filenames was the problem.

@linuxgurugamer, the BETA version from here gives me the same mmap (PROT_NONE) protected memory hard crash during mod load as the CKAN version of Kerbalized SpaceX. I'm running 1.10.1 on debian. There are no logs to present as it crashes hard with the the 'mmap (PROT_NONE)' as the only output on the command line. KSP.log gets randomly truncated depending on the flush status, but never any info leading into the crash. I noticed that the Parts subfolder in the mod has some filenames that look unintentional, like someone was in the middle of working on the code and left some things lying around. I don't know how sensitive the load process is to filenames like 'foobar - Copy (1).cfg' and such. And if there were something causing crashes on linux but not on windows filename format would be a shiny candidate. idk. I figured out how to use environment variables to get the KSP mono runtime to log some stuff to syslog so I'll be going down that path sometime today or this eve and will happily share the results. But it is black and white at this point that when I include this mod, from CKAN or BETA from here, I get the memory violation nearly every time. Not sure why it doesn't happen every time. A race condition of some variety maybe

@linuxgurugamer, is there a plan to get this on CKAN soon? I tend to stick with CKAN and I've narrowed a memory violation during loading to the old version of this mod on ckan and am hoping this one will do the trick. Basically, on linux, I get an mmap (PROT_NONE) mem violation during loading of another mod but I traced the problem to this mod (older ver on ckan) that depends on that mod. I PM'd you and this message corrects some assumptions I was about to go with there until I dug deeper. I think I will install this and see what it does

No, you can't KAS fix a normal strut. There is a mod called EVA Strut with a single part that is about the same thing as a normal strut but a Kerb can install, uninstall, reinstall it on EVA. So I thought that might have been what you were referring to. Actually, an Engineer can "detatch" a normal strut with a drill (maybe the wrench, not sure) if it is in your way. And on third thought, there is one other thing a Kerb could do to a normal strut and that is blow it up with K4 which is part of KIS/KAS (KIS pretty sure). Make sure you get the blast radius right

Do you mean a regular strut? If so you could have a kerbal detach it and replace it with an EVA strut if you have one on hand or can get one delivered. Regular struts cannot be fixed. But I'm not sure I know what you mean

No app button. All dependencies installed. I'll give it a few days. This would not be the first mod whose button was shy about showing in the menus/toolbars. It seems to be more a toolbar/menu/ksp thing than a mod thing ...[a few minutes later] restarted for another mod and now button is showing. All is good

I get quite a bit done with drones using strategically placed Clamp-O-Tron Jrs and the small grabber, but yeah, it would be nice to be able to attach things without having to be able to see the future enough to have put a docking port there. I put all my big comm dishes on with docking ports so I can move them to other ships as needed for example. I also put small/cheap RCS blocks on all assemblies from Mobile Science Labs on up even if the don't have cores and such. When I move them around with my small tugs, the extra RCS blocks really help out. I put clampotron jr ports on all those things mostly to have a way to get a tug on them easy

Are the Procedural Fairing Bases from "Keramzit Engineering" from this mod? If so, is there a way to get more space between the multiple payload nodes? I've tried just attaching things then offset them up but then they fail to have a decouple option in flight

I'm haunted by visions of huge arrays of modular hexagonal orbital mirrors for amplifying and diverting sunlight into power receiving PVs and to farms in pressurized greenhouses on Dres. Is this mod's future plans beaming these visions into my skull?

To keep things simple I like to stick to CKAN for installing mods. But this mod is very interesting. Are there plans to CKAN it?

Ok, so it must be Not Quite Near Future, but a little bit Further in the Future. ha ha. Orbital mirrors are also proposed for farms and such in pressurized greenhouses out where the sun is dimmer, and getting sunshine where it normally doesn't go or getting it more focused to do heavier work

Ok. I'd guess it would cool the tank to some degree in the real world, but maybe not significantly

I want to keep a a kOS vessel on the grounds at KSP to act as a kOS comm hub so miners can report in their current tonnage, scanners their current scan progress whenever their ships are active. I know I can tell KSP not to "clean up" craft around KSP, but I recall there being some mechanism in SR that will recover vessels left on the ground. Is this factual? If so, can I turn it off?

How does heat management interrelate with cryo fuels and boiloff rate?

Are there any plans in NFT to implement orbital mirrors to power PVs on the dark side all night long? Just curious

First thing, the HullCam keys are activated when typing into in game kOS terminals. I can remap the keys but I figured I'd mention it because the terminal doesn't seem to have this issue with other mods key mappings so maybe HullCam is reading keys on too raw of a layer or something, like directly from the device. I think it must be fairly low level because both underscore and minus (same physical key) cycles the cams. There is probably a more elegant way to get that done in the swap meet environment of KSP and all the mods moshing for user input Secondly, what is the syntax of the keymappings in the HullCam settings file? I want to move the cam cycle keys to the number pad for now.

FYI, the GOEVA doesn't work for Kerbs in Command Seats, because KSP considers them to be kind of already on EVA, but then again, they aren't because they show up in the crew portraits and not as an EVA in target filtering. Anyway, I was able to get to the Kerb in a command seat via kOS by looking at Command Seats that had a child node, then using the KerbalEVA module PAW doaction 'leave seat' option that is there when they are in a Command Seat. I mention it because a similar thing could probably be added to the GOEVA fn in C# I imagine, or maybe a more direct way. There is probably a way to make sure that the name matches the one in the CREWMEMBER record but I didn't go that far yet

Suggestions that would make this mod rock even more than it already does. This is mostly related to fuel transfers between ships: 1) Optionally display ship name instead of ship id, and/or optionally display ship name instead of resource part name 2) Optionally concatenate kos tags of part onto part names if part names are to be displayed 3) This is the big one in my view: for any given ship id or ship name be able to flag it as a resource supply vehicle or a resource consumer vehicle. The default would be whatever it was slotted as last time TFB had a category set for it based on ship persistent id under the hood. Then have a one button click action that tops up all resources on the consumer vehicles from the supply vehicles amongst all the craft that may be rafted up together. Users can lock the tanks of "bingo fuel" tanks on the supply vehicles to keep the supply ship from being bled dry, or TFB could optionally do that (after topping up the supply bingo fuel tanks first) based on tag names of the tanks or something. This would, in my case, turn a typical 30 minute laggy eye-roller (one click per 3 second tops; often only every 10 seconds or so) in a 5+ ship raft-up for refueling purposes into a 5 minute operation at most Merely suggestions, but I'm guessing it would be appreciated by a lot more people than just me once it got into use

Once in a while, I'll build a procedural fairing and the fairing sections will start falling off at launch or during flight. The exact same design will usually be fine when I redo it in the editor. How can I avoid this happening? I keep AOA withing 5 degrees of prograde, I keep max Q down below 18000, I've tried strutting them to the payload, I've verified that no RCS is active in the fairing, I've set autostrut on the entire craft, I've verified that none of the payload is touching the fairing. Falling off in flight is to be expected if going to fast in thick air or shifting payload etc, but these are falling off the moment I launch. Like just the shock of the launch clamps releasing is knocking them loose. This is my 6th attempt to launch a simple resupply mission to LKO and the fairing issue is making it very tedious. And no, I don't have the fairing staged with the launch clamps, lol. 1st thing I checked

What are the conditions under which ZeroMiniAVC would fail to prune a MiniAVC.dll file? I found some strays in the KIS and KAS subdirs and manually moved them to .pruned status