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!

I'm currently trying to build a part that can deploy an energy shield. After a few iterations, I've gotten as far as creating an energy shield with a fair bit of success, the biggest issue at the moment is that if the shield doesn't start turned on, the craft will perform rapid disassembly upon being turned on. If it starts turned on I can turn it on/off as I wish, but it seems like when it gets turned on it is subjected to odd physics effects and rips the vessel apart. Currently, I have a model (.mu) that consists of a transparent model and a collider that is a hollow sphere. The .cfg file reference the model for the mini ISRU (which is what I'm using for the part model) and the sphere shield .mu. I've also got 2 sets of drag cubes, one for when the shield is active and one for when it's inactive. To turn the shield on/off I simply mark the game object that has the shield model & collider active/inactive and adjust the drag cube weighting (the ship tears itself apart regardless of if I adjust the drag cube weighting). I'll eventually have to work on marking objects shielded/unshielded I think, but I'm not 100% sure on that. Thus far, I've tried initializing the shield in OnAwake, OnInitialize, and having now been doing it in FixedUpdate with a boolean flag to indicate when the shield state needs updated. Regardless of where I do it, the ship will explode when the shield is turned on if it started in the off state. I've also tried adjusting the shield gameobject to several different positions after examining the locations of other gameobjects on the part using KOI and thinking that if I matched them it might balance out the physics forces. I've also tried calling part.update() as I seem to recall that there may be something I need to do to tell the KSP engine that a part has changed. Any ideas on what might be causing a part that gets a collider added to it to tear itself apart or something else I might be doing that would cause it?

@SpannerMonkey(smce) Actually the atmospheric effects are more what I'm expecting and looking to make use of. The shield isn't really designed for combat, it's designed for late game atmospheric reentry. My current stated objectives for the shield are "At a bare minimum, should serve as a craft-wide heat shield and air resistance to slow you down on re-entry. Ideally, should also be able to soak collision and allow parts (solar panels, radiators, antenna) to ignore aerodynamic forces as long as the shield holds."

So... 40 fuel cells was not enough to lag out my game (with all of them running to keep up with the power demands of me running ridiculous reaction wheels), but I also wasn't able to lag it out by creating a facsimile of my base in the VAB and launching it and turning on all of the machinery. I've been thinking for a couple of days on what could be going on, because I really expected that second test to produce the expected lag and when it didn't was really confused. My facsimile wasn't perfect, and so I may have to painstakingly recreate in the VAB the craft that has been slowly put together in-situ on the mun with KIS. I'm also going to create a larger craft and try to get a count on just how many fuel cells would be needed to start seeing lag. I also realized I didn't actually turn on planetary logistics, and I'm now wondering if that might be what makes the difference. Maybe planetary logistics is actually a much larger issue with base lag. Will post something back here again when I have some more information. This is, so far, actually really confusing.

This still seems like the most valid location to ask this question, my apologies for minor thread necromancy. Any ideas on what could be done to have an object appear in game and be interactive with all of the game physics, but not be mouse-interactive? Trying to figure out a way to make a energy-shield that would surround a craft without having said shield block the ability to click on and interact with parts.

Been a bit since I updated, but really excited about this one. No energy shields yet, but the Kinetic tech is completed. I'm hoping to get a video made, I'm really happy with how this stuff has turned out. The first tier of it is designed to function similarly to atmospheric engines in that it's only useful close to celestial bodies, but it doesn't require air simply proximity to a planetary body. This makes it especially useful for maneuvering near airless bodies. The second tier is more useful for stations and bases. It's much more capable for affecting other objects, giving it more capability for A:orbital rendezvous, B: launching things into orbit from airless planets, C: catching incoming crafts. The kinetic tech has options for killing surface velocity and orbital velocity automatically, allowing for effective automated hovering of craft. It also has options for relative velocity killing for ease of rendezvous.

There would be no way in ksp to build a dyson sphere. The project would be ludicrous. A dyson swarm... maybe. But either way inertial/kinetic shunts aren't a technonolgy that would be useful for this. I expect their biggest uses are for near-celestial body maneuvers and space-station rendezvous, with the later having dangers related to changing your station's orbit (or even deorbiting it) on accident. They allow you to transfer kinetic energy over distance. So, I apply thrust to an object in one direction, but must apply an equal and opposite thrust to another nearby object. If you're close enough to a celstial body, you can dump the kinetic energy into it giving you massive delta vs within a few km of the surface. The earliest ones will only be able to apply a force to themself by dumping that force into another object. Later ones will be able to directly transfer kinetic energy between two nearby objects. I may make another tier beyond that with tremendous range, but that may be a bit too broken for my tastes.

Ohh wow. I had no clue that KSP allowed for the changing of physics ranges on individual vessels. That changes a lot on what I can do and now that I've looked up the specific vessel ranges and physics configuration defaults some of the odd issues I was having make a lot more sense! Thank you. That should be just the tidbit I was needing to fix the rest of these issues.

This probably isn't as big of a performance issue as you'd expect. Local logistics only kicks in and looks for nearby resources if it runs low on resources. So it should only be doing checks of other nearby vessels on pretty rare occasion. I'm in the same boat. I'm hard pressed to believe it's not resolveable, but there's no good solid information on how to build out bases so you don't end up with horrendous lag. I'm probably going to sit down in sandbox and drop a whole bunch of smaller, individual converter parts to see if I can get to the same setup as what I have in my career save with less lag. I'll report back what I find once I'm done. That actually makes sense. Each fuel cell has storage for electricity and manipulates 3 different resources while it runs. If that's 20 fuel cells. Each one is looking at the electricity stored in all 20 fuel cells (400 checks) plus both the LF and O in each of your storage tanks. That means another 40 checks every physics tick per LFO source. At 30 fuel cells that's 900 checks + 60 per LFO source. Every physics tick. I feel like the resource system needs an overhaul to, unfortunately, be less granular or have some optimization so the individual parts don't have to be checked with as much frequency which is absolutely possible, but it is a good chunk of work to write the code to figure out when checks to individual containers are and aren't needed.

Currently working on the inertial shunts/catapults which have actually turned out a lot of fun to play with, which is actually why they've taken a bit of time to get out. I may have spent a few hours building different crafts in attempts to do things like be able to make it to orbit exclusively on the propulsion they provide and seeing what their limitations are as far as orbital distance on their current stats. Given where I'm looking to put stuff in the tech tree atm, the energy shields are next. Once they're done, I'm contemplating doing a balance pass and a first beta release as it'll be the first 2 big groups of technology complete and the EVEs later on.

Not as of yet. Right now I'm working on functionality, numbers balance will come after stuff works. I'm contemplating making a balance pass and releasing a beta after the inertial shunts/catapults (probably going to be renamed to kinetic shunts/catapults) & shields are in.