DeliriumTrigger

Hi there, Encountering this when I launch a vessel with the MK1 (all I have access to in my career save). As soon as the flight scene opens there's a beep, then it says something like "[Avionics System ]INITIALIZATION ERROR" and to check the logs. Looking in the player.log I can see where it's configuring props, and where it's throwing the error: MASComponent] Configuration complete in prop #214 (MAS_SwitchFlatPanelShort_CommNet): 1 nodes created (Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35) [MASComponent] Error configuring prop #215 (MAS_Tablo_Status_CommnetConnected) (Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35) [MASComponent] Error in COLOR_SHIFT Panel Color: (Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35) [MASComponent] System.ArgumentException: Invalid or missing 'activeColor' in COLOR_SHIFT Panel Color at AvionicsSystems.MASComponentColorShift..ctor (ConfigNode config, InternalProp prop, AvionicsSystems.MASFlightComputer comp) [0x00399] in <061bdf6ca8a645abb76768298ae3ba16>:0 at AvionicsSystems.MASComponent.CreateAction (ConfigNode config, InternalProp prop, AvionicsSystems.MASFlightComputer comp) [0x002a6] in <061bdf6ca8a645abb76768298ae3ba16>:0 at AvionicsSystems.MASComponent.Start () [0x00062] in <061bdf6ca8a645abb76768298ae3ba16>:0 (Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35) [AvionicsSystems] INITIALIZATION ERROR: Error configuring prop #215 (MAS_Tablo_Status_CommnetConnected) (Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35) [MASComponent] Configuration complete in prop #215 (MAS_Tablo_Status_CommnetConnected): 2 nodes created (Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35) [MASComponent] Configuration complete in prop #216 (MAS_DigitalIndicator_SignalStrength): 4 nodes created (Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35) [MASComponent] Error configuring prop #217 (MAS_Tablo_Status_CommnetNoSignal) (Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35) [MASComponent] Error in COLOR_SHIFT Panel Color: (Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35) [MASComponent] System.ArgumentException: Invalid or missing 'activeColor' in COLOR_SHIFT Panel Color at AvionicsSystems.MASComponentColorShift..ctor (ConfigNode config, InternalProp prop, AvionicsSystems.MASFlightComputer comp) [0x00399] in <061bdf6ca8a645abb76768298ae3ba16>:0 at AvionicsSystems.MASComponent.CreateAction (ConfigNode config, InternalProp prop, AvionicsSystems.MASFlightComputer comp) [0x002a6] in <061bdf6ca8a645abb76768298ae3ba16>:0 at AvionicsSystems.MASComponent.Start () [0x00062] in <061bdf6ca8a645abb76768298ae3ba16>:0 (Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35) [AvionicsSystems] INITIALIZATION ERROR: Error configuring prop #217 (MAS_Tablo_Status_CommnetNoSignal) (Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35) [MASComponent] Configuration complete in prop #217 (MAS_Tablo_Status_CommnetNoSignal): 2 nodes created (Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35) [MASComponent] Configuration complete in prop #218 (MAS_JSIMainCompUnit): 14 nodes created (Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35) Here's a link to the entire player.log if you need it. As far as effects on the game, nothing apparent other than the loud beep every time I launch, though this is my first time installing MAS so I wouldn't be able to recognize something that's obviously broken having nothing to compare it to. If there's anything else you need from me (KSP.log, modlist, whatever) just let me know, I'm happy to provide.

Hi, I have some feedback about RealChutes and suggestions for RealChutes 2, if you're receptive to it. If not, feel free to skip this comment and move right along, as it's just my opinions and observations. There are some things about this mod that I really like. Presets for planets, awesome. More granular control over deployment, awesome. Combo chutes are great, especially the way they're implemented in SDHI Service Module, love it. Drag chutes too. A lot of these things are valuable additions to the game, so I hope you'll consider my feedback as an effort to highlight ways that would make this mod more pleasant to use, and not as me just crapping all over your work. Because I do appreciate it, and the fact that you've taken a sizable portion of your free time to create it and offer it to everyone free of charge, even if it's not currently for me. I want to use it and not be frustrated. I'm frustrated with this mod for the reasons I'll outline below, but I want to present this in as constructive a manner as I can. If some of my frustration comes through and I fall short at being as tactful as I hope to be, I apologize for that. There's no easy way to say "here's stuff I don't like and think should be improved" without saying the "here's stuff I don't like" part. It's not personal or some comment on your abilities as a creator. It's just my experience using this mod as an end user. I find the user experience of this mod to be something I would call hostile in the ergonomic sense. Perhaps this wasn't the case back when the mod was designed, or maybe there are design constraints that I don't know about. But my experience with this mod is that I never go out of my way to install it, and that's a shame, because as I said there's a lot here to like. It gets flagged as a dependency by CKAN, and then I hem and haw over whether I want to deal with RealChutes or go without the mod that depends on it. If it's getting flagged as a dependency for me, then it's happening for others, and presumably at least some people are installing this mod with no understanding of what it actually does: Completely overhauling the expected behavior of parachutes, which in many ways is a good thing, and changing the way you interface with the settings of parachutes to something that throws out established conventions of the KSP user interface, which in many ways is not. And yes, that's on them. RTFM. But this mod offers a lot of awesome stuff, and could be so much better if it just behaved in obvious and convention following ways. It doesn't. As a result, at best it's awkward to use and at worst it's incredibly frustrating. To my point then. The settings for parachutes being in the action groups menu... I can sort of see the logic behind this, since the deployment of a parachute is an action... I guess? And since "Automatically arm parachutes on staging" is a option in the toolbar button on the KSC scene, maybe it's a design choice to have users assigning the arming of parachutes to action groups, which is why it's put in there? Regardless, it is hiding something that is typically found in a context menu in a place that is not obvious and doesn't follow conventions at all. Literally every part in the stock game is configured in the VAB build screen by right clicking directly on the part and using that context menu. And while I haven't used every mod, most if not all of the ones I have used (which is a lot) follow this convention, except RealChutes. If a mod has configuration options that would overwhelm that context menu, there is typically a button on the context menu that you click, and then a new menu opens with the configuration options you need. If including the configuration on the right click context menu is too constraining or not possible due to technical constraints, there is a toolbar right there in the default VAB view where a RealChutes icon could be to open the configuration screen for chutes. It still doesn't follow the convention, but at least it would be a button with a parachute on it in an obvious place that doesn't require you to switch out of build mode. The action groups menu is a menu that many people playing a career mode have no reason to even click on until well beyond the point that they need parachutes, because unless they choose the option to make action groups always available they have to unlock that functionality, and there's little to do in there before that point. And it's just not where you go, in any other context, to do configuration of parts. You configure the parts in the regular VAB build view, and then you go into the action groups menu to assign those parts to hotkeys. Unless you use RealChutes. That the place to configure Realchutes isn't immediately obvious would be a minor problem if it just added separate chutes that rely on this system and left the stock system alone, but it's compounded by the fact that RealChutes completely takes over all parachutes. There is no more stock behavior, only RealChutes. Sometimes that's nice to have, like for drag chutes, or dialing in parachutes to work on Eve. But sometimes you just want an Mk16 to behave like a stock Mk16 without all the extra steps. It would be great if RealChutes were RealChutes and stock chutes were stock chutes. And if that's not possible for technical reasons, then it would be good if the mod tried to emulate default stock behavior on the changed stock parts as closely as possible. The most obvious example of this is that the default behavior of parachutes with RealChutes is installed is to not deploy "when safe" like the stock system. Which in effect means that any parachute in the game that you didn't configure through the aforementioned unconventional method will be ripped off by aero forces if you arm it before entering atmosphere, unless you fiddle with the settings in flight. From a user experience standpoint it has been an endless source of frustration. It just makes way more sense to just have RealChutes default to stock-like behavior, at least on the 'stock' parachutes if the mod is going to take over every parachute in the game. I've been using this mod off and on since 1.2.2 or something like that, and I still forget to go into the action groups menu and configure my parachutes, because this mod is the only mod that makes you go in there to configure it. I forget, and then I arm the Mk16 on a returning science probe before it hits atmosphere because because the antenna could rip off on re-entry, only to watch the parachutes deploy super early and get ripped off by aero forces and all my science go to waste because the Mk16 no longer performs like a stock Mk16. That's fine if I'm playing a game with reverts and quicksaves, but I've had it happen in a hard mode save more than once. I can't be the only one. To call it frustrating would be an understatement, especially when I realize why I forgot. Because the parachute looks stock, but instead of behaving like stock, it's different. To configure it to behave like stock, I have to go to the configuration menu that has decided for whatever reason to throw out over 10 years of established convention and hide in the action groups menu. It doesn't feel like I made a mistake, it feels like I'm being punished for using this mod and not remembering to jump through its odd and counter-intuitive hoops. The OP of this thread says "If you don't want to use the editor panel, you really don't have to. There is a preset system." That's not really true. You do have to find the editor pane and use it to set the presets, so either way you're using the editor panel, which again, is hidden in a non-intuitive place. You can ignore it if you're using the option to arm when staged, or are going to right-click on it in flight and deploy, but you must do this if you need to or prefer to arm your parachutes before entering the atmosphere, unless you want to do it in flight. The editor menu, presets or not, is not simple. It's tedious and time wasting. The presets don't stick so that the next time you grab the same parachute from the parts list and drag it on to a vessel it has the same settings. They don't even stick if you select a preset for a parachute, go back to build, then alt-click the parachute you set up and make a copy of it to put somewhere else, another UX convention that is disregarded. If I could select a preset on the context menu in a similar way to how I select the contents of a tank or a livery, this wouldn't be as much of an issue. Instead I have to go into the action groups menu every single time I place a parachute. Or hope I remember every parachute, including the one on the drone that is nested inside of both a cargo bay and a fairing, when I go into the action groups menu to configure all the parachutes once I'm done building everything. If there are technical obstacles or design decisions in the way of some of these things, I can understand that. But the confluence of all of these things is jarring, off putting, and frustrating to me. Maybe I'm just not the intended audience, and these things are all the design vision, as intended, and if that's the case then that's okay. But I feel like RealChutes would totally be a must-have on my modlist if even some of these things were different. To summarize, the changes I'm suggesting for the next version of RealChutes: Make the CKAN description, well, more descriptive. It says your mod "fixes a few inconveniences" and also "completely reworks" the stock parachute system. These two statements are at odds with each other. When I read "Fixes a few inconveniences" I think small changes. When I read "Complete rework" I think big changes. This mod makes big changes. Sure, it does fix a few inconveniences, but putting that in the description is almost a red herring. People installing a mod that changes this much stuff should know what they're getting into. Managing expectations matters. Follow established KSP UX conventions wherever possible and move configuration of parachutes to the context menu, or a submenu that can be opened from the context menu. At the very least put the basics there (min pressure/altitude) like stock does. If the above is not possible for technical reasons, at least put the configuration in an obvious place, like in a menu that pops up when you click on a parachute icon on the toolbar while in the Build menu, where you are when you configure everything else. Not hidden in the Action Groups Menu where literally no other part in the game is configured, so that you must go outside of the game and read a forum post to figure out where it is. Make RealChutes an add-on, with complete replacement of the stock parachute system opt-in, so that you can choose a RealChute in the size you need if you actually want the extra options that RealChute provides, or a boring old stock Mk16 if you just want boring old stock behavior without having to configure stuff. If the above is not possible for technical reasons, then make the default behavior of all the RealChute-changed stock parachutes like the Mk16 as close to stock as possible, without requiring the user to change a preset. Meaning they default to deploy "when safe" like stock when armed, min pressure at 0.04atm instead of 0.01atm, and altitude at 1000m instead of 700m. Allow users to choose a preset and have it stay as the default, or copy a configured parachute and have the settings copied as well. If I'm using 6 parachutes on 3 stages that are all going to be dropped in Kerbin's atmosphere during the launch sequence, having to configure each parachute individually is unnecessary tedium. If you've read all of this and given it fair consideration, even if you disagree with it in whole or in part, I thank you for your time. I'm looking forward to RealChutes 2 and hope to include it in my modlist. Thanks.

Yeah, installing that puts the DLL in the folder. Thanks.

To be clear, what I'm doing to install: Open CKAN on a clean instance of KSP 1.12.3 w/ all DLC Mark 1.12.* as compatible Check mark to install Vessel Viewer Continued, version 0.8.8.5, Max game version 1.12.2, which is the latest version available on CKAN Choose to Install ASET Props as suggested by CKAN Choose VesselView-UI-RasterPropMonitor when CKAN says "Module VesselView-UI is provided by more than one available module, please choose one of the following mods" To reproduce the error, I just throw a MK1 on top of an SRB and launch. I just cleared the vessel viewer download from the CKAN cache and reinstalled Vessel Viewer on the off chance that the package I downloaded was messed up in some way, but that wasn't the problem. Here are the contents of the plugins directory inside of the Vessel Viewer package that CKAN installs into Gamedata (sorry about the big picture, 4k monitor): As you can see, the plugin isn't there. Edit: Here is the player.log, sorry, took me a minute to find

you know, thats the one graphics related mod in my list that sticks out to me as one that i haven't combined with others a bunch of times before. i doubt its the source of all my issues, but considering most of what im dealing with are graphical glitches, it's worth looking into. thanks!

Okay, if you're curious you're welcome to it. If anything else leaps out at you as obviously screwed up let me know, I could use all the help I can get figuring out what's causing all of my problems. Here you go.

Isn't that what this option is for?

Honestly with all the other issues I've been having with that particular install, I'm reluctant to send you on a quest to solve a problem that may not even be related to TURD. IDK what's wrong with this particular combination of mods that I've got, but something is catastrophically broken and it's showing up in all kinds of different ways. In any case, I found that if I just apply the color settings and launch, the part appears as normal in the flight scene.

Hi @linuxgurugamer, While diagnosing some issues (serious, numerous, frustrating issues) with my modlist with @JonnyOThanon the /r/KSP discord, we came across this in my logs. 106989 [EXC 14:55:44.928] FileNotFoundException: Could not load file or assembly 'VesselViewPlugin, Version=0.8.8.5, Culture=neutral, PublicKeyToken=null' or one of its dependencies. I'm not really sure if it's an issue or expected behavior, since I've never actually had a problem with Vessel Viewer that I know of. I was able to reproduce the error with a clean KSP install with nothing but Vessel Viewer, VesselView-UI-RasterPropMonitor and the CKAN auto-grabbed dependencies. Jonny said on the discord to report it if I could reproduce it without all the other stuff installed since failing to load assemblies is usually "real bad", so here I am. Here's a link to the KSP.log from the clean install.

nevermind, saw the download link

Been encountering an odd issue with the material science bay. [LOG 13:08:24.302] science.module added to ship - part count: 20 [LOG 13:08:24.419] ERROR: Could not locate TextureSet for MODEL_SHADER from global cache for the input name of: [LOG 13:08:24.419] ERROR: Could not locate TextureSet for MODEL_SHADER from global cache for the input name of: [LOG 13:08:24.419] ERROR: Could not locate TextureSet for MODEL_SHADER from global cache for the input name of: and this is what it looks like when i try to switch the color

yeah, if you install it along side restock it will still let you recolor some plane/wing parts, etc. That said, the end results tend to look better when you can recolor everything, and aside from a few exceptions I think most of the stock parts with recoloring look as good or better than restock.

Created a patch for the TETRIX tree adding support for the ALCOR pod and included camera, figured I'd share it here for anyone that wants to use it, or for you @theJesuit if you want to integrate it. Based the tree placement off the already existing M.E.M. capsule and the HullcamVDS booster cam placement. // ============================================================ // *** ALCOR @PART[ALCOR_LanderCapsule]:NEEDS[ASET/ALCOR_LanderCapsule] { @TechRequired = heavyLanding } @PART[ExtCamRadialVErt]:NEEDS[ASET/ExtCamRadialVert] { @TechRequired = basicScience }

I know this is a couple of weeks years old by now, but another mod that hasn't been mentioned yet is SSTULabs. Lots of nice station parts in there, among other things. The parts are designed to be very tweakable in terms of size and appearance and many of them have toggles to integrate common additions like RCS or Solar panels to cut down on part count.

Thanks so much!!

Thanks a bunch!

It just stages as though you're not using GravityTurn at all. One of the main reasons I use GravityTurn is so that I can focus on camera angles and scene composition. Unfortunately if I want to capture a nice scene of the sparks firing, then the main engine and finally the clamps releasing when using Modular Launch Systems I need to also be ready to control the rocket once it leaves the pad. Which is fine, I can quicksave, record, launch, get the shot I want and then reload and launch with GravityTurn to focus on shots once it's cleared the pad and just make it look seamless in editing. But it would be so much simpler and a lot less time consuming if I could just hit a keybind and only have to focus on the camera after that. If I knew anything about programming I would dig around in the source and submit a PR, but unless its a CNC mill and G-code I'm completely lost in that regard, hence the request.

Hi @linuxgurugamer, I have a feature request. I'm sure you have a full plate so if you can't do it I completely understand. However, if you find yourself with a bit of free time, if you could add a keybind feature so that you can start a GravityTurn launch without having the HUD up, that would be awesome for taking screenshots and capturing video.

Anyone got a USI-LS patch for this?

Okay, so I installed this from the gitlab repo, dragging the KSRSS folder into gamedata, then installed Kopernicus from CKAN, then manually installed EVE and Scatterer since CKAN forces you to download config files for them. Did as the first post suggested, deleted settings.cfg, started the game. No clouds on earth on the loading screen. Selected the texture settings in the window that popped up, saved, restarted, still no clouds Here is a link to my latest KSP log. Not sure what the problem is but any help fixing it would be appreciated. Edit: If this is normal and the clouds will show up once I actually start a game then disregard. Every time they don't show up on the main menu they typically don't show up in game either but i didn't actually check yet. Edit2: Ok the clouds actually load once you get into the game. I am dumb. Disregard.

ah okay, thank you

That's just a link to the gitlab, which I already checked. The releases page only has 0.61 and under. Or am I supposed to download the repo?

Where exactly is this 0.7 beta? I looked on gitlab but only 0.61 and under are listed under releases.

I see. Well, thank you for looking into it. The mod certainly works without CTT, since I removed it and have been using it without. I installed it through CKAN and just deleted the CTT directory since my modlist is basically complete and I have no intentions of installing anything else that has CTT as a dependency. I did drop a line in the IFS thread so hopefully @FreeThinkercan chime in and clear things up. If there isn't an actual need by the mod for CTT to be installed it just seems unnecessary to have it as a bundled dependency, since a modded tech tree is (as far as I can tell) completely unrelated to the purpose of a mod that lets you change tank fuel types.

Not sure if this is the right place for this, I also posted this in the Interstellar Fuel Switch thread, but that mod is set in CKAN to depend on Community Tech Tree even though it isn't actually required or listed as a dependency in the forum thread. If you want to play without CTT but also use IFS, then you have to install it manually. Would be nice if the dependency were removed since having to install a modded tech tree with a bunch of empty nodes is pretty unnecessary for people like me who are playing with a mostly stock parts list.