Darinth

I'm wondering if your issue with the DIY kit jumping between the two locations when in timewarp is an issue with colliders. One of the things I learned when I was making the energy shield for ES is that objects that collide on the same vessel will often just push each other away and not break. During timewarp, physics and collision are disabled which causes that DIY kit to move to the location of it's actual attachment. As soon as timewarp ends, physics kicks back in and forces the DIY kit back to the edge mostly. But at that point, the joint and colliders are fighting each other and I've learned that parts can be forced inside of each other by physics forces applying a sufficient amount of force. After you break and recreate the joint, try using CollisionManager.IgnoreCollidersOnVessel(vessel, newCollider); on the DIY kit's collider. After breaking and recreating the joint it may necessary to tell KSP to ignore the colliders again.

Release thread is now up.

You now have my complete and undivided attention...

Exotic Solution is ultimately designed to provide alternative methods of doing a lot of tasks. It firmly leaves the realm of real-world physics and goes well in to science fiction, but makes an attempt to maintain the physics-oriented gameplay inherent to KSP. The mod focuses around Exotic Materials and Exotic Energies. Exotic Materials have to be refined in a zero-g environment, but can then be utilized anywhere. Exotics Cores convert Exotic Materials into Exotic Energies, which then power the advanced technology. When a vessel is recovered with exotic materials/energies stored they are all converted into exotic materials and stored in the KSC and can be used to launch ships again. There is no buying/selling of exotic materials. Exotic Solutions is 'Balanced' around extended techtrees and the inability to buy exotic materials at the KSC, they must be produced and landed back at the KSC. I strongly recommend installing an extended tech tree for use with ES. Currently, I'm building in support for CTT. I'll be happy to accept pull requests for other tech trees and may be willing implement support for some of them if I can easily find the information I need to do so. Part Types Exotics Cores: Convert Exotic Materials into Exotic Energies. Conversion is very slow, refilling an EE core takes a couple days. Only a single core can be active on a vessel at any time and all inactive cores convert their stores of EE back to EM slowly, but still faster than the generation rate. Exotic Variability Drives(EVEs): By default, these drives are slightly worse versions of drives available earlier on, however by expending exotic energy they can be given far more powerful thrust and ISP. Isp/thrust can be changed in flight, as it is increased the engine will consume progressively more EE. Gravitic Drive: Runs on EE & EC, produces negative gravitational mass which effectively lifts the craft away from it's SOI with force proportional to gravity. Not able to produce propulsion laterally. Refineries: Refine Exotic Materials. Must be refined in-orbit, exotic materials will not be able to be refined on the ground, they require zero-g environments for formation. Kinetic Shunts: Capable of locking on to surface of celestial bodies or other crafts. Transfers momentum between itself and locked on target. Allows for a wide variety of powerful maneuvers with fairly minimal weight, but requires something to transfer momentum to. Kinetic Catapults: Capable of locking onto two targets and transferring momentum between them. Capable of launching other objects without moving themselves. Energy shield: Serve as a craft-wide heat shield and air resistance to slow you down on re-entry. Also be able to soak collision and allow parts (solar panels, radiators, antenna) to ignore aerodynamic forces as long as the shield holds. Water collisions are real funny, and I may not be able to fix this. I may ultimately remove all of the collision soaking capabilities, resulting in these acting entirely as advanced craft-wide heat shields and to a limited extent parachutes due to the atmospheric slowing. Also, currently the only things that cost shield energy are atmospheric reentry heat and collision. I haven't been able to figure out how to figure out the aero forces that are being applied to a part to take that into account. [Not yet implemented] Teleporter: Teleports stuff. Ideally, should be capable of teleporting resources, kerbals, and ships. Requires velocity matching to teleport. Blink drive: Ship self-teleportation. Preserves momentum, but can instantly teleport several hundred kilometers. Precise distance transportation. Mass inversion generator and/or tank: Reduces it's mass and the mass of nearby parts. Increases delta-v, can substantially increase craft manueverability by doing things like placing it on a gimbling engine or other nearby heavy parts. Current Parts Flat Exotics Cores (0.625m, 1.25m, 2.5m): Look like batteries of their size. EVEs (0.625m, 1.25m, 2.5m): Look like existing engines of their appropriate size Exotic Materials Refinery (2.5M): Looks like the science lab Exotic Materials Containers (0.625m 20EM, 1.25m 50EM, 2.5 400EM, 3.75 1800EM): Look like small fuel tanks Gravitic Drives (1.25m, 2.5m, 3.75m): Look like medium fuel tanks Kinetic Shunt (1.25m, 2.5m): Look like ISRUs. Kinetic Catapults (1.25m, 2.5m): Look like RA100 relay satelites. Energy shields (1.25m, 2.5m): Custom models! Produce a 10m and 15m shield around the part. Github Repository Issues Releases More Images!

@guesswho2778 All of the software you need to do modeling is available for free. Blender and Unity are both completely free to use for these purposes. That said, right now I just need to know if it works. Were you able to find the rest of the parts and have you noticed any issues with them? Spacedock is probably not particularly likely. I'll probably rely on the forums and possibly CKAN at some point, though that's not a priority atm. I'll probably be making a release thread if what I have to date seems to be all in working order.

Wanted to drop by here and state a strong opinion that the lag is not caused by base game resource conversions, at least not alone, nor does it appear to be caused by MKS conversions. I've now created crafts with 288 fuel cells and ran them both in a fresh sandbox and my current 1.4 career. In both of these instances, the lag is measurable but not anywhere near what I see in my Munar base. Both saves lag when the fuel cells are turned on/off. When I load up the craft in sandbox, I run at 58 fps and that drops to about 38 fps when the fuel cells are running to charge up the empty batteries the craft starts with. In my career save, the craft loads up at about 45 fps and drops to about 28 when I turn the cells on. In both of these circumstances, the clock stays green which I believe is an indication of the rate fixedupdates which process the physics are being called. Distinct amounts of lag... but that's with a remarkable 288 fuel cells all running. My Munar base on the other hand, runs at 20-22 fps and (at best) a frame or two increase when I disable all of the conversions I can find. The clock stays permanently yellow when I'm over there. Still haven't actually recreated a precise reproduction of my Munar base on the launch pad. I guess that'll be the next step. Do that and then begin tweaking different things until I see a substantial gain in fps or fixedupdate rate.

New release on github. Changes: Only one exotic core active on a vessel at a time, inactive exotic cores slowly turn EE back into EM. Added es exotic solutions ee energy energies tags to all modules. Added a variety of other tags to parts as needed. Part recategorization Moved cores to science, drives to engine.

Will probably move all most of the parts into the science catagory and make sure that they've all got tags on them to easily find them.

I'm going to guess you've got something installed incorrectly or may simply be having trouble finding them. A number of the parts are difficult to spot because they look like squad parts. Folder structure should be "Kerbal Space Program\GameData\Exotic Solutions". The Exotic Solutions folder should have CTT.cfg, Resources.cfg, ExoticSolutions.version, and the parts & plugins folders under it. If it looks right let me know. It's possible I've done something odd. Also, just uploaded a new version to github. Rework of the EVE drives, gravitic drives, and a balance pass on the kinetic tech. Edit: Also, I don't think it's possible to have part collision without ground collision.

The way that mechjeb handles rotation control (a PID controller) I don't think it's possible for it to not take into account gimballed thrust. The only craft that I've had serious enough issues with mechjeb that I just wasn't able to get mechjeb to control it was a massive 'mothership' style craft. It had a central shaft and essentially had a half-dozen additional rockets hanging off the sides that could dock/undock to do things like science or fuel runs to a moon/planet. It had two of each child craft, 1 on each side to guarantee symmetry and everything was aligned down the center of mass... but still mechjeb couldn't managed to keep the craft from oscillating back and forth. Even after I played with the PID settings, it didn't work. To be fair, stock SAS only handled things a hairline better. Mechjeb doesn't generally handle extremely agile craft or extremely sluggish craft very well. If you're on either of these extremes, you may have to adjust your PID settings or ideally adjust the craft to be more/less agile. Also, as has been said, make sure that your RCS is well balanced. As an example, a craft with a TWR in excess of 12 is almost always going to fail it's descent, because mechjeb calculates the suicide burn, knows it can stop the craft's 2000 m/s in just a few seconds, and does a fantastic job of canceling your vertical momentum. Unfortunately, physics says that when you're firing an engine with that high of a twr, being even the tiniest bit off results in the craft tilting to the side and that tends to result in a crash and burn even after canceling your vertical momentum successfully. Check your TWR. Make sure you've got enough RCS/reaction wheels/attitude control and that it's well placed. Make sure the craft is well strutted, use auto strut. Another issue that can pop up is that if a craft 'flexes', then it can cause an issue. All SAS and mechjeb attitude control is based on your control point. If your control point is able to go out of alignment with the rest of your craft, it can cause an issue. I once built a craft with a bunch of reaction wheels attached right near the cockpit. What I didn't realize at first and laughed when I realized what I'd done, is that the reaction wheels were so powerful they were actually rotating the cockpit before the rest of the craft which was confusing the hell out of the attitude control. Long story short, mechjeb isn't perfect, nor is stock SAS, but they're both pretty good unless dealing with extreme situations. I'll put money down that either something has gotten messed up in the install, or there's something odd with the craft itself. Btw, depending on what you consider extremely short, you may be running into the 'too high twr' problem. An easy test/fix for this is to set the thrust limiter on the engine lower. This will reduce your TWR and if the craft lands fine that's probably your issue. The gimbal is being taken into account, it's just too powerful to be effectively balanced.

I played for a very long time without even realizing buildings could be damaged. In fact, the first thing that queued me in that buildings could be damaged was seeing the indestructible buildings option which caused me to immediately go and test crashing rockets into my launch pad and vab. It sounds like this is mostly a problem of rocket design an flight. Get slightly longer first stages and/or pitch over a bit earlier so your first stage is missing the pad. You'll get more efficient launches that way anyways. You don't want to be going straight up for long after launch generally.

I think this is really the fundamental problem with science. Building out a proper set of stock automation tools so you can tell your probes & kerbals to follow a set of actions would eliminate a lot of the drudgery. Unfortunately, this is mostly meaningless without the ability for these tasks to occur on the background which gets into questions of physics simulations. There are extreme limits that are just a part of the game engine, and while technically able to be bypassed I don't think it is realistically able to be bypassed. This means making estimations that are close but don't actually simulate the physics for a rover moving across the surface, for a craft doing a suborbital hop & reland, etc... This is my pie-in-the-sky ideal for what I'd want to see. Instantiation of multiple krakensbanes/floating-point origins and improvements to the physics engine that are sufficient to allow several crafts to simultaneously be undergoing physics simulations regardless of distance. Unfortunately... it really is a dream. I don't think KSP will ever be able to support that level of automation.

Adding elements along these lines is really something I'd love to see. Adding in elements of automation for things like "Here. Take this rover and go to locations x, y, and z and do all these science experiments at all of them." or "Follow x launch profile to get into space, follow y flight plan/set of maneuvers to get to the mun, land at z location. Turn on your mining drills, when your tanks are full, launch and return to Kerbin." Unfortunately, in order to have any chance of this working would require massive overhauls including such things as multiple active floating point origins/krakenbanes so that multiple vessels could be kept active at any time in order to do physics simulations, not to mention performance increases that are an order of magnitude more efficient in order to make a computer realistically capable of running it.

Aaaaaand Energy Shields! They feature my first custom made models, both a part model and the shield model are custom. I may actually remove the collision soaking capabilities from them. Realitsically, they're both A:not particularly useful, and B: a little wonky. At this point, I'm just going to be revisiting some of my earlier parts and updating their mechanics and then running a balance pass. Most of the 1st 4 tiers of tech that I'm planning are implemented. After the balance pass, I'm planning to release the first official beta. If anybody wants to look at it, github does have an alpha release up-to-date with this morning's work.

Yay! You fixed it! It was the CollisionManager, though I'm not certain why. I'd specifically made the sphere collide hollow. I'm going to assume something was lost in translation with unity and that despite my best effort, it is in fact not hollow as intended. Thank you!