TheShadow1138

The Constitution-class starship is officially in the game, and in testing. Here are some screenshots. USS Enterprise (NCC-1701) alongside Atlantis (NX-05): There will be twenty (20) registry variations, some canon, some not:

The refit will be a pure replica of the film version of the Enterprise, so yes. The film version is my absolute favorite version of the 1701, though the DISCO version is a close second. I originally wanted the version I'm working on now to be the DISCO version, but I couldn't find good schematic views of the DISCO version. There is a fan-made model with schematic renders, but there are various differences between it and the on-screen version. Also, the fan-made renders did not use lighting that would permit ease of use in the modeling process. So, I decided to make my own version blending various versions together while also making the film refit more of a refit than a complete rebuild. My intention was always to make the refit version from the films to go along with this one.

Thanks! I whipped up an alternate white/light gray texture with red bussards because...reasons, which I actually like a lot. I have gotten the parts exported from Blender and some config files roughed out so that once I get the parts into Unity and exported to the game it will be easy to quickly build out the ship. It would then just be a matter of fine tuning the CFGs for release. Here's a pic of the texture variant: This is actually a planned feature. There was once a mod, LCARS, that added impulse engines, transporters, and a host of other things Star Trek related so there's plenty for me to look at for inspiration on the transporter front. From my early investigations, transporting kerbals from a vessel to another vessel should be fairly easy, and I think from a vessel to the surface of a planet or moon should also be fairly easy (maybe a bit harder than ship-to-ship). I would also like to be able to provide y'all the option to transport cargo from inventory slots. This would allow you to re-supply outposts/colonies without having to rely on shuttles, or allow you to get more to the surface quickly. Of course, there will be shuttlecraft as well, so there's that too. I can't give an ETA on transporters, but it will probably be once the Constitution-class and related parts are released. So, this encompasses the ship I've been working on, the Constitution Refit, and since it wouldn't be but two (four at the most) parts, a Miranda-class to go with the above Constitution-class, and the "refit" Miranda-class seen in The Wrath of Khan and TNG/DS9/others. So, once the two versions of the Constitution-class and Miranda-class, and at least the Type-F shuttlecraft (a new take on the Galileo-type shuttle) are released that's most likely when I plan to start really working on getting the transporters to work.

Constitution-class Textures (pretty much) Complete! The textures are pretty much complete except for all of the faux lighting. Some of the faux lighting is present on the nacelles (registry lights and glow from the field emitters. I do still need to set up the registry meshes, but I'm getting close to being able to get the parts in-game. Port Elevation Forward Elevation Aft Elevation Dorsal Plan View Ventral Plan View Aft 3/4 View Field Emitter Faux Glow Edit: Here's a few pics showing the registry meshes and all of the faux lighting, except for the fantail lighting.

Engineering Hull Textures Complete! Port Elevation Showing off non-uniform specular Navigational Deflector normal mapping Fantail Shuttlebay interior There is enough room, and spaces marked out for 4 Galileo-type shuttlecraft (Type-F). I haven't included any of the faux lighting effects in the emissive yet as I still need to determine where I want/need those "lights". I'm going to put an actual light in the shuttlebay, so no faux lighting there. On to the nacelles!

Texturing Update: I finally finished the panels on the Engineering Hull, the most tedious part of texturing. As you can see, the windows, and other markings are now present and I think looking good. The nav deflector also has its textures as well as the shuttlebay doors and formation lights. I haven't started with the shuttlebay markings yet because I want to mark out "parking spaces" for the shuttles, so I need to work out the length and width dimensions of the shuttlecraft. I'm thinking of a kinda updated Galileo type shuttle, that will, hopefully, be recognizable as a Galileo-like shuttle, but maybe with some sleeker lines. And now, pics... Port Elevation 1/4 View Navigational Deflector close-up Ventral Markings Dorsal Markings Other than the shuttlebay markings, I still need to do the specular, normal, and emissive maps, but those typically come quickly once the base diffuse texture is done. It shouldn't be too much longer (hopefully) until the Engineering Section textures are complete.

I've thought about that, even going as far as contemplating custom MFDs that would look like LCARS displays. That would also allow the main viewer to possibly be used like in the shows. The problem, however, is the sheer amount of work and time that would be necessary for all the textures and configs is significant as I understand how MAS MFDs work. So, it might happen at some point, but it won't be until I've gotten more parts/ships released. So, for now the bridge IVAs will just be pretty things to look at, but serve no real purpose otherwise. Thank you, and I hope you continue to enjoy it and that it only gets better. Awesome moves there Jeb. Love the jump to warp at the end.

v1.0.1 - Thrust Vectoring Update v1.0.1 - Thrust Vectoring * Updated plugin to add thrust vectoring to impulse engines. Thrust vectoring is toggleable in the PAW and by Action Group * Added a new parameter to impulse engine CFGs, "maxVectorAngle" a value in degrees to control the amount of vectoring. Default value is 15º. This is a relatively small update, but should provide a lot more control for in-atmosphere flight. In testing the NX can be flown in-atmosphere at full throttle with no loss of control or unwanted pitching. The shuttlepod also appears to be more controllable in-atmosphere as well, which is to be expected. On the Constitution, texturing continues with the paneling.

I would like to add thrust vectoring to my impulse engines, but can't use ModuleGimbal because of the way I need the engines to work. I think I have a way to do this, but I need to be able to tell when control input is made. I assume I could use GetKeyDown() to tell if the pitch, roll, yaw keys are pressed, but I'm not sure that is the best option. Is there a way to generally tell if a pitch/roll/yaw input has been made regardless of whether it came from the keyboard, mouse, joystick, gamepad, or the SAS? I know that the FlightCtrlState class has pitch, roll, and yaw attributes, but are these just the current pitch, roll, and yaw angles of the active vessel, or do they hold the current amount of pitch, roll, and yaw input? I presume it's the former rather than the latter. Edit: I realized that the FlightCtrlState class is where I've been getting the main throttle setting and set up a quick test and confirmed that ctrlState.pitch/roll/yaw do give me the values I need for both manual input and SAS control. So, I self-answered my question. Thanks to anyone who saw this and was investigating an answer.

I actually hadn't thought about it that way, but I would think that would work. You've certainly got me thinking. I would think that I'd be able to add a "maxVectorAngle" parameter to compute the components of the acceleration. I would then just need to determine how far from the COM to place the force to create a useful torque. That's just determining the acceleration and where to place them, I'll also need to find out what functions or parameters to use to get the input and make sure that the SAS would work. I'm hoping that the functions or parameters are the same so the amount of code necessary to get it to work won't have to be doubled or more convoluted. I'll definitely look into this since it will add more control to the ships. As you've said, thrust vectoring would probably make in-atmosphere control a bit more manageable. My gut reaction to what the ships could do in the shows and movies is that they didn't have to worry about drag at all. If they want the NX to fly at full impulse through Earth's atmosphere, or the much denser atmosphere of a gas giant, all they had to do was animate it, physics be damned. In KSP we do have to worry about drag, though technically I could define custom drag cubes that were extremely small to cheat the system. I don't really want to do that as I want to keep as much realism as possible. I know that warp drive is often seen as a "cheat", but there is real world physics behind it, and the impulse engines are really just augmented fusion rockets. The impulse engine's, as coded, are more of a cheat since the thrust is directly applied to the COM, but this is again because the shows and movies can just ignore physics and design ships that look cool, but aren't necessarily practical in physical simulation. The shuttlepod does suffer from the same "sail effect" as the NX, it's just that what initiates the pitch is different. With the NX the nacelles cause the initial pitch, and determine the direction of the pitch, which turns the saucer into a "sail". With the shuttlepod, we cause the initial pitch. When the pod starts out traveling in one direction and accelerating, its cross-sectional area is small along the direction of travel. Once any pitch or yaw is made, that cross-sectional area increases creating more drag, which causes the same "sail effect". The same thing happens with a regular rocket made from stock or modded parts. If you make a pitch or yaw maneuver with a rocket that is going say less than 100m/s, there may not be an issue (SAS can cancel out any torque added by drag), but if you have a decent sized rocket traveling over 300m/s at 10,000m of altitude, and try to pitch down 5º, there could be a lot of problems very quickly. For now, we just need to be gentle with throttle application in-atmosphere. If the atmospheric effects are showing up, then slowing down would be a good idea before trying to alter course. I know this is not the best solution, but it is flyable in atmosphere if you keep an eye on your throttle and speed. As I said, I am going to work on getting thrust vectoring to work, which should help this problem, but I don't know when it may be available. There are no plans to make the ventral docking bays operational. When I was making the model I thought about how to do the shuttle bays a lot. At one point I was going to make the bay a separate part that would be part switchable to the refit version where only the two forward bay doors would be operational. I decided, however, that that option added an extra part that didn't absolutely need to be there and I considered part switching the entire saucer. During that time I was completely ignoring the aft bays, and I thought that docking in the ventral bays on the refit would be potentially more trouble than it was worth and that maybe only the most die-hard accuracy players would want to put up with that potential hassle. When I realized that the aft bays were equally accessible in the standard configuration and the refit configuration, coupled with the info that NX-class ships only had two shuttlepods embarked, I decided that the aft bays were the best solution for playability. I will say that @Puggonaut was able to use robotics (I don't remember right off if it was Infernal Robotics, or the stock Breaking Ground robotics) to have an extendable arm that can grab the shuttlepod and retract it into the non-modeled ventral bay to kinda emulate ventral launching. The colliders are set up in such a way that this is safe to do, and if you'd like to do that that certainly is an option. I just have no plans or desires to add an operational ventral bay to the NX On the topic of cargo space, I probably do need to add inventory space to the ship so that one could deliver cargo and supplies to deep space stations, colonies, and whatnot. I am planning on adding transporters after the Constitution release that would, hopefully, allow beaming of crew and cargo in inventory to other vessels/stations, and the surface of planets/moons. Once that's available I'll definitely make certain that there is plenty of inventory space on the NX and Constitution to be useful.

From testing the best explanation is that the atmospheric drag on the nacelles is the root cause. There are no lifting bodies defined on the NX. What seems to be happening is that the center of mass is below the nacelles on the standard variant A, and above the nacelles on variant B, so there is asymmetrical drag while in atmosphere. This causes a pitch up, or down, and then the larger drag cube of the saucer acts like a sail to really kick the pitching into high gear. Try starting with the throttle at 1/4, if I remember correctly that is what I tended to use during testing, 1/3 might be too much for the NX in atmosphere. I know it can feel like a chore to get it to orbit, and I often just cheated it to orbit, I mean these ships weren't meant to fly in atmosphere, in-universe anyway. I do plan on seeing if we can use Extraplanetary Launchpads to construct the ships in orbit instead of having to start from the ground and babysit it to orbit, or cheat it to orbit. As for a gimbal, it's not possible the way I have it coded. The code applies the thrust directly to the COM so that impulse engines placed off axis do not cause unwanted torques. This will almost certainly be necessary for the Constitution-class to behave as desired under impulse power. The result of this is that gimbaling the impulse thrust would actually not work. A torque is caused by a force applied to an object that is not directed through the COM. The amount of torque is determined by multiplying the component of the force that is not directed through the COM by the distance from the COM. This distance is called the "lever arm", the longer the lever arm the less force is required to cause a significant torque and rotation. My code, however, always applies the force through the COM, and is therefore never off axis, and the lever arm is always of 0 length. This means applying a gimbal would not cause any torques or rotation, it would actually just start pushing the ship down, up, left, right, or whatever direction would result from the applied input. The I have given thought to converting the RCS to using LqdDeuterium for "realism", so that may happen. Thanks! I like seeing the progress from a few polygons to fully textured model and know others like seeing that evolution too. Plus, it gives y'all an idea of where things are and that there is indeed progress.

Constitution Texturing Update: It's been a bit since I posted those pics of the panels on the saucer, but progress has been made. Today, I completed the textures for the Saucer, Bridge, and Impulse Engines! Next I'll move on to the engineering hull. Starboard Saucer: Dorsal Saucer showing deflector shield grid grooves and non-uniform specular: Impulse Engines showing the lit observation windows and docking port: The docking port is "lit" using the emissive map. I'm planning on using this on other areas of the ship to emulate most of the spotlights/self-lighting to keep from having a glut of physical spotlights that could cause lag for some, or bad lighting of the ship if a player's settings aren't set to handle a lot of light sources. I'll still use physical spotlights for the main registry, unless the "fake" lighting looks fine in-game. The only thing I could foresee using this "fake" lighting is that when the registry area is not lit by the sun the registry text would be completely unlit by the "fake" lighting. So, if it looks okay, I won't use physical lights, but right now I'm planning to use a physical light, as I said, on the main registry. Dorsal aft view showing the ridge stripes that continue onto the Impulse Engines: Starboard Dorsal view:

How much throttle are you using while in atmosphere? It is possible to fly the NX to orbit in 8 minutes or less without using RCS at all, just SAS. I'm wondering if maybe your install has old part configs because the NX should have 6,000 MonoPropellant while the shuttlepod should have 1,000. Did you install through CKAN, or Spacedock? You can check the configs for NXClassBridge.cfg and the ModuleReactionWheel should have values of 5000 for the various torque parameters. There should also be 1000 MonoProp in the NXClassBridge, 5000 in the NXClassSaucer, and 1000 in the NXClassEngineering and NXClassEngineeringRefit. I'll double the amount in the Refit hull for the next update. Although the NX only has 6 times the amount of MonoProp, it's thrusters are much more efficient, so you shouldn't be running out of MonoProp on the NX quickly. This is another reason I'm wondering if you have old part configs in your install. Make sure that when you install the mod, you completely replace the old TrekDrive folder with the new one, never merge. There should be plenty of SAS control authority to fly in-atmosphere as long as you are gentle with the throttle. Once you get above 30,000m you should have more leeway with throttle as the atmosphere's density drops off significantly above that altitude. The Takeoff and Landing settings should actually be helping you, at least this is what we found during testing. I know that the impulse engines have magnetic thrust vectoring, but my code applies the thrust from the engines directly to the center-of-mass (COM) of the vessel so trying to apply a gimbal-like behavior would not work. The reason it wouldn't work is that the torque would always be zero because the lever-arm would always have zero length.

Increasing the "collectionRadius" in the SW_ModuleBussardCollector of the Phoenix_WarpNacelle.cfg will help. This is in units of meters, and is set at 15, but there's no limit on how large this radius can be, at least in my code. You could also increase "collectorEfficiency" to 1. There's no other way to speed it up, short of me updating the code of the plugin.

Texturing Update: I have completed the UV unwrapping and have begun the texturing process with the aztecing of the dorsal saucer. I may turn down the opacity to make it more subtle as kind of a blend of the Original Series with no panel variation and later aztec'd ships.

Thanks, I hadn't noticed it was doing that. It should be fixed now.

Thank you! That is high praise, thank you!

Quick Update: I've gotten the Saucer, Bridge, and Impulse Engines UV unwrapped into one texture space. I've also gotten the Engineering Section (Neck, Engineering Hull) UV unwrapped into one texture. Once I get the Nacelle and Pylons unwrapped I can start texturing. I'm thinking the part separation will be: Bridge Module (3 variants), Saucer, Impulse Engines, Engineering Hull, Nacelle Pylons (2 variants), and Warp Nacelles. I wasn't thinking about the Navigational Deflector being a separate part, but it might be a good idea to separate it from the Engineering Section. I'm not sure, I'll have to think about it, but if y'all have any suggestions just let me know.

Constitution-class Progress Update: Barring anything I've forgotten I believe I have completed the geometry for the Constitution-class starship! I am going to do the film Refit version also, but I think I'll UV unwrap and texture this ship before finishing the refit. I may go ahead and release this ship once it's done instead of waiting until both the base and refit are done, but we'll see. Before y'all get to the pics of the ship, I want to ask about variants for the bridge. The bridge, as is, isn't symmetrical, and I'm contemplating giving y'all three variants of the bridge: the one I've started with, one with two turbolift stops, and a more conformal variant. Would y'all rather have just one, if so which one, or some or all of the variants I've presented. Pics of the variants are in the spoiler below. Now, with that business out of the way, the pics you've been waiting for... Port Elevation (Flared Pylon): Port Elevation (Straight Pylon): Forward Elevation: Aft Elevation: Aft 3/4 View: Port 1/4 View (rendered lighting):

Constitution Update 2: The Constitution-class is coming along much faster than the NX. I've got the Engineering section and the "neck" geometry complete. Here's some pics. Port Elevation: Forward Elevation: Aft Elevation: Nav Deflector: Shuttlebay Doors (closed): Shuttlebay Doors (open): I may add some small geometry to the interior of the shuttlebay later, but for now I'm keeping it pretty simple, like with the NX shuttlebays. Next, the nacelle pylons, which will have two versions, the flared pylons from the DISCO version, and straight variants of the DISCO pylons that appeared in concept art, and might have been in some on-screen graphics.

Awesome screenshots, as always, and nice base as well. I'm glad it is easy to make such precise landings. Thank you very much!

First Progress Update: Constitution-class I'm starting to wish I had started with the Constitution-class just because of how much simpler the geometry is compared to the NX, but The NX gave me the confidence to know that I could do this well. I started the model yesterday and have already gotten the Saucer, Bridge, and Impulse Engines fully modeled. Keep in mind that I'm not making a 100% TOS accurate Constitution-class, but my own re-imagining based on multiple versions of the NCC-1701. There's actually not too much deviation in the saucer though. The impulse engine module is larger, similar to the DISCO version, but taking some cues from the Refit version from TMP. Part of my goal in this design is to ultimately have a version of the Constitution-class which could actually be refitted into the version from TMP instead of the near complete rebuild that it is from the original TOS version of the ship. Here are some pics of what I have so far. Forward Elevation (front orthographic): Port Elevation (side orthographic): Dorsal Plan View: Ventral View showing the "indent" of the curve: Aft Third Quarter View: Closeup of the Impulse Engine module. At the center is a docking port, and below that is an in-visioned aft observation area. The offset turbolift shaft stop is the one change I've made that is necessary for KSP. Since I intend to make an IVA that at least follows the general layout of the original bridge, I need the turbolift shaft stop to be where it is in the pics above. The layout implied by the original model and sets in the series have the main viewer offset from the centerline, which is fine for them as in-universe the main viewer is just a screen, and not a window. In KSP it kinda needs to be a window, so it needs to face down the centerline. Thus, for the bridge layout to stay the same, the turbolift shaft stop needed to be offset. That's probably a lot more explanation that most will want, or even think about needing, but I wanted to explain at least that decision. The next step will be the Engineering section and the neck connecting the Saucer and Engineering section.

TrekDrive v1.0 Full Release!!!! v1.0 - Initial Full Release * Includes: * Phoenix Warpship * Phoenix Warpship launcher * Enterprise-era Shuttlepod * NX-class starship * Added A User's Manual * Added NX-class Bridge IVA and Props * Updated warp stars configs so that they are visible in the Bridge IVA * Updated the plugin to add an ambient rumble sound for the warp core. The sound is customizable by simply editing the CFGs with SW_ModuleWarpCore to give the path to your desired sound. * Added ENT-era Shuttlepod IVA (Stock and MAS versions) * Updated Shuttlepod Impulse engines to have a hover altitude of 1000m * Added ModuleLiftingBody to the Shuttlepod fuselage improving flight characteristics * Balanced the RCS and COM of the Shuttlepod removing most if not all unwanted movement during docking or other maneuvers. * Updated SW_ModuleImpulseEngine to apply Takeoff/Landing forces to every part to provide even acceleration to the entire vessel almost entirely removing the need for RCS or SAS to keep the vessel level during takeoff/landing in atmosphere. ------------------------------------ It really has been a long road getting from there to here, but the time as finally come. I have reached full v1.0 release. I have created a new thread in Add-on Releases: TrekDrive Release Thread. I will keep this thread open, but most if not all future progress updates will be in the release thread. Thank you all for your support through the early months of this mod. The next step is to begin working on the Constitution-class, the next major update for the mod. Fly safe out there, and may we all go where no Kerbal has gone before.

Introducing... (Source code is included in the download) License: Code and Configs are licensed under the GPL v3 license. Author: TheShaddow1138 Tester(s): @Puggonaut Here's a spacedock by @StinkyAce that @Puggonaut has been featuring in his videos: https://spacedock.info/mod/1815/USS Nimitz and Drydock A scaleFactor of 0.6 makes the best fit for the NX. A compatibility config is included that creates a copy of the drydock and modifies the included resources to include the resources needed by the NX. StinkyAce's mod must be installed for this config to work. Dependencies: (bundled with the Spacedock download) ModuleManager 4.1.4 B9PartSwitch Community Resource Pack Waterfall Small Trailer for TrekDrive made by Puggonaut This fantastic video was made by @Puggonaut, and you should definitely give it a watch. If you like what you see, and would like to support development you can make a donation. One-time Donation through PayPal Mod(s) that Expand or Supplement TrekDrive: @Shammyofwar Is updating the Old SciFi Shipyards mod by implementing TrekDrive modules on that mod's USS Voyager and USS Stargazer, among others. The TrekDrive plugin will be bundled with their mod upon release. Change Log: v1.0.3b - Log Spam Hotfix * Updated TrekDrive.dll to remove spamming the debug log with the number of warp coils that are charged. 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. 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). v.1.0.2 - The Original Reborn * Added Constitution-class Starship (all parts have two texture variants) * Bridge Module (crew capacity of 6) * Saucer (crew capacity of 30) * Impulse Engines (includes a docking port) * Engineering Hull (crew capacity of 20) * Navigational Deflector * Nacelle Pylons (two variants: flared and straight) * Warp Nacelles (Port and Starboard) * Starship Registry Variants (present on Saucer, Engineering Hull, and Nacelles [port & starboard] * USS Bonhomme Richard (NCC-1731) * USS Cassie (NCC-1711) * USS Constellation (NCC-1017) * USS Constitution (NCC-1021) * USS Defiant (NCC-1764) * USS Eagle (NCC-956) * USS Emden (NCC-1856) * USS Endeavour (NCC-1895) * USS Enterprise (NCC-1701) - The Default * USS Essex (NCC-1709) * USS Excalibur (NCC-1664) * USS Exeter (NCC-1672) * USS Hood (NCC-1703) * USS Hornet (NCC-1708) * USS Intrepid (NCC-1631) * USS Kearsarge (NCC-1733) * USS Lexington (NCC-1709) * USS Porthos (NCC-1712) * USS Potemkin (NCC-1657) * USS Ticonderoga (NCC-1714) * USS Yamato (NCC-1716) * USS Yorktown (NCC-1717) * Added two (2) new registries for the NX-class and NX-class * Cassie (NX-11) * S.S. Cassie (NX-11) * Porthos (NX-12) * S.S. Porthos (NX-12) * Added Mirror Universe Kerbban Empire Content in "Extras" (content is encapsulated and may be easily removed by deleting either the "Extras" folder, or the "MirrorUniverse" folder inside "Extras") * Kerbban Empire Texture Variants to the following parts * NX-class Saucer * NX-class Engineering Section Refit * NX-class Warp Nacelle Refit (Warp 7 Nacelles) Port and Starboard * Enterprise-era Shuttlepod fuselage * Constitution-class Saucer * Constitution-class Engineering Section * Constitution-class Warp Nacelles Port and Starboard * Kerbban Empire Registry variants for all currently available registry variants on the NX-class and Constitution-class ships * Flag of the Kerbban Empire * Added Textures Unlimited patch - authored by Puggonaut with "excludeMesh" statements provided by TheShadow1138 so that registries appear correctly with this config. v1.0.1 - Thrust Vectoring * Updated plugin to add thrust vectoring to impulse engines. Thrust vectoring is toggleable in the PAW and by Action Group * Added a new parameter to impulse engine CFGs, "maxVectorAngle" a value in degrees to control the amount of vectoring. Default value is 15º. v1.0 - Initial Full Release * Includes: * Phoenix Warpship * Phoenix Warpship launcher * Enterprise-era Shuttlepod (can be docked in the aft bays of the NX) * NX-class starship (has two aft shuttle bays for the shuttlepod) * Added A User's Manual * Added NX-class Bridge IVA and Props * Updated warp stars configs so that they are visible in the Bridge IVA * Updated the plugin to add an ambient rumble sound for the warp core. The sound is customizable by simply editing the CFGs with SW_ModuleWarpCore to give the path to your desired sound. * Added ENT-era Shuttlepod IVA (Stock and MAS versions) * Updated Shuttlepod Impulse engines to have a hover altitude of 1000m * Added ModuleLiftingBody to the Shuttlepod fuselage improving flight characteristics * Balanced the RCS and COM of the Shuttlepod removing most if not all unwanted movement during docking or other maneuvers. * Updated SW_ModuleImpulseEngine to apply Takeoff/Landing forces to every part to provide even acceleration to the entire vessel almost entirely removing the need for RCS or SAS to keep the vessel level during takeoff/landing in atmosphere. Below are the previous WIP Change Logs: v0.99.1w - Spacedock * Added a ModuleManager patch for StinkyAce's Spacedock, available at this link: https://spacedock.info/mod/1815/USS Nimitz and Drydock The patch scales the dock down to 0.6, a near perfect fit for the NX-class, and instead of modifying the drydock that comes with StinkyAce's mod, it creates a new part with the aforementioned scale, an impulse engine (no part, just the module), and produces the resources used by TrekDrive ships. This will be a good refueling station for the NX. * Updated the plugin * Fixed an NRE spam in the impulse engine code while in the editor * Added the ability to select a "forward" or "reverse" mode for the impulse engines. Toggleable in the PAW, and can be set as an action group. * Cleaned up the Waterfall patch by splitting the warp effects into their own patch. * Tweaked the texture tiling on the NX warp effects (both the Warp 5 and Warp 7 versions). v0.99w - NX-class Release * B9PartSwitch is now a hard dependency. (Included in download) * Updated the TrekDrive.dll * Warp speed formula changed to allow faster interstellar travel * OnLoad function updated to not automatically set the warp drive to "Not Ready" if it was in a "Ready" state at the last save. This allows the player to immediately engage the drive after the vessel loads, if the drive is in a Ready state upon loading. * Added NX-class Starship Parts * Bridge module (Crew capacity of 6) * Saucer section (Crew capacity of 20) * Engineering section * Nacelle Pylons (B9PartSwitch variants) * Upper variant (2 upper pylons) * Lower variant (2 lower pylons) * Four variant (2 upper & 2 lower pylons) * Warp Nacelles (Port & Stbd) * Main Impulse Engines (Port & Stbd) * Secondary Impulse Engines (Port & Stbd) * Navigational Deflector (2 variants) - Serves as a transmitter * NX-01 Oval "Mark I" Deflector * NX-02 Rectangular "Mark II" Deflector * Added NX-class Refit Starship Parts * Engineering Section Refit (Includes warp 7 warp core and warp drive, Crew capacity of 10) * Refit Warp Nacelles (Port & Stbd) * Added Custom Waterfall FX model and texture for streaking stars at warp effect. * Updated the warp stars effect on the Phoenix * Added six (6) craft files for the NX-class and NX-class Refit * NXClass_A: Standard NX-class starship (as seen in Star Trek: Enterprise) * NXClass_B: NX-class starship with two (2) ventrally (lower) mounted nacelles * NXClass_C: NX-class with four (4) nacelles * NXClass_Refit_A: Standard NX-class starship Refit * NXClass_Refit_B: NX-class Refit with two (2) ventrally (lower) mounted nacelles * NXClass_Refit_C: NX-class Refit with four (4) nacelles v0.9w - Shuttlepod & Impulse Engine Release * Updated the TrekDrive.dll * All TrekDrive buttons/toggles can now be set as Action Groups * SW_ModuleImpulseEngine Added - automatic takeoff and landing modes when sub-orbital, it will not automatically land from orbit. * SW_ModuleBussardCollector Added - When the collector is activated it will collect at a random rate for a random period of time before choosing another random rate and period of time. Collects LqdDeuterium and Antimatter with LqdDeuterium collecting at a higher rate. Collection will only occur at sub-light velocities. * Updated Waterfall version. * Updated Waterfall effect on the Phoenix Launcher Main Engine to correct a position issue. * Added a Waterfall effect to the Phoenix - visible when traveling at warp; the effect is based on the streaking stars warp effect from TNG - VOY and ENT. * Added Enterprise-era Shuttlepod * Shuttlepod main body - holds 5 kerbals with airlocks on both sides (No IVA) * Shuttlepod Impulse Engine v0.7.5w - OnLoad Hotfix: * Corrected an issue that prevented engaging the warp drive after switching to another vessel, after reloading the game, or any other loading action. Upon switching back to the warp ship, or loading the save, the warp drive will be automatically disengaged and set to "Not Ready" status. Simply clicking "Check Ready Status" and then engaging the warp drive will get you ready to go. Thanks to @Tanner Rawlings for finding this issue and bringing it to my attention. v0.7w - Phoenix IVA release: * Added Phoenix IVA (Stock and MOARdV's Avionics System) * The MAS version replaces some of the central props with MAS props, and replaces the Main Display with a functional MFD * MAS version of the IVA will only be available with MAS is installed. v0.6w - Phoenix Initial release: -------------------------------- * Updated Code: * Added nacelle glow animation capability, giving a visual indicator of coil charge. * Fixed coil charge logic to allow charging a partially discharged coil * Fixed a logic issue with the Warp Field Generator code. Now the "not enough charge" warning will only occur if the warp drive is active. * Moved to LqdDeuterium and Antimatter from Community Resource Pack * Added Phoenix Parts: * Phoenix Crew Cabin (no IVA currently, built-in RCS, no effects yet) * Phoenix SAS (contains Monopropellant and Electric Charge) * Phoenix Fuselage (contains LqdDeuterium and Antimatter) * Phoenix Nacelle (deployable warp nacelle) * Phoenix Warp Core/Warp Field Generator * Phoenix Main Thruster (matter-antimatter rocket engine) * Phoenix Vernier Thruster (matter-antimatter rocket engine) * Phoenix Fairing (to conceal the warp nacelles during launch) * Phoenix Interstage Decoupler * Phoenix Launcher First Stage * Phoenix Launcher Main Engine (Liquid Fuel Oxidizer engine) * Added Phoenix Warp Ship Test craft. * Added Community Resource Pack and Waterfall as hard dependencies (bundled) Inspired by RoverDude's Standalone Alcubierre Warp Drive, this warp drive aspires to operate in a Star Trek-like manner requiring at least two types of parts to operate: warp coils/nacelles and the heart of the drive, the warp core and warp field generator. I have seen in other threads here where people were trying to figure out how to require the use of warp nacelles to get that Star Trek feel to their KSP warp drives, and that's what I set out to do with this, my first plugin mod. Maybe a bit ambitious, but I think it turned out well. Now, on to the details. Technical Aspects: The plugin includes three Part Modules: SW_ModuleWarpCoil, SW_ModuleWarpCore, and SW_ModuleWarpGenerator. SW_ModuleWarpCoil: This module would typically be attached to a warp nacelle part, but could be added to any part for a design that perhaps doesn't use a nacelle, or similar structure. Requires: Warp plasma, which is generated by a warp core part using SW_ModuleWarpCore. Restrictions: Cannot be added to the same part as the SW_ModuleWarpGenerator. This is the restriction that requires at least two types of parts. Example Config: MODULE { name = SW_ModuleWarpCoil warpPlasmaConsumed = 5 // Amount of warp plasma consumed per second during charging and operation warpPlasmaNeeded = 250 // Amount of warp plasma needed to fully charge the warp coil cutoffThreshold = 2.000 // When the charge percentage drops below this percentage, the coil and drive cut off (1 - 100) coilEfficiency = 0.01 // Thermal efficiency of the coil (0 - 1) maxWarp = 2 // Maximum warp factor this coil can safely achieve } SW_ModuleWarpCore: A simple generator module that takes in deuterium (matter) and anti-deuterium (antimatter) to generate warp plasma and electric charge. (Could be replaced with a stock ModuleGenerator I suppose, but it's included all the same). Requires: Deuterium and Anti-Deuterium. Restrictions: None hardcoded. Example Config: MODULE { name = SW_ModuleWarpCore minAntimatter = 0.05 // Minimum amount of anti-deuterium required to operate minMatter = 0.05 // Minimum amount of deuterium required to operate warpPlasmaProdRate = 10 // Amount of warp plasma generated per second ecProdRate = 100 // Amount of electric charge generated per second } SW_ModuleWarpGenerator: The heart of the warp drive that actually moves the ship at warp speeds. Just like RoverDude's Standalone Alcubierre Warp Drive, the drive uses translation, not acceleration, to move the ship through space. Also, like RoverDude's drive, I used a slightly modified version of his gravity braking code (RoverDude's source code including the GravityBrakes() function) so that ships will slow down when they near gravitational bodies. Requires: At least one part implementing SW_ModuleWarpCoil that cannot be the same part implementing SW_ModuleWarpGenerator. This is what forces the requirement of multiple parts. Restrictions: All warp coils must be charged before the drive can be activated, and enough electric charge to run the drive is also necessary. If either of these is not true the drive cannot activate, or will automatically disengage. Example Config: MODULE { name = SW_ModuleWarpGenerator maxWarp = 2 // Maximum warp factor this drive can attain minNacelles = 2 // Minimum number of nacelles required by the drive to operate (must be at least 1) electricityReq = 50.000 // Amount of electric charge that is required per second of warp operation } NOTE: Some part on the vessel should have a container for warp plasma. In the included test parts the nacelles have their own warp plasma containers, but it can be on any part of the vessel. Warp Speed: The ship's warp velocity is computed using a simple cubic function, which was used for the original series and in Star Trek: Enterprise. So, velocity = (warp factor^3) * c In my initial testing, I find that Warp 2 is a good speed for traveling to the edge of the Kerbol System in a comfortable amount of time. I haven't tested higher warp factors, but will install appropriate mods on my end to further test travel times with increasing warp factors before final release. How to Use: I have kept the operation of the drive entirely within the Part Action Windows (PAW) of each part. Follow these steps to activate the drive. All of these actions can be set as Action Groups to somewhat simplify the process. Step 1: Activate the Warp Core by clicking the "Warp Core Status" toggle. Step 2: Charge the Warp Coil(s) by clicking "Charge Warp Coils" in the coil PAW Step 3: Once the coils are charged click "Check Ready Status" on the Warp Generator (combined with the Warp Core Test Article here). The drive will not enter the "Ready" status until all the coils are charged, and will not do so if there are any other active Warp Generators. Step 4: Once the "Ready Status" reads "Ready", click "Engage Warp Drive" on the Warp Generator. This will change from "Drive Inactive" to "Drive Engaged" Once the drive is engaged, any throttle input will move the ship at warp speeds. To return to non-warp operation, simply click the "Engage Warp Drive" toggle in the PAW to disengage the drive, or use an Action Group. Current warp factor is determined as a percentage of the drive's maximum warp rating, based on the amount of throttle: 50% throttle is half of the maximum warp, 100% throttle is maximum warp. E.g. for a drive with a maximum warp of 2, 50% throttle will be Warp 1, and 100% throttle will be Warp 2. The warp factor can also be selected using a slider in the PAW. The slider moves in 0.25 increments from Warp 0.25 to the maximum warp of the drive. The slider defaults to Warp 1. Increasing the slider scales the throttle so that your warp speed does not increase until you manually increase the throttle. The current warp factor is displayed in the Warp Generator's PAW Step 5: Once you have reached your target destination simply throttle to 0%, or use "x" to cut the throttle. There is an "Orbit Mode" option in the Warp Generator PAW that defaults to "Easy", this places the vessel in as close to a circular orbit as possible when the throttle hits 0 after having been non-zero. That is, it doesn't continually change the orbit while the drive is active, only if it had been moving the ship and then stopped. If the Orbit Mode is toggled to "Realistic", it will simply use the vessel's velocity vector to determine the current orbit, in the same manner as RoverDude's Alcubierre drive. Limitations: I tried to implement some limitations to make the drive less "cheaty". I took cues from Star Trek, particularly Star Trek: Enterprise, which dealt repeatedly with the limitations of the ship's warp drive. In the show, most problems occurred with the plasma injectors, but I though trying to code some kind of simulation of the injectors would be cumbersome and place unnecessary computational overhead. Other limitations that come to mind are the stability of the warp field, and the warp coil temperature. I opted for warp coil temperature to place a limitation on time at maximum warp. Warp Coil Temperature: While the drive is active, and moving at warp speeds, to emulate the warp plasma cycling through the coils I have implemented an exponential function that increases the temperature of the warp coil part. The smallest amount of heating occurs at low warp, while the maximum heating occurs at maximum warp. There is a built-in warp coil efficiency that can be used to aid in cooling. The value in the config file is between 0 and 1, and the upper limit is enforced in the code to prevent config editing to make the coils cool themselves at high warp. If a value greater than 1 is used in the config, the plugin randomly chooses an efficiency in the correct range. So, you may get a decently efficient coil, or a really inefficient one. This is also done per coil, so you could have one coil that is really efficient and one that is terrible, which could hamper your warp travel to keep one coil from overheating and exploding (the stock behavior). The maxWarp parameter of the warp coil also plays a role in temperature calculation. A ratio is taken of the active drive's maxWarp to the warp coil's maxWarp to further scale the exponential function. If the warp coil's maxWarp is equal to the drive's, there is not scaling, if it is less, there is more heating, if it is greater it is less. The reasoning is that if you have a warp coil rated for Warp 1, and try to push it to Warp 2, it would burn out much faster, but if it's the other way around, it would be able to handle the temperature better. Warp Coil Discharged: If the source of warp plasma runs out, or is shut off, the coils may completely discharge, if the user doesn't notice that warp plasma production has stopped. If the coils completely discharge (or their charge goes below the threshold set in their config) the drive will automatically disengage and either be automatically placed in a nearly circular orbit (Easy orbit mode), or be in a realistic orbit based on the vessel velocity vector. Running out of Electricity: If there is not enough electric charge to run the Warp Field Generator, the drive will automatically disengage and enter an orbit based on the selected orbit mode. Multiple Warp Generators?: If there are multiple parts on the vessel that implement SW_ModuleWarpGenerator, only one may be active at a time. If you try to activate a second warp generator when one is already active, it will not activate. If you disengage the active drive, you may then activate another. Screenshots Phoenix Warpship: NX-class: NX-Refit NX-class Bridge IVA Custom Registries There are ten (10) different names and registries in two variants each, so 20 textures in all giving you NX-01 through NX-10 and names with and without the "S.S." prefix. The registries are B9PartSwitch selectable on the saucer part and the refit engineering hull part. I have included instructions on how to make custom names/registries in the config file that sets up the variants under "TrekDrive/Parts/NXClass/Registries/Registries.cfg". The instructions are at the bottom of the file. There are also two (2) template images, one in PNG format and another in PSD. To use the PSD file you will need to have the font "Airborne", or one that looks close enough to it, if you want show-accuracy, or any font of your choosing will work.

it is. Everything is working aging. Thanks!