Ruedii

Quick question, do you have mods installed? Many times unsupported mods will soft-fail leading to lag, bugs, and save file breaks.

Not compatible with KSP 1.10. (Linux) I might look into it later. OK, Looked into it. The Drag cube computation is throwing an NRE on initialization of the game database. It probably needs it's drag cube to be specified properly in the part file. Hopefull this same bug won't affect every mod out there with wierd shapend objects missing manual drag cubes. Log:

I don't know who to blame for the whole mess of the transfer. I do not see anything wrong with the change of development company. Star Theory didn't want to continue developing under the terms provided by Private Division, so they decided that a new company would be made. The problem is that the developers weren't consulted in all of this. I don't know who is to blame, but if Star Theory was in these negotiations and they are the formal employer, it is their duty to consult them and bring them in on the discussion. Honestly, Star Theory has had a lot of problems, and 2K's largest ethical problems have been in not mandating that their subsidiaries follow proper ethical behaviour, and then taking the blame so they can be the big corporate bad guy and the middle management gets off with no blemishes on their reputation. So I think logic says that 2K didn't make Star Theory bring in the programmers, and Star Theory didn't think to. Making Star Theory at fault, and 2K Negligent (as usual with anything that happens under their umbrella, which is why I was so glad to see Squad keep it's current management lineage in the merger.) Fortunately nothing here is more than bad corporate practice. Nothing illegal, and everything did get sorted out in the end. Still, it is a good reason to pressure 2K to try to at least give some decent advice to their subsidiaries about when something is a bad idea. They also should probably go and maybe get some people with some real world experience to consult in these sort of things as to know what sort of things can go wrong, and what the fallout might be from it. I think part of the problem is that 2K's business division is too far detached from the real world and doesn't know what kind of mistakes can happen and what the press will think of it. The later one is the bad part. For instance, letting the greedy stand-up guys at RockStar request cease and decist letters against modders was a clear and obvious bad press moment. A more kindly worded letter saying to restrict particular usages of the modkit would have been better. Even better would be to provide guidelines for modding in an EULA ammendum for GTA V and GTA V Online, with separate designations of what is acceptable for regular play and online play. As of what I would like to see now, as of cleaning up this mess on KSP 2 should be done in a fully transparent manner. They also need to make sure this kind of mess doesn't happen again.

Thanks for the details. You need to adjust the animation behavior of the shocks. That is where your issue most likely is. I suspect the animation might be reversed or something. I wish there was an easy way to do a controlled halo test of these thing on mods. Oh well. I presume you are doing the layers in blender and doing the sliding animation in Unity itself. That should be how you should do a simple animation like this. Additionally, you might want to consider masking the non-wheel physics from impacting the wheel with the ground by using the collision mesh layer configuration.

As a note, SCANSat has their mechanism fixed, so if you want to know who to contact as of asking for code that works, that's your lead. It's probably better not to reinvent the wheel on this. Hopefully we can get a Github repository made for this function.

I just thought of something. The stock wheels have no conventional collider for the wheel themselves, instead using the wheel module to create the forces. That is likely your issue. You need sufficient distance between the wheel and the ground. Sometimes such issues only appear if the wheel is at an angle due to leverage-torque behaviour in the physics engine.

Is there any way to get the KSPedia version working in 1.9.x I know there were changes to the KSPedia mechanism that broke most of the KSPedia pages added by mods.

I'm still having the same issue too. You should release a CKAN-Only Point release (20.0.1CKAN) with only that one single file changed. Don't bother making a fresh tarball for GITHUB unless CKAN insists on it, and note that this update isn't necessary for anyone who doesn't use CKAN.

So divide the actual vector into the two virtual subcomponents on the aerodynamic diagram? This would be nice. It would be no difference in the physics to do this breakdown there, so I wouldn't bother, but for visualization this would be very helpful. That would be very useful when designing aircraft as it would make it easier to visualize what is going on (or more acruately wrong.) I'd like the visualized vectors to be combined of all blades connected to the motor and blended instead of instantaneous of each blade too. I would visualize the torquing as the 4 directions (up-down-left-right) at the center of aeordynamics of the blades as they pass. As of actual physics, the current system is right. However, blending the physics over the path of the propeller considering the propeller's position response (if this is possible on the current physics engine) would give MUCH better physics response.

I've noticed this a lot. It happens in real planes as well. Counter-rotation reduces roll shifting dramatically, though. It's why I say they need to add an acceleration limiter so that the yaw force shifts are slow instead of sudden.

Sustained torque in flight is steady and can be corrected with trim (unless you are in the habit of suddenly changing your propeller angle instead of slowly changing it.) Spinup torque is horribly sudden. Also, when you make robotic wheels and other ground rotors they don't have traction control. This would basically provide them with traction control. This is literally what traction control is. Currently, the improvised solution I use is to turn down my engine torque during takeoff to reduce the spinup torque. I'm thinking of adding some computer units to the planes to "smooth" any transitions as well. This could help a lot.

I'd like to suggest a little cosmetic effect. You could put a parallax map of the interior of the nozzle on the outward facing surface. This would make interior of the nozzles visible, further completing the illusion that the RCS is embedded into the surface.

One of the ways to limit heavy vehicle torquing on propeller motors without using a torque limit is to use an acceleration limiter. This would be very useful to implement. It would allow even propeller load torque without allowing heavy spinup torque. The other part that can use these is wheels as a means to reduce slippage.

Mods have been known to create various hitching issues. These include errors and heap management issues that result in world-lock thread waits on various memory operations. The only way to fix it is to find what mod is doing it and uninstall it.

Hmm, I haven't worked on that part of the wheels. However, I think there is a collider you can edit to handle this. Look for a spawn clearance collider of some sort.

If you need help tuning the wheel module I can give it a go.

Well, first of all, air-breathing nuclear-turbojets are very impractical and ineffective because air isn't a particularly good conductor of heat. This means the heat exchanger has to have increased surface area, and thus be heavier. More effective variants use a wet system where a coolant heated by the heat exchanger is injected into the airstream. Typical coolants would be methanol, liquid CO2, Liquid Helium or Liquid Hydrogen. The combustion of the coolant is minimal and not a real source of expansion compared to the raw heating power of this setup. Even water can be used in this manner, but it isn't the most effective option. It's thermal properties and boiling properties pale in comparison to methanol, which is the least effective coolant I mentioned. As of where water is used in the design, it is usually used as a stage 1 coolant to move heat from the reactor core to the heat exchanger, which would be water or heavy water in a traditional design, although newer reactor designs small enough for this purpose move to molten salt or other materials less prone to boil-off. There were experiments with this sort of thing in the 60s and 70s, but none of them were deemed practical, and most of them exceeded the radiation leakage level for regular usage. Honestly, if air-breathing nuclear-turbojets were determined a viable option, there would be no stopping the US Military from using them for Operation Chrome Dome in the early 70s. No amount of political pressure would outweigh the option to have bomber that only has to land to take on food and water supplies for it's crew.

Unless it was fixed in the latest update (which I just downloaded) there is a (very) minor bug of the separation mini-boosters using the wrong staging icon. (They use the standard rocket one, not the solid rocket one.) I know that this is a minor issue, so no rush to fix it.

As of textures, the only ones left still not working are the short tails. I may need to check if there are any recent updates that I haven't grabbed.

The problem is that it keeps throwing NREs and other debug error spew. They are almost all related to data in the KSC++ mod, which is why I suspect that. KSC++ also has some bad colliders that Kraken my crafts if I run into them. I'm thinking of using the lighter building mods next time I install Kerbal Konstructs.

Yeah, I'd have to try my hand at the canopy. I know how to approach it. For a bubble cockpit. A. Base mode: 1. Create an appropriate ovoid model that clips into a matching fuselage cylinder 2. Delete the portion that clips into the cylinder. 3. Put that block in layer, and give it a nice transparent material with a glossy glass effect. B: Edge "Seal" Trim: 1. Use an edge select to select the edges. 2. Use a feather on that edge select to create trim. 3. Apply a nice "plastic seal" or "classic leather seal" material to that. C: Re-enforcement bars: 1. Select cross-sections 2. Feather cross-sections lateral 3. Widen cross sections. 4. Add metal texture with rivets. D: Mount rails (Mount side) 1. Build base rail design as a simple rectangular pyramid 2. Apply an "inner rail" parallax map to the top to create the appearance of a trench line that can go below the surface it is mounted to. 3. Apply a nice metal texture brushed lengthwise with some nice rivets. 4. Duplicate via mirroring and place the two rails at the sides of the canopy (or any other object you'd like to attach them.) E: Mount rail interface (canopy side) 1. Create a flat plate with a small cylindrical axil and cylindrical wheel attached to each side of it. 2. Double up this on one side. 3. Mirror to the other side. F. Fine tune everything to mate nicely and mate to the 1.25m profile cylinder. Of course there is a difference between knowing how to do it, and actually being able to do it.

I have thought about taking a look at the model file to see if I can just remove the gun and have it be a rear facing seat. I also considered seeing about getting someone to build a slide open, eject off, canopy for this.

Yes, running a less powerful stage at full throttle IS more efficient than a throttling back. My point was that getting that angle lower and staying closer to the apoapsis will provide you with better TWR. Thanks for describing it in more scientifically verifiable terms. Also, that assuming all the burn is either vertical or horizontal WAS the fuzzy math I was talking about. Thanks for point that out. Additionally, the fact that he just gave his finished formula WITHOUT showing his work.

I'm thinking of checking the license to see about continuing this mod on my own. I'll probably strip out the tail gunner seat, rather than worry about the BD Armory stuff.

Oh, also combining all game generated physics on each part to single part into a single force set before applying it to Unity's slower physics engine should boost performance a little (if you aren't doing this yet.) Second, thread out terrain loading onto a helper thread to reduce it's load on the main thread if you aren't doing so already. Finally, put each vessel and each quad of the planet's surface in it's own layer, and only enable interactions between them if they are close enough to interact within the next half second or so. Furthermore, place each ship and, if applicable the quad of terrain under it in it's own "krackenbane" virtual space when it's on it's own layer set. Then integrate them when they are close enough.