Sandworm

Given that this thread has been allowed to continue, I suspect they have a release date. Allowing these threads is part of the hype machine we see prior to every update. It helps with google search. They don't start the hype machine until they have an internal date picked. It may be tentative, but I believe we are in countdown. (As if there was ever any doubt about things. Squad's business cycle is no mystery.)

I never said it was a good idea, just that that's the way they see the market. I don't think they have to make a car absolutely safe, just better than the minimum standard for drivers today. Given that machines don't drink, race, speed or have strokes, it might not be all that difficult. Airplanes, even less so imho. An airplane flies in a rather homogeneous (air) and regulated (FAA) environment. Even today probably 90% of "heavy metal" landings are done by machines. If you go by hours, probably 99.99% of flying hours are in the hands of autopilots already. Automated cargo craft are probably doable today.

Actually, they aren't heading that way. Google is aiming for cars without human controls, and have been slammed for it by regulators a couple times. (see http://www.wired.com/2014/12/google-self-driving-car-prototype-2/). It boils down to market forces. Google doesn't want to compete with Ford and Toyota for drivers. Google wants to hit the untapped "grey" market of people who do not today drive. The over 65s have most all the money in this world and will pay anything to keep their "mobility". Google wants to give them cars for which you do not need a license. The scary end goal is that they want to give cars to the legally blind.

Running a linux game from within a VM isn't the same as running it withing a proper OS. A VM adds a level of abstraction and opens up a series of potential bugs. A VM will never be more stable than the OS on which it is running. Ubuntu inside a VM, inside windows, will always be less stable than windows because the VM is still relying upon windows. KSP might be more stable, but if your issues are related to windows and/or hardware, a VM won't help. Windows would also be less stable running in a VM running within ubuntu. And the same is true for duel-boot installs, albeit less so. Commit to installing linux properly before coming to any judgments.

Is the 32-bit version stable? Is windows itself even stable? Try the 64bit linux version if you can. It's rock solid. In fact it's probably one of the most stable games I've ever played on any OS. The only time have issues is when I start bumping up against my physical ram limits. But that's to be expected if you are watching a movie in one window, playing KSP in another, and editing a spreadsheet in a third. (No joke. You have to do something during those long ion burns in RSS.)

Imho the occulus will overcome much of these simulators, probably reducing their market. While no sane person would say they provide an equivalent experience, there are things that could be offloaded from expensive simulators to the, now, more capable desktop thanks to the occulus. Once upon a time they build massive simulators that used real terrain, miniatures with a camera/scope on a pole "flying" through them. These were massively expensive but did allow experiences (fog/reflections/sunlight) that no electronic sim could hope to match until very very recently. At the time everyone laughed at computer-based sims. But while the computers of the time could not provide an equivalent experience, they could do some things very very well (ie IFR navigation). So some of the training moved from the expensive simulator to the desktop. The same will happen today. Some part of the expensive simulator's role will shift to the cheaper but increasingly capable occulus. I'm not sure exactly which training will move first, but am in no doubt that something will. See https://design.osu.edu/carlson/history/lesson13.html And http://en.wikipedia.org/wiki/File:TL39_Flight_Simulator_Visual_System.jpg

I suspect that you won't need shielding for anything coming back from low orbit, regardless of angle. Anything with a hint of re-usability, including all aero parts, will probably be nearly indestructible on reentry.

The fairing system does look cool. Squad it now catching up to the modders in terms of aesthetics. More important is their functionality. We know things inside them are to be basically removed from the drag calculation, but how are the fairings themselves going to interact with the aero model? Is the overall shape going to play? Or will each fairing part have an assigned drag value much as standard parts do today? I worry that without a proper drag model, nesting fairings for each stage might become the new OP technique, akin to asparagus staging. (Nesting fairings would involve each and every stage using a separate fairing to hide all above it from the drag model, creating almost drag-free rockets.)

I would go further and say that it will not ever make sense. Temperature, pressure, gases ... these planets are so small they probably shouldn't even be round. But they need to be to support KSP's spheres-in-a-vacuum approach to physics. The colour pallet for the planets is as it is because it looks good and provides visual diversity. If Squad stuck to any notion of accuracy when it comes to light and colour in space, KSP would be almost black-and-white. (For reference see the TV series "Space:Above and Beyond"). I would dismiss any notion that Squad will ever carefully calculate a temperature gradient for eve to justify its lack of polar caps. They will always have other priorities.

I'm working on some stockalike, tweakscale-ready, TAC parts. They are still in development but I thought I would mention them here to get some feedback. Dev thread: http://forum.kerbalspaceprogram.com/threads/115126-Stockalike-TAC-Containers-09-04-2015-v0-1 It's basically a revisit of these parts: http://forum.kerbalspaceprogram.com/threads/66479-23-Somnambulic-Aerospace-Life-Support-Parts-0-0-1-%2818-Jan%29

The parts will work without tweakscale. Other sizes are an option but I'm not sure I want to add those extra parts to everyone's editor window. I suspect that some people will be happy enough without tweakscale and will use this as an addition to TAC rather than a replacement.

Version 0.1 is up on dropbox. https://www.dropbox.com/s/mxsleeqecb16zrh/TAC_Stockalike.rar?dl=0 I had a try at KerbalStuff but ran into issues. I'll get it working eventually. Got busy yesterday/today and haven't been able to work on this as much as I thought I would. So no new textures atm. But the parts are all there now and are tweakable. I thought about FS and decided against. I do want to remove clutter but things like FS, RealFuels, and procedural parts all just replace one form of clutter with another. And they create cross-mod dependency. With 1.0 only weeks away I want to keep dependencies to a minimum. A small number of parts plus the tweakscale option is best imho.

Stockalike TAC LS Containers Release thread: http://forum.kerbalspaceprogram.com/threads/118746-1-0-2-Stockalike-TAC-LS-Containers-v0-3-2-05-15?p=1895100#post1895100 TAC has far too many parts. All the different sizes, the filters, reactors ... it really should be called Kerbal Accountancy Simulator. TAC is also the best supported LS mod. The others are great. I like IFI and I miss the original IonCross CS, but TAC is the market leader. I find myself always returning to TAC for important saves but I hate the number of parts it requires. And the models, especially hexcans, look far more Trek then Kerbal. Over a year ago there was a great stockalike parts pack for TAC. The radial cans were retextures of the long monoprop tank and a large inline can was built from Squad's cupola model. It was lighweight and non-intrusive. But TAC and KSP have changed in the last year. So, with permission of Somnambulic, I've updated his mod to support TAC's current resource definitions. I've also added a new radial tank containing a month's worth of TAC resources (the one with "life support" written on the side). At the moment I have FIVE parts in this pack. I intend no more. The radial tanks contain either a 90-day supply of a single resource or 30days of each for the combined can. The 2.5m inline can hold three years worth, or one year for a three-kerbal crew. All are now tweakscale compatable. So you can probably delete all the stock TAC parts. I do not want to discuss volume and part dimensions. I don't care that these parts do not comport with realworld resource volumes. The cans contain 90 or 30 days of resources because that keeps the math simple. Their mass comes from the resource definitions. While they may or may not be the wrong volume, they are properly heavy and therefore not OP imho. I need feedback on three questions: (1) How should these cans be labelled? I was going to make the external labels descriptive of contents (ie "H2O - 30d") but that doesn't work once they scale. Or should I keep with the colour patterns? "Life Support" is probably confusing because another mod uses that resource, so perhaps "Supplies" instead? (2) Does anyone actually use individualized resource containers? I'm tempted to ditch them and stick with the one inline and one combined radial cannister. That, with tweakscale, really cleans up the clutter. (3) Does anyone want smaller/larger parts without using tweakscale? Adding them is dead simple. A non-tweakscale version with 1-year and 1-week parts wouldn't take more than a few minutes. I just don't want to add to the clutter (3 sizes x 5 part types = 15 parts = an extra half-page in the editor). Original concept and non-Squad models/textures reproduced with permission of Somnambulic. --------------------------------------------------- Download:https://www.dropbox.com/s/gtctiuhm5e1bbwe/TAC_Stockalike_v0.4.rar Installation: Put contents of rar in ksp gamedata directory. Dependencies: Relies upon two stock models. So it might not work if you have deleted/moved any stock parts. Source: Non. Not a plugin. Just parts. All is human readable. License: All original/derivative work(s) are released subject to Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License See http://creativecommons.org/licenses/by-nc-sa/4.0/ While this mod does refer to and rely upon stock models/textures owned by Squad, they are not here distributed in any form. For original version by Somnambulic see thread: http://forum.kerbalspaceprogram.com/threads/66479-23-Somnambulic-Aerospace-Life-Support-Parts-0-0-1-%2818-Jan%29 Changelog Version 0.4 Changelog 0.4 - Corrected errors in rar (duplicate file names -> access errors during install) -Moved o2/h2/food cans to slightly higher tech node. 0.3 - Update for KSP 1.0.2 (no actual changes) -Added text to last three textures 0.2 - Update for KSP 1.0 -Flipped node on large in-line can. 0.1 - Initial release -5 parts -textures -tweakscale cfg.

Me 2. But I add that I remain disappointed that Squad has not purchased FAR for integration into stock.

Really? People are interested in this? It's mostly just flavour text added through MM. I stopped development when I ran into trouble adding experiments to active parts, specifically engines and decouplers. I'll have a look at things this weekend to see if it can be updated. The Kemini mod allows the addition of unique experiments to specific pods. That might be an easier means of adding experiments and incorporates duration requirements.

I just finished a save with OMS but am not going to use it on my next. Two things.. (1) Too much clicking. For instance doing the prep, then exposure, then ending things, then storing samples, then moving back to storage, then finalizing ... its too much fiddling with menus. (2) Far too much science. I did a series with a fully equiped MSL-1000 low around Mun and came back with 4000+ science. Granted I'm playing in 64k and getting that lab to mun wasn't easy, but OMS can max out any tech tree in only a handful of missions, without ever leaving kerbin/mun/minmus.

They don't. The SSTO-related hardware in KSP is basically magic. Scaling the wizardry up to 64k can be done, but defeats the increased difficulty that is the point of 64k and RSS.

Yes. 122345

Given the movement of the stars in the OP... no. No stock KSP launch will ever take that long. Kerbin is so tiny that any gravity turn taking more than a minute or two is more hovercraft than rocket. And no explosions? No flaming boosters being thrown all over the place? No wobbling engine nozzle? Launching a rocket in stock isn't SpaceX. It's Wile E Coyote.

Given the timing, I take it that these new IVAs were the 32mb recent additions to the QA builds. I'm all for IVAs, but KSP is getting larger and larger. 32mb might make an actual difference for windows users.

Lol. The IPs I mentioned belong to FBI.gov and NSA.gov. I was suggesting that there are also bad jokes we can play on squad, such as manufactured evidence that KSP is an NSA front. One of the codes for any acceptable April fools joke is a nearby mention of april 1st. The cover of a paper can carry a joke because the date is right beside the story. That same joke on march 20th falls flat. If you want to run a joke early then you start it with "With April fast approaching, we are today announcing that the forums are to be sold to EA." THAT's how you phrase an april fools joke.

Bad joke Squad. Bad. The truth is that a great many companies really do pull this sort of thing. You are not above suspicion in that regard. My first reaction at loosing access to old threads was that this was part of a 1.0 launch plan. Specifically, I thought that you were trying to remove old forum posts from google searches, building a 'fresh start' for 1.0. The money angle also plays into discussions around the internet that certain people are looking to wind down KSP and walk away shortly after 1.0. That sort of thing happens with indi games. April fools is a week away. Btw, I've been sniffing KSP and found unusual traffic heading to 23.45.42.121 and 23.50.66.76. I've got some nifty screenshots showing that KSP is generating considerable upstream traffic to those IPs. Perhaps someone on reddit might know who lives at those locations?

Very nice. But did anyone else notice that all the rockets are pointing skywards... except for that of the Koviet Union. It's pointing downwards. And it's the only one without an exaust plume. Lol. It's broken.

1. No liquidfuel/oxidizer on missions lasting beyond a few hours in vacuum (stock fuels). 2. No manned missions out of comm range (remotetech). 3. No 8+g reentries (not using DR).

It's not about cheating for me. It's just that differently-scaled command parts look silly when they meet in space. The textures get blurry when expanded and the size discrepancies just look wrong imho. I see tweekscale more as a problem-solving tool for slight adjustments rather than a major construction tool. Lego isn't lego once all the pieces start changing size. Anyway... here are some additional tanks for RLA. Updated cfg for RLA: https://www.dropbox.com/s/7wu1e2nchl066dm/RLA_TweakScale_0903.cfg @PART[RLA_x_s_tank] // PB-X450 Xenon Container { MODULE { name = TweakScale type = stack defaultScale = 0.625 } } @PART[RLA_l_mptank] // FL-R200 Monopropellant Tank { MODULE { name = TweakScale type = stack defaultScale = 2.5 } } @PART[RLA_m_mptank] // FL-R50 Monopropellant Tank { MODULE { name = TweakScale type = stack defaultScale = 1.25 } } @PART[RLA_s_mptank] // FL-R15 Monopropellant Tank { MODULE { name = TweakScale type = stack defaultScale = 0.625 } }