Darinth

Exotic Solutions features a part capable of launching other parts into the air and continuing to apply forces to them at distance such that they can achieve sub-orbital hops. The problem is that as soon as something hits 25km, it gets deleted. I'm going to guess that this is the result of the standard deletion of anything on rails that leaves the physics bubble. Does anybody know if it's possible (and if so where I'd need to go in the API) to hook into the code and override the delete behavior to ignore crafts on their way up? Alternatives I'm aware of as potentials are to increase the physics range or decrease the atmosphere delete limited. Even a modest increase to the physics bubble of about 35km or a drop in the delete height to between 20-25km would let a craft be high enough up when it leaves the physics bubble to not be immediately auto-deleted. If I can manage it though, I'd prefer not to interfere with either of these mechanics.

There's also Kerbal flying saucers by Angel-125 which looks gorgeous, has a bunch of sci-fi related parts all themed around creating flying saucers. And Exotic Solutions which is my own mod and has a series of parts that work in various sci-fi related fashions. Currently working on the inertial shunts and catapults which is able to transfer momentum around wirelessly between crafts. Unfortunately neither of them is in a release state yet. Exotic solutions does have alpha releases with a few parts, I'm hoping to do another alpha release either today or tomorrow once I've finished the inertial module.

So, in my case I'm using the USI suite including life support for most of my resource intensive operations, and I'm trying to gain a better understanding of what causes the atrocious lag and what the most effective methods are for having functional, relatively lag-free bases in KSP. From what I can tell reading through the forums, and this is supported to-date by my circumstantial evidence in that I can build a 500 part craft with minimal lag, but a 100 part craft doing dozens of conversions brings the engine to it's proverbial knees, is that the resource system in KSP has a lot of issues. And when I say resource system, I'm not referring to memory allocations or anything along those lines, I'm referring to vessel resources (ore, metallic ore, substrate, etc...). So... what are people doing to reduce lag and make their bases functional? Right now, I've got 3 bases on the mun. 2 are automated mining bases and are completely lag-free. My 3rd base is too monolithic, and I know that's a large part of the problem. It handles all of the conversions from base mineable resources all the way up to finished products (material kits, specialized parts, machinery, supplies, colony supplies). The lag is at the point where I can still deal with it, but becomes frustrating over longer periods of time. So.. the question is... what are the best ways of handling these issues? I know I need to separate out many of the components of my monolithic base. I'm just curious if anybody has more knowledge about what needs separated and what will result in the performance increases. As an example, I was reading through a post that mentioned part of the problem is that a lot of the resource requests in KSP run in O(n^2) (or possibly worse). If this is the case, it might be a significant benefit to literally just take and have 10 bases that are relatively small in the same area because they're not hurt by that O(n^2) algorithm by keeping their part counts low. But I don't know if there are other issues that might make large numbers of individual bases in the same area problematic. Also, there are issues (due to using USI:LS) involving needing to put life support parts on all of these crafts (or at least on one craft within 150 meters of a cluster of others, as crafts within that range share at least some life support structures though I'm still not sure if they share colonization modules). This means that in order to fix a lag-problem within a game, I've actually gotta be less efficient than otherwise makes logical sense which is frustrating and so I'll admit I'm trying to balance my frustration over trying to handle lag vs. the frustrating which is going to be caused by adding otherwise unneeded life support systems. What are other solution to this problem? Am I even on the right track or is there a simple obvious solution that I'm just not seeing to handling the life support requirements while simultaneously managing all of these requirements? If possible, I want explanations as to why things work rather than just 'Do it this way, because reasons'. Feel free to be as technical as needed in the explanation. I'm an extremely competent coder and have worked with game engines a fair bit. I fully understand concepts like big O notation, and am capable of learning nearly any algorithm that I might need.

So, trying to play with the GNRs I ran into a problem. Given the tank mass:LH2 mass ratio, the highest Delta-V that can be obtained is actually lower than that of the NERV as far as I can tell (by a huge margin). If I had enough tankage (which is a huge amount of tankage) to get myself down to the same TWR that I have with craft running NERVs, the Delta-V is far lower. This is because the CRP definition for LH2 has about 1.4% of the density of LiquidFuel (which is accurate to the density of real LH2) and about 1/5th of the volume. This means that a tank with LH2 can hold about 7% of the mass of a tank that holds liquidfuel. With that ratio (and using the Kontainer Tanks from USI), that means about 64% of the mass of a container tank full of LH2 is the tank itself which results in LH2 based engines simply not being able to carry enough LH2 to go anywhere. Am I missing something? As far as I can tell... GNRs are worse in nearly every factor than a NERV is. They have a slight gimble which is nice, but they don't have the NERV's alternator and their effective max Delta-V is about 1/3th of a NERV due to tank weight. FYI, it appears that the only reason Cryo Engines is able to use LH2 is because most of the mass those engines burn is actually oxidizer.

Mostly full set of Flat cores, EVEs, Gravitic drives, EM Tanks, & a refinery.

Half of what KSP is teaches you orbital mechanics through trial and error. The other half is it simply engages your brain to be interesting in those mechanics, so you'll go and look it up yourself. Honestly, the mission system in game doesn't do much of use. Probably the most interesting moment I've ever had in KSP was when it allowed me to understand a physics concept that had eluded my understanding for years: gyroscopic precision. Playing around and getting to understand orbits I suddenly and intuitively realized how gyroscopic motion works. And after multiple attempts to understand it in other fashions had completely failed, suddenly understanding it was a legitimate adrenaline rush.

There's a bit of a blurry line in what constitutes an SSTO. My general requirements are A: Must make it to orbit without losing any parts through staging (feel free to activate parts through staging, just no dropping stuff) B: After it's payload is release, must be able to land again to be reused without refueling (reuse is the whole point behind SSTOs) What you do between point A and B is on you.

I'm mostly interested in this to make sure that my most recent saves are located near the top/bottom instead of right in the middle... for that purpose leading/trailing zeros are a simple and obvious benefit. And I'd put down good money that this is a single-line change to the codebase (surrounding whatever quicksave counter is used with a format statement to specify a number of digits).

So... we've all done it I expect. Every game in existence has trained us that shift and control are modifier keys that we can use to modify what we're doing. So it's instinct to try doing things like 'shift right-click' to open up the window for a second/third/etc part. What happens when you do so? You suddenly find yourself accelerating towards god knows what and wasting precious Delta-V. You can fix this by rebinding those keys... but KSP's keybindings are already a bit tight. A part of this problem is caused because KSP's default keybinding choice is IMHO poor and made worse by the fact that you can't use key modifiers in your keybindings. Ideally, I'd like to see Shift-Z and Shift-X used to set your throttle to max/zero and z/x to increase/decrease it and then reserve the shift/ctrl to be used properly as modifier keys. At that point, KSP's keybindings are pretty wide open to be properly setup however an individual wants them. Even just getting the keybinding interface setup to atleast give you the option of assign ctrl/shift + another key as your binding would go a huge distance towards fixing keybinding issues.

You seem to be working on some similar kinds of functionality to myself... just... a lot better and a bit earlier... This looks pretty awesome.

Orbital refinery, Gravitic Drive, 2.5m EVE, and an EM tank added.

Posted up an image of a test craft and an imgur album of it in flight.

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 ship 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 recomend 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 Images New imgur gallery Old Imgur Gallery

For anybody that google might point towards this topic in the future (as today it kept wanting to point me back to my own topic to find the answer) it can be found here and here. This issue was that the transform names listed in the engine config files are defined in the models. The model for the Vector defines a variety of transforms to connect particles to. The model for the swivel doesn't define the same ones. The only one I know for certain it has is thrustTransform. After using it for my particle transforms I had particles, though they were often offset or pointing in the wrong directions. Those threads also give guidance on how to adjust those properties and after fiddling around for a little bit I had all of my particles lined up and originating at appropriate locations. Here's my current iteration of the config file:

Have been working on a plugin, which is going great, but part of what I'm doing was extending ModuleEnginesFx. When I made my test engine I used the swivel as a base, not even realizing that it was still using ModuleEngines. Immediately noticed that the effects (at that point both sound and particles) weren't there, but didn't think much of it and continued with the designing the modified ModuleEnginesFx. Mostly done with that particular component of the plugin and decided to figure out how to get the particles working. Realized pretty quickly that the engine I'd used was based on the wrong Module and worked towards converting it over using the Vector as a base. At this point, I've got sound working but I still can't get the particles to show up. Anybody willing to take a look at tell me what I'm doing wrong?

Thank you for the input/responses. I'm curious to test if there's actually a rep hit for using it in atmo. Another possible balancing factor might involve identifying unshielded parts of a ship (anything that's not directly behind the ablative shield) and potentially damaging them or heating them up (unless the mod actually does this, my test rocket was a nice cylinder directly and fully shielded by the orion without parts sticking out so I wouldn't be aware.) The closest thing that KSP seems to do to modeling radiation is the excess heat that the NERV puts out. This may simply boil down to personal preference. It feels a bit much to me atm.

So... after testing the power of these in my sandbox world before using them in my current playthrough, I came to the conclusion, at least for where they sit in CTT, that these are OP as excrements. I'm trying to figure out if I've missed something about them which makes them not incredibly overpowered. They've got a steep price on them, I can see that, but sitting at the 550 tier they let me execute a brachistochrone trajectory to the mun in about 10 minutes. Putting one of these on a ship could easily allow me to bypass a lot of game mechanics by sheer power while still in technology that is otherwise considered mostly if not entirely conventional. Is there some downside that I'm not seeing, or is it simply a matter that this is just too overpowered for my personal tastes?

One of the balance passes reduced the bubble size of the 3.75m drive from 44 to 37.5, but didn't update the bubble guide. scale = 2.2,2.2,2.2 needs to be changed to scale = 1.875,1.875,1.875 I've got a pull request that should resolve the issue. You can fix it yourself by changing that or changing the bubble size back to 44 if you really want the larger bubble.

@Doggydog Is it always the same parts being ripped off and are they always ripped off or only sometimes? Try reinforcing the parts with some struts. This may be an unfortunate issue where I think KSP/Unity just doesn't know how to handle some of the physics involving what warp drives do. Reinforcement may ward off the kraken.

Figured out why the drive was getting stuck 'on', I set the ignition threshold to 0. Unfortunately, I didn't realize the alcubierre drive was hard coded to destroy vessel parts if the warp field collapsed. So this will require code modification to work no matter what. On the positive side, this drove me to play around with setting up a modding environment for KSP which was *WAY* easier than I expected it to be. I might actually just do some modding and make this myself.

So... I spent a decent chunk of tonight trying to make this. After trying out a lot of different variants to figure out if it wasn't working right because I was doing something wrong, I think that something in the warp drive plugin just goes completely haywire with these bizarre settings that it has no clue how to work with. The general idea was to make a single use 'ship teleporter' that went a fixed distance. I can think of two uses for this: "I dun screwed up! Abort this landing!" and the warp drive equivalent of an SRB. The idea was to take a warp drive, give it a tiny amount of exotic matter, remove it's ability to produce more, and lock the throttle. Once you turn it on, you're going and once it's expended, that's it. Ideally, I'd actually want it to go from point A to B instantly, but this was the closest I was going to get without digging deeper into KSP and making a new plugin. Unfortunately, it has (at least) two issues. The first is a nasty habbit of simply exploding on the pad when it gets turned on. The second, it continues to run after it runs out of exotic matter, forever. If anybody is interested in tinkering with it, they're welcome to it. If you figure out a way to get it working, I'd love it if you could let me know. Roverdude, on the unlikely off-chance you want it, you're welcome to make use of it if you can get it working.

There are still issues. I wish the EL had the capacity to just select parts to build. You're correct that it's technically possible to do this, but unless I'm unaware of something the only way is to build a 'ship' with just that part and then use EL to construct it.

Ever figure out what was going on with OSE? I want to play with KSPI, but to be honest am unwilling to give up the ability to produce parts on-site.

While that'll work for the nodes that I can't manage to fill out, I'd actually really like to find useful things to fill in the nodes with.

Does anybody by chance have a more comprehensive list of mods that make use of the tech tree. It's great to see a bigger tech tree and I've got some of the branches filled out decently, but there are still huge chunks of the tree completely unpopulated for me. I have nothing on or past the following nodes on my tech tree: Experimental Nuclear power, Fusion Power, Improved Nuclear Propulsion, Colossal Rocketry, Extreme Fuel Storage, Subsonic Flight, Specialized Landers, Specialized command centers, Specialized science tech, Exotic Plasma Propulsion, High Power Electrical systems, Exotic Solar Technology, Heat Management Systems, Advanced Colonization