StahnAileron

Members
  • Content count

    520
  • Joined

  • Last visited

Community Reputation

232 Excellent

About StahnAileron

  • Rank
    Spacecraft Engineer

Recent Profile Visitors

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

  1. StahnAileron

    [1.4.*] RCS Build Aid Continued - New Dependencies

    That feature was re-enabled relatively recently. It was removed WAY back in 1.0.5 or so. Since @linuxgurugamer took control of the mod and this is a more code-centric mod, I asked him to re-implement it. It's been about a month or two since the feature update, so I'm not surprised if you never knew it was there: it actually WASN'T for a long time. (And the original implementation was just a magnitude. LGG was kind enough to add all 3 axis numbers as well.) I was going off visuals and the torque numbers for a long time as well. (Building stock-ish VTOLs without an engine management mod took a bit more tweaking. I should probably look into VTOL engine management mods anyway though. I know of a couple...)
  2. StahnAileron

    [1.4.*] RCS Build Aid Continued - New Dependencies

    That is precisely what I was talking about. Thank you! You are a godsend to this community!
  3. StahnAileron

    [1.4.*] RCS Build Aid Continued - New Dependencies

    Possibly stupid question/feature request (if you're even doing feature requests and not just maintenance): In versions of this mod from the 1.0.x-era, there used to be a mass-offset reading that gave you a direct line offset measure of the current wet CoM relative to the DCoM. Is there any chance of bringing that back with perhaps 3-axis readings? (Or at least 2 axis?) I tend to built VTOL aircraft and DCS build is has been indispensable for ensuring I get the CoMs and thrust vectors aligned. I know there are other mods that work with dynamic engine thust-limit to provide the same effect in the long-term. However, I always found them unwieldy, especially in light of how many mods I can have installed. (My screen can be full of menus...) Granted, that may have change last I bothered to test one of those mods. (Problem is the last one I looked at had WAY too many features than I needed/wanted that I couldn't hide like MechJeb.) The Torque value helps me align the thrust vector, but eyeballing the mass indicators isn't very easy at times. I believe the feature was removed because the original dev thought it wasn't used much. (For RCS use I can understand, but for VTOL engine placement without a dynamic thrust management mod, it helped me A LOT.) Otherwise, could anyone direct me to a simple mod that can dynamically adjust engine thrusts to align the thrust vector with the current CoM inflight? I know of Allista's mod, but is the "overladen" mod I hinted at above. It looks amazing, but has WAY more features in it than I need or want. I want something simple like Diazo old Vertical Velocity Mod. (Basically just a toggle.)
  4. StahnAileron

    KSP Weekly: Colonization of Mars

    It's been a while since I've posted here, but with the current and upcoming 1.4.x releases, I'm guessing the codebase and modding API have stabilized. 1.4.4 shouldn't really break 1.4.3-era mods when it gets released...Right? (Maybe at most a simple re-compile?) I got out of KSP for the past year or so because of a new job and the broken mods that always follow nearly every KSP patch release. (Especially the major ones.) I'm hoping the modding API has stabilized for both the sake of the modders' and players' sanity. (DISCLOSURE: No, I do not use CKAN for anyone who wanted to say, "But keeping up-to-date with mods is easy with CKAN." No, I will not start using it. No, I will not bother trying to justify, argue, or debate my choice to not use it.)
  5. StahnAileron

    Reverting Jet Sounds to 1.3.1 standard

    Perhaps you can make an MM patch to swap the sounds to something else? I did something similar when I was using RealPlumes in 1.3.x because they swapped out some default engines sounds that were great for initial launch, but made no sense when I was re-activating engines at zero thrust. (They were stupidly loud and didn't match the visual action.)
  6. StahnAileron

    Loading. Just loading. How does one speed it up?

    And SSD would alleviate the transfer of the game data to RAM/main memory. However, KSP and the mods for it are Just-In-Time compiled on load. A faster processor would (in theory) help as well when Module Manager has to actually process the config files and compile the parts. The only other thing that might help is to get a RAM drive and enough RAM so that an install (or more) of KSP can reside on it. Problem there is cost and the fact you'll either be chewing up power keeping the drive alive or having to re-copy the content during each power cycle or reboot. (You'll be bottlenecked by the transfer speed of the interface though, like any other data transfer-related problem.) Some RAM drive have a battery back-up system. Still, RAM drive are fairly power hungry last I looked into it. As noted before, smaller textures would help since you would literally be reducing the amount of data you're transferring each time on game start-up. The question is if you're willing to live with the lower quality visuals. (This is dependent on the screen resolution you play at as well.) You don't need 4k textures when you play at 1280x720 all the time, for example. BTW, the issue with SSDs mentioned earlier is mainly on the WRITE side. READ operations are generally not a problem. However, in KSP's case, I can't be sure as I know KSP keeps quite a log going and sometimes a LOT can happen in a game session to bloat that log, especially with lots of mods. I'd get a second SSD just for KSP/games in general rather than having it alongside your OS install. (I'm using a hybrid system via Intel RST for my game drive. OS is a dedicated SSD-only drive.) At the very least, it should be more consistent performance without OS disk operations getting in the way of KSP.
  7. StahnAileron

    Making money besides contracts

    As far as I know, if you have a 100% re-useable design, you can mine ore and then recover the craft for 100% cost + worth of ore (or fuel if you convert the ore). This is for pure stock. The same can be done if you use mods that add other mineable resources. The best bet might be Karbonite+. The Karborundrum(sp?) resource is worth quite a lot, though there's only 2 or 3 sources of it with the normal settings for that mod. (Low solar orbit, Eve, and Eeloo, if I recall...) Not sure about the mining rate for it since I have yet to really leave Kerbin's SoI. Otherwise, I usually crank up the fund (and science) rewards in a career game if I care more about just having contracts to give me goals to aim for. Career-mode gameplay is a half-assed after-thought.
  8. Not a problem. I know modding is a time-consuming hobby. It's why I don't do it myself (that and I lack artistic and/or programming talent/skills at this point). The patches is the main thing. Internals I can get around with a simple brute-force methodology. (Besides, does AoA even have a stock internal view? I thought all the IVA views were predicated/reliant on ASET/RPM?) Again, if I get around to doing real, proper MM patches, I'll let you guys know. Lastly: yes, I meant SpaceDock. I read up on the Star Control reboot by Stardock relatively recently and it stuck for some reason. (Despite the fact I had visited SpaceDock not too long before those posts...)
  9. @martinezfg11: I'm looking over the mod (v1.3.9.0 via Stardock) and giving it a once-over to suit my needs. I'm doing a more brute-force method (MM cfg that removes all BDA modules from any part), however, given my request, I may later on do a proper edit of the configs and pull out the BDA sections and place them into one (or more) separate patch file(s). Also, I notice some stats are still from the Beta-era (3400-degree MaxTemp, no SkinTemps), so I may decide to do a balance pass on that (I can't do mass and costs though; MaxTemps are simple for Atmo-only versus Space-capable parts, for the most part.) If I do any of the above (no promises...), I'll let you guys know and post the changes some place (or just send a pull request on github). Getting stuff up to par with stock 1.3.x configs is a chore...
  10. @Wolfair corp., @martinezfg11: Is there any chance of parts with BDA-functionality having those functions split off into a BDA MM patch? As it stands with the current configs, this mod implies BDA is a required dependency instead of an optional one. None of the BDA module calls have a NEEDS to even check for BDA first, so the mod assumes BDA in installed. I haven't touched BDA for a long time. (Considering the complexity of BDA compared to its utility for me, it's just a drag on my system with all the other mods I have installed.) There's no reason to mandate the BDA modules in the part configs without declaring BDA as a dependency. I would like to ask the same for RPM/ASET support (I don't bother with IVA mode at all), but that's directly integrated to the models as far as I know, so that's probably asking a bit much. (I've just deleted interiors from mods if they start affecting my install. I actually got performance boosts from deleting interiors because KSP doesn't have to render them in the Kerbal windows.) Besides, I realize the IVA views are half the reason people use this mod.
  11. StahnAileron

    [1.3.1Beta 2 ]Kerbal Aircraft Expansion _Continued v2.7.1beta

    Regarding a custom KAX resource: is there a chance of including/supporting an MM config that swaps out the KAX custom resources for more common ones from CRP for those of us that have extensive modded installs (and therefore likely to have the needed dependencies anyway)? I'd rather have a common pool of resources that the mods I use pull from (that make sense) than each one using their own set of custom resources, if possible.
  12. Two items: I don't recall if this supported Radiators as specific category. It currently doesn't (and I don't think it ever did, but again, not sure...) Radiators take EC to use for quite some time now, if I recall correctly. Any chance of adding them to the filter list? I recall Ratzap once telling me that certain categories in the filter for Fusebox are dependent on mod version-specific dlls being present when Fusebox is compiled to actually support that mod properly. This is because some mods reference EC usage with atypical methods that Fusebox has to specifically account and look for. SCANsat in particular seems to be notorious (well, to me) for breaking support in Fusebox each time they release an update. (Ratzap basically had to recompile each time certain optional supported mods updated, like SCANsat.) I'm on 1.3.0 currently and don't see SCANsat as part of the Fusebox filters. Any ideas about SCANsat support in FB-Continued? On a side-note: Kinda wished you called it Fusebox Rewired
  13. StahnAileron

    KSP Weekly: The Eridania Region

    There's a reason they called it: ... and not just "Gemini Service Module." It's kerbalized historical referencing. If you want something a bit more faithful, look at actual historical mods like @CobaltWolf's Bluedog Design Bureau.
  14. StahnAileron

    [1.2.2] Kerbal Aircraft Expansion (KAX) v2.6.4

    @keptin Given what you just said, for future reference: My understanding is that KAX is just a parts pack with a plugin-dependency in the form of FireSpitter. I'm guessing KAX will work for the foreseeable future assuming: The FireSpitter plugin is updated to support future KSP versions (and players actually update it properly...) and KSP's codebase doesn't change (once again) in how it handles models (like how I think 1.0.5 switched to convex-only colliders or something or 1.1 handled wheels/legs.) Anything else should be maintainable by the player-base if you ever drop KAX completely, no? (Like config changes.) If you do actually abandon KAX, have you considered changing the license so another modder or the KSP community can adopt it for at least maintenance and distribution, if not further development?
  15. StahnAileron

    [1.3.*, 1.4.*] SpaceTux Industries Recycled Parts

    @Skalou, @linuxgurugamer First, a grateful thanks for the work on Atomic Age. I don't use much from it, but I abuse the crap out of the KANDL for small probes and commsats. That said, something I want to ask @Skalou regarding the KANDL: Have you looked at the shroud set-up for it? Most other engine fairings/shrouds I've seen in KSP either stick with the decoupler/separator or split and eject sideways. The KANDL's seems to be a single separate physical entity that kinda gets flung off due to collision on staging. I bring this up because in prior versions, it would get explosively ejected when staged. I wound up always having to disable the shroud. (Otherwise I'd risk damaging my vessel or shifting the orbit a bit. I've lost solar panels to this a couple of times, at least.) I just checked this version with KSP 1.3.0 and the same issue seems to persist. Though I admit, it doesn't seem as bad as before. This was tested with zero ejection force on the decoupler (to rule that out). No shroud = safe and gentle (no shifting), as expected. With shroud = forceful ejection, causing a spin and orbital shifting. This was a very small test vessel with low mass. Something about the size and mass you'd expect for use with the KANDL, if not a little lighter. This mostly a minor thing with a workaround I know about (I think I defaulted the config file to disable/hide the shroud), so it's not something I expect to be addressed quickly. Just something you might want to be aware of. (The lack of a shroud kinda kills the immersion when I go for practicality over aesthetics.)