Jump to content

Search the Community

Showing results for tags 'design'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • General
    • Announcements
    • Welcome Aboard
  • Kerbal Space Program 2
    • KSP2 Dev Updates
    • KSP2 Discussion
    • KSP2 Suggestions and Development Discussion
    • Challenges & Mission Ideas
    • The KSP2 Spacecraft Exchange
    • Mission Reports
    • KSP2 Prelaunch Archive
  • Kerbal Space Program 2 Gameplay & Technical Support
    • KSP2 Gameplay Questions and Tutorials
    • KSP2 Technical Support (PC, unmodded installs)
    • KSP2 Technical Support (PC, modded installs)
  • Kerbal Space Program 2 Mods
    • KSP2 Mod Discussions
    • KSP2 Mod Releases
    • KSP2 Mod Development
  • Kerbal Space Program 1
    • KSP1 The Daily Kerbal
    • KSP1 Discussion
    • KSP1 Suggestions & Development Discussion
    • KSP1 Challenges & Mission ideas
    • KSP1 The Spacecraft Exchange
    • KSP1 Mission Reports
    • KSP1 Gameplay and Technical Support
    • KSP1 Mods
    • KSP1 Expansions
  • Community
    • Science & Spaceflight
    • Kerbal Network
    • The Lounge
    • KSP Fan Works
  • International
    • International
  • KerbalEDU
    • KerbalEDU
    • KerbalEDU Website

Categories

There are no results to display.


Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website URL


Skype


Twitter


About me


Location


Interests

  1. First off, it's not my first rodeo in KSP. However, I found that one of my greatest challenges for interplanetary missions is designing a ship that is aerodynamically stable while performing an aerocapture maneuver. The primary reason for this is that rockets are naturally bottom-heavy, especially when launched from KSC. So while one can easily place an inflatable heat shield between the launch abort system and the command module, the center of mass will be so far back that the ship will tend to flip unless you add a ton of drag to the back end, in the form of literally tons of fins or more creative means. That was my first instinct, and I ended up with various semi-successful designs including turbine-like fins and infernal robotics deployed drag-inducers (heat shields). This solution isn't consistent, so I started designing ships to aerobrake engine-side first. Designs, using KIS/KAS, included using winches to haul a massive heat shield in front of the engines, assembling a heat shield in situ, or robotic arms moving radial shields into a heat shield snow plow design. Then came my most successful design concept - separation. I started designing ships to separate into two equally massive halves and aerocapture separately. Then would then rendezvous and rejoin after they left the atmosphere. The two halves were always much more stable than attempting to aero break with my typical burj khalifa looking design. My question is: what have been your successful solutions? I have a sneaking suspicion that there is a more elegant one out there.
  2. Howdy Everybody! First off, I want to thank @Pudgemountain for this idea. He recently posted the results of an ai program attempting to recreate images of the Saturn V rocket. The results were...something to say the least. However, the images provided interesting ideas for rockets. I invite everyone on the forums to create spacecraft based on their own ai images! Post ai images for others to springboard off of, post images of your KSP creations, even both! I will also be posting ai generated images of my own so that folks can pick out ideas they want to bring to...reality?...kerbality?...whatever. Just a few rules: 1) Any craft that are created must be functional. Rockets need to be able to get off pads, spacecraft can achieve proper orbital spaceflights, etc. 2) If you decide to post your own ai inspired craft, show the original image that provided your inspiration. 3) Whatever ai generation software you use, be sure to provide credit to that site. On that note, make sure they allow public usage of images you create (shouldn't be an issue, but you never know). Above all else, have fun! Let your imagination run wild! If you want to provide a mission report or a short story for your vehicle, by all means! Below I have the original post plus examples I worked up today. Above is one of the original images that gave rise to this idea. Again, send your praise @Pudgemountain's way! Here I recreated the last rocket on the right. Then I decided to check out these ai image generators myself. Which gave me more ideas. Also I started typing a lot of random and "what-if" ideas to toy with. One of my KSP saves, 101 Rocketry, is a US-inspired private aerospace company with a bit of a Taiwanese/ROC flair. I recreated the top center rocket (at least my interpretation). Almost forgot, I have the craft files for these two rockets if you want to mess around with them: https://kerbalx.com/ManateeAerospace/XN1-Tallcom-A https://kerbalx.com/ManateeAerospace/Salamander-II
  3. Hello folks! Based on the warm response of my last Experiment on a possible Tweakables Redesign (Result) , I decided to take another take on a bigger experiment! The idea was to redesign the Flight HUD, by polishing existing UI and respecting the original project (aka: don't reinvent everything). My approach was: Adjust the balance between skeuomorphism and flat design, adding a bit of texture but removing overused bevels effects. Improve usability by working on clear affordance. If you can drag, press, toggle... Differentiate it in a consistent way. More consistent iconography Easier learning curve for critical controls (staging as button, keyboard hints for throttle/roll/yaw/pitch) Add some small quality of live improvements (toggle solar panels/antenna, warp to next node) Better color mapping. Blue to delta-v, orange arrow for direct input, white arrow for readouts Flight HUD redesign In the end this looked like a very conservative approach, by keeping a lot of things in the same place... But boy, what a challenge! I had no idea that it would be that complex to redraw everything Things that I would like to improve: The action parts buttons could be better integrated, they feel a bit "meh" The app button could be better solved. I would love to see in the future something more iOSish, with a mix of mini-hud/modal/sidebar solution for the apps. I messed up with the font size. The raster version looks awful. Anyone uses the HDG reading? I hesitated to replace it with orbital info multiple times. I would love to add a "time to:" that adapt to hit ground/leave orbit/next maneuver Check the hi-resolution in vector format: https://www.figma.com/file/09xWDTa5XQJy140q7sCyPX/Kerbal-–-Design-experiments?node-id=33%3A134 What do you think?
  4. Hello! This subject has been a lot on my mind since I started playing KSP because I've always found myself wasting a lot of time designing unique upper and booster stages for my payloads instead of just slapping on a previously used assembly. I feel like there should be some better assembly building gameplay mechanics and incentives to guide the designing, building and integration steps towards an easy to use iterative process. Allow me to explain: What we have in KSP1 VAB / SPH have gameplay features that allow us to save our designs: Saving craft files in folders Saving with distinct folder roots for VAB and SPH this is a problem when you have a structure like the one below it also messes with the orientation Craft files can be manually overwritten although the path to the file is not loaded automatically and if I want to overwrite I save I have to point to the appropriate folder every time I load the craft, otherwise it saves in the root folder - I feel like this is a bug; We can of course create folders that are the basis for our organizational choices - I like to separate them initially into: Craft designs: Prototypes Structural assemblies Planes Fighter Space Cargo Other Rockets Boosters (by weight to LKO and diameter) Upper stages (by weight to solar orbit and diameter) Mothership propulsion elements Space Stations Rovers and vehicles (by size, number of passengers, purpose - science, fun or utility) Manned exploration Landers Return capsules Unmanned exploration Deep space / fly-by probes Orbiters Landers Return missions Satellites Science / mapping Communication relays Fuel Tanker stages Refineries Wheeled transports Pods Living pods Tourist pods, Science pods / labs Escape / transport pods Other Missions (the rockets / space planes I actually launched): with a folder for every celestial body, in orbit or landed + asteroids / comets As you can see things get very complicated and there is potential for overlapping functions, sizing problems and other issues All of this does not even touch on the problem of design versioning and evolution - this adds another whole new level of complexity to the issue Of course a very big problem is that if I save the craft as a mission and I change or improve something after mission failure or after returning from the launchpad.. then I have to go back and change that exact same thing in the original assembly design file. Saving subassemblies This theoretically should be straightforward but there are some issues: The root part mechanic makes it complicated All subassemblies are in the same "folder" When overwriting its difficult to change the description if the design changes, sometimes its better to write everything anew I have to search through and update the subassemplies every time I change something in the mission / craft design files I have to go to the subassemblies tab, its extra effort What we need in KSP2 We desperately need a better way of creating iterative designs, group them by families and separate them by version Craft versioning system (like GIT, to track evolution of specific craft models according to part and science progression) Missions and designs should be separate abstractions, missions should contain design versions Changes to designs should cascade into missions that use that design version We need some kind of default structure for the craft designs.. like the one I described above, otherwise players will take ages to become efficient in organizing all their stuff What has been confirmed for KSP2 Saving a workspace containing multiple craft assemblies Can you please help with other ideas? I think its a very important topic.
  5. ..why not? I think it's a game changer. Think of the incredibly creative sci-fi designs! PS: Hmm, I wonder if this could be done with wings containing fuel.
  6. One thing I've been curious about is a possible multiplayer feature that would allow multiple players to design vessels (stages) at the same time in the VAB. For everyone one person would work on the rocket while another world build the payload - at the same time, in the same VAB room. This feature would also allow more experienced players to teach beginners how to design and build correctly. Has anyone seen any clue about this feature?
  7. Welcome to the KSP Original Design Competition, brought to you by @Servo and @HB Stratos! The Idea Servo came up with a challenge for his own to build an original design for each jet fighter generation. I was inspired by this and in collaboration with Servo we made background information/guoverment contract for each jet plane generation. The Contracts 1. Generation 2. Generation 3. Generation 4. Generation 4.5. Generation 5. Generation 6. Generation Transport Aircraft form various times Few rules Part clipping is allowed Craft File Editing is allowed Stock craft only No Making History Expansion How to win I can´t really say there will be a definite winner, but I will probably make a video on my YouTube channel featuring the 3-5 best aircrafts of each generation. How to submit your Planes You are allowed to submit as may planes as you want, but just one is also fine Template for submitting stuff, coupy this and replace with content to contribute. [contact no. xy] [generation] [author(s)] [craft name] [description] [pictures (max 3)] [Download link (if possible KerbalX)] HB Stratos over and out
  8. So this is not a new question; I've seen many other posts on the same general topic. The previous one with this exact title was a bit outdated, though, so I thought I'd open a new one. The question is: what can you do to improve performance of your game (outside of bying new computing kit). More specifically: what can you do to improve performance around space stations. The reason I ask is I've been having inconsistent results with my station designs. I've had massively big stations, 500+ parts, with reasonable (given the total part count of station, docking and approaching vessels) though not stunning performance: And then I've had this tiny station ... : (Modlist for above spacestation: https://drive.google.com/file/d/1vajct196DKoGFBZJ_YWFe_QXjAEuXLRe/view?usp=sharing) ... which sports an entirely reasonable 200 parts (including a few docked tugs) but drops my framerate down to single digits per second - and I didn't even try to make the rings rotate (the rings were just a convenient shape for getting stuff to orbit). So obviously, it's not just the part count, but the type of parts that matter. Some guesses as to what type of parts have the potential to affect framerate: Solar panels: they have to keep track of the orientation of the station relative to the Sun and, if they're the tracking type, adjust their angle. Docking ports: they may be scanning for nearby targets and adjust their behaviour accordingly. (Though the first pic shows a station with massive numbers of docking ports that nevertheless performed way better than the one in the second pic...) The USI Kolonization mod I'm using probably recalculates the current life support status of habitation modules every other. In the above stations I cheated by using the UbioZur Welding mod to reduce part count, by welding most continuous 'inactive' parts together (like adjacent crew cabins, girders or fuel tanks). Now theoretically this should reduce the load and therefore improve framerate. But I'm not a coder; I have no idea how the code for this mod works or how the code of the game proper has evolved since this mod was first developed. It may be that it's not just about the actual parts, but about the modules inside those parts, which aren't welded - I presume. So, mods installed, type and number of parts ... what else affects framerate? Can I - can we - come to some kind of consistent set of guidelines for constructing stations big enough to be worth having that don't cause you to grind your teeth at every docking manoeuvre? What parts to avoid, how to avoid them; what mods to install, and which mods not to ... I'd love to hear your advice and your experiences. Thanks! EDIT: Another thing, I forgot, that may have impact: settings. Like the max DT per frame spent on physics calculations. The Max DT was lower with the top station than with the one below, but I've been told that bigger is better in this case. Soit, I'll have to experiment with this a little. SUMMARY TO DATE: Limit the number of docking ports. Docking ports, especially unshielded ones, scan the environment for partners to mate with, which puts extra load on the CPU. Also, if you limit the number of docking ports, you'll be limiting the number of craft that are docked at any given time, which limits total part count. Limit the number of solar panels. All solar panels, not just the ones that actively track the sun, need to be able to calculate their position and attitude relative to the sun, and whether or not any obstacles are present between them and the sun. Limit the potential for fuel crossfeed. Modularize your station: all fuel (or presumably consumables of any given kind) in one section. See Starman4308's mention of Stratenblitz's video here. Following AlpacaMall's suggestion: limit the number of lights. I haven't had this problem myself, but I can see how lights might require CPU intensive calculations. And of course, try to limit the overall number of parts. Mods like UbioZur's Welding mod my help here, or things like the various Station Parts modules I occasionally see mentioned. Sure, you can build grandiose stations just for the kick of it; try and match Stratenblitz's Kerbol 0 if you dare. But if you're looking for something to use as a staging area and (re)fuelling post for forays into the system, then Simpler Is Better (which is what gave me the initial idea for the station in the first pic in this post: basically just a bunch of girders, docking ports and fuel tanks).
  9. Do you guys have any tips and tricks to build a munar base as efficiently as possible? Recommendations? Tutorials?
  10. Level: Intermediate/Advanced: You need to be able to slap together a plane that flies reasonably well before attempting a VTOL. Background reading: Start with the fantastic Basic Aircraft Design tutorial in this very forum. Craft used to illustrate this tutorial: BAK Cyclone BAK Karmilla BAK Drakula BAK Zephyr BAK Bumblebee What's a VTOL aircraft? VTOL stands for "Vertical Take-Off and Landing." A VTOL aircraft as discussed here is a craft that's designed to fly aerodynamically, using lift produced by lifting surfaces, but take off and land vertically. That's what this guide is all about, so we're not talking about VTOL rockets that don't make use of wings to produce lift. We're also not discussing helicopters here, because stock kerbals have not invented the propeller, and stock propellers are a whole big topic of their own. So this guide is about atmospheric craft designed to fly by making use of lift generated by wings, which can take off and land vertically by use of downward-pointing jets or rockets. This guide also applies to STOL (Short Take-Off and Landing) aircraft which do their thing using downward-pointing jets or rockets, because they're pretty much the same thing. Their hoverjets just have a TWR of less than 1.0. Why VTOL? Because they're fun and educational and you can. Next question? No, seriously. Is there a point? There are a few missions for which a VTOL aircraft is ideal. Kerbin has some biomes that are difficult to reach any other way. The same applies to Laythe, although it has gentler topography. Finally, it is really difficult to land a HTOL atmospheric craft on Duna because of the thin air: you'll be going really fast and terrain is really bumpy, so there's a huge risk of ending up as a big ball of fire, whereas it's very hard to land a conventional rocket lander precisely, like when you're aiming for your surface base. On the other hand, atmospheric craft are superb for exploring it for the very same reason – you can scout for the perfect spot for your base, then land precisely there. A V/STOL atmospheric craft built for Duna can drop you on any dime, anywhere on the surface. But mostly, the answer is still "because they're fun and educational and you can." The BAK Cyclone hard at work on Duna. It's a flatbed freighter suitable for shuttling base modules to and from the surface. The cargo is near the centre of mass, but because it can shift, it's important to adjust the exact balance by tuning the power on the nose hoverjet... The basics At its core, a VTOL aircraft is a plain old aircraft, with downward-pointing jets that produce a TWR of > 1.0 with the vector centred on the craft's centre of mass, and some way of controlling its attitude when it is hovering, because control surfaces do nothing at an airspeed of zero. Getting all of this into one craft is a pretty intricate business, however. In particular, there's one constraint that needs special attention: centre of mass, and the invariance thereof, as you burn fuel. In other words, your fuel tanks need to be placed symmetrically around the centre of mass so it doesn't shift as the tanks dry, and you need to get your vertical thrust vector exactly aligned with said centre of mass. Regular HTOL aircraft can afford to be a bit sloppy with this because aerodynamic forces will effectively obliterate moderate shifts in CoM -- if your plane gets a bit more tail-happy as the tanks drain it's no problem, as long as your CoM stays ahead of your CoL. Mostly anyway. Not so with VTOLs: if the CoM shifts, you're not going to be able to land vertically anymore. Here's how you go about building a VTOL under these constraints. Build yourself a plane. However, don't put any fuel tanks on it yet, and empty any fuel-containing parts that you are using. Switch on the CoM and CoT overlays. Set the thrust limiter on your main engines to zero. Your CoT vector will disappear. Add enough downward-pointing jets to lift the plane, as symmetrically as you can around the CoM, in a minimum of two pods (fore and aft). (You can add more pods to the sides if your body plan permits it.) Adjust the thrust limiter on the fore (or aft) hoverjets until the thrust vector lines up with the CoM. Add fuel tanks symmetrically around the CoM. Add RCS jets to the bottom of the craft, at the nose, tail, and wingtips. Don't forget the fuel – Vernors need oxidant, the others need monoprop. (If you're building a very small craft, you can just use a reaction wheel instead. But that's less cool.) Set up your control scheme: one action group for toggling the hover jets, another action group for toggling the main jets, plus yet another one to toggle the hover jet bays, if you're using them (as you should). There, done. Simple, eh? Hoverjet design The first challenge you're likely to hit is choice of hoverjet. The second one is likely to be aerodynamics – if you just stick on some downward-pointing jets, you will find that they produce a lot of drag, which is going to be really inefficient. Your plane will be slow and have limited range, or you'll have to make it a lot bigger to brute-force your way around that limitation. The solution is to house the hoverjets in a cargo bay of some kind, with the doors opening downwards. That way you can tuck them away for normal flight, and expose them for hovering. There are lots of ways to make this work, but here are some designs I've used successfully: Juno in a Mk 1 utility bay. Stick it inside the utility bay, rotate it to point towards an opening, move it until it's completely inside. These are easy, pretty light, and you can add more of them – within reason – for more lifting power. Array of Junos in a Mk 2 cargo bay. This needs scaffolding: you need to put something in the cargo bay that lets you attach the Junos to it. A short Mk 2 bay will fit an array of 9 Junos, and a long Mk 2 bay will fit 18. That's a lot of lifting power – three Wheesleys' worth in the bigger bay! Also a lot of parts. I hope you have a fast computer. For rocket-powered hover, use Spark, Aerospike, or Vector (if you really need a lot of hover power). Terriers will also work on Duna. Sparks will fit in Mk 1 utility bays, the bigger ones will fit in the bigger cargo bays (Mk 2, 2.5m utility bay, Mk 3). Giving them air Air-breathing hoverjets need intakes. At this point you'll probably need to go back to the plane design you started with, because air intakes are dry mass and will shift the CoM as you add them. Hint: The engine pre-cooler and engine nacelle are fantastic air intakes, and they can be mounted in-line or combined with other elements. You don't have to use their fuel capacity – you might want to leave them dry if they're not symmetrical to the CoM. Hover control The main challenge for hover control is to keep the craft horizontal. If it starts tipping in one direction, you're really likely to flip over and crash dramatically, like a tree falling over. If additionally you can give it a controlled tilt and hold it there, then it'll start accelerating in that direction, like a helicopter. This can be most helpful when transitioning to or from level flight. Option 1: RCS RCS will get the job done nicely, and looks cool to boot. You will need more jets at the nose and tail than on the wingtips, as there will be more forces on pitch when transitioning to or from level flight. Your choice of RCS jet is the Place-Anywhere or the Vernor. You may need to add several on bigger craft. Option 2: Reaction wheels Reaction wheels will balance smaller craft just fine, but are probably insufficient for bigger ones. Managing centre of mass One of the most finicky problems with VTOL craft is managing centre of mass. In principle it's simple – just place your fuel symmetrically around the dry CoM, and centre your vertical thrust vector on it – but... how? Use wing-mounted engine pods on pylons. Engines are dry mass. Mount them on pylons on the wing, and it's easy to move them forward and back to fine-tune the CoM. Put fuel tanks outside your main stack. Wing-mounted tanks, wingtip tanks, drop tanks, and side-mounted tanks flush with the body all work, as long as they can be moved backwards and forwards relative to the dry CoM. If you don't mind a bit of clipping, you can even make the latter look pretty good by clipping them a bit in the body. It makes no functional difference, but if you consider it cheating, don't do it. Use a long, light tail section. Long tails are good for stability anyway. If you make a long, light tail, you can adjust the balance of the craft by making it slightly longer or shorter without adding a lot of weight or making big design changes. Body plans I've found a few body plans to be especially amenable to conversion to VTOL. They have in common that it's easy to tweak the balance by moving things around, rather than having to add or remove pieces. Twin-boom The twin-boom design is one of my favourites, largely because it looks cool. In a twin-boom design, you have one hoverjet at the nose, and one in each of the booms. Light craft have a single engine at the rear of the fuselage. Larger ones have additional wing-mounted pods. The BAK Karmilla. This one is balanced with reaction wheels. It uses six Mk 1 utility bay-mounted Junos for hovering. The BAK Drakula. A bigger twin-boom design using two arrays of 18 Junos on each boom and a single array of 9 on the nose. Twin-Pod A twin-pod design is similar to a twin-boom, except that it has a conventional tail extending from the fuselage. The hoverjets are housed in the big wing-mounted pods. The BAK Zephyr, a rocket-powered VTOL craft designed for conducting science missions on Duna. It is entirely powered by Terriers. The absurdly big wing and control surfaces make it highly economical for high-altitude supercruising. The BAK Cyclone, delivering a station module to Duna. Note the landing area markers. The Cyclone uses Aerospikes for propulsion. Rockets are much less efficient than air-breathers, so it needs to be much bigger than a Kerbin-bound craft performing the same mission! Control schemes and flight To fly a VTOL craft, you need to be able to perform the following actions, which must be bound to a an action group: Toggle the hover jets Toggle the forward jets Control attitude If you have full RCS control, you will additionally need control for that, and if your hoverjets are inside pods, you will want a control for toggling them too. Taking off The procedure for a vertical take-off is as follows: Hoverjet pods OPEN Forward jets OFF RCS ON SAS ON Hoverjets ON Throttle MAXIMUM When off the ground at a sufficient altitude to clear obstacles, main jets ON When at sufficient speed for aerodynamic flight, hoverjets OFF, pods CLOSED, gear UP The procedure for a short take-off is the same, except that forward jets and hoverjets will both be ON from the start. The craft will lift off once generated lift + hoverjet thrust overcome its mass. Landing To land a VTOL aircraft, approach the landing zone as you would with a regular HTOL craft, until on final approach. Then: Hoverjet pods OPEN Gear DOWN Throttle ZERO Main jets OFF Hoverjets ON Keep pitching up as you approach stall speed. When you're close to it, INCREASE THROTTLE until your rate of descent nears zero. Your airspeed will also fall. When your airspeed is low enough that aerodynamic control is getting sluggish, RCS ON, SAS ON. Control your vector primarily with pitch, and your descent rate with throttle. When your airspeed is near zero and you're above your landing spot, reduce throttle until you start descending. Touch down, CUT throttle, CUT engines, BRAKES ON. You've landed. ...and that's it really! I hope you've found this short tutorial useful. Have fun with your S/VTOL craft – and don't forget there are more ways to do them as well, including helicopter-like things that don't fly aerodynamically at all. My first VTOL craft was the Bumblebee, and it's still one of my favourites!
  11. This rocket that I have designed to deliver a rover to duna keeps flipping immediately after launch. I have tried adjusting fins, fuel tanks, thrusters, and throttle. I have also tried launching with and without SAS on and it flips over no matter what. Can someone please tell me what is wrong with my rocket?
  12. Hi everyone, I’m super new to KSP. I’ve managed to get into Kerbin orbit using the excellent tutorial by quill18 on YT. When he moves on to Get to the Mun, he doesn’t get into the rocket design well enough for me to replicate it. It doesn’t help that the designs of the parts have changed between his version of the software and mine (newest). Any rocket I build starts to roll when my liftoff speed gets to around 100m/s when I need start to make my turn to 90° so that I end up being at 45° on the NavBall when I reach 15000m per his tutorial. This is the only way I know to get to orbit so far. Can anyone tell from looking at the rocket what parts he’s built the rocket from so I can stick as close to the tutorial as possible? Here’s the tutorial: TIA for any assistance
  13. Hello, I have been making cars for sometime now, but they never seem to look perfect or sometimes good. Even my best replica (an AC Cobra) pales in comparison to some cars that others have made. I wanted to ask everyone (who are all probably better than me by a long shot) for any advice and help on how to make the bodywork look better. Most of cars look somewhat boxy. Also, how do you add such fine details with parts like wings, such as very precise offsets and rotations of parts onto your cars. This is because when I try to make the front of the car, I always make it look more like a psychotic duck than a sports car. Thank you
  14. Even though I have 15,000 excess science.. it's not enough. I found I had not yet landed on any of the Jool moons. Bad Kerbals! So, i decided I would take a lab with me, and make a single lander that can hit all the moons except Laythe (requires a specialized design). Tylo being the biggest challenge, because of its very high gravity/size, it's like landing on Kerbin without an atmosphere. So I designed a lander with some jettisonable fuel, with the idea I would go to Tylo FIRST, and then wouldn't need those tanks for Vall, Pol, or Bop. I would bring my lab with me as an undockable section, with its own fuel, RCS, etc. Unfortunately, I forgot to put a probe controller on it, but that's OK, I'll just have the lander always dock to it. The small docking ports are for refueling (note that I can't refuel the lander without the lab until I jettison the tanks, but might have been nice to put one on an external tank just in case.). The lab acts as the big com relay back to Kerbin, if needed. And, of course, I need to refuel constantly, so I made a one-piece driller/ISRU/fuel transport, with a small docking port for refueling the lander/lab sections. Small engine to just handle interplanetary and landing on Pol. Checking out the dV for the lander, the DV maps *say* I need about 2280 to land and take off at Tylo, with 4750, I *should* have enough, right? (more on this later). It may take a low starting orbit, but on paper, it should work. So, first we get up into Kerbin orbit, and head to Minmus to refuel everybody for the long drive to Jool. Note that I was able to keep the lower booster from Kerbin, so it took two refueling runs, but the landing section would come into Jool with plenty of fuel, while the driller would come into Jool orbit with maybe only 800 dV, probably enough to get to Pol on its own, but this added extra insurance. Turns out I had plenty, transfer, orbit and landing is maybe 500-700. We refuel everyone at Pol, and head to Tylo. Now, I begin to worry- if I start my landing low (say 17km), and get back to a low orbit, can my fuel ship dip down that low to refuel (before landing and after re-orbit), and climb back out the gravity well and get back to Pol and land? The answer, it turns out, is yes. I leave about 1000 dV for each run back to Pol. So, we try our first descent from 17km. We learn two things. (1) You can't start from 17km because you can't slow down fast enough before gravity sucks you into a mountain. If you thrust downward enough, you use too much fuel. So we raise the descent to about 30km. That works well, but we land with only about 2100 dV left, not nearly enough to get back into orbit. It turns out it takes about 2500 dV to get to a roughly 10km orbit. Yep, this looks bad. So, after failed attempts, I realize I need help. So I built another fuel/engine "top" component to provide more fuel (and the thrust to counter its extra weight). Note that I added a decoupler to the docking ring, because those BIG docking rings have enough magnetic attraction they don't come loose easily. I am still granted the proper dV, but I didn't want to have something that might crash on top of me and explode after landing. With this component and some careful piloting, I'm able to land with about 2561 dV left. Note that I hit hard when I landed and broke a strut, but I should still be fine for Vall. 2561 was enough to put us back into a 9kmx20km orbit, with enough dV left to re-dock with the science section. Then the refueler only had to make one stop! So, the major lesson learned is- don't trust the dV maps. It took about 2600-2800 dV to land and 2300-2400 to reach stable orbit, and that's with optimal piloting. But other than that, the "two ships, single lander for four moons" project is so far a success, and has passed the toughest test.... Tylo, with only one landing strut as a casualty.
  15. This is a post I originally started a couple years ago in a thread for My History of Spaceflight, but it got a little buried (...I couldn't find it...) so I thought I'd make a new post and include my thoughts on spacecraft design et. al. I would like to keep updating it with comments of various craft that I've created as well as the through process behind them. Philosophy and Approach This actually encompasses more than just KSP as I've been "designing" spaceships since I was a little kid, "swooshing" a few little Lego parts that I wholeheartedly believed was a spaceship. I have a vivid memory of playing with these handful of Legos and intuitively thinking: Spaceship. That passion for Lego eventually evolved into much larger SHIPs (Ex: #1, #2, #3, #4, #5). But at that same time, I would pore over the many versions of Star Trek technical manuals, marvel at blueprints of the Millenium Falcon, and stand in fascinated awe at the Space Shuttle in the early 80s. Add to that, basically 30+ years of pop-culture spacecraft awareness, a dash of actual space history, a whole of of imagination, channelled into a digital medium that allows me to build & fly these things. Watching Star Wars movies literally more times than I can count, continuously consuming Star Trek for over 30 years, loving late-70s Buck Rogers (unaware of the monumental cheesiness), hyperactive over Battlestar Galactica (the 70s original, but then much more importantly, the 2004 reboot); really just about anything in the Sci-fi genre that might include a vehicle maneuvering through the vacuum of space, or on alien planets, or heck even our own planet. With Kerbal Space Program, I've found one of the best tools to express the combination of creative and analytical thinking that is spacecraft design. It's a pseudo-practical approach that, for me, makes this game endlessly playable and allows that expression. So even though it's a game, the fact that you engineer things in this game to actually fly adds an entire level of realism (or not... depending on your KSP playstyle) to the process. And while KSP & Lego are aspects of the same thing, i.e. working with a specific set of parts, creating something unique but not overbuilt; KSP allows me to take this newly created vessel for a spin around the solar system. So, you ask, what do I mean by "pseudo-practical"? A personal philosophy, I guess, that imposes a set of realistic parameters on an inherently unrealistic creation. Designing in a way that balances in-game mechanics with a broader use case for a spacecraft. Working with symmetry and aesthetics, while balancing the inherent asymmetricality of space technologies melding together into a ship. Maintaining the internal logic of specific part choices used in specific ways within an overall visual context, that hopefully comes across as both "realistic" and creatively interesting at the same time. I find myself constantly evaluating the aesthetic choice of a set of parts in trying to meet a certain need, then reviewing whether those parts meet the game's technical needs, then going back to adjust how they mesh visually, then back to the parts specs... until many iterations later, an actual spacecraft evolves. Then I keep looking at it, noodling with it; taking away anything that strikes me as "off" and in some cases completely re-working the craft. When I do orbital test runs, if anything jumps out at me visually, I usually re-work it. If the ship isn't meeting the technical needs of the mission, I re-work it. This goes on until I think I can't possibly make any more changes (then I usually find 1 or 2 more...) until FINALLY, I can't stop looking at it. There's nothing that my brain says, "Wait. Change that." It's odd to use the word 'perfect', but in a sense that's what it is. My brain has gone through just about every iteration until it just seems 'right' on all facets. There's a creative pride that comes from this iteration process. There's a sense of childlike whimsy when the thing can actually make orbit, or I can actually dock it, or the antennas extend, or the light and shadow catches it just the right way. The same feeling as when I was 6 years old making Lego ships. "I made a ship that flies through space."
  16. Disclaimer: Hey devs, don't take this as criticism. I know how regular people usually are clueless about how complex things are beyond the surface of a development process... This is just for fun, peace ✌️ Hello folks! I work as a full-time UI/UX designer, and something that grinds my gears is how a super complex game as Kerbal Space Program lacks a good interaction design foundation in some parts. I'm always worried about how hard is the learning curve for newbies... To understand how basic things work. So, I decided to give a little bit of love back to the community by doing some design experiments. I hope this gets people inspired somehow. --- Experiment on a possible Tweakables Redesign 1. Analysis Ok, so this tweakable popover looks too complex for a basic part. I start by analyzing the content, trying to understand the patterns behind. I added a color-coded interpretation on how most of the content relationship, so I could compare with other screens. Using Advanced Tweakables sounds unfair, so let's get it going without it. I will miss you Autostrut. The screens stills look complex, with a loose relationship between the content. The main thing that draws my attention are: Lack of order and relationship Inconsistent readouts Different kind of controls look like the same button Parameters (input) and Resources (output) looks too similar "#" have a loose mapping to the Parameters input "Crew report" generates science, but it doesn't stand out from secondary stuff. This is a "cold" analysis that I'm doing without a proper user research process. To do it for real, the right way would be doing some usability tests and card sorting with real people. If you are short on time, the best way to start studying a user interface is by these two points of views: 10 Usability Heuristics for User Interface Design https://www.nngroup.com/articles/ten-usability-heuristics/ Understanding mental and conceptual models in product design https://uxdesign.cc/understanding-mental-and-conceptual-models-in-product-design-7d69de3cae26 Alright, let's see what else I can collect... Comparing some basic tweakables side-by-side opened my mind that the "real" problem in the pods is how they fail to communicate the different modules bundled in a single part. Most of the smaller tweakables are pretty straightforward to understand, even with some features that feels they slipped through Advanced Tweakables and ended in the stock mode. This a non-extensive list of the inputs/outputs, so I can have a clear picture of the main UI patterns. 2. Process I decided to use the Mk1-3 Command Pod as a reference. It's fairly complex and it covers a god range input/outputs. I start from a basic wireframe (to focus on the content) and then move my way up adding more structure... In the end, I decided to not use the "collapsible category" idea because of the amount of visual noise it introduced and rollbacked some of the ideas because the original ones seem better. 3. Result This looks like the first steps of a draft for a UI library. It was way harder than I expected to give proper feedback/affordability to the buttons. The main idea is that the user can figure it out what kind of button it is before clicking it. What do you think? My favorite parts are the science indicator and divisors Source file: https://www.figma.com/file/09xWDTa5XQJy140q7sCyPX/Kerbak-–-Tweakables-Redesign?node-id=0%3A1
  17. I am trying to design the a rocket that has the exact right amount of Delta-V required to get to the Mun and back. The first stage should be capable of getting the rocket clear of the atmosphere. I have looked everywhere for how much Delta-V the first stage needs and have found nothing. How much Delta-V should I be aiming for for my first stage to be able to get above 70 km?
  18. Welcome to the... KSP Stock Prop Design Challenge! The aim of this challenge is to create the coolest looking stock prop designs you can! Your plane will be judged mostly on appearance and as such, speed and performance won't be judged very harshly; as long as it flies, and flies well enough it's okay (though good performance is always good to have). The goal of this challenge is to create a plane that fits both the requirements and aesthetics of what a contract of your choice says. The contracts will range from 1920s-30s biplanes to post WW2 superprops. There will be no definitive winner to this challenge, but aircraft I especially enjoy will have a spot on this original post. Please lay out your submission like this: [Contact No. XY][Generation (biplane, ww2 etc)][Manufacturer name/author(s)][Craft name][Description][Pictures (max 3)][Download link (preferably on KerbalX)] Guidelines/Rules 1) Unless otherwise stated in the contract, the plane must fly only with stock propellers. 2) The Design MUST be original and NOT a replica. 3) Stock designs only. DLC is not allowed. 4) Part clipping/craft file editing is allowed. ----- The Idea The idea for this challenge was blatantly ripped off HB Stratos' and Servo's Original Jet Fighter challenge. If you've stumbled here but aren't a fan, or don't know how to make props, visit their challenge instead: Major thanks to HB Stratos for letting me actually make this challenge even it's literally the same thing. ----- The Contracts Biplane Era ----- WW2 Era ----- Postwar Era --- Hall of Fame! @Jon144's fantastic K4F Scimitar is on the list because of it's superb performance; the best so far! While not as detailed as some of the other props, it's fast, and maneuverable enough to compensate. Good job! --- @erasmusguy's HF-108 fantastically detailed. It doesn't quite fit a category, but looks superb. I appreciate the detail added to it; especially the little men/RCS tanks. Well done. --- @Phantomic's P-45 bolt just looks like a plane straight from WW2. It has nice clean lines and isn't a bad flier either. Fits the contract almost perfectly. Great work! ----
  19. So this here is set up to show off race cars made by you guys! Here's what you're going to have to do. 1) Show the car off. (Show pictures of the side (Either side is fine), and the top. You can choose to add a third pic, but no more than 4.) 2) Tell it's features (i.e. RCS, Fins, etc.) And the part count. 3) (Optional) Take it around the test track provided here. (You can make your own track (Just make sure to include a pic or the map) 4) If possible, could you please let me know the setup on the car? This includes wing angles, spring/damper settings, friction control, etc. 5) Have fun! Here's the first car; the AS-1A, a fast, sleek open wheeled car with a tested top speed of 52 m/s with some speed ability still left. (I had to slow down for turn 1. I'll try to get a video of it doing a test lap up asap.
  20. I know most of you like badges, so why not add one to my upcoming event: Are there any members who are willing to design a badge for this event ? Looking forward to see your designs/ideas. The event will start september 1st
  21. What is the Kopernicus Creativity Marathon? An open competition for those who want to build planets. Every three weeks, a new challenge, describing what sort of planet or celestial body we are looking for. After the closing date for each challenge, the planets shall be judged and the winner shall be put in the Community Planet Pack. Judging: Planets shall be judged by thee following characteristics: Beauty: How attractive they are to view, and the level of detail and apparent effort was put into the world. Accuracy: How closely they match the challenge guidelines. Creativity: How unique and original is the planet, its features, and its use of procedural generation and/or textures. General Entry Rules: Planets must be made using an up-to-date version of Kopernicus and Kerbal Space Program. Any planets that are not updated to the current version will be disqualified. Planets must be created for this contest. No planets released in other planet packs may be entered. Any planets must be entered for the competition before the completion of each challenge. After the final day, submissions will be ignored. All planets must be released to myself under an MIT license, such that the worlds can be polished and made more consistent with each other so they can be released as a community planet pack. We can discuss alternate licenses in the private messenger. All credit will be given to the creators of the planets. Any entry containing a generic Space Engine export will be disqualified, however those which use the in-game editor may not be if it looks good in KSP. One planet per person per challenge round. Co-operation with other people is fine, but must be restricted to one planet per team. The above two rules may be loosened if a challenge calls for a specific number of bodies together. No plans, ideas, screenshots/images, or files regarding your planet may be shared until the completion of the challenge round for which it was designed. -CURRENT CHALLENGE ROUND- Post Date: July 18th, 2017 Closing Date: August 8th, 2017 Time: 3 Weeks The terrestrial space agency NASA has just released topographical data of one of their solar system's dwarf planets, Pluto. As such, the gods of the Solar System are gloating at us. We must one-up them. Your task is to design an icy dwarf planet oribiting the sun outside Eeloo. GUIDELINES/RULES: -Take inspiration from the known dwarf planet terrains: Pluto, Charon, and Triton. -Its orbit must be apparently stable, and not particularly ridiculous. -Try to strike a balance between realism and beauty. -Planetary radius should be between 70km and 180km, with a density between 1.5 g/cm^3 and 2.5 g/cm^3. --Radius, Mass, Density, and Gravity are related, in Earth-relative units, as G = M/(R^2) = R*D. --Earth density = 5.51 g/cm^3. Earth radius = 6370 km. --If your values for geeASL don't fit within the radius and density, then it will be lowered in the polishing phase. -You may add a small minor moon if you wish, but it will be judged separately from the dwarf planet. If it is not satisfactory it will be removed.
  22. Hey guys! I thought of a challenge for you guys; if I could draw a design or an artwork/paintings of anything (KSP related), See if you be able to make it and build it in ksp and post your pictures here. (sorry if there are similar challenges like this before in this forum, I did not have time to do a bit of searching) ok let me upload some drawings!!
  23. We have a small problem The seas off of the Kerbal Space Center is getting quite cluttered with spent stages and solid rocket motors that have splashed down into the ocean. Lately some of the higher ups in the research and development offices have had a radical idea: "What if we recovered our first stages?" After so heated arguments with the engineers who said it just can't be done, they have turned to you! The Challenge: Recover the first stage of your rocket (this means SSTO's don't count). You can do this however however you see fit, whether you want to land the first stage on a barge in the ocean, have it glide its way back onto the runway, or do something completely crazy! I want to see your ideas on how to recover a first stage, the Kerbal way. Points for this challenge are awarded as such one point: your craft is able to land its first stage safely two points: your craft is able to land the first stage near the KSC' three points: your craft is able to land the first stage on the runway/ launchpad four points: your craft is able to make the first stage land on the island runway five points: your craft is able to land the first stage on a barge/mobile landing pad you have put somwhere BONUS POINTS you will be given an extra 3 points for each of the following you are able to land your second/third/fourth ect stage/stages as well as your first you land your first stage using only SRBs you land your first stage using propellers you refuel your first stage and have it meet back up with the second stage or whatever stage is in orbit you recovered not only the first stage but any liquid/solid boosters that assisted it Hope to see some cool designs Leader Board 1: sevenperforce 11 points (two for landing near the KSC, 3 for recovering second stage, and considering how he refueled and rebuilt the ship I am giving him 6 points there) 2 3 4 5 -AtomicSnails
  24. Kerbal Express Airlines is in need of updating its aging fleet of regional jets and turboprops. It's a big client, operating at hundreds of airports around Kerbin, and that means big fleet sales. Does your aircraft company offer the right kind of aircraft for the job? Kerbal Express wants profitable aircraft. They're looking for aircraft that meet or exceed their requirements for fuel efficiency, speed, range, passenger load, ease of training, and cost of maintenance, for the right price that gives them the best return on investment. They also want a design that's flexible, offering variations of the same design for a variety of different routes. The Rules: KSP version 1.3 or 1.2.2 (Craft file must import into 1.3 for judging). Stock parts + Airplane Plus (optional) only. The Mk1 and Mk2 Crew Cabins count as 8 Passengers Mk3 Passenger Module and Size 2 Crew Cabin count as 24 Passengers Small aircraft must have at least 1 pilot in a cockpit, and medium-large at least 2 pilots. No command seats. No reaction wheels. Air breathing engines only. No overly wacky designs or "spaceships", it must look like a modern aircraft. Minor clipping is allowed, within reason. A rolling runway takeoff is required. Takeoff & Landing speed of no more than 80 m/s (Use flaps to achieve this, if necessary) Flaps must be set to toggle on action group Custom 01 Your aircraft must stay intact. [No drop tanks, etc.] Model variants may only have minor differences between them to be considered. 15,000m altitude limit. Mach 1 speed limit (343 m/s) TweakScale is allowed, just please don't ruin the spirit of the challenge with it. Submission Deadline: 9AM PST, 7/6/2017 What is a variant? To improve your design's competitiveness, your company can submit a variant of the same design (See Wants section below). A variant is built on the same model platform with minor changes in design to give it, say, extra range, or extra passenger room. This is most commonly achieved by adding fuel tanks or lengthening the cabin, sometimes with minor changes to wing and emmpanage design. To qualify as a variant, it must generally have the same structural layout, meaning engines, gear, and lift surfaces must be in roughly the same location & design. Basically, if you make it too different, it will be considered a separate model/submission. What Kerbal Express Air Wants, By Category: For all categories, Range will be calculated by total fuel capacity divided by fuel burn rate at the recommended cruising speed & altitude. Turboprop Range of at least 800km Cruising Speed of at least 130 m/s 24 Passengers, and optional 32 Passenger variant Small Regional Jet Range of at least 1000km Cruising Speed of at least 220 m/s 32 Passengers, and optional 40 Passenger variant with an extended range of at least 1200km. Medium Regional Jet Range of at least 1500km Cruising Speed of at least 240 m/s 72 Passengers, and optional variant with extended range of at least 2000km. Judging Criteria: Every submission that meets the requirements will be ranked w/ feedback from Kerbal Express Jet test pilots, but how well it ranks depends on: How well it meets or exceeds the category requirements How well it meets or exceeds the requested variant Cost of Aircraft Fuel Efficiency at recommended cruising speed & altitude Ease of maintenance; fewer parts and fewer engines are preferred How to Submit (See Example Submission in post below). Your post must include the following: The name of your aircraft company and model names for the designs you're submitting. At least one screenshot of your designs. A link to your craft files in your submission post. No PMing me. The price of your aircraft times 1,000,000. (If $23,555 in-game, submit as $23,555,000. This is just for fun to make prices more realistic.) The recommended cruising speed and altitude for your aircraft. This is the speed and altitude you've fine-tuned your designs for, ensuring the best balance of speed, range, and fuel efficiency. It's also what the test pilots will be testing your aircraft at for judging. (Optional, but will help in review) Pitch your aircraft to the Kerbal Express Airlines executives, selling them on why it should be purchased for their fleet. Include any notable features (even if fictional). ========================================================================== Challenge Submissions & Rank Turboprop Kramer - 50-100/150 Avery, A well balanced turboprop with good all-around performance and handling characteristics. Small Regional Jet Kembraer ZO-135, While unconventional in design, the Krembraer ZO-135 performed excellently, besting the competition in every way. Pizio & Hartmann Co. - Bluebell A+, Well featured, and meets all of our requirements at a reduced price. Osprey Regional Jet ORJ400/500, A well-rounded aircraft, meeting our requirements in all areas. Kerbolde Supersonic Jet - AAA072-1, An efficient, high-performance aircraft, but its supersonic speed significantly restricts its use over populated areas. ScarsTarsProducts - Vulture-01, A beautiful looking aircraft with excellent flexibility, but it burns fuel like a mofo. Medium Regional Jet One More Booster Co. - Kerb Ferry 72, Sturdy for cargo use, but its high fuel burn rate and steep price make it expensive for commercial passenger use. Kramer. - 150-100 Baltimore, Expensive, inefficient, loud, and too big. The Baltimore fails to be competitive on all fronts.
  25. Artificial Intelligence: Can we redesign the world? So I have thought about how AI systems are become so much more powerful and complex. So along those lines could computer system AI become self learning enough like google DEEPMIND project to improve just about everything? : Antivirus software with DEEPMIND rooted together so that another computer system could repeatedly attempt to hack with various viruses, then after such a point the Antivirus software with DEEPMIND becomes aware of creating a defense or destroying the virus as soon as detected. Redesign the virus attacking computer to become aware that it has still not found a route of taking control of the device, as this cause the DEEPMIND system would be added to the virus computer to make that happen. As well as come up with combinations of the current viruses to learn and then create more complex viruses of it's own to unlimited possibilities. This in turn could maybe help some networks get an antivirus software that would be incredibly unbeatable. "Antivirus software" is a relative term as to what software it would actually be called, would be up to the designer of course. DEEPMIND self learning AI could possibly learn the capabilities of the current computer system the AI is working in then calculate all kinds of different computer technology improvements. For example the move from HDD to Solid State Drives, seem to be a great step. Of my own curiosity would multiple flash drives being so small, be converted together easily enough to make like say a 40-500 Terabyte Solid State Hard Drive of sorts? This might be the ultimate kicker if two computers are running DEEPMIND and they both begin communication with each other, in an effort to improve their AI. Would it be possible for the DEEPMIND AI on each machine to learn to create just about anything. Such as a biological organism 3D printer for lack of a better term, in which case tissue of a person could be sampled to create a whole new organ within hours. This is just another thought of no evidence or research yet. With such efficient ways to have computers redesign various capabilities of current technology, I believe I read that the DEEPMIND AI developed a way to reduce cooling cost of googles systems by 40%. Along with all those aspects imagine the future designs this system could create for Aerospace, Rocket design, Possibly another way to enter space in a vehicle made to take flight and at a distance predetermined to quickly speed up the the Earth's atmosphere. Although if such technology becomes available likely this won't be a issue. Alien technology UFO you may think of in this case to explore space more quickly than we have ever before. These are just various comments on possibly some ways DEEPMIND AI could help advance the world. In no way do I say these are feasible or close to even happening at this point. With an Artificial Intelligence system and nano-technology and creative ingenuity, seems like most anything is possible perhaps probable. Just some interesting thoughts in my opinion. Have a great day. Thanks, for reading
×
×
  • Create New...