TheShadow1138
-
Posts
654 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by TheShadow1138
-
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.
-
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.
-
The Orion capsule is 3.124m in diameter. It's a very non-standard size I know, but I based everything off of having the SLS Core Stage be 5m in diameter. I may be misremembering the reason as it's been quite a while since I made the model, but I'm pretty sure that's the reason for the size.
- 506 replies
-
- 1
-
-
- delta iv heavy
- orion
- (and 3 more)
-
The winter term has come to an end, grades have been submitted, and the shipyard has been at work. I give you the geometry complete Constitution-class Refit, my favorite version of the NCC-1701. Orthographic Views: I have begun unwrapping the saucer section with the goal being to have only three texture sets like with the released Constitution-class ship: one for the saucer, bridge, and impulse engines, another for the engineering hull, and the third for the warp nacelles and pylons. No ETA yet on the next release, or when texturing will actually begin but it will get done. This is a bit more daunting as I want to get it right.
-
There is a User's Manual included in the download. You don't collect warp plasma, the warp core generates warp plasma from Liquid Deuterium and Antimatter. To generate warp plasma, activate the PAW on the part which contains the warp core (the saucer of the NX, the NX-Refit engineering hull, the warp core part on the Phoenix, or the engineering hull of the Constitution-class ship) and click the button next to "Warp Core Status" under the "Warp Core Operation" heading to activate the warp core. Assuming there is plenty of Antimatter and Liquid Deuterium the warp core will begin generating electric charge and warp plasma. To collect Liquid Deuterium and Antimatter simply activate the Bussard Collector by activating the PAW on the nacelle parts, and under the "Bussard Collector" heading click the toggle next to "Collector status". This should activate the bussard collectors, but the ship must be moving to collect Liquid Deuterium and Antimatter. I hope that helps, but if not just let me know.
-
It stands for "After Action Report", at least that's what I think is stands for in general KSP context.
-
It's the same, dividing by 1.6 is the same as multiplying by 0.625. 1/1.6 = 0.625
-
I assume you mean the struts that are on the SRB decoupler models. Are you using the attachment nodes to attach the decouplers? I just did a quick check and the 4-segment and 5-segment SRB decouplers' modeled struts sit flush against the SLS core stage tank. Regardless, the struts modeled on the decouplers are cosmetic and do not actually serve a structural role. You will still need to use struts to prevent the SRBs from flopping around, but they can be placed so that they are not very noticeable. Now, if you're using the SRB decouplers on other tanks (stock or other mods) I cannot guarantee that they will sit flush and look as though they are connected to the tank since I modeled them with the SLS and External Tanks so that they would look right with them. Now, those tanks are 5m diameter tanks, so I suppose any 5m tank would work fine, as long as the decouplers are placed properly.
-
To attach the Orion Service Module to the Exploration Upper Stage use the 5m Amun-Ra Fairing. It has three variants and nodes for attaching the SM fairing walls. It should be under "Cargo". To attach the SM fairing walls you need to attach them either to the SM decoupler (SLS Block I SM decoupler), or the 5m Amun-Ra Fairing Base. These two parts have three attach nodes for the fairing walls. Simply select the SM fairing wall, rotate it 180º, change symmetry to 3 (really anything other than 1) and attach to the node facing the camera in the VAB, and you should be good to go. As for the Launch Escape Tower, it is in two parts (the top with the jettison motors and the bottom with the abort motors and the boost protective cover). Attach the top of the tower to the CM first, so you will have a spire floating over the CM, then attach the bottom of the Launch Escape Tower to the upper part of the Launch Escape Tower. Hope that helps get you flying.
-
Progress Update: We're still testing out the Type-F shuttlecraft. Some quirks were discovered in early testing that could make it difficult to fly. It seems that as the CoM changes from propellant usage/generation it can cause unwanted torques in smaller craft, which may warrant a small rewrite of the plugin's handling of impulse engine thrust. Once we get that all sorted out I'll release the Type-F shuttle. On another front, I've taken some time to start work on the Constitution-class Refit. I've gotten the Bridge, Saucer, and Impulse Engines pretty much geometry complete. Here are some screenshots of what I've got so far. Port Elevation Port Elevation (with schematic) Forward Elevation Forward Elevation (with schematic) Aft Elevation Dorsal View (docking port cutout visible) Ventral View
-
ShadowWorks v2.0.5.1 Changes 2.0.5.1 * Re-added the Connected Living Spaces compatibility patch after accidentally leaving it out of v2.0.5 Changes 2.0.5 * Added Waterfall FX compatibility patch - converts all engines and RCS thrusters except for SRBs to Waterfall FX. * Fixed texture issue with the 5m Amun-Ra (SLS) Fairing. The texture will now appear correctly in 1.12+. * Updated the SSMEMount part to use transform-based attachment nodes. Just a quick update to add Waterfall compatibility for all liquid fueled engines, and corrected a texture issue with the 5m SLS fairing base.
- 506 replies
-
- 2
-
-
- delta iv heavy
- orion
- (and 3 more)
-
That sounds like a good idea, just not for this shuttle. I'd have to remodel most of the shuttle to get this one to have that customizability. I might be able to set up future shuttles to allow for this type of construction. I think the TOS Film-era and TNG type shuttles lend themselves a bit more to that type of construction, so maybe with the next iteration of shuttlecraft.
-
Type F Shuttlecraft Texture Complete! There will be three (3) registry-related switches for this shuttle. The first is the "mothership", which will use the same textures for the Constitution-class registries (so no duplication of their textures), the second is the shuttle number (the number following the "mothership" registry), and the last will be the shuttle's name. The included numbers are 1 - 10 while the included names are: Columbus Conrad Copernius da Vinci Einstein Galileo Galileo II Heisenberg Kepler Nye Picasso Rembrandt Schrödinger Tyson von Braun I am also including a few starbases/stations as "mothership" registries: K-7, Regula 1, Starbase 1,6,9,11,32,4077,8063, and Starfleet Command Pics: Lighter gray with red bussards texture variant: Mirror Universe variant: (will use the Mirror Universe starship registries) The part breakdown will be: Type F Shuttle Main Hull, Type F Shuttle Impulse Engine, Type F Shuttle Warp Drive, and Type F Shuttle Warp Nacelle (Port & Starboard). So, that 5 parts total. These are warp capable and I'm thinking of having their maximum warp be Warp 2. It shouldn't take too much to get this in-game, so maybe (and I stress maybe) by the weekend there will be an update.
