Sandworm

They are on a quarterly (+/- 3month) release schedule. The last was towards the end of july, making the next towards the middle-end of october ... not this weekend. But they also want to do another release (.26) before going on christmas vacation. So if you want to pick a target period, start with the midpoint between the last release (July 25th) and the next planned release (say December 15th). Then look for a Tuesday. After that you can compare the pattern of public statements, talk of experimental builds and such, to pick which Tuesday is the scheduled date. It's not rocket science. And don't listen to statements regarding Squad having no schedule. They do. The last dev notes said "...we’ve arrived to our first goal in our production calendar. Some models were missing...". They could not arrive at a goal with missing work unless that goal was a time rather than a development milestone defined by the completion of work. They have a calendar on the wall with target dates. They just don't share that info with outsiders.

Squad is becoming more and more predictable, more and more like a standard software house. That isn't a bad thing. It's progress towards a more structured approach to development. More art = new look = new youtube vids = christmas sales drive.

So destructible buildings exciting not for what they are but for because they enable some other future feature ... that they don't want to talk about? So the big feature today is in fact only a quasi-promise for something better tomorrow. I don't get excited about promises, especially ones hedged with unknowns.

Lol. You mean .26 the pre-christmas sales hypetrain? I'm sure that something big is coming in .26 but it won't have much to do with destructible buildings. I suspect they are working on new textures. The new explosions look out of place with squad's soft textures in the background. I think they will try and update as many pixels as possible to generate a fresh batch of LetsPLays but seriously doubt any new in-game mechanics we be here before the new year.

You mean like every single flight simulator ever released? Or virtually every fps? KSP may not be a pure flight sim and certainly isn't a fps, but destructible buildings are not essential to any game. I also question what greater features of which this is meant to be a part. Constructible buildings away from the KSC, especially on other bodies, seem totally outside of Squad's current direction. See the resources issue. Now, I can see upgradeable buildings at the KSC. An upgraded science center, that one would have to pay to expand/maintain, might work. But I would still call that eye candy as it could/should be implemented first without in-game models.

Any and all "improvements" to the physical KSC are useless to me. KSP is about space exploration. It is about going places OTHER than the launch pad. Blowing up buildings may make failure fun and provide youtube eye candy, but I'd much rather see features added to make non-failure more fun. Am I the only one who hasn't ever crashed into a building? This "feature" could have been added a year ago and i wouldn't have noticed.

The larger issue might be steam's new "curator" scheme. You now want youtubers not only to review the game, but to recommend it on their curator page. That's two different questions. Some would probably play KSP on their channel for fun/visuals but not recommend it given that it isn't feature complete. There has been a pushback in recent weeks against pre-release titles. Some (TotalBiscuit) are becoming very negative regarding pre-release/early-access programs. See the Spacebase DF-9 fiasco.

Imho it won't be anything more than eye candy. KSP is in a rut with the people that drive sales: the youtubers. Search for "kerbal" on KSP and you won't find anything with a high view count in recent weeks. Squad therefore needs something shiny, loud and accessible within 10 seconds of liftoff to get the youtubers making new vids. Wether it's new explosions or a destructible space center, it will be junk of little interest to anyone who plays KSP for more than a few minutes at a time. The spaceplane parts fits in the "eye candy" category as anyone who really wants them already has them via mods. Moving them from mod to stock only matters to reviewers (ie youtube).

Yes. With a couple minor exceptions (see the linux support thread) the linux versions of KSP run far smoother than any of the windows/mac versions. That is IF you run it on an actual linux box, not a virtual machine on a windows box. I'm running KSP_64, using 6gb of ram, as I type this. I cannot remember the last time KSP crashed. In fact I think 24.2 hasn't ever crashed on me.

Every ray of blue does have higher energy by definition (shorter wavelength) as does UV, but when it come to heating from our Sun, red and infrared is the dominant source. The total heat energy from the blue wavelengths is very low in comparison. A blue surface, ie reflective to blue light, is absorbing all that red/IR and will be much hotter than an red surface. Of course if either colour is dark enough you get towards black either way. Using pigments to selectively absorb heat is tricky. What if they bleach white over time? What it they react/burn into something darker? I'm betting these colour schemes had far less to do with heating than with in-flight observation and potential post-accident recovery.

Are you using RemoteTech2? I've found that the non-updating menu problem only occurs with unmanned probes using the RemoteTech module. Mannded craft, or non-Remotetech-enabled probe cores, don't have the problem.

I have mods, many of them. See http://forum.kerbalspaceprogram.com/entries/1411-My-Day-with-Reality.

Like I said, dovetailed issues. Pick them all apart and individually they seem acceptable. But as a whole they make for something nowhere near 'simulation'. 8000+m/s orbital speeds would be for a more realistic-sized kerbin ... which means much more time accelerating through atmo ... which means more demand for predictable/realistic aero models. On assent to such an orbit, any small error in something like inclination or launch timing can result in an unrecoverable situation. Plane changes are massively harder at realistic orbital speeds. Fixing any single deficiency wouldn't make much difference. Furthermore, Squad has outright stated that they will never ever address the root problem (imho Kerbin's tiny size) which itself has links to deficiencies in Squad's memory management, or lack thereof, which limits how kerbin is rendered (no ability to selectively load/unload textures as they pass under a craft in low orbit). Without that ability, any larger Kerbin will look horrible from low orbit --> back to the youtuber problem. Tied into that memory issue are other features (ie parts icons in the VAB). Everywhere one looks at KSP one sees layer upon layer of grandfathered compromise, each depending on the other. By this point it's all locked down. Scream if you want, but Squad isn't in the position to change much of anything. All they can do it add more layers (tech tree, reputation etc) or double down on previous decisions (more parts).

That's assuming that anyone has ever played KSP with a realistic aero model. FAR is certainly more realistic than stock, but it is far from a simulator. You can still brute force most things into orbit, at least on a stock-sized kerbin. All of KSPs non-realistic 'features' dovetail into each other. Aero is tied to kerbin's size as a full-sized atmo and 8000m/s orbital speeds would make aero much more relevant to the overall game. Aero is also tied to KSPs magic SAS systems as slight errors in aero design are today overcome with a little magic torque. SAS is in turn tied to the lack of reentry damage as no kid wants to end their mission with a capsule burning up because they couldn't point it correctly. And all of this ties into my point regarding the youtubers. KSP needs new players to achieve orbit with relative ease, at least in the first hour of playing the game. All of KSP's non-realistic features are at least partially a means to that end. Tell JackSepticEye that he needs to spend a couple hours learning how to build a stable rocket before having any hope of getting to space and he won't do many KSP vids. Tell him that after those hours a slight error in a 5+ minute assent profile means his Kerbal is doomed and he probably won't bother with even a second.

It's not about FAR or even the player base. Squad works to make sales. Sales come from media coverage. For indi games, that means Youtube and the youtubers. Take a look at the youtube vids recently. They aren't about realistic rockets simulating realworld space travel. They are about ridiculous spinning contraptions or massive craft doing impossible things. None of that would be possible with any sort of realistic aerodynamic model. Squad must keep allowing low-information gamers to launch massive objects quickly, without worry, without planning ... without math. That keeps the youtubers happy. That brings the sales.

From squad re classified feature: "...just let you guys discover it through gameplay with hilarious results." It looks to me like they are going to finally finish work on reentry effects.

I'm running into a strange GUI conflict in the VAB. More of an annoyance, I've noticed it for a while. Today I thought I would figure things out. Realfuels works perfectly on wholly manned craft, but whenever I either start with or add a probe core the VAB GUI becomes unresponsive. The interface does function. When I click on the fuel/tech level the change is applied to the rocket, but the display in the tooltip doesn't update. Clicking elsewhere and then returning to the part shows the new info. If I remove the probe core, the GUI returns to normal. I'm running RemoteTech2 and I suspect that is the problem as that module is the only thing special about probe cores. Has anyone else run into this?

I've been playing around with the IFI life support mod. Here's a CFG that adds the LifeSupport resource and module to HGR parts. Comments are welcome. https://www.dropbox.com/s/fv3rhlac8jox95o/ModuleManager_HGR.cfg

Speaking of cfgs, here's one that adds IFI life support to HGR parts. I've tried to balance them against realworld craft but am open to any comments. https://www.dropbox.com/s/fv3rhlac8jox95o/ModuleManager_HGR.cfg

I would suggest updating the OP to indicate that this mod is compatable with 24.2 and has been recently updated or, if that is not possible. starting a new thread.

Nope. I've been playing remotech for many months under 64 without ANY such issues. 64 is not the problem. That said, the WINDOWS 64-bit build is a hash. It's full of bugs. Remotetech nor any other mode can fix those.

Glad to see you're back. Lately I've been playing a 6.4x RSS carrier mode and keep running into the same issue with HGR. I love the engines and tanks, but I find myself never using the command pods. The problem is that they are too spread out in the tech tree. Getting the whole launch package together requires too many nodes. The fairings are useless without the LES. So having them in separate nodes is just frustrating. Also, the long tanks should appear earlier. I know that Squad spaces out the tank sizes in stock, but imho that's not how the technology works (insert rant about Squad's tutorial approach to progression). The piping required to pull from multiple tanks is far more complex than just building one big tank. With HRG I find myself stacking 5+ small tanks and I cannot be the only one. The long and medium sized tanks should appear alongside the first engine. I do make these changes myself, but I think it would benefit others. Other than that, all the parts are great and fill the void between 1.25 and 2.50 perfectly.

I see this all the time. It's normal behavior, especially when you dont have an sas/asas module attached. The craft was aligned before warping. After warping its is still pointing to the node, but its attitude in respect to the planet has changed. Remotetech doesn't just try to point at the node, it tried to align itself with the planet. So it swings around trying to get back to the node. It will do so eventually, but not before the maneuver has been totally borked. Solution: Come out of warp a few minutes early and let the ship stabilize itself. You can then warp the last little bit and execute the node properly. This works even when disconnected.

????? I've been playing with RemoteTech under 64bit since long before .24. I'm playing it today under 24.2 without any issues whatsoever. It works perfectly under 64 (linux). I therefore suspect that any problems have more to do with windows builds than RemoteTech, pushing any real improvements back until Squad's next patch (a couple months).

Ah, I was having a problem and the latest update seems the have solved it. Suggestion: I know it's probably not possible, but is there any way we can the specifics of the orbits before we argee to them? I just started a new save using RSS (6.4x kerbin) and RemoteTech. Both play nice with Fineprint but do create technological limitations. For instance I cannot get anything into an accurate orbit beyond Mun until I unlock the needed dishes to send signals that far. So knowing the specifics of the orbit prior to clicking agree would be great.