akardam

For what it's worth, it appears that while RedShell is gone from v1.4.4, UnityEngine.Analytics.dll is still included, and the game still tried to make a request to "config.uca.cloud.unity3d.com" upon startup (baked into the main KSP exe according to ./strings). So, continuing to run KSP behind an outbound-blocking firewall would probably be the best course for now.

Being the curiousity-killed-the-cat type, I did a little poking about. It appears that the RedShell facility is used to gather, among other things, information on when a user starts (and completes) a tutorial mission, what language the game is launched with, if one or more mods are present, and if Making History (specifically) is installed. Interesting that they're doing it, though for the moment I feel inclined to refrain from speculating on *why*, exactly... I agree with others in this thread that blocking things with a firewall (of some type) is probably the least of evils at this point - still lets you play the game without worrying (much) about the tracking and analytics shenanigans. My gaming rig is behind a hardware firewall which blocks all outbound attempts at my hardware firewall, but for what it's worth and for good measure I deleted both the UnityEngine.Analytics and RedShellSDK DLLs (as others have pointed out you can do), and the game seems to run without them. Nice for all this to come down right when I got motivated to get into the mod-making scene... *grumble !@#$% moan*

Brief update: For the moment I've set aside the idea of re-skinning the DSKY, as the existing texture use does not lend itself to what I want to do - I'd have to redo the model as well, and perhaps recreate/expand the keypad texture (and my Blender-fu could be described as sub-amateur at best). So, for the moment, my goal is for the initial release to utilize RPM, and look at starting to partially/fully convert it to MAS sometime down the road. This summer is turning out to be quite busy with work and travel, so please bear with me. I'll work on getting an initial release ASAP.

Thanks for looking into this.

Anybody else having issues with the VSR large 2.5m hub (Extra-Large Rockomax HubMax Multi-Point Connector)? Had a 1.25m Clamp-O-Tron attached directly to one face of the hub, and a ship docked to it. When I went to undock the ship was pushed backwards (really more went flying away) from the hub at about 5 meters per second. Arr, there the Kraken blows! After doing a little playing around with a Kerbal, it seems that at least in flight, the collider is behaving oddly. If I have a Kerbal on EVA fly into one of the facets of the cube, he bounces off about 1/3 of a meter (give or take) from the visible surface of the facet. The VSR model for the stock 1.25m multi-point connector does not seem to exhibit this behavior. Urrr?

OK, OK... I surrender! I'll seriously consider MAS :) In the mean time... I have a breaker-controlled FDAI and associated controls! w00t. Now to bang my head on the DSKY a bit (whoops, Program Alarm!) In the mean time, with the news of Al Bean's passing, and it having been Memorial Day weekend and all, I decided to combine some IVA testing with a trip up to Skylab, in tribute. Original-res image: https://i.imgur.com/JcBEn1h.jpg Al Bean was one of my favorite astronauts, and was the commander of the second manned Skylab mission (confusingly sometimes referred to as Skylab 3). For those that are curious, my Skylab (and Apollo craft) use parts mainly from Ven's Stock Revamp, and R&S Capsuledyne (aka Taurus HCV - I find the 3.75m science lab and crew can make a great Skylab body), with a little AIES and BDB thrown in for good measure... and a heckuva lot of custom configs and part welding.

Fair point and good idea. I'll start looking into MAS. On the flip side, I suspect more people will be using RPM than MAS for some time and I'm not sure I want to make MAS a requirement just quite yet, and the curiosity-killed-the-cat part of me wonders exactly what it would take to do it in RPM, and I suspect I'll have to satisfy that particular cat at some point... In the mean time, I'll balance my curiosity with the actual work of getting everything else in the IVA to play nice, whilst taking a little break every once in a while to, y'know, actually play KSP. Most of the "simple" breakers are working (and I have the internal lighting controls working too... w00t). Next up is to tackle the C/W interplay of breaker, lamp test, and MA silence button. I figure that'll make a good prelude to doing the FDAI and DSKY.

All y'all are evil... now you have me thinking about what it would take to re-skin/re-program the DSKY prop to make a more-or-less functional AGC DSKY using RPM... :) @Capt. Hunt, I have actually included an ASET CRT on the far left of the cockpit, but it just performs its "stock" ASET function of target selection, and in keeping with the spirit of the IVA, I don't think I'm keen to start modifying it just quite yet... @MOARdV, I was definitely thinking along those lines. Will have to see what looks workable. In the mean time, making decent progress on the breakers. But, speaking of the DSKY, from looking at all the code I think that will probably be the toughest to get a breaker to control... hence I'm saving it for last. Keep the feedback comin', it's all good...

The solution to that problem... moar fuels! :) Let me think about it. As I said, this was heavily inspired by ASET's Mk1 Landercan IVA, which also doesn't feature any MechJeb controls. Including the ASET CRT for target selection was a concession for playability. I'll have to see if using just MechJebRPM button methods, if anything really constructive can be done. The only other alternative I can see at the moment would be to code up a custom CRT that offers more MFD-type control over MechJeb. In the mean time, circuit breaker work continues...

I think I've finally got the Caution & Warning system working the way I want it to (except for the breakers, more on that below). Imgur album: https://imgur.com/a/PNRYkP0 The C/W "lamp test" function actually came out of my wanting an easy way to make sure the C/W panel looked OK (instead of trying to simulate all those conditions at once), but then of course it dawned on me that usually when you have a set of indicators you have some way to light them all up to make sure they're all working, and as far as I can tell the Apollo crafts had such functionality. As seen in the album, the C/W MODE switch has three settings - AUTO, TEST and ALL MUTE. The AUTO setting (the default) will fire off the C/W indicators and the Master Alarm as necessary (if conditions warrant). The TEST mode lights everything in the C/W system up regardless of conditions (sadly there's no sound, but the 2nd tile in the album shows this in action). The MASTER ALARM MUTE pushbutton is actually where the Master Alarm audible alarm comes from. It lights up under the same circumstances as the big "MASTER ALARM" tablo indicators, but if pushed while lit it will silence the audible component of the Master Alarm (at least until another one comes in). If the C/W MODE switch is in the ALL MUTE position, this button's operation is inhibited (it will neither light, nor make noise). This button functions using the RPM "alarmSound" and "alarmShutdownButton" and is bound by the limitations of those facilities. The next hurdle is the breakers. I learned a lot about RPM custom variables in my work on the C/W system, and I think I know how I want to incorporate the breakers - the main challenge as I see it is to do this in a way that won't break any of the "stock" ASET props and/or other IVAs. It'll take some work (which for me is limited to some nights and some weekends), so everyone's patience is appreciated. As always, suggestions and feedback are welcomed and appreciated.

Well... figured I'd dive into working on my first real "mod". Introducing the (very much WIP) Mk1-3 Pod IVA by the Akardam Propulsion Laboratory. Direct link to Imgur album with preview images: https://imgur.com/a/URqxabI This project started off with me goofing around with the new Mk1-3 pod introduced in 1.4.0, and admiring the internal model (very Apollo CM-esque) but thinking "surely, we can do better in the props department". Thus I began to delve into IVA development - boy did I pick a doozy as my first go-round. But, here we are. It's my first, so be gentle... This IVA was heavily influenced by the ASET Mk1 Landercan IVA. I loved the retro looking props and their obvious basis on the Apollo and Space Shuttle era hardware, besides being a huge space nut in general (big surprise, eh?) Goals: Create a fully immersive and playable IVA. As much as possible, the controls should function and be discrete (limit the number of "dummy" controls), and the only time you'd have to pop out of IVA would be to map mode to plan maneuvers (I justify this by thinking that Apollo had mission control pre-compute all their maneuvers (directly or via Pre-Avisory Data) anyway), and perhaps to control some specific part of the craft that wasn't (or couldn't be) mapped to an Action Group With the obvious concessions to the way KSP works, and gameplay, stick to the general layout of the real-life Apollo CM, with an emphasis on placing controls in about the area they would be (for example, power subsystems in front of the right-hand seat where the LMP would fly) Control over the internal model lights present in the .mu (cabin flood and tunnel lights) Individual breakers control individual things or groups of things (for example, a breaker that controls power to the DSKY, another breaker that controls the FDAIs (8-balls), etc) Enhance the general ambiance by the inclusion of misc static props (manuals, storage bags, etc) without overdoing it Mod support: At the moment, concentrating on anything that has plugin hooks in RPM. Focusing on Chatterer, KAC, and RealChute (because I use them all). I don't think I'll be integrating any MechJeb controls into the IVA (for lack of room, and in the spirit of the technological level of the Apollo CM), but if there's a lot of demand I may reconsider. Functioning Caution/Warning system (including a lamp/test function), closely mirroring that of the real Apollo CM C/W system Action Group support: The base layout is envisioned to have 10 AG buttons (with RPM AGMEMO support), but I'm also working on an optional patch to tweak the layout a bit and include some more specific controls tied to specific AGs (for example, a yellow-striped guarded switch intended to fire an AG which would separate the CM from the SM) Write up and publish a user guide (so folks know what all these dang doo-dads do) Progress (last updated 4/2018): As you can see from the pictures, the layout is basically complete, barring some minor tweaks here and there. There remains a lot to do on the backend (individual breakers are proving a particular challenge). I've been learning as I go, and some of the early prop configs & tweaking is... well, it ain't pretty. I certainly want to get a lot of that cleaned up before I'll be comfortable even doing a beta release. I also need to thoroughly test this (my development copy of the game is still on 1.4.0) with the current release and mod dependencies. I also need to make sure I'm squared away on all the license stuff (and pick my own license to boot). So, a release is probably gonna take a while... In the mean time, feedback and questions are encouraged and appreciated. Releases TBD Dependencies JSI Raster Prop Monitor ASET Props Pack

Maybe I'm missing something, but I can't seem to get any of the TRIANGLE_90 or TRIANGLE_90_Beveled primitives props to show in any internal in either KSP 1.2.2 or 1.3.1 (haven't tried in 1.4.x yet). The BOX (plain and beveled) and the equilateral triangle ones show up just fine. Any ideas? I'm using v1.5 of the props package.

Yeah, I shoulda looked into that before posting, afterwards I went back and did a similar test and found that to be true. However, you'd have the same limidation when grabbing a "subassembly" off of a craft and moving it around - you couldn't put that into your inventory either. This at least would make it (for those of us who don't remove the specialty requirement from the tools) so that any Kerbal could move one of these pallets between container mounts. I understand having the ability for a Kerbal to stuff a "subassembly" into his inventory, or carry it on his back, would probably require a non-trivial amount of code work. On the other hand, I could see that enhancing what I consider to be one of the few (if only) shortcomings of KIS right now. @Wyzard, thank you for your great models. I especially love the tank part. If, by the way, that's your definition of not-an-experienced-3D-artist, then you're light-years ahead of me. Thank you for your time, gentlemen.

First, I'd like to say to those who created and maintain this mod, that it has fundamentally changed how I play the game, and enhanced my enjoyment of it immeasurably. No more Russian-style "let's dock a buncha stuff together" routine for me, no sir. Constructing ships and stations in orbit is the name of the game. So, thank you, thank you, thank you! Now, down to business. A part that I feel is lacking would be a "pallet" of sorts that clicks into the Container Mount, with a flat top that one (or one's engineer-Kerbonaut) could bolt stuff to (either in VAB or flight), that then any crew member (of any specialty) could drag around between mounts on different ships/rovers/etc. I suppose one could already to this with the SC-62 container, but it's a rather bulky, and something more low-profile I think would be nice(r). I'm envisioning something like the SC-62, with the same molded bottom that fits into the mount, and a flat top, lopped off just above where the "tangs" on the mount come up. I tried importing the container model into Blender and lopping the top off myself, but I must admit my Blender-fu is quite weak, and my patience for things I don't fully understand thin, and my time is already short as it is... So, if anyone cares to take on this "challenge" (read: part request), they would (as Picard says) have my gratitude.

Couple MM patches I've been messing around with to enhance my enjoyment of Habtech. The first adds a simple RPM MFD to the Cupola IVA. The second one (which I suppose really ought to be sorted out in the base mod config files itself, but here it is in the mean time) works around a duplicate internal name and title in the two Cupola parts (with shutters and without). // Habtech v0.1.7 Cupola RPM Internal // Dependencies: ModuleManager, RPM, ASET Props // Abstract: If RPM is installed, adds a single small RPM MFD to the IVA // Add custom IVA +INTERNAL[habtech_cupolaInternal]:NEEDS[RasterPropMonitor]:FIRST { @name = habtech_cupolaInternal_RPM // RPM Basic MFD PROP { name = RasterPropMonitorBasicMFD scale = 0.4, 0.4, 0.4 position = 0, 0.26, -0.47 rotation = 0.15, 0, 0, 1 } // ASET Props blank panel (used as backing for the MFD) PROP { name = SwitchFlatPanelShortClear scale = 0.7, 1.9, 4.0 position = 0, 0.26, -0.47 rotation = -6, 0, 0, 1 } } // Patch any parts using the Habtech Cupola IVA @PART[*]:HAS[@INTERNAL[habtech_cupolaInternal]]:NEEDS[RasterPropMonitor]:FINAL { MODULE { name = RasterPropMonitorComputer } @INTERNAL { @name = habtech_cupolaInternal_RPM } } // Habtech v0.1.7 Cupola De-Dupe // Dependencies: ModuleManager // Abstract: Since the referenced version of Habtech has two Cupola variants (but they are both named the same), de-dupe by creating a second part with different name and title // Whichever part we ended up with, make sure it has the attributes of the shuttered variant @PART[habtech_cupola]:FIRST { @MODEL { @model = HabTech/Parts/ISS/cupola } %MODULE[ModuleAnimateGeneric] { %animationName = Open %isOneShot = false %startEventGUIName = Open Shutters %endEventGUIName = Close Shutters %actionGUIName = Toggle Shutters } } // Add the shutterless version +PART[habtech_cupola]:FINAL { @MODEL { @model = HabTech/Parts/ISS/cupola_shutterless } @name = habtech_cupola_shutterless @title ^= :$: (Shutterless): @description ^= :$: This model does not include shutters.: !MODULE[ModuleAnimateGeneric],* {} }

That appears to have done the trick. Thank you!

OK, picture worth a thousand words. KSP 1.0.4, MechJeb2 2.5.3.0: KSP 1.2.2 MechJeb2 2.6.0.0 Build 698 Both tests were started in an approx 100km orbit of the Mun, and burned to about the same velocity and about the same direction. In the 2nd pic, mousing over the periapsis marker clearly shows you the time-to, but MechJeb doesn't, whereas in the first pic, it does (and as I remember it used to). Hope this helps...

So, I'm experiencing an oddity vis-a-vis Apoapsis/Periapsis times. Have searched this thread and the GitHub issues tracker, and don't appear to have come across a solution (or even a mention of the problem), so here it is. I've noticed when on an escape trajectory from/around a body, that the Time to Apoapsis AND the Time to Periapsis show "Inf"... most of the time. Take the following example. Depart Kerbin for Mun, free-return trajectory (still in Kerbin SOI): Times shown for both A and P Enter Mun SOI (on flyby/escape trajectory): "Inf" shown for both A and P Reduce velocity to almost-orbit (still on Mun escape trajectory): Times shown for both A and P Enter orbit of Mun: Times shown for both A and P Break orbit around Mun for Kerbin atmo entry (before reaching P, so that a P still exists): "Inf" shown for both A and P Note: While accellerating out of Mun orbit, I noticed that while I had achieved escape velocity, it wasn't until my A showed something on the order of Gm to Tm (terrameters) that it would switch from showing a time to showing "Inf" for both A and P. Currently I am running KSP 1.2.2 x64 with MechJeb2_2.6.0.0-698. I first noticed this in my heavily modded install, so I tested it in a fresh install with only MechJeb2 and a MM patch to apply MechJeb to all command pods and probes, and I experienced the same. Previously I had run KSP 1.0.4 with MechJeb2 2.5.3.0 and don't recall experiencing this issue. Let me know if any more info (logs, screenshots) would be helpful in chasing this down, or if it would be helpful to open an issue on GitHub.

Your derpiness aside (don't worry, we all have it from time to time), yes, I know, I was there. Just saying since of that default key issue, why bother doing the work to modify any key starting with default, since it won't matter?

Since there's a pull request to skip modifying key names with an existing asterisk at the end (which makes sense), might as well also not only ignore "default", but ignore any key beginning with "default". Maybe something like this? foreach (ConfigNode.Value key in results.values) { if (!key.name.StartsWith('default') && !key.name.EndsWith('*')) data.AddValue(key.name + '*', key.value); } Hope Squad actually fixes things soon, so the default entries will come into play too.

I filed a bug report in the tracker on this back in january. #13552

Another issue I've come across, which I'm not sure is by design, or I'm missing something, is that a CollectScience parameter inside a VesselParameterGroup doesn't seem to fire its defined completedMessage or any funds, science, or rep rewards. I have two test cases. First test case, no VPG, simple contract to get into orbit and transmit back a temperature scan. When I finish transmitting, I get the completed message, and the funds and science rewards: CONTRACT_TYPE { name = TestMission title = Test Mission group = TestGroup description = Test Mission Description synopsis = Do it! completedMessage = Did it! targetBody = HomeWorld() maxSimultaneous = 1 DATA { type = ScienceExperiment title = Desired Experiment desiredExperiment = temperatureScan } PARAMETER { name = ReachOrbit type = ReachState situation = ORBITING } PARAMETER { name = DesiredScience type = CollectScience title = Perform @/desiredExperiment.Name() situation = InSpaceLow experiment = @/desiredExperiment recoveryMethod = Transmit completedMessage = You did the science! rewardFunds = 1000 rewardScience = 10 } } The second test case wraps the ReachOrbit parameter in a VPG with a define line, and the DesiredScience parameter in a VPG with a vessel line. When I finish transmitting, I do not get the completed message defined inside the CollectScience block, and even watching the funds/rep/science window, I don't see funds or science increment by the given values (I've long since exhausted the actual transmit science for temp in LKO): CONTRACT_TYPE { name = TestMission title = Test Mission group = TestGroup description = Test Mission Description synopsis = Do it! completedMessage = Did it! targetBody = HomeWorld() maxSimultaneous = 1 DATA { type = ScienceExperiment title = Desired Experiment desiredExperiment = temperatureScan } PARAMETER { name = GoodOrbit type = VesselParameterGroup title = Good Orbit define = TestProbe PARAMETER { name = ReachOrbit type = ReachState situation = ORBITING } } PARAMETER { name = DoScience type = VesselParameterGroup title = Do Science vessel = TestProbe PARAMETER { name = DesiredScience type = CollectScience title = Perform @/desiredExperiment.Name() situation = InSpaceLow experiment = @/desiredExperiment recoveryMethod = Transmit completedMessage = You did the science! rewardFunds = 1000 rewardScience = 10 } } } I've tried other parameters (such as requiring the probe to have a solar panel) and they do complete within a VPG. So far CollectScience is the only parameter I've seen this issue with. Any ideas?

There's a number of things broken in the current published DLL that don't work with 1.2.x. In fact the other day I discovered that if you use the lighting fx, and have in-flight highlighting enabled, there's a good chance if you mouseover any part it'll crash the game. Still trying to figure out why that would be... This MM patch should do the trick. You'd want to install RcsSounds as normal, and delete everything from the RcsSounds folder except for the Sounds subdirectory. Unfortunately since the stock ModuleRCSFX has only a running effect, you can't use the shutoff sound. Note that I've monkeyed with the 3rd and 4th volume curve values as the stock values seem rediculously low - I had to boost past the usual 1.0x multiplier. This should work out pretty well for the default ship channel volume setting of 0.5. The commented-out block is a more generic way to do it, as opposed to referencing particular parts. However, as noted it could have unintended side effects, so use with caution. // Stock RCS parts only @PART[linearRcs|vernierEngine]:FINAL { @EFFECTS { @running { @AUDIO { @clip = RcsSounds/Sounds/RcsHeavy @volume,2 = 0.5, 4.0 @volume,3 = 1.0, 8.0 } } } } @PART[RCSBlock]:FINAL { @EFFECTS { @running { @AUDIO_MULTI_POOL { @clip = RcsSounds/Sounds/RcsHeavy @volume,2 = 0.5, 4.0 @volume,3 = 1.0, 8.0 } } } } // More generic, but might conflict (or simply not work) when other mods are involved // Uncomment to use //@PART[*]:HAS[@MODULE[ModuleRCSFX]]:FINAL { // @EFFECTS { // @running { // @AUDIO { // @clip = RcsSounds/Sounds/RcsHeavy // @volume,2 = 0.5, 4.0 // @volume,3 = 1.0, 8.0 // } // @AUDIO_MULTI_POOL { // @clip = RcsSounds/Sounds/RcsHeavy // @volume,2 = 0.5, 4.0 // @volume,3 = 1.0, 8.0 // } // } // } //} // Remove any RcsSounds modules @PART[*]:HAS[@MODULE[RcsSounds]]:AFTER[RcsSounds] { !MODULE[RcsSounds] {} }

I've been trolling through some of the other contract packs looking at how people did things, the one you mention above is a good example. I have kind of a chicken and the egg thing right now, in that I don't have anything specifically in mind (other than the mass thing above, which with your assistance I think I've figured out a way to do). Generally, I'm just trying to learn the syntax and musing on cool things I could do. Thanks for your help. I'll keep plugging away at it...

OK, makes sense. I already had an idea along these lines for a backup, glad to get a second opinion/confirmation on it. I'm still fuzzy on the Vessel and VesselItentifier expression types, the Vessel() method/function, and their relation to Vessel IDs defined by VesselParameterGroup(s). Can anyone explain how I might access or act upon the properties of a Vessel ID that is captured by a VPG? In other words, how would one potentially use them other than defining in one VPG and using the vessel = assignment to make sure other VPGs only track said vessel?