weezl

I generally agree.. but I think the restrictive memory model of 32 bit affecting a lot of their customers using Mods might have had a slight influence. Yes.. essentially folks were doing an end-run to use Unity 64.. but that, in and of itself.. is customer communication! How, exactly, do you think most features make it into software products? Many many times its smart folks outside the company filling some niche that is not originally provided by a manufacturer. And the company (if its paying attention) catches wise and puts that feature in their product. This is no different. I expect that some mods that right now exist on their own might get that same attention. Time will tell. On the subject of the quality and useful ness of OSX.. I've never had a single issue with Mac.. As has been much lamented in my industry.. its not the OS/Hardware that sells systems.. its the apps available. Mac is a really nice platform.. but as you said.. reality is what it is.

First, if you knew how difficult cross platform development was, you'd say no such thing. The fact that Squad has stepped up to even try to do this is an incredible comment on their capabilities as software engineers. Second.. 64 bit support on windows is a requirement pushed by their customers.. and I'm without a doubt sure that the vast majority of their customers are on Windows. Which means their requests will be preferred. I know you like your Apple.. I get it.. but requirements for any program (game or otherwise) is driven by the majority of the player base.. not by a minority.. Squad is trying to get things done for all platforms, that is to their credit. You used the word 'intentional' in one of your posts. That, to me, is inexcusable given how they are actually trying to support what are going to be for them much much smaller (and much less profitable) portions of their user community. Don't spit in their face for it. It doesn't reflect well on you, and shows no respect for a team who has your best interests at heart. Third: you complaint is with the mod developers.. but keep in mind.. cross platform development is difficult.. WAY more difficult than you can obviously imagine. I have a hard time believing most mod developers will be able to do true cross platform development. I've personally done it a lot in the last 30 years.. and any thing you can imagine about fixing a bug or implementing a feature on just one platform is tremendously magnified when its 5-6 platforms (win 32/win 65/mac 32/mac 64/Linux 32/Linux 64). And yes.. I'm listing 32 and 64 as different on each.. BECAUSE THEY ARE. Each has its own set of problems that you must be aware of as a programmer to get things right. This is why I'm so impressed with Squad.. and I'm a professional saying this.. If you don't like being treated as a 3nd class citizen on the Mac, then move to a better platform. You are railing against a reality that WILL .. NOT ... CHANGE. Mac is never going to be the mass market device for games.. Those would be consoles.. Mac is never even going to be even a 2nd class platform for games.. That would be Windows PCs. Look at the installed base numbers for the platforms if you doubt me.. its easily searchable on google. According to current reports, for Mac installed base is just at 6%.. Windows is 90 ish.. and a very very small portion is Linux. This is an inescapable reality of the platform. Complaining about it will change absolutely nothing. If you want choice in games.. choose consoles or PCs.. or get ready for constant disappointment. There is no other alternative. Macintosh has earned a niche in certain areas where it has traditionally done better.. This is why there is a 6% market share of Macs. PC games, unfortunately for you, is NOT one of those areas.

Wobbles during takeoff seem to be induced by a feedback loop between the SAS and the vectoring on the rockets driving your craft. Things will shift one direction, the engine will vector, then it shifts back, the engine compensates (kinda), and the loop is going.. Its a resonance wobble induced by the SAS control system.. and the only way I've found to get rid of it is to use struts on the connections between tanks/modules/etc. to reduce wobble. Creative use of girders and struts is the trick to longer rockets to keep them from resonating apart. The reason that reducing throttle reduces the wobble is because there is less force working to bend the connections out of place during each resonance cycle. The only real solution in game is to reduce wobble with struts, since we don't have control over how fast the SAS reacts to attitude/thrust measurements(anyone who has worked with industrial control PID loops will 'get it' regarding this issue.. PID loops are tuned based on the portion of the system with the most inertia... i.e. the thing that is the slowest to change in reaction to a control change.. you tune your loop specifically to avoid these types of feedback resonance issues.. you can always tell when someone did something wrong with a PID, since a motor (typically the slowest thing in a control system) will speed up then slow down in an even time cycle.. a feedback resonance. In a rocket the bending changes the center of mass, which changes the rate of turn for a given vector position on the engine.. and its changes slowly in comparison to many other things in the system). Note that in all this there is a trade off.. if you slow down SAS reaction speed, you could make the rocket uncontrollable because of the speed needed to overcome changes in attitude in the last control cycle.. so (IMO) I think its better to strut up anyways..

^^ this. The early adopter part of this game can definitely be felt in the VAB. On these ground alone anything you do via debug is not cheating.. and to echo other posters.. hang what other folks say is cheating.. if you did it, if it works, and it pleases.. its good. To me personally.. in reference to gaming in general.. if I do something that makes the game easier to 'beat', makes AI stupid, gives me overpowered units, etc... something that makes achieving what I want to achieve trivial rather than requiring me to work at is as designed.. that classifies as a stupid move for ME. I didn't buy the game to be bored after 15 minutes because I did something to make it easy.. that is the only real sense of the word cheating that matters to me.. because I'm cheating myself. This also echoes the posters on this thread.. at the end of the day the only real judge that is important on this subject is you.

My money is on this slot on the roulette wheel.. and roulette it IS...

Blasting Illuminati?? CHEATER! Illuminati should always be loved, not berated!!! CHEATER!!

Almost for me.. my order is: sub-orbital, orbit, rendezvous, docking, Minmus, Mun. Minmus is easier to learn landing on because the gravity is lower (and therefore more forgiving of the inevitable mistakes you must make on your first few landings.).

Agreed. I've researched all biomes on both Mun and Minmus.. and actually landed and taken off from Duna.. The rest of the planets *not yet*.. I'm still only 5 weeks into this game.. and life decided to intervene this week.. so my rate of doing things has slowed a bit.. I'm also somewhat expecting that a new update will happen soon.. and when it does I'll just restart my career and all do all the activities required by the new missioning system.

This ^^. My first attempts at docking were extremely modest.. Two mark 1 capsules with clamp-o-trons/RCS/RCS-fuel/solar panels.. and staging to get me to 80,000 m with enough fuel to de-orbit. Do this a number of times and the rest becomes fairly easy. You'll learn about how docking goes.. Hohmann transfers... and properly locating RCS thrusters on your spacecraft so that docking is easy, even if your spacecraft stabilization is turned off. If you know anything about the US space program.. I essentially followed the framework of that.. I learned how to put stuff in orbit and de-orbit reliably (Mercury), then how to rendezvous in orbit (Gemini), then dock while in orbit (Gemini), then did all the necessary steps to form a mission plan for getting to Mun.. first to orbit, then land and takeoff and get back (Apollo). Doing an Apollo style moon lander is really good practice .. since you must use all you know from all previous missions to make it work.. Following that mission plan is really the 'KSP Tutorial' as far as I am concerned.. at least on how to use the tools at your disposal to make missions that work.. and building a skillset for flying those suckers. The big hurdles as far as flying missions are landings on airless bodies and rendezvous/docking. Those skills are truly essential to everything you do in the game.

Well done. I stand quite corrected. LOL!

"Before I discovered and played KSP, I.." 1) had a life. 2) Had never heard of Hohmann. 3) knew about orbital rendezvous and the Gemini program (my father in law was part of Apollo and the Space Shuttle).. but only as a name.. 4) played more games involving shooting (still do actually.. except that the greedy little KSP game likes to take a lot of my gaming time!!). I'm addicted to games that reward personal effort and are hard.. and KSP is hands down the winner in this category.. I had to understand all the math just to know what was going on.. flip side of all this is that I was 'that kid that was into math' when I was younger.. so for me its just a matter of warming up stuff I knew 40 years ago... that is a LOT easier than learning it the first time 8-)

Flip side is, if you have to go afk your dog can take over and fly a passable approach to an orbital station.... although I'm not sure I'd trust the little guy with the actual docking..

As shift and diomedea have said.. look to your TWR. You must have a good TWR at liftoff.. no amount of delta-V will compensate for that. Most posters here aim for at least a TWR of 2.0 at liftoff from Kerbin. This gives you good acceleration out of the gate.

.. nothing but net!... Fantastic vid.

When this happens I've noticed that the textures for the geometry you are landing on did not load (so I'll get a blue dot and some shineyness, but no textures are loaded for the land).. If you notice the textures are not loaded for what you are landing on.. quick-save at that moment and restart.. things will work fine after the restart. And to date I've seen this 3 times. And note that I've only got one MOD loaded.. the docking UI mod. And I had seen this bug two times before installing that mod.. so its not related to the mod (although I could see the mod aggravating it if its a memory issue). And an FYI to StreetWind: It happened to me in pure stock twice.. =(

Since right now in career mode there is no concept of cost of a rocket.. I tend to build lifters based on general lift needs (5 ton/10 ton/20 ton/40 ton) and don't worry about the wastage. I'm expecting this to change in the next release.. which is another reason why I built my spreadsheet (the first being understanding how the Rocket equation works in mixed ISP engine situations). There are certain situations where I'll tailor the rocket to the payload (long range very light probe is a good for instance).. but for repetitive use, you can't beat standardized lifters.

Most of my 'big' Tier 2 lifters work on basically this principle.. for the initial ascent stage (where I mostly use this style of staging): I size the inner-most part of the asparagus stage for TWR = 2.0, then place radial tanks with engines sized to keep the TWR at 2 (approximately). for a 40 ton lifter this means a mainsail/jumbo tank in the center, then the next layer out has poodles or skippers (depending on tank size and the exact size of my upper payload), etc. One thing to note.. I do spreadsheets to figure my staging.. I don't use an add on. I wanted to understand the rocket equation from the inside out.. so I implemented a spreadsheet that pre figures the total dV for a given stage and shows the TWR for all combined engines on that stage. I can throw a basic design together VERY quickly using the spreadsheet, by just copying my desired parts to the proper place in the sheet. Its not super-fancy at this point, but it certainly gets the job done. Since I typically design for low risk vehicles, I don't worry much about how the ISP changes between air and vacuum.. I just use the air values for all stages that are either at liftoff or in the transition.. this gives me extra dV for emergencies and monkey-based-accidents (I mess up).

^^ this. My early rescue vehicles use a Mk 1 command pod with a probe mounted on top of them so that I can launch them without a Kerbal on board. I'm assuming your new here.. so keep this in mind: probe cores require electricity to use.. so carefully test your new ship before sending it out.. specifically your goal should be to understand what types of actions expend electrical energy so that you can plan for how much battery you need and the amount of solar panels required to run/recharge your craft.. Good luck!

..will provide 'closest approach' markers when your orbits overlap.. and may create two sets of markers when your orbit intersects with the target orbit more than once.

Didn't say it was good advice.... you did read the rest of my post, didn't you? You can actually radially burn from Kerbin to Mun if you want.. you'll need horrific amounts of fuel to do it.. but its possible. More to the point.. because of gravity interfering.. you'll have to learn how to make it work no matter HOW you choose to do it.. which is what folks are faced with anyways.. its why my second statement is about fuel efficiency. At the end of the day if you don't learn Hohmann transfers, then most of the solar system is closed to you (because of the extreme fuel requirements). I get it Red.. please take the whole post in context, not just one sentence.

Do a search on this site for 'Hohmann transfer' that is a good start.. Some things to keep in mind.. Since you wish to rendezvous.. you can just point at your target and fire your booster.. but it isn't very efficient of fuel (as in you may need more than you can reasonable lift into orbit).. the most efficient is to transfer from your own lower/higher orbit to the target's orbit so that they both meet a the same point in time at near the same place.. this is called a Hohmann transfer. If you disregard target position and just think about orbits.. you can burn prograde from a lower orbit (or retrograde from a higher orbit) and adjust the OTHER side of your orbit so its apoapsis (or periapsis from a higher orbit) is at the same altitude as the target's orbit. YOUR orbit should now be elliptical... with its periapsis (or apoapsis from a higher orbit) at your original orbit's altitude and the apoapsis (or periapsis from a higher orbit) at the target orbit's altitude... That point where the two orbits meet is where you want to rendezvous with your target.. but since you can't just floor the accelerator like you would on earth (since changing speed = changing orbit), you must time when you do your burn so that when those two orbits meet, the target is in exactly the right position NOW to meet your craft when you get to apoapsis (your rendezvous point) at the exact other half of the orbit you are on. Another point to consider is that both your orbit and the target's orbit must have exactly the same inclination. That is easy to determine in KSP since once you mark a target it shows the inclination difference (they show up as two dart markers on your orbit after you've selected a target.. or one if the target is on an escape trajectory.. like an asteroid).. and you can use maneuver nodes to adjust that. This is important because if the orbits DON'T have the same inclination, then there are only TWO points your orbit where it will cross the other orbit's path (when looking at them side on).. You want those suckers to be aligned at ALL points so that when you adjust your orbit you have the minimum distance between your apoapsis and the target orbit, no matter where your maneuver node is placed in your own orbit. Another point to keep in mind is that as much as possible both orbits should be as circular as you can make them (apoapsis ~= periapsis)... that is important for what comes below.. That is the 2nd point of Hohmann transfers. Its not just the touching orbits.. its waiting until the target is just in the correct position in its own orbit so that given its speed and YOUR speed you both meet when the orbits meet. If you are below your target (in altitude), then generally you'll be behind your target when starting your burn (since you are currently going FASTER than your target). Planning Hohmann's is easy if both orbits are fully circular.. wait until your target is up orbit of you if you are lower (i.e faster).. back orbit of you if you are higher (i.e. slower).. then lay a maneuver point a bit ahead of your craft and adjust the orbit until its apoapsis (if you are lower) or periapsis (if you are higher) just touches the other one.. arrows should appear showing the target's and your relative position at the point the orbits meet (as well as their distance at rendezvous.. you must hover over the arrows to see this). Now slide the maneuver node around until you've minimized the rendezvous distance (this is where its important to have circular orbits.. if you DON'T, then you must adjust the apoapsis/periapsis as you drag the node around..). Once you've mastered this doing circular orbits.. you will have a basic understanding of orbital intercept mechanics for interplanetary travel.. since those are just hohmann transfers done over months rather than minutes. Further.. once you get to an intuitive understanding of all this.. you'll understand how to match orbits under less than ideal circumstances (i.e. one or both orbits are non circular).. which is important for doing things like asteroid intercepts or intercepting objects in elliptical orbits. There are some video explanations of this.. as well as one that uses pictures taken at points in the process.. but its not the pictures that are important.. its the concepts.. if you have more questions.. ask..

LOL.. fantastic post.

^^ what he said.. PLUS: once you have your delta V budget.. build out your manned rocket as you would normally.. but put a probe core on it and launch it UNMANNED. The purpose of the mission is to test your assumptions to make sure your delta V budget is actually true or not, with actual live hardware you will eventually launch manned. This maps to real life, where all the space missions run with humans were in some way run non-manned so as to not risk people's lives while you are figuring out if your calculations are correct.

Second trip to Duna.. on this one I didn't grossly underestimate the amount of fuel needed (like I did on the FIRST one.. 'nuff said), but I hadn't twigged to the ability to use parachutes on Duna (I just winged the mission because it was late and decided to try a landing.. definitely a break from my normal over-planned approach to this game). I'd never made a landing on Duna.. so didn't know the target altitude for touch down.. started my burn early.. and it became VERY evident that I was going to be very close on fuel.. basically waited until what I thought was the last second and burned down to a soft landing.. right clicked on the fuel tank (since the fuel thermometer in the lower left showed nothing).. it was 0 fuel 0 oxidizer!!! EEEK. Normally don't like to do landings quite THAT close. And note a Kerbal was on board.. and I do NOT like losing those little guys to foolishness on the part of the monkey at the wheel.

Very good.. so it was sarcasm.. I take back what I said.. your position on this is essentially mine.