DAVIDESCOTT

I've tried it on both hard and easy. It feels grindy to me either way. A big part of that is that I really don't want to take on half the contracts that are offered, because they feel neither realistic or enjoyable. My reactions tend to be either: A. You want me to trigger a decoupler on the pad? Why am I doing this again?! What possible sense of accomplishment would I feel there? or B. You want me to start the largest SRB available between 62,000 and 70,000m and at a speed of between 400 and 500m/s. The only way I could do that is with a special purpose craft or a large airplane. Since I don't have plane parts it has to be the former... in which case the largest rockets I have will only allow me to get an empty SRB up to that altitude at that controlled speed. Why am I doing this again?! How does this move me along towards my goals? So on easy I have to repeat a bunch of stuff I know how to do, to get overpowered rewards and finish the tree out without lifting a finger. On hard I have to do a bunch of stuff I don't want to do to keep a positive balance.

IMHO the game is just too grindy, especially early on (and as a result I've yet to enjoy a career mode game long enough to get to the late game). The things I don't like are: 1. The science click-fest (New biome, EVA report, Store report, wait...). 2. Repeated launchings of identical craft (Launch 1: goo capsule report on the pad. Launch 2: goo capsule at 10,000m. Launch 3: goo at 30,000m. etc..). 3. Special purpose craft for particular contracts (ie part testing). So to that end the changes I would make are the following: 1. Science points automatically accrue whenever you pass through a new biome/research area. Yes that means a munshot could come back with a ton of science points and almost exhaust the entire mun. That is fine by me, just reduce the number of points available from the mun to achieve balance. Exhausting planets will force players to move on to the next objective and make real progress in the game. 2. Science experiments can hold as many results as they need and can all be reset. No more single use goo canisters. 3. Replace part testing contracts with something like: "Kerbodyne is offering 3 free landing legs for a mun lander. Contract is meet when the legs are landed on the mun, and future versions of those legs will be 5% cheaper and 5% lighter weight." Contracts for decouplers would be satisfied when used in space, but eliminate the limitations on altitude and speed which force you to make special purpose craft for particular testing purposes.

I voted for "too hard" but that isn't really what is wrong with career mode. The problem is that the science mechanics are grindy and boring and the contracts are grindy and boring. Here are the changes I would make: 1. You should never have to click on anything to perform an experiment. Science points should automatically accrue whenever you take a science capable module through a zone. If I am launching a craft I don't want to be dealing with crew report nonsense. I just want the points. 2. There should be no contracts on the ground of Kerbin. If I wanted a flight simulator I would buy one. I want missions in space not on the ground. 3. A lot of altitude requirements of "test this part" contracts should be dropped. If you want me to test a part, then let me test it by actually using it, not by building a special purpose launch vehicle and then having to press the button at just the right moment. Changing "test this part" to "use this part in a vehicle that reaches orbit" would be a lot nicer. 4. Blow open the science tree into a forest. Have individual nodes for "Solar Panels 1/2/3" and "Jet Engines 1/2/3." If I don't want to build planes, then let me skip planes. If I don't want to build rockets, let me skip rockets. Let me focus on what I think is important to accomplishing my missions. 5. Provide some fringe benefits to repeated launches, but don't make it necessary. Currently you have to launch the same craft a half dozen times to get all the science data (because the stupid goo canister cannot be reset). Instead of a requirement, make it optional. If you repeat a mission a second or third time, then you: get experience points for pilots, reputation points for successful missions, improved stats for parts used in that vehicle (say a 5% weight reduction in those parts going forward). Perhaps every time you reuse a launch vehicle without changing it, it becomes a little bit cheaper, etc...

When you stretch an SRB are you increasing thrust or burn time?

1. You have to load parts initially to verify that all parts work (and to generate thumbnails for the VAB). If you don't then you could arrive at your space station to find that the central truss of the station no longer exists because the part cfg has a typo. That leaves no good options to gracefully exit the game. 2. The part loader is currently rather slow. Its the majority of startup time, and loading parts dynamically would cause lags when you approach objects with new parts. 3. The part loader might leak memory or do unneccessary allocations and GC, which would be compounded if you had to load and unload parts dynamically. Those are just a couple issues that might need to be addressed before any kind of dynamic loading could be introduced into the game.

I think there is. Its not a downside in that you don't get the points, its a downside in the feeling that you aren't progressing. The feeling of progression in the game is going to come from flying to or landing on the next moon or planet. It feels annoying to me to know that you can get to Jool and perform experiments there but still have points to accumulate upon landing back on Kerbol. Where is the progression? Why did we go there when there was still stuff to do here.

I would do it completely differently and associate the science to the actual experimental apparatus. So in your save-file the craft would list the parts, and the parts would list all the places that the experiment was performed. Once performed at a location by a particular part it cannot perform that experiment at that location again by that same part. An example of a low sub-orbital flight with 3 thermometers (called A, B, C). On the launchpad you perform a reading of all three and transmit A and B but store C. While in flight you read A and B but only transmit A (storing . In the upper atmosphere you expose and store the results of A. On landing your payouts are something like: 1/3 from each stored result, 1/6th from each transmitted result. You have 2/3 of the total available science from the on Kerbin surface. 1/2 the total available from the Atmosphere 1/3 from space. On your second flight of the same type you expose and transmit all three on the surface and all three while in the atmosphere, you then store all three form orbit. You payoffs from this flight would be 1/2 on the surface, 1/2 in the atmosphere, and 1/1 in low space. This would give you: 4/3 from the surface, 1/1 from the atmosphere, 4/3 from orbit but when calculating the payoffs it simply caps the payoff to the maximum so in two flights you have maxed out the thermometer experiment. I would make one further change, instead of requiring the player to interact when he performs an experiment I would make the readings and experiments automatic, and make transmission automatic provided the antenna is deployed. The player would manage their power usage by deploying or retracting the antenna, they could also prevent transmission by clicking on an experimental apparatus and saying "Save next result." The benefits I see to this are: 1. Less player interaction. You could just make 6 flights with the antenna deployed and forget all about doing experiments. You would automatically get the full science just being in the right place at the right time. 2. No grinding for fractional points. One of the more annoying things is when you have 119 science and need one more you don't want to regret not performing experiment X an additional 3 times. 3. No ridiculous completing the entire tree in 2 flights. I think the grinding is a byproduct of their silly formulas for diminishing payoffs which ensure that you almost never get 100% of the science of a particular experiment. They spent all this time thinking about series that sum to 1 without using a simple min() function.

That is my criticism. Its is NOT suitable as a tutorial. Its an opaque and insurmountably complex mini-game involving going on EVA at illogical times which is only fun for the really advanced players who see it as a new challenge. Its a terrible tutorial system. If you wanted a tutorial you could accomplish that without the tech tree.

That is a really great way to describe it. One thing I think is ridiculous about the current system is that a good player will know that while his rocket is throttled up and flying in the atmosphere he needs to be actively clicking to generate and transmit crew reports. When he is 30,000m above the ground on a sub-orbital flight he is supposed to get out and perform an EVA. If this is supposed to be something like a tutorial... then that is just insane!! For the brand new player on his very first flight THE ONLY thing that player should be doing is keeping his rocket pointed up. Nothing else. As it stands the game is this really confusing and weird mini game that doesn't make a lot of sense. Why do I generate science for going on an EVA on Kerbal? WTF? Why do I get science for rocks from the home planet? A novice player will never thing to do that. I get extra science for different areas where I take samples... It makes logical sense, but the current game graphics don't do enough to really distinguish the planets so its hard to know how to configure your orbits in order to get those benefits. What is high vs low mun orbit? I don't know where the cut-off is so I have to play the mini game where I check the crew-report every 10000m. As it currently stands I find the science gathering to be harder than the real game (partly because I refuse to cheat and won't go Scott Manley style and build a rocket that intentionally explodes), and I am not a novice. I can only imagine how confusing this will be to a brand-new player. There are some really good ideas but they need to be isolated. First flight being and SRB supported sub-orbital launch makes excellent sense. Getting science for flying over different areas of Kerbal or the Mun make sense, but it needs to be clear to the player what those areas are. Something like the Kethane map might be useful. Perhaps even better get rid of the whole manual crew report nonsense and have it automatically trigger for each area. Store the crew report that gives the most science benefit and automatically dump the others. If there is some desire to keep the transmission parts then automatically transmit provided there will be sufficient power afterwards/reduce the transmission power requirements. I'm currently playing the modded tree: "KSP-TV’ Yargnit’s Tree" and its actually an enjoyable process to build up to something like a real mun landing. A big part of that comes from transmission not entering the game until after the first few launches. It means you don't have to spam transmissions in low Kerbal orbit, and you have the batteries you need to support some real scientific research. Its much more enjoyable than losing kerbonauts to dead spaceships in munar orbit.

That's exactly my point though. I think the current "electrical power is the limiting factor" does make it downright possible for new ones. Yes an experienced player can deal the complex interactions and trade-offs involved in managing power consumption through transmission vs. power generation from timed burns vs. power needed to keep the reaction wheels going, and generate 400 science on their first launch. A novice is going to feel that they did well to get 30 science on their first launch. The novice are going to struggle just to keep the craft pointed up, to add to that a demand they must properly time their experiments and transmissions to have the power needed to complete their experiments just seems like too much to ask. The limitations I am suggesting would actually make the game easier for the novice. Everyone's first flight is a simple suborbital launch and splashdown. Yes its more scripted but it gives that novice player some time to ramp up to the real game. Think of the first 5 flights as the introductory level you see in other games. After those first few flights then maybe take the kid-gloves off and allow people to really go crazy. When someone says they complete the tech tree in two flights, I think that can be really damaging to the player experience of others. Imagine if the first time you sat down to play Mario you were next to some guy took advantage of a bug used by speed-runners to complete the entire game in 2 minutes. I realize the game isn't a competition, but people are by nature competitive and if there is nothing to compete for that's going to hurt the game.

There are a lot of people complaining/bragging about finishing the entire science tree in as little as two launches. It seems clear that the only way to do this is with a full-on kerbalization of the the process. If you lack decouplers use a bunch of SRBs configured to overheat at just the right moment. Landing legs optional, etc... While its an interesting challenge I think it does constitute abuse of the system and shouldn't be possible in the final release. I also think it is evidence that the current system whereby power consumption is the major limiting factor on the amount of science that can be gained is deeply flawed. I would suggest dramatically reducing the power consumption of transmitters and instead implementing any combination of the following approaches: 1. Transmitters are not initially available, everything must be recovered from landings. 2. Limit the number of components that can be placed on a launch vehicle by the tech level. The initial launch vehicle might have to be made of as few as 4 parts (essentially mandating a suborbital flight). 3. Limit currency/science is converted to currency (presumably by the government). 4. Make exploding rockets more explodey (and eliminate the SRB overheat as a decoupler). 5. Big penalties for abandoning kerbonauts in deep space (this might require some kind of life-support addition which might be on the do not suggest list). I welcome any others that might be suggested.

Why not just use module manager to add mechjeb to the parts you want. These days there is a MM patch that allows you to make wildcard additions to all control pods.

"on the order" I'm not disputing it is effective as there is an enormous multiplier in front of that, but it is a resonance. That big multiplier should be something like the time it takes for two orbits with a 1Dv difference to match up (which would depend on the various orbital parameters).

How did you manage to skip over the barrier?

There is no kraken there. The game will kill you at 1000m above the surface but the physics are fine.

Its a bug that the parts loader is so inefficient that it takes that much memory to load all your mods. The whole point of not doing a 64bit transition is to fix the issues present in the parts loader and "do it better" so that its not taking 4GB of RAM to load all the mods. Adding things like texture compression, being careful to lazy load parts, searching for memory leaks, etc.

But then they are using the AWE API not PAE. There is an API on Unix that has allowed you to store and retrieve terabytes of data for decades its called "fopen" ;-) In any case without special support and some unpleasant modifications to your program structure a single process could not access 4+GB even with PAE.

Userspace programs never used PAE. It was a way for the kernel to provide multiple independent 4GB chunks to different userspace programs. You had to be in Ring 0 to even take advantage of it and it was available across different page tables which makes it hard and slow to use. PAE does not increase the virtual address space. If you really needed to use >4GB in a single program then you bought an Alpha or other 64bit architecture. In any case as you indicated there are other ways KSP can reduce memory usage (such as texture compression). Given how few objects and textures there are in the game there is no reason for it to ever use remotely close to 4GB of RAM. In your case the bug is that it uses 3.4GB not that it crashes. The crash is just a side-effect.

The answer to both questions is "it doesn't matter". You clearly don't understand that having a 64bit address space is not important to most games and certainly not to a game like KSP. The only time a game would benefit from a 64bit address space is if it consumed >4GB of memory, and consuming that much memory is a bad thing. There is no reason for KSP to ever consume remotely close to 4GB of RAM. It is simply not a texture or object heavy game, it is not GTA V. Furthermore those 64bit wide pointers come at a performance cost. You can only ship 1 pointer across in a single machine word where you could be shipping 2. That is why there is an effort to introduce an x32 ABI for linux and make it the default for all applications. In x32 the applications see a 32bit memory space, but get to work with the larger 64bit integers (which is useful for lots of things including say solving the Year 2038 problem). Since KSP (like most games) is constrained by fp issues not by integer arithmetic, even x32 does not really benefit KSP. If you want to push for a 64bit version of KSP at least push for it for valid reasons. The only valid reasons are additional registers and additions SIMD instructions. There are so many other things that the developers can do which will improve the game dramatically more than using AMD64 every could that its ridiculous to suggest that they waste their time with 64bit. Honestly the more people complain about stuff like this in the forums the less time they will have to make real improvements that would actually benefit the game.

It is. This is a stolen modified copy of the Celestial Body Parameters spreadsheet. https://docs.google.com/spreadsheet/ccc?key=0AthzlH8eMa0DdFZJSjlMLTA0ZlBtTnhMQWVlc2hDNmc&usp=sharing On the Physical Parameters sheet columns AC/AD/AE are new put in your phase angle to synchronous orbit in AC2 and the Pe you want will be calculated. In AD put your Pe and AE will spit out your phase angle.

I don't get the whole dumping on Unity thing that is going on. Its not Unity's fault that the GPUs are designed for 32bit floating point arithmetic. It is the limitation of the GPU that dictates that the game engine work predominantly with 32bit models, geometry, and physics. About the only thing you can fault Unity for is not providing a view space pipeline API which forced the developers to roll their own.

I don't think these issues would be fixed by the 64-bit unity engine so its a bit deceptive to describe the video that way. This is just a float vs double issue and won't change with 64bit Unity. The fact that Unity choose to use 32bit floats instead of 64bit doubles is probably dictated by the graphics card hardware which has traditional supporting float but not double arithmetic. In fact any floating point arithmetic done on general purpose x86 CPUs is promoted to an 80bit extended precision type within the CPU registers and then down-converted to a float or double when you store it back to a general purpose memory address. Therefore programs written for 32bit CPUs will generally use 64bit doubles because it is just as fast and more accurate. The only reason to not do so is if the application doesn't call for that level or precision or range (a rare occurrence these days) or a need to interact/shift computations off to another processor (ie your GPU).

There is a Kerbol way to answer this question. Just land on Kerbol and figure out how fast the surface is moving.

That was true but this is false-ish: Your Core i7 can run in 64bit or 32bit mode. It uses the exact same floating point unit to compute (double) x + (double) y. Same silicon, same clock, same speed. There are things that can make 64bit mode faster than 32bit mode but they are additional instructions SIMD that allow certain vector computations to be done more quickly. While that would be helpful to KSP, but it would require that the compiler for Unity know when to emit those instructions. A good compiler can probably do this, but its not really anything squad can easily control.

It is a limitation in AMD64/x86-64. While the pointers are 64bits wide the first chunk is required to be all zero or all 1s, otherwise the CPU will reject the pointer as a load/store address. See http://en.wikipedia.org/wiki/X86-64#Virtual_address_space_details. Thats in the silicon. Now the instructions are perfectly forward compatible with silicon that would not reject such a pointer, but technically it is "in the instruction set" because its in the silicon. So currently AMD64 is only 48bits, the next implementation will make it 56 but it could be years and year and years before that is necessary. Anyways to answer the original question 64bit is not needed or desired for KSP. At best it would allow you to load effectively unlimited plugins at startup, but that goal can also be reached by a number of other optimizations such as lazy loading parts, or just making the part loader more memory efficient. In fact its not even so much a memory efficiency issue as a memory fragmentation issue, but in any case its just not needed.