SyberSmoke

The generic mod manager is meant to over write files, that is true. But also I use it as a desktop front end to activate and turn off mods in the case of errors, glitches, and such. I understand and agree that having each mod as a defined separate folder in GameData is good for modding. But I am just not a fan of renaming or moving folder after folder to track down a bug or error by hand. So the MM I use just takes what I place and puts it in the directory I designate in my KSP_MODS folder it creates. A mod with the directory say Kethane/GameData/Kethane/(Files) just ends up in the GameData folder using the first folder to track the name and contents/placement directory. IF the MM HAD to overwrite a file, this one does not, instead it will in fact preserve a backup of files it would have to overwrite from vanilla and then replace them so that the game can always be reverted back for patching purposes. It is very handy for games that do not always have a good mod system. As for why it is my preference even though KSP has their act together on this. Ever play one of Egosoft's X games? Heh...scrips have to be dumped into core folders and if your not careful...uninstall is impractical as a mod can have hundreds of small unique scripts. There are many games like this out there...so I go with the safer approach.

The hex effect, if that is what you mean by grid, can be turned off. I turn it off when not needing to find Kethane. The UI element that lets you turn it off is in Map mode.

You realize that fighting personal preference is like trying to swim up Niagara Falls right? Any way back onto the topic, Kethane.

True enough, but I do like a good mod manager as it can make things easier if there is a conflict. Juggling folders is just not fun.

Well first, find a copy of JoneSoft Generic Mod Enabler, good piece of kit. Second, Follow the JSGME instructions. Third, this mod (the named folder) goes into the GameData folder, there it will be activated. PUT THE NAMED FOLDER in there, not just the data and so on folders. Using JSGME will allow you to turn off and on mods with out having to shuttle folders about. ;-) So if you use JSGME, you should have you MOD folder (created by GME) and in side "Folder with mod name ---> Folder with desired directory to place mod (Game Data) ---> Folder containing mod files (usually named). That I know. But having something scan faster and something scan a wider area are equal concepts. So in this case say having three medium scanners that each scan a three hex diameter would allow some one to scan a nine hex wide area instead of scanning just one or two hexes at 1000x warp. It is a more efficient use of the players time.

Ok, yeah TBH I thin it would be better to have it so that adding additional units will increase your scan area or resolution instead of just allowing you to warp faster to get it done. As it stands no one likes to sit there watching it scan...fair enough right. But having a broader scan would be better if balanced.

I have looked around a little and experimented some, but is there a purpose...point....reason to have more then one scanner on a ship? From observations they do not appear to scan a wider area, nor does the data they produce seem more accurate or better. So besides sucking power out of my probes, is there a purpose? As a note, for the Wiki, it may be a thought to add this and the general benefits of the scanners as it is not immediately apparent. I mean do they scan in parallel...if one scans a block will the next scan a block to the left or right depending on position and orientation...it is just hard to discern. As another thought, has it been considered to give the larger scanner a larger scan radius? May be the compact scanner scans one hex. While the medium, a more advanced scanner can scan 7 (One in the center and the 6 around it). Ok, end of thought.

I have read this thread and I agree with this post. This is a game, not reality. Reality is dull, boring, and more then likely I will not live to see humans reach even the asteroid belt with the way the US fed keeps cutting Nasa's budget. Yeah...that is depressing. I want to play a game because it is intriguing and does things I can not as a lowly mortal. So if that means I get to build an infinite improbability engine to blink to another star system as a ball of yarn, then god damn it, get out the hard stuff and a gold brick because i am going to. For those that want reality, go buy a rocket kit or start building your V1 in the backyard. But please keep it out of the game because it is not a simulator.

Phycix, if Procedural Fairings is still current and in development, why not talk to the person developing it to see if a "proof of concept" can be made. I think some of the ideas need a little tuning, like I do not think the fairing base should be the point of mass, but instead the physics skeleton should remain to provide accurate mass calculations. That skeleton is just made inert when it comes to calculating flex and stretch at the joints. This would be the most reasonable alteration to prevent obscene payloads. As a thought also, given the weighted nature of the fairing as described. It may be an idea to have it also have built in counterweights. This would give it mass but also allow less balanced payloads to be balanced out by the fairing weight. There should be limits of coarse, but it is a thought.

I like the idea, it is a very nice way to see what you have done and are doing. As for reality...I some times think we have lost something. Politicians and the like are to concerned with a single life when it comes to this sort of thing, and yet we loose more in car accidents and wars every day. We have a mentality of a shut-in, and we need to just stop and realize there are billions of humans right now...one or two casualties in the name of progress is not a very high cost at all. Especially if those that are lost accept it is a possibility of the job.

The last time I tried docking it was with MechJeb. I tried manual docking and well...I sucked at it. The problem I ran into was when I tried to dock, I could not lock on to what port I was going to link with (there were 5 available). And even zoomed out and right on the station the ports were hard to select. What I suggest is the ability to "Target" individual components (docking ports) that have been named in advance. To do this the player would fist select the port they wish to name and bring up its menu. In the menu would be a "Name Docking Port" option. Using this option will give the port a unique name. Once a port is named the user will be able to target that port from another ship. To do this the player will just need a docking capable ship and to right click their target object. This will bring up a menu that offers the current options and one that says "Target Docking Port". Selecting this option brings up a menu listing the named ports and could even have a small PIP window showing a close up of the port to be targeted (some people are just forgetful...like me). Once the port you want is selected, that port will be the target until changed.

Well the way I see they got ports to work was to create a very loose physics spring that interacts with the connection points from a distance. There should not be any reason though that the physics spring could not undergo a state change and be allowed to "Tighten Up" once a ship is docked. The spring is useful for pulling in a docking ship. But after they could change t to a more rigid or even a permanent format as the Quantum Strut mod demonstrates.

Actually you would not need as much fuel (Still need allot) to move an asteroid. If you plan it right, you can use the gravitational pull of near by bodies to slingshot your rock towards where you want it to go. This is not a small effort though and it would take time...allot of time to achieve. But really if they are planning to bring rocks from the belt to earth so they can be mined with convenience...why not offer something similar to those interested in KSP. I will say this though, This like probes would not be something a player SHOULD focus on. This is something that deserves an out of seat autopilot. Where a coarse can be plotted and then left to the placed Kerbles or piloting system. Some of the concepts in the game scream for this kind of interaction (Ion Engines) and so I hope it is also planned. Any way back of coarse. Oooo...Asteroids do have one other cool thought. A random mission in career mode. KSP Observers have spotted a rouge asteroid on a intercept trajectory with Kerbin. It is our mission to launch a series of missions that will divert the asteroid and save the Kerbals from utter destruction. After all, Jeb would get so lonely since his awesomeness would protect him from all harm. And much to the contrary of science fiction, a nuke would not make a good method for diverting an asteroid. A nukes blast is not focused enough to provide the jolt needed to move something like that. Plus you do not know if the asteroid is stone, metal, or a debris pile. So using a nuke could cause it to shatter into a million smaller objects.

Well Jeb does need his snacks. But yeah, a little off topic there. :-)

To help you with 3, the thing I was trying to make was a decoupler, but instead of using a stack decouple (you can see that would not work because of the jet engine) I wanted a pair of decouplers connected via I-beams. The I-Beams would be the connection between the rocket and the plain portions with the decouplers releasing the two when the decouplers blew them away. This is what I was calling a clamp. The second thought stemmed from the first, an object with arms that attach to the ship like the LSE's. These could be used for payloads or for objects that do not fit well with the use of a Stack Decoupler or a decoupler. You could also place it more or less free form on an object to tune the balance due to the asymmetric nature of some parts. Once placed, it would act as a mounting point for a stack. Or mounted to a stack and ready to hold a payload, depending on how you build your craft. That was the thought at least. Concept Object: Payload Clamp Description: The payload clamp acts like the Launch Stability Enhancer for payloads on the ship. The base comes in two sizes, Medium and Large. From the base the Payload Clamp has arms that rise from the base and attach to the payload. The arms must be symmetrical. It may be possible to allow the arms to be placed using Symmetry mode selecting the numer of arms with the remainder of the base filled in. On the arms are adjusting pads that will attach to an object holding it in place. The pads will adjust to fit the objects shape to get a good connection or hold with the arms adjusting their angles to facilitate a good grip. When activated, the pads will release and the arms will rotate from a pivot point in the bass to be inline with he plane of the base (think Starfish). The payload will be released and allowed to escape under it's own thrust. Alternately, the clamp could be used as a grabbing mechanism. The arms could be powered using electric motors, when activated the arms will close and the pads will seek to attach to an object they strike. This would facilitate the capture and movement of orbital debris with out the risk of it jostling or bouncing. Better explanation.

I like the idea that the fairing would treat the object as just a mass while removing the physics calculations for each spring/attachment. This though is more of a work around for a fundamental issue with the engine. That being objects in the game only have one connection point. While this is good for putting things together (in most cases at least), it is not so good for calculating the stresses on a physical structure that would be "knitted" together. The wobble is caused by these single connections, something that (by my observations at least) the struts were put in to fix by adding additional physics connections and linkages. But part of the problem could also be fixed by adding more discrete connection points. Points that treat connections between tanks as a rigid weld making them a solid single body. While others that simulate flex between smaller more fragile structures. These structures would most likely need struts to compensate. But for the interim, if implemented properly and drag was properly balanced out (*Cough* Nosecones *cough*) then this would be a good way to make assumptions about the cargo with out making the player place 100 struts in the process. As for loading the objects...it is remarkable how little people know about games some days. The objects would not need to be unloaded from memory and could in fact remain as a static mesh with textures in the fairing. The object would remain in the fairing and would not be rendered by the GPU, and really it should not be rendered by the GPU if it is not visible any way. If it is being rendered...that is just sloppy programming. When the Fairing is popped, the object will be there and render as normal. The engine should also have time, even if a delay of a couple frames is added, to reintegrate the constructs physics into the system with out an issue. Especially since the fairing will be deployed in the relative calm of space and not during the launch window. Really this is all game technology 101.

Just today I had to bang my head against the limitations put in place on how ships are designed. My goal was to use a rocket to boost a small space plane into orbit. Eventually...it did it, but the resulting creation was...ungainly in many different ways. As you can see below, I built the plane first as I knew the shape I wanted. The problem I ran into was how KSP treats objects. Objects must be built linearly going from A to B to C to D. But this was the issue as I wanted a less...unstable launch platform for this specific craft. The issue was that I could not designate distinct entities with in the editor. So my plane could not be one entity, my rocket could not be another entity, and I could not create assemblies to connect the two as an inline structure. Essentially clamping one onto the other much like the Launch Stability Enhancer clamps onto the ship and then lets go. So what I would like to suggest is three fold. 1. The ability to create, on a limited basis, distinct entities or craft as a single project. This could be expressed in many ways but both would be valid and allow the user to build on then separately. Allowing the user to work on A->D, and G->K in parallel. 2. The addition of a user created pallet for entities. This is so commonly used objects can be pulled out of the pallet or transfered in with out having to edit anything. So in this building a space plane, then placing it into the pallet and going to the rocket center where the plane can be grabbed, oriented, and placed onto a rocket. Why reinvent the wheel each time?? 3. Allow the creation of, or add an object into the game, clamping objects. The simplest method is an I-Beam connecting two decouplers. On decoupler on each element your attaching. A small set of varying length objects could also be added to achieve this, but allowing the player to build unique and interesting solutions is more of what KSP is about. I hope you enjoy the thought, please be constructive. And if your wondering, the plane got to orbit, flew great, and got Jeb home safe and sound.

As posted above, you can create a belt and procedurally generate a number of larger asteroids as points of interest. If a ship gets close enough, other asteroids could also be generated with in a set radius around the ship. These asteroids could have a conditionally "fixed" orbit, so left alone the asteroid will just be there and when the kerbal leaves, so does the asteroid. But if the Kerbal ship decides to land on that asteroid, then the asteroids orbit can be changed and considered an object. So say you get enough parts out there and engines, you could nudge it out of orbit treating it as a super massive ship. This would be a HUGE endeavor and I doubt that it would be at all fast. I would also suggest that besides placing engines, you would also need to drop a special control center to manage the rock as you take it to where it is going. This is not a small effort, and it would be the culmination of MANY launches as your literally building a ship out of the rock and would need attitude control, thrust, and retro's. But it could be a fun thing to do.

The Ion Engine does not work like a rocket, they have a very very high fuel efficiency but have a very low thrust. The point of them is for probes that you do not want to spend a lot of mass on to get to some place. The problem is this is an engine that would be BEST with a defined path and just left alone, and I mean with out a player sitting there drooling as it goes. This way the drone can do all its burns and so on and the player can do something less mind numbing like build and launch that spanky new rocket...or blow up that spanky new rocket.

If your referencing the third image, I see both clouds and an alternate launch mechanism.