Divstator

I modified some configs for my own use. I made more categories for USI stuff(PackRat, Akita, Malemute, Otter and Karibou. Also put the categories that Roverdude adds to the "Filter by Function" into the USI filter, Konstruction, Kolonization, Logistics, Manufacturing.) Also Added "Payload" to Procedural fairings, so the fairings show up. Added Life Support to KPBS filter. Added a Rover category to the defaults category. Added MKS stuff(including Life Support) to the ISRU default category. Added Kerbal Foundries stuff to the landing gear and rover wheels categories. Added wings, control surface and parachutes to Squad category. Put in a cfg to change the color of the defaults categories. However some of the changes required icon modifications and I am unsure how that is going to apply to "copyright" stuff. Most of the icons were in Squad, but needed to be inverted to "look right". I modified and used some of Roverdude's icons for the default categories and the USI stuff. I don't think he would have a problem with it, but he does need to be credited? I'm not as up to date as I should be with particulars of the icon copyrights as I should be. As far as I can tell, Roverdude's stuff is CC-Share Alike-Non Commercial. I had to do some code pretzeling to reorganize the default categories without modifying the files directly, which added some unusual complication to the cfg files. I did a quick glimpse of previous posts and I didn't see the process of how you wanted the configs shared, assuming that you do. So it kinda boils down to this: Do you want the config files? If so by what means(drop box, git hub, spoiler)? Do you want the configs as they are currently, or modified into a better fit for the FE mod(In their current condition, they have been renamed so that I could reorder the default categories.)? And lastly, I make no guarantees implied or otherwise that they will work as intended, but they seem to behave properly in my own set up...you have been warned. I'm not an experienced professional programmer. On a side note... Thank you for all the work that you do. I probably use most of the mods that you have adopted and my gaming experience would be severely diminished without your hard work...and I live to game. ;).

Is there some way to reorder the default categories other than modifying the files inside the "Default" directory?

Not sure if this is going to be helpful or not... Was having an issue with KIS throwing the checklist out of whack. What I found was, that if there was tool in the inventory of a saved ship, it would properly set that the tool was in the inventory, but any checks past that would fail. Also the settings screen to set whether Wernher would show on VAB entry would not set either. Went back into VAB, removed tool from KIS inventory and all checks succeeded and also the setting for having Wernher open on VAB entry would succeed as well. Kind of behaved like an initialization issue? It seemed once the ModuleKISItemAttachTool was initiated, everything behaved the way it was supposed to. I don't know if ModuleKISItemAttachTool is initiated on vehicle load from save. I checked the output log, but it mostly reflected the KCT issues earlier(I do NOT have KCT installed btw).

I have 5. I was looking through my log file and came upon this line. File 'E:/Games/Kerbal Space Program/KSPx64_1_3_1 - Aviation/GameData/LoadingScreenManager/Plugins/PluginData/LoadingScreenManager/LoadingScreenManager.cfg' does not exist That path is incorrect for my install. The path should be: File 'E:/Games/Kerbal Space Program/KSPx64_1_3_1 - Aviation/GameData/LoadingScreenManager/PluginData/LoadingScreenManager/LoadingScreenManager.cfg' does not exist I just don't know if that line is relevant or not. Well, I tried copy the config file into the path listed above, but it didn't change anything. Thanks anyways for trying to help.

That is the part I can't get to work. I checked the button, but the original loading screens arn't in the rotation as best as I can tell.

Is there a folder I need to specify to get the original loading screens along with the screenshots folder?

Well, I wasn't really pursuing help just yet, which is why there wasn't a log file. I was just kinda tipping my toe in the water of 1.4.2, at least as far as a "modded" 1.4.2 version goes. I couldn't get it to behave on 1.3.1 either though, which is why I asked if it was me or not. I usually run quite a few mods, 100-150 and 1.4.2 was having a lot of issues with many of them. So I deleted that install and decided to just wait for it to mature a bit. Unfortunately, that deleted the log file as well. However I am having the issue on 1.3.1 as well. All were installed via CKAN. I have many installations of KSP and none of them are in the default parent directory(can't cause Steam will overwrite it if I do that). I am running a new game with it installed now and will submit that log file after it loads up(with LSM reinstalled through CKAN). The only pictures I get during load up are those in screenshots folder. I dunno if it has anything to do with it or not, it seems to me you take an educated guess at the length of load time / number of screenshots for display fade in and out to cure the last one from repeating. I have like 5 ss' that display for maybe a minute a piece. due to extensive addons my game takes roughly 5 -10 minutes to load. Make no mistake, I have sliced and diced my install a LOT, so there are bound to be MANY issues with it. Hence why I asked if anyone else was having the problem before I got lost in the black hole that is my install. I will send the link to log file in PM. Also, the logo screen seems to be showing properly as well.

First, let me say thank you for all your hard work(I don't see how you do it myself...that is a LOT of mods to support). Is there something I'm missing? I can't get this to mix and mingle with the default loading screens? I just didn't see any other posts about it and was wondering if I was the only one having trouble with this aspect of it.

Thanks for your hard work, I appreciate it.

I think CKAN's mission scope is too vast, It should be limited to maintenance, conflict and dependency detection. Right now it is maintenance, acquisition, conflict and dependency resolution. Acquisition should be left to the user, so that the instructions are read first. Conflict resolution and dependency resolution should probably be a separate mission altogether(maybe through plugins?). I realize that CKAN is trying to be a repository for KSP, like Linux. But I don't think that is the correct methodology here. Linux is a vast operating system with many subcultures, which is why the repository methodology is probably the best solution for that, it's just not the case for KSP.

You mentioned something about tumbling out of control and I haven't seen it mentioned here yet. You do have SAS turned on correct? Because without it, it is REALLY difficult, to fly smaller craft especially.

I probably should have posted something here that I had solved this. Appologies to both stupid_chris and blnk2007. I did post over in the Sounding Rockets' thread here. Speaking only for myself, I consider this "fix" outside the scope of RealChute because you are essentially modifying the internals of Sounding Rockets to get it to work, which is in Roverdude's arena. He may have internal reasons that he wants that part physicsless. Anyways, my bad, sorry about that guys.

Took me a bit, but I got the parachutes to work with RealChute and FAR. Or they seem to anyways. I changed the NEEDS: to BEFORE:. I modified the diameters to increase drag and kind of help with proper firing of the animations. For PackChute, I had to override the physics less behavior flag, RealChute won't recognize it otherwise. This is not my code, I just modified it.

And the crowd goes wild! :-) Thank you. :-)

Actually I forgot to mention that the "pack" loses it's texture once the chute comes out and it doesn't do that when it's inside the nose cones. @Gaiiden No worries.

Actually, mine looks suspiciously like his. I changed the diameters because in FAR with the "thinner" air, chute drag is almost less than the rocket itself, which causes the rocket to be pointing downward when the chute fully deploys. When that happens the animation makes the chute deploy upside down and then it snaps back once the physics kick in. I used the chute calculator to help me figure out which diameter of chute I needed for my applications, and I was going to post it over in the Sounding Rockets forum once I got the PackChute to working. Unfortunately, I can't get it to work. As far as the config goes, the nose cones work, it's just the Pack chute I can't get to work. I messed with it for like 16 hours yesterday. I'm starting to think it might have something to do with the fact that the pack doesn't have an animation, it doesn't "unpack" as it were, the chute just pops out of it. But nose cones have animations where they split and then the chute comes out. I looked at the pack in Blender and "looks" right, but I have very,VERY little modeling experience. Who knows, I went through the cfg over and over yesterday and if something is wrong with it, it's something that I just can't see. The latest changes to that cfg was to substitue :NEEDS for :FOR before[RealChute]. I "think" that allows you to put the cfg outside the RealChute folder. I know MM will find them anywhere in the game directory, but since it's a modified cfg not done by stupid_chris, it just seemed proper.

Am I the only one that the SR_PackChute_35 doesn't work with this patch?

My assumption, my bad. Tested as you advised, With just the RealChute and Sounding Rockets, it still fails(just the one chute, the nose cone ones still work). Also fails if I run 32 bit(don't know how it worked before, I had brought over a saved ship, but I changed the chute out every time, or at least I thought I did). I've been messing with it for too long now to make any sense of it. I'll try later to see if I can figure out. I'll post if I figure out if it's something I've done wrong.

I just restarted KSP everytime, If that doesn't reload the part database, then , no I did not reload the part database and I will have to research how to accomplish that. The only reason I know it works on the 32 bit version is because I was making a clean install to try and narrow down the cause. When I did the "clean" install, it worked and I thought I had a mod or MM patch walking on each other, then when I started adding back in my mods, it started crashing(because I was running out memory) and that was when I noticed I was running the 32 bit installation. So I restarted my "clean" install and made sure I was running the 64 bit version, and it messed up with just the 3 mods and their dependencies installed. But, like I said, I get the work load thing, I was just concerned that it might be a piece of info that might come in handy.

Interesting. Well, far as I can tell, FAR 15.6.1 is the one he credits you with helping him fix and it's the one on Github. As far as the MM patch goes, it works on the KSP 1.1 32 bit version. <shrug> I thought it would be better to report it than not. I didn't really expect it to be fixed any time soon with the update mania that's going on. Thanks for the mods though. Oh, also I didn't know if it might be a MM bug? I figured you would know better than I, if that were the case though. Thanks for the Mods.

KSP: 1.1 64 bit Problem: Sounding Rockets SR_PackChute_35 parachute doesn't work, it just plummets to the ground. The nose cone chutes work, both the 035 and 625, which is odd because they use pack chute internally. Mods installed: FAR v3:0.15.6.1 Module Manager 2.6.22 Modular Flight Integrator 1.1.3.0 Sounding Rockets 0.4.1.0 USI Tools 0.7.1.0 RealChute v 1.4 Reproduction steps: Build a simple craft with a 0.035 engine, 3 small fins, 0.035 payload truss, avionics package, battery and top off with small pack chute. Launch. Stage until chute opens, be amused as it plummets into the ground. This is the patch I cobbled together: @PART[SR_Nosecone_35]:NEEDS[RealChute] { @category = none @mass = 0.005 !sound_parachute_open !sound_parachute_single !MODULE[ModuleParachute]{} MODULE { name = RealChuteModule caseMass = 0.005 timer = 0 mustGoDown = true cutSpeed = 0.5 spareChutes = 1 PARACHUTE { material = Nylon preDeployedDiameter = 3 deployedDiameter = 12 minIsPressure = false minPressure = 0.1 minDeployment = 6000 deploymentAlt = 600 cutAlt = -1 preDeploymentSpeed = 2 deploymentSpeed = 8 preDeploymentAnimation = PreDeploy deploymentAnimation = Deploy parachuteName = String capName = Cap } } MODULE { name = ProceduralChute } EFFECTS { rcpredeploy { AUDIO { channel = Ship clip = sound_parachute_open volume = 1 } } rcdeploy { AUDIO { channel = Ship clip = sound_parachute_single volume = 1 } } rccut { AUDIO { channel = Ship clip = RealChute/Sounds/sound_parachute_cut volume = 1 } } rcrepack { AUDIO { channel = Ship clip = RealChute/Sounds/sound_parachute_repack volume = 1 } } } } @PART[SR_Nosecone_625]:NEEDS[RealChute] { @category = none @mass = 0.01 !sound_parachute_open !sound_parachute_single !MODULE[ModuleParachute]{} MODULE { name = RealChuteModule caseMass = 0.01 timer = 0 mustGoDown = true cutSpeed = 0.5 spareChutes = 1 PARACHUTE { material = Nylon preDeployedDiameter = 2 deployedDiameter = 20 minIsPressure = false minPressure = 0.1 minDeployment = 6000 deploymentAlt = 600 cutAlt = -1 preDeploymentSpeed = 2 deploymentSpeed = 8 preDeploymentAnimation = PreDeploy deploymentAnimation = Deploy parachuteName = String capName = Cap } } MODULE { name = ProceduralChute } EFFECTS { rcpredeploy { AUDIO { channel = Ship clip = sound_parachute_open volume = 1 } } rcdeploy { AUDIO { channel = Ship clip = sound_parachute_single volume = 1 } } rccut { AUDIO { channel = Ship clip = RealChute/Sounds/sound_parachute_cut volume = 1 } } rcrepack { AUDIO { channel = Ship clip = RealChute/Sounds/sound_parachute_repack volume = 1 } } } } @PART[SR_PackChute_35]:NEEDS[RealChute] { @category = none @mass = 0.005 !sound_parachute_open !sound_parachute_single !MODULE[ModuleParachute]{} MODULE { name = RealChuteModule caseMass = 0.005 timer = 0 mustGoDown = true cutSpeed = 0.5 spareChutes = 1 PARACHUTE { material = Nylon preDeployedDiameter = 3 deployedDiameter = 12 minIsPressure = false minPressure = 0.1 minDeployment = 6000 deploymentAlt = 600 cutAlt = -1 preDeploymentSpeed = 2 deploymentSpeed = 8 preDeploymentAnimation = PreDeploy deploymentAnimation = Deploy parachuteName = String capName = Pack } } MODULE { name = ProceduralChute } EFFECTS { rcpredeploy { AUDIO { channel = Ship clip = sound_parachute_open volume = 1 } } rcdeploy { AUDIO { channel = Ship clip = sound_parachute_single volume = 1 } } rccut { AUDIO { channel = Ship clip = RealChute/Sounds/sound_parachute_cut volume = 1 } } rcrepack { AUDIO { channel = Ship clip = RealChute/Sounds/sound_parachute_repack volume = 1 } } } } NRE after staging chute. Don't know why. Log:https://drive.google.com/file/d/0B4fEVZ0-dHhAbE5nejhDRi1KWms/view?usp=sharing

I'll try to clarify. y'all = modders = mod developers. Wasn't referring to moderators at all. I just meant it as "in general" and not at any specific developer at all. by "exclusionary" I meant veteran mod developers vs newcomers whether they be new players or veteran players and new developers. I don't believe it's intentional. It is sometimes necessary for me to take a step back occasionally as a developer and remember to look through the eyes of someone who is seeing things for the first time. I figure if it's necessary for me to do it, that it might be helpful to remind others to do it? I know that I am guilty of getting caught up in coding and not seeing things clearly sometimes, especially when I have been involved in something for a long time, it's easy to overlook what I take for granted. Plus I don't have the skill set that others do when it comes to dealing with the public (a.k.a. KasperVld). Also I am in no way trying to call anyone out or anything like that. I am very grateful for what all the developers do, which is why I want to see more developers. And yes, pestering developers for updates is the current problem. I was thinking more of "general rules of conduct" kinda thing so that people that are new to not only KSP but gaming in general would understand some of the world that developers have to live in. To understand that developers have to respond publicly to some requests that are frustrating, because the person making those requests either doesn't understand the difficulty, amount of effort involved or the fact that their request is the millionth time it's been answered either in the current thread or hundreds of threads over years worth of development. Also I imagine that KSP is attractive to younger players that don't have the life experience to know that they are expected to read 2 posts above and actually be considerate(which is what I meant by "growing pains"). Perhaps "thrashing" was a poor choice. Yeah, it was a poor choice. Like I said, not the best at dealing with the public. I think I used that word to kind of demonstrate about the added weight of the words that the gifted developers are burdened with, if that makes any sense? Disapproval by someone you respect always carries greater significance than coming from someone you don't. Also, by "fleshed out", I meant something a little less formal than forum rules. by the way @Snark, I hope you didn't take what I said as disapproval, I meant just the opposite. Sorry for the late response, had family things I had to take care and wanted to answer to the best of my ability.

(boldness by me btw) Is this the result you are looking for? This is my first post and normally I wouldn't post. I lurk. I follow the dev threads and the modder's threads to check on the state of things. Not only am I very thankful to both SQUAD and the the modders, I am in awe of them. I'm a pilot(not a jet pilot, single engine land weekend) and I really like how FAR recreates "ground effect" when I am trying to land, it's impressive. I have also wrote mods in the past, mostly assisted on mods for Elder Scrolls stuff. That said, my opinion as an outsider and relatively new player(1100 hours) is this: Modders as well as devs words carry weight. (btw nice job KasperVld, he does his job well I think.) While the devs have KasperVld the modders don't really have a dedicated spokes person that I can see. On the mods that I worked on, thankfully we had a pr person that allowed us to work on coding without being hassled. This, I think is the best approach to fix that. But maybe a little better fleshed out? A little less "commanding"? Because to me y'all are sounding exclusionary, which seems out of character. New players and new modders are going to be ignorant, everyone starts out that way. Best way to fix that is with guidance. Perhaps if you have to school someone, maybe do it through PM first? Giving someone a public thrashing is not really... inspiring? Also if you had a community guide on how to communicate with modders then when someone went astray they could just be directed to the guide without the modder coming off as the heavy, because that's not really fair to somebody who gives so much for very little return. I think a lot of this is growing pains as well. In closing I would like to say that I really admire Ferram, the amount of patience he exhibited for the whole lift debate thread was impressive. However, him trolling his own thread was what got me to press the little yellow button(on a side note, Does the "donate" button have, like an auto "Thanks" mechanism? Might be handy.). That was really funny.