TheShadow1138

Check your settings to see what "Reflection Refresh Mode" is set to, it needs to be at least set to "Low". I had this same issue (reflective in the VAB, black in flight), and this is what fixed it for me.

Thank you for those kind words. I'm quite proud of it myself. It could be that most players prefer a more realistic approach to FTL, or that a lot of people just don't know about it. I'm not that great at promotion, but I have seen the Phoenix parts show up on the BDB thread, which was nice.

I've got the UV unwrapping left to do on the engineering section, neck, nacelles, and nacelle pylons, then texture the whole thing. The saucer, bridge, and impulse engines have already been UV unwrapped. Honestly, the texturing is part of what's gotten this stalled. The refit Constitution-class is one of my favorite designs, and the model has turned out so well, I want it to look perfect so texturing it seems like a monumental task. I'm starting, however, to get the motivation to finish it to finally see it in all its glory. I did do a little bit of tweaking to the photon torpedo launcher at the base of the neck to round off the edges more like the filming model. The schematic images I was using to build the model showed hard edges, but I like the slightly rounded edges better.

It's not dead, I just haven't had a great deal of motivation for the last year or so. I am getting the feeling back and do intend to finish the Constitution-class Refit model, build a Miranda-class engineering section so that will be an option for people. I do also plan on a possibly modular TMP/TNG era shuttlecraft, and hopefully adding a transporter to the plugin to allow kernels and cargo to be transported between ships and from ships-to-surface and back. Awesome screenshots and video! As for KSP2, a pretty major hurtle will have to be overcome, one that I have no control over: they will need to make it available on Mac. If they don't make a Mac version, I'm afraid TrekDrive will be a KSP1 only mod. I might even need a newer computer, but it's not much good if they don't release a Mac version of KSP2.

There are plans for the Constitution-class Refit. There are some WIP images of the model in the release thread here:

That's awesome! I like it.

I'm doing well, just haven't had a lot of motivation to work on this. It is still a go, I haven't forgotten about it, and fully intend to finish it. I've just had some other projects that have consumed my attention and motivation.

Awesome mission and screenshots! Never really thought I'd see my TrekDrive parts in the BDB thread.

From this image from 1963, Launch Complex 39 was proposed to have five pads LC39A - 39E. In the image the built 39A was 39C in this image:

They did drop from the bottom of the NX in the show, and I gave a lot of thought to how to do it for the mod. I wanted to make the ship as few parts as possible to hopefully give it fewer failure points while maintaining ease of construction for players. I also ran into what to do for the refit of the NX. The information I could find on the NX-Refit indicated that the shuttlepods would have been launched from the aft bays, mostly because the neck of the refit engineering section would make maneuvering the shuttlepods to their original bay precarious. Since the aft bays are relatively unobstructed I figured the simplest solution was to just use those and not worry so much about having a separate bay part with a part switch or two bay parts. Anyway, that's why they launch from the aft bay, and not the show-accurate ventral bay. They are a bit of a tight fit. I was going for as accurate a model and scale with both, so that's why they're that way. Actually, now that I think about it, imagine having to dock them in the ventral bay. The ventral bay doors are just big enough that a shuttlepod would fit, but only with retracted wings, so they'd probably be even more of a pain/hassle to dock if I had used those instead. I have been able to guide the shuttlepod into the bay and translate downward so that it rests on the bay's floor collider and gently thrust forward sliding on the floor of the bay. There isn't a collider on the ceiling, except for the docking collider, so there is tolerance there, it just doesn't look like it. I'm glad you're enjoying the mod and as long as you're having fun with it, that's really all that matters.

I'm doing well. I've got a class that I'm teaching now, and had a few other things going on that have been distracting me. As a result I haven't really done any work on the mod. I do plan to finish what I've already started, I just haven't felt like working on it lately.

i'm glad you were able to figure out what was causing the NRE spamming. Awesome screenshots, very cinematic! I currently have the Constitution-class Refit from the films in production. It's fully modeled and I have the saucer section (bridge, saucer, impulse engines) UV unwrapped. I've kinda stalled out with other obligations and slight waning of motivation. I keep reminding myself that it's there. It will get done...eventually. Part of it is, admittedly, self-induced anxiety because I want the textures to do the model justice, and right now the model looks absolutely gorgeous in my opinion. But, like I said, it will get done. As for other ships, I do plan on the Miranda-class, but haven't made any commitments beyond that. I have this "lofty" idea of making some generic components (saucers, bridges, engineering hulls, pylons, nacelles) that would go together and could be mixed and matched to create multiple unique ships. I would base these parts on existing designs, not necessarily recreate existing designs. I haven't settled on anything yet, but that's something I'm thinking of.

Firstly, thank you. I'm not sure why you're getting NRE spamming. There were some issues with some earlier versions of the TrekDrive plugin that would cause NRE spamming, either all the time, or just in the editor, or just in flight. I doubled checked the current version of the plugin and don't see any NREs being thrown. You seem to be using the TUFX configs, which I don't personally use, so I'm wondering if that might be the source of the NREs. I say this because if you're getting them with the Constitution-class bridge, my plugin doesn't add any special modules to that part, so those definitely aren't TrekDrive related. I did test a full ship, both NX-class and Constitution-class and didn't get any NREs under impulse power, or warp power. I did find, however, that the plugin was spamming to the log about how many nacelles are charged while traveling at warp speed, so I have posted a small update that removes that log spam. Have you removed any part of the mod, or any of the dependencies? Did you install via CKAN? I assume that installation through CKAN would not cause issues, but it might be possible that it didn't pick up the correct version of the plugin. If you did install from CKAN, you might want to download the mod from Spacedock and copy over the plugin from the Spacedock download. That's the only case I can think of, if the NREs are actually being thrown by the TrekDrive plugin. My guess is that it's not coming from the TrekDrive plugin, but maybe the TUFX or some other plugin that is being added to the parts through a ModuleManager patch, but it's not finding the necessary module or plugin. If none of these suggestions helps, could you post your Log so that maybe I can figure out what's going on. Hotfix Update: TrekDrive v1.0.3b Hotfix Update v1.0.3b - Log Spam Hotfix * Updated TrekDrive.dll to remove spamming the debug log with the number of warp coils that are charged.

I can certainly understand that sentiment. I would point out though, that a macOS version of KSP2 is yet to be confirmed, unless I missed an announcement. Coupled with Apple's move away from Intel processors, KSP1 may be the only way we Mac players can enjoy KSP in any form, barring moving to console.

I'm honestly at a loss. I can't think of what could possibly be causing this for you. How have you installed the mod, manually or CKAN? Could you provide a mod list, or a screenshot of your GameData folder? I'd like to see if we can figure out what's going on. I haven't had anyone else say that they've experienced this, but if we can figure it out, then maybe we can fix it so that no one has to deal with it in the future.

I'm glad you've been able to mitigate the issue. The only other thing I might suggest is that maybe the way Kerbal Joint Reinforcement works, overrides some of the stock behaviors for attachment rigidity that causes the joints to be "floppy" when rigid attachment is set to true in the part CFGs. That would be kind of funny though if KJR was actually causing loose joints. Maybe, as a test, uninstall KJR and see if the problem persists. Either way it seems you have a workaround so that you can still use KJR and TrekDrive.

I did have this happen after initially updating to KSP 1.12+, but defining rigid attachment to be true in all the part CFGs fixed that months ago, for me any way. I personally haven't used autostrut on the ships, and I don't have Kerbal Joint Reinforcement installed, so I don't know if that could be negating the CFG defined rigid attachment. My guess is that that wouldn't be the cause though. Do you have any mods installed that auto-scale parts or anything like that? I'm trying to think of what could cause this for you, but not for others. If there is anything that might be altering the mass of the parts, maybe that's causing issues, but other than that I'm not sure what would be causing it.

The craft called "Apophis II" is a liquid fueled alternative to the Ares I (Apophis I). It simply replaces the SRB with the proposed F-1B powered liquid booster for the SLS. To build it yourself from the Ares I (Apophis I), simply remove the SRB and adapter from the interstage decoupler. Then, place the Anubis Liquid Booster Tank on the bottom of the interstage decoupler, then attach two F-1B engines and you're good to go.

The SRB's are set up just like the stock SRB's, no thrust curves or special mods, so they probably are a bit over powered. I did try to tune them to get somewhat "realistic" performance for LKO and Mün missions. The parts shouldn't require any mods. It's very possible that I wrote the RealPlume patch wrong. Try deleting the RealPlume compatibility patch by deleting "ShadowWorks/Compatibility/RealPlume", then delete your ModuleManager cache and restart KSP. All of the compatibility patches should only apply if the required mod is installed. I designed the mod to be self-contained requiring no other mods so I'm not sure what the problem could be, other than the RealPlume thing I mentioned. I believe I have them all set up so that they will unlock at "reasonable" points in the tech tree and so can be used for a career mode game. I've never used Duna Direct, so I had a quick look at the mod's opening post. It says to launch in a 5m expanded fairing, and the core stage and EUS in this mod is 5m, and a 5m fairing base is also included. The 5m Fairing Base uses the stock fairing module so you shouldn't have any problems there I'd imagine. I assume that the mass of the Duna Direct vehicle wouldn't be an issue, but you could always use the Block II SLS with the Black Knight boosters, or with the liquid boosters.

It was built for stock scale, so you should be good to go. There actually might be some difficulty using in in upscaled systems, but I haven't tested it in anything other than stock scale.

No I do not.

I'm glad you're enjoying the Type F Shuttlecraft. I do plan to do an IVA eventually, but I don't know when it will get done. As for docking the shuttlecraft, it can only be docked in the Constitution-class ship. There are no visible docking ports/mechanisms they are set up only with invisible transforms. In the shuttle bay of the Constitution-class ship you will see four "parking spaces" marked out in yellow. You will need to maneuver the shuttle so that it is over one of these spaces, and then move it downward using its RCS. With the shuttle near the center of one of the "parking spaces" it should start experiencing the "magnetic" attraction of the docking ports until it successfully docks. It will work, as I just tested it to make absolutely certain that it works. Let me know if you have any issues, and happy flying.

TrekDrive v1.0.3a Hotfix v1.0.3a - Warp Drive Hotfix * Updated TrekDrive.dll * Updated the CheckStatus function to check if the minimum number of nacelles have been charged instead of all nacelles on the ship. Fixes an issue where embarked warp-capable shuttles prevents the mothership from going to warp. * Updated the warp coil code so that coils that are not charged will not try to drain themselves and prevent the ship from going to warp if the minimum number of nacelles are in fact charged. This is a quick hotfix that should solve an issue related to docking warp-capable craft with a larger warp-capable mothership (i.e. a Type-F shuttle in the bay of a Constitution-class ship). Thanks to @stormhawk427 for finding this issue, that thankfully had a fairly easy and quick fix (I literally changed one variable and added one extra condition). This should prevent this issue from popping up again. Let me know if any other issues, new or old pop up.

I just did a quick test to make sure it is in fact working, and I was able to get the Constitution-class ship to orbit and go to warp. I think I have figured out what the problem is. I'm assuming that there was a Type-F shuttlecraft in the shuttle bay. Apparently, I overlooked something in the check status code on the warp drive. Instead of checking to see if the minimum number of nacelles are charged before allowing the drive to be engaged, it's checking to see if all attached nacelles are charged. I checked this by putting a Type-F shuttle in the bay and I could not get the drive to enter the "Ready" state until the nacelles on the shuttle had also been completely charged. This is definitely not an ideal situation. I'll have to change the code so that it only checks to see if the required number of nacelles are charged. So, if the drive is set up to have at least 2 nacelles, so long as two nacelles are charged, it should be able to enter the "Ready" state. Of course, that would technically mean that you could charge two nacelles on shuttles in the bay and be able to go to warp with the mothership. I'm not sure if there would be other issues with nacelles on shuttles while the mothership is at warp. I guess we'll find out. I may end up removing any warp capability from shuttles if it becomes too much of a hassle, but we'll see. For the time being (until I update the plugin) you'll just need to charge the nacelles of any Type-F shuttles on your ship before you can go to warp. It's not the greatest workaround, but it's what we have at the moment. Edit: Turned out to be a much easier fix than I thought. I already posted the hotfix.

Happy New Year! v1.0.3 - The Galileo Seven v1.0.3 - The Galileo Seven * Added Type F Shuttlecraft (all parts have two texture variants) * Main Hull (crew capacity of 7) * Impulse Engine * Warp Core * Type F Warp Nacelles (Port & Starboard) * Added warpEffectParent.mu (an empty transform model) This model is in "TrekDrive/Generic" along with usage instructions * Added a WaterfallFX template for the TrekDrive warp stars effect to make it easier for others to add the effect to non-TrekDrive parts. * Added Mirror Universe texture variants and registry/name variants for the Type F Shuttlecraft. * Updated all parts with the SW_ModuleWarpGenertor module to have a warpEffectParent transform to standardize the transform to which the warp stars effect is parented. (Doesn't affect anything, all effects are intact and the same as before.) * Updated all parts with RCS thrusters to use LqdDeuterium, removing MonoPropellant entirely from the parts. To maintain propellant consumption rates all RCS thrusters' ISP were increased by a factor of 25. * Updated surface attach node on NX-class warp nacelles allowing for sane surface attachment. * Updated TrekDrive.dll to apply forward and reverse impulse thrust per-part instead of to the vessel as a whole (thrust vectoring still works). The update to the impulse engine code shouldn't have any noticeable affect on your ships. During testing of the Type F shuttlecraft it became apparent that for small vessels with warp nacelles mounted off-axis that as they fill with warp plasma the center of mass shifts enough that thrust vectoring may not be able to stabilize the craft. It seems that there is either a lag in the application of thrust at the COM, or the applyForce command doesn't actually update the COM every frame. Anyway, it works without issue, and as I said should have no noticeable impact on any other vessels.