Jump to content

Teirusu

Members
  • Posts

    68
  • Joined

  • Last visited

Reputation

47 Excellent

Profile Information

  • About me
    Rocketry Enthusiast

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. For my own uses, I've been happily enjoying poking at this mod to figure out what I can do with EVE and decided to use SFVE as a base for my own setup. Mashing it up with SVE so I can have some of these neat effects in OPM along with SVE's effects, as well. So far, I've been pretty happy with it. Thanks @panzer1b !
  2. So originally, the engines I designed for that P-38 Lightning I posted in another thread not too long ago, came about because I wanted engines powerful enough to make one of these... A functional stock Osprey. It.. manages to hover, barely. And it manages to fly like a plane, although its very slow... But trying to get it to transition between the two modes is... basically impossible while the plane is moving. The plane itself is more willing to tilt itself then the center axle once the plane is in motion. I figure this is something that can not be easily over-come without a complete redesign into something that doesn't really look like an Osprey. Oh well. Not everything works out! Here is my engineering sample in-case anyone wanted to play with it. https://www.dropbox.com/s/6glbx6ii7843zv0/Osprey Test.craft?dl=0 Action group 1 to decouple the engines, 2 to start all the fuel cells that power the thing, 3 was going to be the docking port releases for the center axle, and 4 is to change the deploy of the blades.
  3. Oh yes, she flies really nicely. I've spent a lot of time tuning that bearing setup on that engine so it runs as smooth as possible. Pretty much up to the limits KSP can do with such a setup. The engines hiccup a bit on a steep dive, but otherwise seem to stay together no matter the G-loading. Jeb definitely enjoys it!
  4. Some one gave me an idea the other night in Roverdude's stream SAS powered stock part Lightning. Built with a bit of EE Redux magic, however. Engine pulled out on the bottom there so you can see it, the SAS bits are fairly clipped in there but at least instead of using RTGs, they're powered by fuel cells so they're slightly less cheaty? https://www.dropbox.com/s/z2g7q5pdz6nv1ax/P-38 Lightning.craft?dl=0 How to fly, for those interested! Best to turn on SAS and the brakes first, then hit '2' to turn on all the fuel cells. Press '1' after to decouple the engines from the main craft. (They're attached by docking port jrs.) After that, switch to each engine separately and slowly trim them up to full, pausing in-between trimming to let SAS briefly stop the engine so lift doesn't start to drag the craft. Once you have both engines trimmed all the way up, quickly cycle through both engines and turn off SAS and the engines will begin to spin up to full power. Finally, swap back to the plane and turn off the brakes and have fun buzzing the KSC!
  5. So, after a lot of trial-and-error and much mucking around, I believe I've come up with one of the smoothest bearing setups possible with the tried-and-true Stayputnik along with 650 I-beams. At least on my machine, it is exceptionally smooth spinning and fast! While also being fairly compact. https://www.dropbox.com/s/5ismrasz1vll9ic/Electric Prop Motor.craft?dl=0 As you can probably tell in the images, the Stayputnik head gets cupped by the octogon edge created by the 650 I-beams and it pretty much just locks in there. It does seem to work with 6 or even 4 I-beams, but it isn't as smooth. You can see the shaft/engine assembly in the back. There's 8 RTGs in there for power with the axle being the 1.25m fairing mount, there's also the 1.25 reaction wheel in there because the fair base doesn't play nice with the structural fuselage. It seems to easily hit the RPM limit with very little bucking of the housing and/or shaft. I tried using other parts in place of the 650 I-beams, like octostruts, but they don't provide nearly the same smoothness. I used a docking port Jr. to decouple the engine which is on action group 1. Built in 1.2, btw. Makes quite a bit of use of auto-struts. https://www.dropbox.com/s/4ao9h1kutig41tw/Tornado Mk1.craft?dl=0 Here's an example plane I've called the.. Tornado for.. reasons. How to fly: Enable brakes. Press 1 for action group one to separate the engine from the plane. Turn on SAS. Press bracket key to switch to the engine. Press Alt+Q to trim engine to max speed. Switch back to plane and shut off brakes. Take off and fly!
  6. Ahh! Well, I was aiming for efficiency on that one. Wanted to see if I could make something that could fly around for a good long while and the MK3 was to mostly test how much weight it could carry. On the other hand.. After a quick edit for more blades, it can -just- barely get off the ground with only the 4 panthers. Woooo
  7. So, by mucking around with the new floaty nodes on the fairing bases, I came up with this work-in-progress co-axial copter with a hybrid rotor design. Definitely need to work on the bearings a bit, but seems to fly reasonably okay. Certainly more fuel efficient then the quad I came up with.
  8. After watching EJs stream a few nights ago with him making a co-axial helicopter, I got the urge to mess around with these stock axles and came up with this quad-copter. Uses four stayputnik bearings with a bunch panther engines blowing on them. The caps to the bearings are SAS reaction wheels, so they can spin up on their own.. just not fast enough to get off the ground by electric alone. The panthers can spin them up fast enough to get off the ground without using the reaction wheels. Although it looks pretty ugly it as pretty fun to build! But flies a bit.. squirrelly, tends to want to pitch up. I guess the center of mass needs to move forward? Not sure.
  9. Another issue I've run into, (And I believe I've seen this one for a long time, just couldn't put my finger on it..) although I believe this is more of a bug with Kopernicus itself then OPM, but I've done all my testing of it within OPM. The short version is if you don't use a template planet the atmosphere that Kopernicus creates appears to be.. a little wonky. I've been doing some aero-braking testing of Jool, Sarnus, Urlum, and Neidon atmospheres to test the changes to thermal mechanics. Jool works exactly how you expect it. [imgur]H0tpu[/imgur] Used around 200 ablator on a sub-orbital drop coming in prograde. (Coming in retrograde roughly uses 2.5x times more ablator.) But the important thing to note is that you follow surface-mode retrograde coming in and eventually your horizontal speed eventually drops to nothing. Makes sense, right? The atmosphere is rotating with the planet properly. (Its a gas giant, the atmosphere technically -is- the planet after all, lol) This doesn't happen with Sarnus, Urlum, or Neidon! Instead you get something wonky and I hazard a guess that it doesn't work properly on -any- planet created by Kopernicus if you don't specify a template planet in the config. [imgur]HBNJS[/imgur] So, on a similar sub-orbital drop to Jool, you end up using more ablator braking into the atmosphere. This makes sense if you imagine that Kopernicus is creating a Kerbin-like atmosphere instead of a Jool-like atmosphere around Sarnus. Same thing happens at Urlum and Neidon too. The more important thing to note, however, is that you can not follow surface-mode retrograde down into Sarnus. At some point, the horizontal velocity starts to go -up- to over 1.1Kms! Even though you're obviously falling straight down. Then, it gets even more odd! At exactly 15Km altitude, the game suddenly decides this isn't right and apparently tries to switch your orbital and surface velocity. The resulting Kraken attack literally rips most of the parts off the ship and sends them flying into the great beyond. Amusing, but wrong! The same effect happens at Urlum and Neidon too, however, since the velocity change isn't as.. large, it only causes the ship to violently lurch and flop around as it 'corrects itself'. But, if you add template Jool to the config.. [imgur]AgZeW[/imgur] ..Everything works properly. Sarnus inherits the newer thermal mechanics of Jool (Didn't even use any ablator on this sub-orbital drop, although the heat-shield did warm up a bit!) and you can follow surface-mode retrograde all the way down with no Kraken attack at 15Km. Also, the normal map used on Jool shows back up which, in my humble opinion, looks better then the completely smooth look of the atmosphere. I guess what's happening is when Kopernicus is asking KSP to create an atmosphere, without a template, there's a few variables missing so KSP defaults to using some old Kerbin-like values, resulting in the wonkyness.
  10. Well, your just in luck. I wanted a cloud config for Sarnus as well, based on the Oblivion pack. I think this is pretty good, if I do say so myself. Ironically, it makes Sarnus look alot like Jupiter, but.. that's not a terrible thing, in my opinion. Sarnus shouldn't be completely like Saturn, after all. https://www.dropbox.com/s/p8rtoa8y5f9tdyc/Clouds-Sarnus.cfg?dl=0 Try not to get vertigo on the way down! Some of those clouds go really fast!
  11. This is similar to what I was trying to setup in my .25 career game for.. the fun of it. I wanted an asteroid base in high Kerbin orbit (Above the Mun) to be some kind of fuel dump, for the heck of it. Obviously this wouldn't qualify since its faaaar to high up but it might give people some ideas. This A and two Bs weren't too difficult (For me, once I figured it out.) to get all docked together with minimal hardware. The Kraken did attack at the beginning, but this was because of some Fine Print bugs that have since been fixed in .90 Once I figured out the issue with it, I was able to dock them all together with no further issues. I haven't had any time to continue the project, particularly with .90 having since came out and the holidays.
  12. I never said they were the same, you should reread my comment a bit deeper as I didn't make that claim. My claim is that 'because of the construction of the spacecraft' the electronics would probably be fine from some kind of discharge. I gave 'highly shielded from from radiation' as an example of such construction, but not necessarily the reason they would survive, mostly because they're built tough. These things aren't like your typical cell phone with their fragile electronics. The cores of these things are built to survive cosmic rays and gamma rays. (Hopefully many times) What are these? High energy particles that when they hit something.. transfer their energy. (Discharge) And you do realize the solar system isn't a complete vacuum... right? Solar plasma, solar wind, any of these strike a bell? These are all a constant in space (In our local system) and thus, is not a complete vacuum. There can be a transfer of charge from non-touching objects, it just doesn't happen very fast. But of course, Rosetta spent plenty of years in space.
  13. Not that I truly believe in the electric universe theory myself (Although the Standard Model is quite holey itself) but in this case, there wouldn't have to be some massive discharge. You have to remember that Rosetta matched orbits with 67P and came up from behind the comet/asteroid itself and thus came from a similar orbital distance. It was also in orbit around 67P for some time before hand. Thus, it's possible that whatever charge difference existed was eventually balanced out before the landing. ...Its also quite possible that the reason the harpoons and thrusters failed in the first place was some kind of discharge shorting out the lander. The electronics would be fine, I'd imagine, simply because of their construction. Spacecraft gear is usually highly shielded from from radiation and is built to be quite tough.
  14. As far as Part Clipping goes, I always enable it. I do not consider part clipping a 'cheat' for two main reasons. A) You can already clip parts fairly easily without it being enabled: Stick an engine on the BZ-52 radial plate, pick up the plate and rotate it around. Tada! Engine clipped into the tank. Works for anything stuck to a surface mountable piece. The game doesn't bother to check for collision with any of the parts attached to the piece that your moving. Just the root part. All enabling part clipping does in the debug menu is disable checking for collision with the root part that your moving around. Moreover, enabling part clipping tends to fix those issues where your trying to attach something in symmetry.. but it won't do it, even though nothing is apparently 'colliding'. NASA and aero-space companies don't have to deal with 'part clipping'. They just engineer the stuff to fit together how they need too. They don't deal with pre-manufactured parts that they can't modify to suit their needs. Heck, when have you ever seen a rocket with batteries stuck to the sides? In anycase, as for air intakes, I'll typically do anything from 1 to 4 intakes per engine, depending on the plane and if it 'looks' okay doing so. I won't just stack them. For instance, I'll use the stack coupler plates to attach more then 1 intake in front of the engine, like this: Where it stimulates an extra-wide air intake, or a high-bypass turbo-fan engine.
  15. Alternatively, you could design a rover where flipping over isn't too much of an issue. The structural panels and short I-beams are quite impact resistant, for instance. But, In general going slower is a good idea.
×
×
  • Create New...