Coreador

Another weirdness on Amethyst: Some of the flats are below altitude 0. I can live with that, but the engine doesn't seem to like it... when my view goes below 0, the moon disappears and I see my ship floating in space. If I keep the camera above 0m by zooming out, I can see the moon just fine with my ship sitting landed on it, but I can't zoom in to look at my ship or the ground disappears. This is purely visual, it seems; the ship seemed to land and take off normally.

Hey, it seems like the science multiplier for Amethyst is off... I'm getting several times less than the science on the moon right next to it (Grain). Is this intentional?

I think I have a partial answer to my question, but I'm not sure if this is intended behavior. My ship fits nicely within the bubble, but I have some landing gears(stock) that extend beyond the bubble when extended. I keep them stowed during Alcubierre flight, and this seems to be okay, because the drive works normally and the ship doesn't explode. However, the ship explodes at SOI transition (any SOI: planet, moon, etc) if the drive is active, which I now think is caused by the drive seeing something outside the bubble and detonating. Remove the landing gears with no other changes and the problem goes away. To me this doesn't seem to be expected behavior... either the drive should always be okay with it, or it should fail immediately on activation. Does the drive somehow treat parts as extended when transitioning SOIs?

Is anyone having rapid disassembly at SOI boundaries? I can use the drive just fine, but if it's on when switching from a solar orbit to a planet SOI or vice versa, the ship violently explodes without warning. And I do mean violent... like every part flying away from every other at ridiculous speeds. I've taken to just moving to the edge of an SOI and then time warping until my ship intercepts the body with the drive off. Anyone know a better way to deal with this?

Thanks. I was able to find the settings now. That said, I don't think I ever would have found that. As a suggestion, maybe you can add a note in the Play Modes dialog that indicates these can be modified from the default and where to look? So, I've had partial success. I found the settings, but actually, my custom config was working correctly. It was actually configured to not charge for reconfiguration by default when running my custom play mode. I can see that by observing that the options are disabled when looking at the settings dialog. But, despite the configuration setting, it was still not working in the game. If I try to inflate a hacienda, I have to pay equipment. Likewise, if I reconfigure the hacienda to another mode, I have to pay equipment again. Am I misunderstanding what the setting is supposed to do? As I read it, if I uncheck the requirement to pay resources for reconfiguration, then changing my hacienda to a new template or inflating the module should not cost equipment. But this is not what is happening. I have to pay equipment the same in normal mode and in my custom mode. The only time I don't have to pay equipment is when trying to inflate or reconfigure the hacienda in Simplified mode, but in that case the hacienda is using totally different templates. In my game I want to remove inflate and reconfig costs, while retaining all the templates and options normally available. Am I misunderstanding what the settings are supposed to to? Or is it not working for some reason?

I've searched through the dialogs and I can't find them. This is what I can see: Click Pathfinder toolbar icon from KSC: Only option in the Pathfinder settings dialog is "Play Mode". Click Pathfinder toolbar icon from ship with Pathfinder parts on launchpad: I see at the top of the Dialog buttons for "Manage Operations, Resources, and Cheats". Then there's a text entry for distribution time, followed by 4 distribution options. None of those seems to be applicable. Under cheats, there's only "Top off resources". "Resources" just shows the distribution options. "Manage Operations" goes to a complex dialog that allows central control of all the components, but nothing in there appears to be related to global config settings. Am I looking in the wrong place? Is there another settings dialog somewhere?

Question: Is Alt-P still supposed to work to allow changing the behavior (e.g. whether configuring needs equipment, etc)? It does nothing for me. I can't find any other way to remove resource requirements, short of switching to simplified mode. I even tried creating my own custom template that only changed the default values and didn't modify any behavior, but that didn't work either. Thanks for any advice.

Anyone else having problems with RCS? I've noticed the following issue: I made a craft with several VTOL engines, and I when I try to activate RCS (via R key) I get the message "RCS deactivated; not enough thrust available". The navball RCS light will not come on. Now I understand this is supposed to happen unless the VTOLs are under thrust, but this happens for me: 1. Even when all engines are under thrust, and 2. Even when there are other RCS devices on the craft that could provide RCS (needed for orbit), including both honey badger RCS and stock RCS. I've tried this with all the parts' RCS enabled and disabled (via right click menu). Even with all VTOLs RCS disabled, I can't use non-VTOL RCS. So, basically I can't use RCS on the craft at all. I believe at some points during my messing around with the design of this craft I had some RCS working from the VTOLs, but not anymore. I just recently updated Karbonite to the latest; any possible conflict there (even though it's also USI)? FTT has been at 0.5.2.1 all along. KSP 1.1.2, Win64. I just tried out an older design that uses the VTOLs and ducted fans... it works okay and can go into RCS mode, and uses the RCS thrusters from the ducted fans and the honey badger module (and maybe the VTOLs; not sure). So it doesn't seem to be a mod conflict. Maybe my craft is in some kind of weird state?

NVM, the problem is module manager. Apparently it breaks in 1.1.2 (goodness knows how many mods would be affected by that). But an update is available on the MM thread and it solve the survey station problem. Not sure if everything else is ok in 1.1.2, but haven't seen anything else yet.

I have a possibly related issue to the above poster mentioning exceptions. After upgrading to 1.1.2, the survey station seems to be gone. I can't find it in VAB, and one of my ships failed to load because it couldn't find the survey station. I didn't add/delete/change anything on KSP between when it worked yesterday and failed today except for the version update.

EVE was updated for 1.0.5... is this updated version supported by Keridani? It seems to be working in my game (still base game 1.0.4 w/ EVE at the new 1.0.5 version), but I'm not sure I know what to look for in the visual effects to know if anything is broken. Seems like nothing is horribly broken, at least with respect to Keridani (city lights on Mun and random flickering textures need some fixing in EVE).

Me too.

Sorry, I guess I wasn't really clear. What I meant by group membership is that every action group can be in zero or more of 5 groups (identified by a small 1 2 3 4 5 in the dialog). All the action groups on a ship can be categorized into those five groups of groups, which you can also name. They act as a filter to what action groups are displayed as buttons. You choose these groups individually per action group by clicking on the numbers 1 - 5. Maybe what you refer to as "Group Visibility" is what I'm talking about? So what is happening is that I set those in VAB, but when the ship is spawned and then released on a launchpad (the base has no actions tied to any of the action group numbers used by the ship), all of my actions are reset to being in all 5 visibility groups, even though the action groups, the actions, and the group names are all correct. Is this more clear?

I've also run into AGX error messages with the K+ (Karborundum) mod mini-drill. I think that piece needs a fix too. It seems like most of the EPL issues are resolved now. Thanks for looking into it! However, I did see one thing I wasn't sure about. It looks like the group membership settings aren't being recovered. So, if a key is defined on ship A and not on base B, and A is launched from B, then the name and the parts associated with the action do work on A (correct), but the group memberships (i.e. Action #X is in group 1,3,5 and not 2,4) seem to revert to being Action #X in all groups of groups (is there a better terminology for these groupings?). This is something I've noticed but haven't heavily tested so I may not have the details perfectly accurate, but I have been losing at least some group memberships for sure. Could it be that base B's memberships for the action which in their default, unset state would be in all groups, are being overwritten into A's action? Thanks again for all your great work. Your mods have made some designs possible that I wouldn't have been able to try before. For example, fan-based VTOL probes, base cores, miners, and more for atmospheric planets using your horizontal and vertical hover controls, and most recently a Karborundum transport that launches from Eve using many banks of sequentially fired capacitors which would have been difficult or impossible without AGX.

This mod appears to work off your other mod that calculates height from the lowest part of the ship to the surface. While this is reasonable, it does have some strange side effects. For example, I tried to hover 10 m above the ground to lower a KAS magnet on a winch. Unfortunately, as I tried to lower it, my craft started flying away! I was really confused until I realized that what was happening was that the magnet was being selected as the bottom of the craft, so the height control was constantly moving me up to keep the magnet 10m off the ground. Since then I switch to Zero Velocity mode instead of height mode before deploying the magnet (if I remember...).