EpicSpaceTroll139

Thanks! It is indeed based off of yours, although I first tried other fuselage designs and then came to the conclusion that yours was the best for getting a somewhat rounded look with a flat floor. As for code I meant a script for K-OS. Creating a new plugin is way out of my league haha. Edit: Progress on the heavy-lift

I've been working on my own heavy-lift helicopter, and I accidentally discovered an effect that helps significantly with the problem of dissymmetry of lift, while ironically being caused by it. As I make the blades longer to help absorb more power (in this case 4 panthers), they are able to flex, riding upward as they get more lift and down as they get less. This greatly increases the speed I can go without rolling over compared to my smaller helis (even taking away the wings with the ailerons). However gyroscopic effects cause the blades to ride up in the forward region and down in the aft region, so some of the rotor lift is directed backwards, working against my forward speed. I need to do some testing to determine if this is enough to warrant using a tandem rigid rotor design instead. Also been working slowly on a preliminary base for a cyclic code. I now have a vague idea of how to translate pilot inputs into rotor flap movements. I have no idea how to give SAS any control in the matter though.

Haha great minds think alike! I made a very similar thing to that also based of Klond's tiny coaxial heli. It can fly, but usually within about 30 seconds of taking off, the synchronization gears (or something, I can't really tell) snags and either one or both rotors get ejected. I think my problem has to do with a vibration caused the power pulsing as each turbine in turn gets a bit of thrust from the engine. I'm thinking that it *might* be a better idea to have the gears separate and have the engine blowing on a turbine on just one of the shafts. Though now that I've made the tiny single rotor monoblower, the only benefit of this would be to null out the torque and thus make handling a little easier.

Presenting the lightest turboshaft helicopter to date! The Sub-ton Turbocopter! Weighing in at just 948kg, and based off of @klond's Tiny Coaxial Turbocopter,* this heli is ready to be taken wherever you want to fly. Flight time is about 5 minutes, however an engineer suggested another fuel tank could give it a greater endurance. But then it wouldn't be < 1 ton would it? But here's the best part! It fits in a 1 long + 1 short Mk2 spaceplane cargo bay! ^this picture is of an earlier version, and will be updated soonish *Released with Klond's permission.

@klond Also: you're right that coaxial or otherwise counter-rotating rotors help by cancelling out each other's gyroscopic effects. At significant forward speeds they can also help by cancelling out the assymetric lift that results from advancing rotor blades having a higher airspeed (rotational speed + heli airspeed) and thus getting more lift than the retreating blades which have a lower airspeed (rotational speed - heli airspeed).

@klond I suppose you are referring to my old Coax Mk1? If so that thing is definitely lighter. Yours is only 41% the mass of mine. It looks more compact too. Great job! I will have fun trying it out!

Ummm... that sounds similar what DMP does... Are you suggesting something like multiple persistence files, so that, say, if Player 2 wants to go to Duna with 7 and 8, he loads a onto a new save/game instead of launching there and syncing? I'm a little confused

Nice strawman argument. Have you even tried DMP? It gives the freedom to have different groups of people doing different things. You can have 2 people flying planes while 2 people build a space station and send it to Duna, and yes, one person can do his/her own thing if s/he so chooses. And it's far more than an online chat (even if it may seem like it at times due to lag-induced teleporting bugs getting in the way lol). I fail to see what's wrong with that. Many multiplayer games allow people in the gameworld to do different things.

I did in fact read what you posted. I simply disagree with the idea that people should have to consult other people before warping and/or follow some mission que. I think people should be able to do whatever they want whenever they want. Take a look at an example of a typical session on a DMP server: Player 1 is landing his first rocket on the Mun. Players 2 and 3 are designing turboshaft helicopters. Player 4 is learning how to build a plane from Players 5, Players 7 and 8 are building a base on Duna. In my humble opinion this is a nice way to have things, even with the occasional paradoxes. Maybe I am getting confused and missing your ideas completely (that might just be it, to be honest some parts are a little confusing to me), but what I'm reading in yours is that everybody will be in the same timeframe. Thus, taking the example above, Players 7, 8, and 1 would get annoyed at having to wait until players 2, 3, and possibly even 4 and 5 land so that they can warp. Likely it would end up with the helicopter/airplane people being made to leave or change over to flying rockets so the others can get on with their flights. Or maybe the other way around, but more likely the former, considering it's called Kerbal Space Program. Your multiplayer idea has here worked well at avoiding paradoxes. It has however herded players towards doing activities that require or at least allow significant amounts of warp. It's cooperative, but not necessarily by choice. In my opinion, this means it has not worked great overall. I'll admit DMP's system is not fantastic. There are paradoxes that can occur as mentioned before. However, it allows players to do whatever they want, whenever they want. Also: Sure it's a "NASA simulator." That hasn't stopped people from making helicopters, propeller planes, boats, submarines, blenders, fighter jets, cars, cannons... the list goes on. Anyways, I guess we just have different ideas of how things should work if it becomes an official thing. And that's ok! I hope we're not dragging this thing too off topic.

I understand that KSP will never work well with multiplayer (I would know from all my time playing DMP, yet somehow I still have fun), and I will understand it perfectly if Squad never comes out with multiplayer for KSP. I just hope that if it does, people aren't forced to go to space to warp or to only warp when everyone else wants to.

Ah yes those would be problematic situations. I understand that I guess I don't encounter them as much since I've avoided space missions in DMP for a while now (I've had enough of disappearing motherships leaving me stranded on Eeloo and space stations exploding as if they had impacted some invisible space wall lol. Even when I do go to space though, I'd rather have these kind of problems than ones that force you to cooperate with someone else's mission, or to go to space if you want to warp.

This is understandable, but I am curious to what kind of issues you would be referring to. Would that be like, for example, that if you crash into the ship of someone who's in the future, they are unharmed but you get blowng up? Because if you put that kind of thing aside (seems kind of minor in the grand scheme of things), from my experience with DMP... if you disabled reverting and quickloadng (It is difficult to comprehend the number of crashed planes people leave on the island runway by using this), and figured out a way to get rid of the "vessel changed in future" bug that likes to suddenly happen while you're landing a plane... Those are the main problems that seem to plague us in multiplayer (other than the crashes and "my parts in the menu disappeared" and similar things that are probably unrelated to the inherent nature of subspaces). Or is the "vessel changed in future" bug something that probably can't be fixed? Or are there some things I don't see as problems that others do? I'd be happy to learn!

I've always thought the current DMP method of working with timewarp using subspaces and syncing worked great. Why would we throw that out the window and impose a no-warp bubble around planets??? I mean sure, there are some bugs that result from it right now ("your vessel has been changed in the future"), but nothing that some devoted programmers with time couldn't fix.

I flew around Kerbin 9 times in the not-so-creatively named Voyager X1. I've put further work into my K-OS autopilot scripts, one of the latest being to get the plane to bank , and thus change heading well. However, I think I did something backwards in it because when it turns in banks completely to 90 degrees (even though I thought I had limited it to 30 degrees), and then when it gets to the right heading it starts doing sideslip, with it banking 30 degrees to one side and yawing hard against it. Made a display of various stats. It also screams at me with both text and a tone if I go too fast too low (it gets higher in pitch the faster I am and the closer I am to terrain. I might want to make that toggleable. It can get annoying to get extremely high pitch whines when I'm buzzing through the space center. Also I think I need to modify the atmospheric constants in the formula for density altitude, so that they are exact to relative to Kerbin, not Earth. http://imgur.com/a/TpVKE (darnit can't seem to insert images right now I've also been using K-OS to do something a bit unconventional: play music. It's kind of work intensive to code in all the notes, let alone begin to put dynamics and stuff, but I have some occasions in mind for which it will be fun. Because saving 15% on car rover insurance is always a great answer

*Zeus comes along* "DID YOU JUST CALL ME SMELLY?!?!" *Hurls lightning bolt* KSP helicopters can in fact be efficient for heavy lifting purposes. My standard rotor has an efficiency of converting blower thrust to rotor lift of > 200%. Anyways, I like your Asura line! Good luck with your massive heli.

Ok so I'll enter my oh-so-creatively named Voyager X1 for the Voyager division. I severely underestimated the powers of fuel mass fraction and altitude when designing this ugly duckling, and only expected 3-4 circumnavigations from it. It did that, and then it just kept going... and going... and going... I got 9 circumnavigations. I hope it's ok that I used my own K-OS code to hold altitude and provide various data. I did try mechjeb, but it kept altitude like this: UP UP UP UP OH NO I'VE PASSED IT DOWN DOWN DOWN DOWN OH NO I'VE PASSED IT BY A KILOMETER NOW UP UP UP UP I'VE LOST 200M/S DOING THIS BUT I DON'T CARE OH NO I DID IT AGAIN DOWN DOWN DOWN DOWN. Anyways, with no further ado: http://imgur.com/a/jZXkp I'll try to copy all the pictures into a spoiler box. There's a lot of them. But for, now, just use the link .

Idk about lake beds, but I've always found the polar ice caps to be fantastic for doing runs in missiles on wheels fast cars. I should pull one out of my garage and see if it still works.

(Insert a few other people's quotes about timewarp not working with multiplayer here) Why do people keep saying this? There's been a multiplayer mod out for a long while that handles timewarp fine using subspaces and syncing. It used to be called KMP. That eventually became defunct and now it's been developed into DMP.

I think this would be a great thing to implement. While I think there are many aspects of the audio that can be improved, this I think is one of the most blatant and easiest to fix.

I'm guessing rule #3 would disallow me from using (whenever I get it working) a KOS code to automatically fly a tanker up to me, transfer fuel, and go back to the KSC?

The above replies are correct in that there are no missiles from the mod that work in space (well, other than going in a straight line if you don't lock them I guess). Considering what you said you were doing however, it might be significant that guns and lasers seem to work quite fine in space.

Been working my coding/K-OS skills up (been a long time since I last did anything with either it or Raspbian (similar to Python)). I have two program projects in the future. The first is a program that I hope will make In-Flight-Refueling practical. Basically the idea is that the tanker will be sitting or the runway, and when the program detects the receiver aircraft coming within, say, 20km (I'm probably going to have some mod running to increase load distance), the tanker will take off and fly up to altitude. I will then dock the receiver aircraft (or if I get really good at K-OS I could go fancy and have some kind of docking assistant), transfer the needed fuel, undock, and then the tanker will fly back and autoland. So far I have a code that can do takeoff and climb up to about 30-100m (depending on the air density) below a target altitude. I'm still working on how to get it to fly at exactly the altitude I ask. My problem is that the code has it set so that at the target altitude the pitch value is 0. The problem is that my plane needs to be at some slightly >0 pitch to fly level, and this changes depending on airspeed, air density, and between aircraft.* I do not yet have a script for maintaining a certain speed, and I would like to add that. I've been testing... I think it was "dunbarantu" 's autoland code to land my tanker (in these pics it doesn't have the boom bcc it's a PITA to attach it with the claw every time I do testing). It however apparently needs some tweaking to deal with large, sluggish aircraft, because currently it's working more like "autopancakeintorunway". As a side thing I have a script that displays demanded engine power vs. what the engines are currently spooled to, the thrust in kN, the fuel consumption, etc. However it can only give the correct thrust in kN and fuel consumption if there is only one engine though, because I haven't yet figured out how to get the total current thrust on the vessel, instead of that of one of its engines. The second major code I want to write in the future is one that actuates control surfaces on a stock helicopter rotor to give cyclic and maybe collective controls. *If anyone has any tips on how to make this work, please let me know.

I didn't! I just built the little thing (doing the usual tweaking of the motor and prop for efficiency like with any other design) and stuck it on there and it pretty much just worked. I don't remember, I might have had to adjust it forward or backward a little bit to try optimize the countertorque (same thrust at a greater distance provides more torque and vice versa), but I definitely didn't do any calculating.

I have what is probably a dumb question, but I'm currently stumped. Is there a way to find the current thrust on a craft? I know there's VESSEL:MAXTHRUST, VESSEL:MAXTHRUSTAT(), VESSEL:AVAILABLETHRUST, VESSEL:AVAILABLETHRUSTAT(), ENG:THRUSTAT(), etc, but for the life of me, looking through the documentation, I can not find a command to get the current total thrust. Also is there a way to get the combined input from sas and pilot, instead of just the pilot?

Uhh... do you mean to have "WHEN READYTODRILL < 2..." on that last statement? It looks like you put "<>" by accident... or does "<>" have some function in K-OS that I'm not aware of?