Ruedii

I would like a full runway lighting system as well as objects highlighted in the GUI HUD that are in a certain range of the approach vector. I would recommend a complete lightbar setup quite a ways out, but I'd probably skip the strobes and communication lights on these, because they would be unnecessary bloat. There should be 3 diffent ways to render of these approach lightbars for different distances to allow for better range ov visability. (The same should be done for KSC itself. One is a landscape decal that appears when the light in question exceeds view distance. Then is a greatly simplified "imposter" model for the long range, to allow for having some sort of model well beyond the clip plain for regular objects, finally is the standard model that is adjusted for LOD further by the game engine. For angle systems, I would like to see a T-VASI type system, because it's easiest to use. I'd also like to see a single-light Pulsating VASI system on each of the helipads, and on the launchpad for good measure. This will allow experienced to easily approach them with VTOLs for nice swift landings, and it would make nice eye candy for regular players. The desired flight angle range for each indicator position should be adjustable in .1 degree increments from a menu accessible at KSC. The managing of the visibility of the lights should be handled by a shader, so it even functions with just a decal, but there should be an actual model when you get down close to them. The purpose of all of these lights are three-fold. They provide nice eye candy (we all love that), they provide reference for perspective when approaching KSC for all users, and provide quite accurate landing guidance for expert players. I apologize if my words sound jumbled today, on top of being sick, I messed up the dosing on my meds earlier in the week, and between the two my thought process has become extremely jumbled.

I was thinking we need more science experiments and contract types in the base game. What type of science would you like to see? Here are some of my ideas to get the thread started: For science contracts, telemetry. It should be allowed to be taken from a probe or capsule (unless specified in the contract), that is in an orbit and position of the specified trajectory. The more specific the harder the contract, and various specifications, including altitude range of the report, if on a downward or upward trajectory, apoapsis, periapsis, elongation, orbital period (if not hyperbolic or sub-orbital). Obviously there should be a lookup table for the valid ranges to prevent impossible contracts (like an orbit of the Mun with a period of one Kerbin month or longer), without having to actually do major number crunching when generating contracts. Surface sample contracts: A company wants a physical sample from a specified planet, and possibly specified biome for experiments and/or display. For experiment ones they will give you the rights to use their research, so you get science points as well as reputation and funds. Considering Kerbals seem to have a lot of cash to throw around to settle debates, these can still be profitable. Many of the experiments will be to once-again disprove some preposterous theory, like Minmus actually being edible, or the idea that eve's lakes might be usable as rocket fuel and/or fruit flavored beverage. Also, distinguishing the difference between water and drinkable water on Laythe might be fun. If it's for display, then they will usually offer a lot of money and reputation depending on how difficult the sample is to retrieve. However, sadly, display missions will get you no more science than you get from your lab analysis. This is usually companies that would want to impress visitors. Atmosphere and particle samples: Also, much like surface samples, you should be able to take atmosphere samples. This of course can be done early on in EVA, or later on with a device. Since the vacuum of space technically has non-physically significant gases and dust particles, you should be able to collect "particle samples" from space, but it should require a special device that must be mounted to the ship, and unfortunately requires a science lab to clean before it can be used again. Obviously, in addition to general science, there could be contracts for this, both science and vanity. As much as the dust floating near the surface of Minmus is useful for science experiments, the clear glass vial with a few deliciously blue-green specks in it from Minmus can be quite the trophy once put in an appropriately prestigious case along with a certificate of authenticity signed by none other than Jeb Kerman. Another contract on trophies is of course recovering a craft (or part of a craft) that did something in particular. Finally, stranded Kerbals should be found places other than low Kerbin orbit. While their orbits should be in a place that you can easily get to them in the time-frame of the contract, which could be a long time because the only safety technology Kerbals have developed is very efficient life support, but I think that Kerbal will be pretty sick of liquid nutrition concentrate emergency rations diluted in reprocessed sweat and . . . well, you know, from his space suit by the time you pick him up, and will be more than happy for some nice space snacks from Sean's Cannery.

I think the launch tower should be a part for the add on. It would provide a launch clamp on the nose of the vessel and scale to fit it.

I was thinking more parts need to be run test. They should have two separate possible contracts on stage-able parts, one is to stage the part (with the name for the staging process in the contract) and one to "run tests." I think every part should have the "run test" option, and some items should even have a sequence of behaviors on the run test. The third one is to actually specify what type of science they want. Some contracts should still just be generic, but some should specify exactly what they want.

Honestly, I think the stock jet engines are overpowered, but the way to address that is to simply make them overheat at over 75% throttle. Additionally, they should have the thrust-velocity curve seriously loose power at supersonic speeds for the basic jet engine (which lacks advanced nozzle mechanics) and hypersonic speeds for the advanced jet engine. As of what is proposed, contrary to popular belief, the combustion chamber is not in the nozzle of a rocket, but behind it. The nozzle just improves the direction of the thrust. Using the nozzle as a combustion chamber like an afterburner does is extremely inefficient, which is why it's only used in military craft that need that kind of power on demand.. While one could theoretically place the afterburner in a secondary combustion chamber, the backfeed would make the primary combustion chamber produce little to no thrust when the afterburner is off. This is a highly inefficient setup and that is why it's not used in real life. Most jet boosters in real life are ramjets or pulse-jets depending on the size of the rocket in question. Pulsejets are very useful for small rockets that don't have to travel supersonic speeds. Ramjets on the other hand can handle fairly high speeds, but can't be activated until they reach a certain speed, due to having no mechanism other than intake force to stop backflow. Scramjets are still experimental at best. No full-scale ships have ever used them, let alone a manned one. The most that have used them is a modified Pegasus rocket, which failed to properly ignite on the first couple tries.

The normals, height maps and models of many of the stock parts could use a tune up. This is especially so on certain parts that have colliders too far above or bellow their surface. However, what really needs to be added practicality wise is the use of sparse textures for terrain, which would largely offload terrain loading onto the graphics engine, hence dramatically reducing the low-altitude slowdown many players experience, while at the same time allowing for much higher detail height maps on terrain.

I noticed that there is no RLA_Stockalike config. How would I go about writing one?

Just checking, you've sent these patches to the Active Texture Management GITHub page? I know you aren't obligated to by the license, but it's a nice thing to do.

Congrats on getting some of this into stock I hope you continue the mod to FURTHER advance the contract system even more! After all, Squad looks at the modding community to see what is really needed that can be implemented with minimal effort. (I suspect FAR-like features haven't been integrated due to the later part.)

Yes, but both are widely supported in OpenGL, starting in version 3.x where it became an optional extension.

Sarbian, yeah, I heard that DXT1 and DXT5 variants are the only two that they provide guaranteed support for on desktop. Results may vary for other formats. There is also a technique ATI used in their research into the their 3Dc and 3Dc+ formats. It involves using reversable color-space transformation on the color-space of normals. Usually this is done with a 45 degree rotation, so you have an LV format texture instead of an RG format texture. I'm not sure how this would work exactly, but I suspect they used color transformation shaders to pull it off before they implemented hardware support.

Definately an aerodynamic system with something between FAR and NEAR. It needs to have the Mach curve system, but it doesn't need to have nearly as much complex calculation, and we certainly don't need aerodynamic failures and such.

The jitter is due to rounding errors. Unfortunately, so long as the ship is off rails, it will happen. There are some options to reduce rounding errors, but almost all of them cost processor time. They include the use of a sparse calculation grid for the map, instead of a single floating point grid, the use of less frequent, but higher precision map points, using bezier curves to estimate the points in between. The best option would probably be to use algebraic notation variables for map-prediction math calculations instead of floating point. Unfortunately all these options include much more coding, and significant processor hits. I'm not sure if Squad would see it as a viable option at this point. After all, they would have to research the available advanced math libraries, then decide on one.

For normal maps you should use DXN/BC5/3Dc or ASTC Those are the two "modern" standards I was referring to. Unfortunately Unity only currently supports these on mobile platforms, because most developers find the S3TC algorithms tolerable, even if they aren't the best, and mobile devices don't support S3TC. Mobile devices instead instead force you to chose between 3Dc, ASTC, and some compression standards that were designed for OpenGL ES 1.0. 3Dc and ASTC are superior to S3TC, but the other standards, well let's just point out that OpenGL ES 1.0 doesn't even support 24bpp/32bpp RGBA mode to give you an idea of what I'm talking about.

I've encountered a similar bug with rockets on FAR (except a tad more explosive). It seemed to be fixed by either disabling aerodynamic failures or installing Kerbal Joint Reenforcement. Additionally, make sure all your mods are running the latest version of KSPAPIExtensions. You can get the updated DLL from the KSPAPIExtensions GitHub page.

Did you try to remove both mods and reinstall them? (Also try rebooting it, and and unplugging it and plugging it back in. *j/k*) Seriously, though, many mods get screwed up by a bad upgrade process, and the best way to fix it is to remove the mods and cleanly install them.

How is this doing with 0.25 Do I dare try, or should I just be satisfied with the default RPM display for now.

There are DDS export tools for The GIMP. Also, AMD has released some texture reprocessing tools that can generate DDS textures from various formats. On another note, does this work on all platforms, or just Direct3D ones. I know the DDS texture load routines are different on Direct3D (which has driver-level support for DDS textures) and OpenGL (with which you need a loader program, but still has many advantages with DDS textures.) On one more thing, is there any way you could supplement the texture compression options in Unity3D to add actual modern texture compression formats selected based on what the user's graphics driver supports?

I found it works good with FAR. I'm not sure if the stock aerodynamic changes cause issues, as FAR does it's best to eliminate them. There were changes to quite a few of the stock aerodynamic modules, however they shouldn't be an issue with Firespitter. The parts may behave a little differently, but that's not really enough to go and say OMG IT'S BROKEN!

I ran into a bug. This mod causes crashes in VAB/SPH when running Linux in sandbox mode.

Fluid ropes aren't supported by Unity3D, the engine that KSP is based on. They also aren't supported by PhysX the physics engine that Unity3D uses. The closest you can have is a straight anchor line to a reel that will pull taunt at a certain point. This often will mess with the camera as it will consider you and the craft one object.

I can verify for certain that Procedural Fairings works so long as you update one of the community dlls included. (KSP API Extensions.) Firespitter also works but gives a warning. I haven't tried all the firespitter parts, but I tried the propellers, and they work.

Oh, thanks a lot! This is the best simple mod yet.

I was thinking to see if there is a way to do this with module manager. Do you think it's possible?

I'm not sure if I already suggested this, but I'd really like to see an option to allow the toolbar to be a drawer in the stock toolbar. Obviously, players should be allowed to configure their toolbar(s) how they like, and they shouldn't be forced to use this option, but it would be a nice option to have.