W1ntermute

Course begins March 3rd and will be lectured by former NASA Shuttle Astronaut and current MIT Professor: Jeffrey Hoffman URL: https://www.edx.org/course/introduction-aerospace-engineering-mitx-16-00x

After an issue with one rocket blowing up the launchpad in Sandbox mode, I decided not to revert as the space centre mode has a button to repair the launchpad if it needed it. Unfortunately this won't occur, when I click on the launchpad, the button stays greyed out and the status of the launchpad states it isn't in need of repairs?!? Yet it clearly is destroyed with the rubble and the askew angle that the rocket is on when trying to launch. Does anybody know how to fix this? Why isn't an option for indestructible buildings in the regular options menu, why is it only selectable when you start another sandbox campaign?? Why was destructible buildings the 'default option' for older sandbox saves. It's really annoying tbh. I've had this save since v0.21

Hey Cybutek, i've been able to make Engineer parts from v0.6 totally backwards compatible with v1.0. It's very simple, you copy the EngineerChipFlight folder from the v0.6 of Engineer into the parts folder for v1.0. No messing with configuration files or anything required. It works perfectly. All my ships that had the 0.6 parts are fine with the newer version. No issues. I love the interface in V1.0 btw, very clean

I think somebody should devise a mod for KSP based around this principle, something in the vein of a steam engine with forum posts as its coal

Amazeballs Yanfret! btw, says planetshine has compatibility error with 0.90

0.90 no likey KSPAPIextensions Anybody else get this? I guess you could say; "somebody beta fix this dll" (*drum roll)

Patronizing reply. Especially to somebody who codes for a living... Yes, optimization in regards to removing the Asset loader and instead getting the program to load assets in and out of memory dynamically as it's running, both in the background and synchronously (not cache everything the game has in at startup) is something this program begs for and should have been addressed at alpha. It shouldn't be loading up with a +4Gb RAM requirement on the vanilla installation, especially for a program that has an extensive modding user-base and balloons that memory requirement exponentially because of texture decompression with each mod installation. When you code a game that is reliant on such a method of asset acquisition it becomes increasingly difficult to implement a more streamline and efficient method to replace it such as dynamic asset loading. The Asset Loader is easier to implement, but it's also symptomatic of lazy coding too. There's no reason for it to exist, especially when we live in an age where single core CPU's are now a thing of the past. It has to be removed.

This, my God, THIS! Get rid of the Asset Loader! Worst, most laziest thing built into KSP

Could you pls compile these builds into different OS formats? for those of use who don't/can't do it. Thankyou

This would be a great mod if other mods had alternate DXT versions in their textures so there was no slow load in the initial run, nearly 3hrs for me only to find my clouds disappeared and no planetshine either. Reverting back to ATM 3-1 till further notice

this game needs an optimization overhaul

Here's an article on the dev team that's working on the game 'Rust'. Seems like it went pretty painlessly and with major improvements to sound and Physx implementation http://blogs.unity3d.com/2014/11/19/porting-to-unity-5-the-untold-rust-journey/ So Squad, when can we expect a shift over to Unity 5 for KSP?

Fuel lines - honestly, that's retarded. Radial monopropellant tanks don't need fuel lines, why should the other radial tanks in this mod require it? I'm using these radial tanks solely for this stage of the rocket, so when I put in tandem the radial tanks of oxidizer and liquid fuel, there shouldn't have to be fuel lines connecting between them. Just like any normal fuel tank. This stage of the rocket doesn't even have a combinded l.fuel/oxidizer tank for the fuel lines to connect and finally go into, I want to use them on their own because the regular tanks are either too bulky or too low in the combined fuel content. My using them is to reduce size and fine control the thrust to weight ratio. The engine should recognize that there is both oxidizer and L. fuel available for that stage from the two different radial tanks placed within that stage without the need for fuel lines. That's what I'm trying to get to work from this mod. Fuel lines, smh... What's the point? Useless

When placing separate radial liquid fuel and oxidizer tanks in conjunction on a rocket to power the engines, Ive noticed the engines within that particular rocket stage they're attached to don't recognize the oxidizer tanks and thus wont ignite. Infact when I attach the radial oxidizer tanks to any other stage, it only adds greater weight to the ship relative the the radial tanks weight but it doesn't increase the total amount of oxidizer available. Is this a bug of the mod within 0.25? I distinctly remember them working on earlier versions

this runs great in x64, no major issues. Cockpits are a bit dark when in planetshadow (both in orbit & landed, the console/cockpit lights don't illuminate kerbalnaut faces) but all else, I love the simulated raytrace-like color bleed effect, V. nice

Thanks for the compression update dude, I can finally run 0.25 x64 again lol

firespitter should be part of the default core code in this game

Whoa, patronizing much?!? They asked pretty simple straight forward questions. You should've just ended it after the first 'can.'

Thanks for this, I find this version really stabilizes memory usage. To explain, after loading KSP with any version of B9 (right up to 5.2.2) it would start on roughly 5.3Gb Ram and expands to around 6.5 - 7Gb over extended play. This version, however, loads me on 6.1 - 6.3Gb of Ram at game start and stays roughly around there rather than fluctuates up and down. It also cuts up to 30 seconds off from the initial mod load-up before the game starts. This is also on x64 version of KSP btw

2.3.5 works fine, no probs

For some reason, every ATM mod after Release 3-1 doesn't work, it always a CTD for me when the game loads up. I use x64 btw. I'll test the later versions when they get released but i'll stick with 3-1 till then, it still does the job

I feel the current usage of Quad Sphere's to design planets is way too resource heavy and redundant, especially with a function like leveled subdivision involved. If the planets used elevation data from height maps then allow fractal algorithms to further define planetary details on closer scale once a certain resolution with the height map was reached, this would free up a lot of system resources currently used by the game's processes. Using height maps allows for a consistent appearance of planetary terrain when implementing fractal algorithms, it's not a planet generated randomly through procedural generation (which would make MP impossible). Using fractal algorithms means that a process of dynamic level of detail can be used in place of the static level of detail currently used with quad spheres. Only the areas that are within a certain distance of an object, be it a ship or Kerbalnaut, will increase the resolution of the mesh within the vicinity of their location to a certain distance from the objects POV while everything outside of it will be lower. This can increase the scale of other areas if the object moves position to another area, which will free up memory and other CPU/GPU functions. Additional details can be added too. Vector Data can be integrated on the planet surfaces to allow for artificial structures like buildings to exist, textures can be created on various heights of terrain using perlin noise algorithms, atmospheric scattering can be implemented at various altitudes and with different effects, you can create better and more lush vegetation types like grass, clouds and tree's with real-time projected shadows.

works fine with x64, pushes the memory up to bleeding edge when it loads before receding down at the title screen. The parts are a lot more stable too oh and thank you for making this backward compatible with earlier versions, two thumbs up! Unlike some other modders here who change their part names for asinine reasons and break your save files... smh

Whats with other people changing original settings in the mods tech tree? Unless the game itself has changed the way it operates, make it 100% compatible to older versions of that mod and stop breaking peoples savegames. You want to change the mod, fine, but who in their right mind, who's spent hours building stuff, would want to go over and use your crappy save breaking version mod over the original?!? lmao

I think there's some confusion over what procedural generation is and what it can do. Procedural generation can either be random or fixed. If squad think procedural generation is ONLY randomized, then they have assumed an incorrect viewpoint of it and need to pull their heads in. Fact is, objects can be generated dynamically and still have the exact same features as everybody else's copy of the game. What defines this is a fractal algorithm of each planets features, variables (size, gravity, atmospheric height, apogee/perigee, etc) and also of its texture values. This is what David Braben used on the Elite series of games and EVERY COPY of EVERY GAME he made has the EXACT SAME shaped solar system and universe. The values are set numbers for each body orbiting each solar system. They aren't randomized willy-nilly. Outerra uses this method, so does Space engine. Virtually everything made on the Demoscene does this too. This, rather than having modeled an entire planet and texture its surface as the main elements. That's insanity, who has the time to sit behind a computer, go click click and do that all day? The end result just gobbles up memory, especially on a juvenile 3D game engine like Unity. Using procedural generation to create planets uses only a minuscule fraction of the memory that KSP currently uses now, even with 64bit. I feel KSP's ridiculous memory usage and the Unity engine are its Achilles heel. The devs flounder under Unity's limitations, this is evident with the slowness of their updates and the time at which it's been in early access. It should be done by now. Truth is, the engine can't handle it. I don't hold a candle of hope for Unity 5. KSP would do much better on a more mature game engine like UE4, less an in-house proprietary one