jarmund

Thank you Note to self: Doublecheck that I'm in the right subforum before submitting a new thread

Yup, it's called a butterfly valve, if i'm not mistaken. When i was in the oil and gas industry ages ago, i got the impression that most electronic components has a hydraulic equivalent. Diode -> One way valve. Resistor -> Flow reduction valve. Capacitor -> Accumulator, etc.

I was actually thinking of something similar - How awesome it would be to have an engine designer where you could really get into the details with engine design to determine cooling method, bell shape, fuel pressure, fuel mix, and all that good stuff. You get to tweak each individual part to see what it does to thrust, weight, Isp, heat tolerance, and cost real time. Save it, and you get that part in the VAB. But for those not wanting to tamper with this part of the game, you still have the stock engines.

In advance, sorry for the useless post: I just want to chime in in this thread that seems mainly about compatibility issues some are having: I for one is running KSP (0.90 for the time being) just fine on Linux Mint 17. Once i had installed an up to date driver from NVIDIA, the game worked out of the box just as well as it worked under windows 7.

I agree with you. That's why I edited in that short line about having the ability to, but not being required to, do more of the detailed adjustments and tweaks. I've always liked the expression "simplicity works", so tedious things should be made simple, fun stuff should be just as simple, but with the addition of allowing for very low level stuff. While i do agree with "It's more right than wrong" I'm leaning towards adding complexity. - Way back when i played it, i liked Anarchy Online for its implant system that could take days to plan and upgrade. - Hearts of Iron will always be a favourite when it comes to strategy games.

Additional ideas: Proximity sensor activating landing gear, lights, and other things that can be assigned to action groups Barometer deploying solar panels SAS disabled if electrical power runs low (in addition to enabling "fuel flow" from an assigned backup battery) Thermometer ditching a heat-shield Fuel tank decoupling once empty Basically, a part that is set to be connected to the CAN bus can trigger an action group. In addition to obvious things such as a centralized data readout for all attached instruments, for example, right clicking the pod or the controller gives allows you to see data for thermometer, data store, and others, in one single context menu. Any others?

I for one love KSP for its complexitiy. I find that "simple" games bore me after not long. I've heard people giving KSP some flak because of the steep learning curve, but i consider this one of its strengths. Where do you stand on this in KSPs case? Should it be simpler, more complex, or is squad managing to balance this just right for the most part? EDIT: By complexity, i don't necessarily mean "Harder" or "More realistic". I mean, i want to be able to choose how much my kerbals weigh and have that count towards the craft mass, I want to have cities nearby that i can crash into to ruin the public opinion of me, i want the HR department to give me tough choices about personell, and i want the engineers to perform sub-par if not provided with coffee. Basically, more stuff that i can (but don't have to) tune and tweak as i please.

While the electronics-mod is a lot more detailed than the scope of what i want to achieve, the proximity sensor is certainly something that could be useful for this. In fact, most types of sensors would be useful, so that a controller node can act on sensor input. As for cooperation, it could be an idea, but I believe I am curently lacking in ability to keep up with any form of cooperation at this point due to: I'm still just getting into KSP modding (I'm more of a linux dev, and android dev, so perl and java are my primary languages). + I have very little time on my hands (too many kids, too little elbow room, can barely hear myself think during daytime) = It would be faster for you to just do it yourself rather than wait on me to catch up

Since I'm both a coder and a KSP player, I decided to give modding a go. I somehow inspired myself when making a comment somewhere a while back saying something along the lines of "...Because the numpty who installed the accelerometer on the pod couldn't be bothered to connect it to the CAN bus". The keyword here being CAN bus. I want my ships to have one. Partially because I like the concept, partially because it'd be a nice project to learn the KSP API. For those not aware of what a CAN bus is, think of it as a form of network made for inter-device communications on a scale much lower than ethernet and the likes. What it does in it simplest form is allow electronics to communicate with each other without having to implement, for example, a full TCP/IP stack. It is found in many, if not most, modern vehicles, cars being the most familiar application. For those not yawning themselves to death this far down the paragraph, feel free to read more about it here. So, the question now is: What would a CAN bus be used for? My rough ideas would include: - Auto-grab science from instruments, similar to what Science Containers does, but with some alterations/additions/modifications. - Inter-vessel communication, allowing the above to be done wirelessly with nearby (physics range, I would guess) vessels. - Vessel remote control, not having to focus on that vessel to control it. I remember seeing a mod for this, but i can't remember its name. It's not important anyway. What else would a CAN bus be used for in KSP? I'm especially after what could be achieved by letting parts local to one craft talk to each other. And yes, I am aware that most, if not all, of what is mentioned above already exists in one form or another through other mods, but think of this mainly as a training exercise than a mod idea.

I'm thinking something else: I've noticed that a ship, once it starts calculating its physics, can start wobbling, especially if an enabled onboard SAS is reacting to it. "Crap, nose pointing west, move towards east, crap overshoot, move west (repeat)" This is especially true for orbital assemblies such as motherships consisting of multiple parts with the large ports connecting the pieces. A workaround if you're willing to use mods is KAS. It comes with a type of strut that can be attached by an EVAing kerbal, and is invaluable for large orbital assemblies (The struts themself is enough of a reason on its own to install KAS. It's a great mod, you'll love it, i promise you) Sounds to me like the wobble starts once you get within physics range, and then gradually increases to something unmanageable when you get near. Have you tried disabling all reaction wheels on board the mothership to see if it settles? Related: Just when the ports are about to dock, disable SAS on the docking vessel. Then the ports won't fight each others inclination difference as much, and that should in theory reduce the amount of pull the ports do on each other. EDIT: KAS can be found here. - - - Updated - - - I'm not sure if it's imaginary or not, but i do get the impression that the large docking ports are more wobbly than the medium ones.

That just brings up theadd-maneuver-dialogue for me. I'm running the linux version, by the way, if that makes a difference (I doubt it)

Silly question, but how? I'm sure i saw Scott Manley do it in one of his vids - He did something that made the PE altitude stay open, as if he was hovering all the time while adjusting the maneuver node. Is there a feature that i'm missing, or is he using a mod to achieve this?

Hehe, no need to ask, i remember it now that you mention it. Thanks for the reminder.

I'm thinking that with most of the fuel used up, your plane becomes back heavy - Loads of engines in the back, with no fuel forward to balance it out anymore.

"My computer is too potato" Not sure if that's of KSP origin or not, but I never heard it before i came here.

For unexplained reasons, it actually took me quite a while to actually learn what RCS was for. "Huh, there's no difference with it enabled? Why use it?" (I of course didn't have any RCS thrusters on, or monoprop). This resulted in me managing to dock two vessels using main engine only. Never again.

While RCS isn't strictly required, it's of course convenient for various uses. Which uses do you use RCS for? Not just RCS fuel, but the system as a whole, including vernor engines and any mods that provide functions linked to the RCS. EDIT: Crap, missing option: Fine tuning orbits. Any others I missed?

I did a mun-trip yersterday without a problem. I use FAR, so by taking aerodynamics into consideration when constructing, launch wasn't that much of an ordeal. With some canards, and a slight tilt after clearing the pad, the gravity turn pretty much happens by itself. My transfer and upper stage were fairly small, so they were easy to orient in the proper direction, with very short burns to achieve the desired orbit changes. Landing on the surface of the mun was a bit tedious, but not that hard if done carefully. During reentry, no SAS was needed, as my heat shield (Yes, deadly reentry) made it bottom heavy, and of course when it came to parachutes, they were mounted on top.

Maybe. I know there are a lot of visual mods that improve things. Sadly I do not know the name of any, but i know for a fact that one enhances and improves how objects, planets included, appear from far away. I haven't heard of one, but it sounds like one of this things that just has to exist: A telescope/observatory mod. Combine the two above, and you should be able to.

On a more general level, we have the Kraken. The KSP community is the first place I've heard it used as a turm for a generic, often destructive, unexplained bug.

I feel like hacking together a perl script that does this for me. 1. Keep all mod-folders as they would normally reside in Gamedata in some other folder. We'll call this folder ModRepo 2. Run perl script 3. Check the ones you want to install (The mods are populated from the ModRepo folder , or load a preset of checked mods) 4. perl script copies in the mods you've selected. 5. play Not as clean as i'd like it to be, but at least i wouldn't have to: - Drag and drop each individual folder - Have separate installations - Have multiple gamedata folders

I'm guessing the origin of this question stems from the same issue as I've been having: Not wanting to make a separate installation for each combination of mods you'd like to use. I think it would be best if the game asked you with a list of checkboxes, one for each mod, every time you start a new game. Maybe with the ability to bring up this list at a later point if you chose to add more or remove some.

A note regarding this: NVIDIA is usually a safe bet when it comes to linux compatibility, as they release linux drivers for ubuntu that can be used on most (all?) distros. These are the drivers i use on mint. Other hardware can be more flakey, yes. I too had issues with an obscure embedded wifi module eons ago, but most are supported.

My TAC supply ship for Duna is mostly just a stack of TAC parts with a decoupler in each end connecting to fuselage, probe core, some very basic wings for stability, and control surfaces. Works like a charm. When I'm low and above the landing site i go for a stall to slow down, decouple and trigger the chutes. This was my backup solution after realizing that i couldn't estimate a landing spot if my life depended on it.

When it comes to which distro, just pick one that is fairly common. 90% comes down to personal preference. Personally i can't stand ubuntu, as i'm more of a command line user, thus preferring arch linux for most things. Currently running Mint mostly to test the distro. Mint works fine with KSP Ubuntu probably would too And it wouldn't suprise me if Centos also did a decent job at it. Plus a myriad of other distros that are oriented towards desktop and ease of use.