akardam

Members
  • Content Count

    49
  • Joined

  • Last visited

Community Reputation

49 Excellent

About akardam

  • Rank
    Akardam Propulsion Laboratory Director

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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*
  3. 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.
  4. 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?
  5. 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.
  6. 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.
  7. 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...
  8. 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...
  9. 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.
  10. 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
  11. 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.
  12. 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.
  13. 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.
  14. 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],* {} }