Ruedii

I have not personally had the issue, but some people have been complaining about performance issues with the new releases. I strongly suspect that this has to do with the added rendering passes required for the reflective surfaces. Adding an option to drastically reduce the quality of that pass, replace it with an algorithm that only reflects light emitters only or (for lowest quality) a simple specular algorithm. Preferably having all three options would be best. We all like shinies, but some of us like mods that hurt performance more when combined with them. The other thing that might add issues is the Delta-V calculation system. All that can be done should be done to keep this routine garbage-free (Permanantly attaching the routine to the vessel object, using permanent data structures for any intermediary variables in the calculation and display process. Using fixed layout for display instead of dynamic.) Allowing the user to cap the refresh rate of all on-screen statistics and many other HUD objects should help. Calculating them at a fixed rate instead of every frame would drastically reduce overhead. Generally the option should be give for 15 times a second 20 times a second, 30 times a second, 40 times a second, 60 times a second or every frame. Since these are relatively static objects 20fps should be default on low performance computers, and 30 on high performance computers. Consoles should use 15 or 20 times a second. p.s. Sorry for the late reply, I just figured this was the right place to put it considering it is a release related issue. Based on feedback by other players I will make independent suggestions for these as well.

Any way this could be ported to one of the fully open source computer math systems? There are some pretty incredible ones out there, many of which put MATLAB to shame now. (NASA almost exclusively uses the various open source mathematics systems and mathematics languages they have recently contributed to.) The various Open source languages work different. I think any programing language with the ability to generate 3D or psuedo-3D graphics would be good for this. The lightest most generic use application that would work is Libreoffice's extended math packages. (Could do some really nifty stuff with that and export some pretty HTML5 pages or word processor documents with that with that the could include nice forms docs with nice encapsulated macros with the formulas pre-simplified for each purpose.) Axiom is also good. This would be a nice tool. This tool predates MATLAB, but recently has seen major enhancement due to being open sourced. As is (Wx)Maxima: This was an alternative to MATLAB built from the ground up by various contributors to create a free and open solution for scientists so they can integrate far more advanced tools.

Unity finally released a slightly improved GC in their 2019 Beta! It still isn't a modern Generational GC (groan) and is still full stop the world (double groan), but they finally added a change to support for incremental mode at least, so stutter should be substantially less. Could we get this fast tracked for the next KSP release?

By tank size I mean length, not width. Sorry if I was unclear. The whole point is this particular width that allows the matching of the electron platform. Any other width would be smaller to match any accompanying probe equipment.

Yeah, Intersteller FuelSwitch will probably break on this update. It messes with fuel tank quantities. Currently the new texture switch is retro-ported onto the mod by Interstellar FuelSwitch (A lot of legacy mods are using this function of Intersteller fuelswitch. It was nice of them to put in.) However, many visual materials (texture shader combinations) may stop working properly with these some of these new shader functions and the accompanying render pipeline changes.

The amount you can recover in costs with reusability is actually pretty substantial. Especially when doing heavy lifters. The best heavy lifter for reusability is a simple 3 stage with a disposable solid booster attachment (with on-booster drop-tanks of course). The maintainer stage gets almost to orbit then detaches, leaving the orbital stage to finish. For a super heavy you could make a separate maintainer/core and orbital attainment stage, then detach reenter the orbital attainment stage with a tiny bit of extra fuel. There is a little bit of tricky jumping around between subvessels, but after the core stage reaches suborbit and is detached, you achieve orbit, then switch back to the core stage and land it. You then deorbit and land the orbital attainment stage if you use one. (That is if it isn't doubling as an orbital placement stage, in which it returns after it's done it's job.)

According to his redit posts he's been doing a lot in Elite Dangerous lately. Anyhow, I might try to fork it from the github page sometime. I'll be getting a new hard drive soon so I'll finally have working space to do actually productive things on my computer. That battle with the free space has been what has been keeping me from really getting into modding. (Modding tools take up a lot of space.)

I know I already asked this on Fuel tanks plus, but could we get this, Fuel Tanks Plus and Color Coded Canisters map the stock textures to the list of selectable textures? BTW, I love this mod!

For future versions could we get the new stock textures mapped to the texture switching options on this and color coded canisters?

Anyone have an update on KSP 1.5.x status on this now that Contract Configurator has been updated for 1.5.x support?

Honestly, I doubt that KSP has things move fast enough on a regular basis to make higher refresh rates noticeable on a non-VR display. It isn't like it's a first person shooter game where you have to aim at moving targets. Honestly, if I was choosing a monitor for KSP, I'd go for other display quality attributes, such as higher resolution. KSP suffers from bad anisotropy and aliasing and a higher resolution would reduce this.

Is this working on 1.5 now that Contract Configurator has been updated? Has anyone else tested it?

With VR, the screen is closer to your eyes. I'm talking about when you are sitting a normal distance from the screen.

Assuming it's a stock game there shouldn't be any major issues. Wheels changed mechanics slightly, so you might have to readjust their advanced tweakables configuration if you use them. Otherwise, any changes other than added parts are purely cosmetic.

That's probably the biggest argument against it. I didn't think of that.

I noticed that some developers used the two tier trend where they put all the mods they started (not necessarily ones they maintain) in a single directory with subdirectories for each mod. This goes with the mode directory as: GameData/Developer/Mod/ I honestly like this layout because it reduces clutter and prevents conflict if two devs accidentally chose the same name for their mod.

So basically cool ideas, but beyond the scope of this mod. Thanks!

Two good uses: 1. MASSIVE heavy lifter stages 2. Massive fuel tanks on stations, and interplanetary mother-ships. 3. Massive long range interplanetary tugs. 4. Massive fuel transports. Basically, they are for moving big stuff around. A really good way to use them is using them in space to feed a Wolfhoud clusters with them. That gives massive high-efficiency engine tugs for your mother-ships. For lifters they can be great for launching 3.75 and 2.5 meter equipment, as well as (obviously) for getting the 5m equipment off the ground.

The visibility of framerate has more to do with how fast things are moving on the screen relative to physical distance on the screen. So the bigger the screen the more you will notice improvement from higher framerate. The same goes with higher resolution, as the bigger the image is being scaled to the bigger the pixels. I find it annoying that people don't understand that when they have a 26 inch or 32 inch monitor of course they can see more detail and more motion, but somehow expect that to translate down to a 15 inch or 19 inch monitor.

On 1, 2 and 3 are for creating variant designs based on the platform wouldn't be a bad idea. 3 might be unnecessary, though, as a heavy lifter for this radius would be pretty useless. As of multiple engine modules in a single part, as long as the center of thrust of each engine module is the same, independent engine modules are absolutely possible. The best way to implement this might be like the "switch mode" on the rapier except switching out emitter patterns as well to indicate which nozzles are active.

Don't put your engines too close together, and certainly don't clip engines together. Second, you shouldn't need that much power to launch anyhow. You need about 2.0-4.0 TWR for the first 20-40 seconds of launch followed by 0.5-1.5 TWR for the remainder. Angle 5 degrees from horizon, lock to surface-forward and get your time to apoapsis to between 45s to 1m and hold it there until the apoapsis reaches the desired height (between 70.1km and 80km, really your choice). After that, circularize at apoapsis and you are good. p.s. Now I'm going to prepare to be called a heretic for suggesting you need less launch power.

Any way you could make a few Science Senior parts that incorporate several experiments and a science storage. Here's a quick list: Science Sr. 1.8m diameter (with top/bottom designed to look clean when attached to 1.25m parts) Materials Bay Mystery Goo Thermometer Barometer Science Storage Unit Some KIS storage (if KIS is installed) 400 electric charge Ultra-Short range science transmitter (500K) Science Sr. XL 2.5m Diameter (Same nice top and bottom for fitting 1.8m and 1.25m parts cleanly) Everything in the Science Sr. Second Material Bay Second Mystery Goo Acceleratometer Fluid Spectro-Varometer More KIS Storage (if KIS is installed) 1000 Units Electric Charge Medium Range science capable transmitter (50M) Science Sr. XXL 2.5m double height, or 3.5m single height variants available Everything in the Science Sr XL Lots of KIS storage (if KIS is installed) 3000 units electric charge Long range transmitter (500M)

A few requests: Multiple colors/styles, some using stock textures. More tank sizes (of course) Matched radial decouplers for heavy lifter designs. Base engine operates as technically 3 engine modules (Center, Side, and Booster) that can be toggled individually using action groups or toggles. Multi-Parachute stage cap assembly for those of us who prefer the inaccurate but easier chute-based landings. Matched style in-line probe core. Theoretically it should work, just add the appropriate additional modules to the config file. Please note the disclaimer of "Theoretically." I've never seen that combination be done before, so it might not work. The drone core modules are non-animation modules and thus can be added to any part in theory, but the fairing base creates a child part-set (the actual fairing), and that could create issues. I'd make sure to test it, because you know Murphy's law.

Old laptops sometimes had them. Some tablet computers still have them. 60Hz interlaced was actually common on older CRT monitor displays for higher resolutions, because the horizontal sweep couldn't reach high enough rates to handle the higher row count. 1080i is technically 30Hz for a full refresh (two vertical sweeps for a full refresh).

Technically Direct3D 10 w/ SM3 is just as good on KSP. I don't even know if KSP uses SM4/SM5 shaders at all. Direct3D 10 changed the context management method for texture maps, improving memory footprint drastically. OpenGL probably has the best memory savings. BTW (Vulkan probably better still, but it's horribly buggy. I'm surprised they build with the beta Vulkan support in Unity.) They went released 1.5.1 only a couple days later with a small number bug fixes.