Corax

How about ALT+<TakeScreenshot>?

And still working in KSP 1.2 Edit: I just wish I could like this more than once.

Plus they have a whole week to write up some devnotes. Oh wait...

Just wanted to drop by and say thanks for getting the email RSS notifications sorted out - good job!

FYI, CursorDeleter is still working with current KSP 1.1.0.1230.

No worries, as I said, this would be the icing on the cake.

It's not so much the time running, as having to repeat certain steps again and again before getting to the actual point of the simulation. It simply would help immensely to start the sim, set up all that needs setting up (that may or may not include launching and flying to a certain situation), and then be able to revert to that point to test different approaches, which IMO is the point of a simulation. Nothing stops me from "simulating" with the default KSP facilities of putting a craft on the pad, quicksaving, and returning to that quicksave at will. I do like KCT's, and now your mod's, idea of having "proper" simulations within the framework of career mode, and would love to have the ability to "simulate" whatever initial conditions I need to set up. As it is now, neither KCT nor KRASH can provide that, and I understand the technical challenge. It doesn't break the mod for me if that isn't feasible, but it would be immensely helpful and in my opinion, realistic to be able to set initial parameters beyond what the editor provides.

What I was thinking of was configuring parts that you can't do in the editor, like setting up kOS, Remote Tech, Infernal Robotics etc., or getting to a certain state in the flight from where you start the interesting part; merely starting in flight wouldn't necessarily help with that. Maybe if KRASH would keep track outside the game state, in its own data file, it could "remember" the running cost regardless of a reload. Of course that would completely contradict the approach of keeping all relevant information inside the .sfs file. I'm not convinced that would be worth it, but on the other hand, I'd like to see an option to allow quick-saves; I mean, who defines what constitutes "cheating"... if I decide I'm fine with that, I'd like to at least have the option to conscientiously do so. EDIT: Just a thought... if it were possible to intercept the quick load function, it might be possible to manipulate the previous quicksave with updated information, and keep it all inside the sfs. Not saying it would be easy, or even worth the effort.

Not necessarily. Sometimes there is quite a setup process involved before you get to the point where the actual mission simulation launches; it would at times be helpful to be able to revert to that state, instead of having to set up everything anew. I'm not entirely certain how KCT handles the financial side of restarting the simulation, i.e. whether costs are additive, or a one time, up-front flat fee regardless of how many times you rerun the simulation. I suspect the latter, but I think both methods have their pros and cons. I wouldn't mind an initial, fixed setup cost, and if there's a time based cost too, I don't see how repeated re-running of any phase of the sim would contradict the idea of simulating the running costs of a mainframe... the tricky part would be to keep the running total in memory while reverting the rest of the game.

Something along these lines should do the trick (untested, not at KSC right now): @PART[dmSIGINT]:NEEDS[RemoteTech]{ %MODULE[ModuleRTAntenna] { %Mode0DishRange = 0 %Mode1DishRange = 50000000000 %EnergyCost = 1.5 %MaxQ = 6000 %DishAngle = 10.0 %TRANSMITTER { %PacketInterval = 0.3 %PacketSize = 3 %PacketResourceCost = 25.0 } } %MODULE[ModuleSPUPassive] {} } Paste that into a .cfg file somewhere below GameData; I suggest making a directory for your own patches, call it ReadPanda or whatever does the trick for you, and put all your personal modifications in there instead of modifying the mods' own configurations. That way, when a mod updates or changes things, all your tweaks are not lost.

You see, three or four years ago we had regular releases that were not tested and QA'd, and were made available for general bug testing, regardless of being "feature complete" or bug free in any way. With growing numbers, more and more forum users arrived who didn't understand that concept. The signal-to-noise ratio dropped to the point where Squad decided to withhold public test releases on the grounds that it were more productive that way. Now they tune into much higher noise than ever, and hope to find a signal again... I certainly do hope it turns out well for them, however if their reasoning back then was correct, they would be facing more work to sift through the complaints, and worse, bad word-of-mouth reputation, than getting useful bug reports.

Since I do not use Steam but still want to support KSP growing and improving, I purchased another copy of KSP. On the KSP store of course, to make a point. What I really don't understand is why Squad are opening up pre-releases again. I hated the decision when Squad axed them years ago because a growing minority of users didn't understand they were testing an alpha version. Certainly the issue has not improved since then, with ever more new users who even less expect to test a buggy pre-release. On top of that, Squad exclude a large part of the community who were here from the start - who were here precisely because they wanted to help test and improve an unfinished product, and who already got slapped in the face by that decision the first time around. As much as I love this game, I'm surprised time and again by the PR decisions made by Squad, being a marketing company...

If it isn't too much trouble, I'd say go for it. Integration into the standard save file mechanism can only improve compatibility with other mods that allow or require to revert flights - Kerbal Construction Time's simulations come to mind, and I'm certain there are a few others. For the sake of interoperability, the less mods cook their own ways, the better.

"all the legal difficulties" have never really stopped anyone - nobody asked me whether I'd be OK with Microsoft or Ebay getting my account data for Skype, or Ebay for PayPal, or Google for YouTube, or Yahoo for del.icio.us, or Condoleezza Rice for Dropbox... and that's just off the top of my head, and there are many, many, many more which I can't even remember, or didn't even notice. I don't say they should, but if Squad really were interested in taking Kerbalstuff under their wings, I'm certain there would be a way, even on such a short notice. Maybe in the future Squad could be a bit more supportive of services the community offers to each other, instead of plain ignoring them, even though they are currently in bed with a Curse. Rise... and shine ; )

Switch the forums to https. Or at least enable it.

[quote name='KasperVld'] [LIST] [*]The critical addition of some Kerbal themed emoticons, and support for emojis [/LIST] [/QUOTE] I hope this "support" you mention includes turning them off completely. There's little about these forums that I find as annoying as how they break the flow of reading, mess with line spacing, and just look plain ugly. I know I can switch them off for my posts , but that setting ("If selected, [noparse]:)[/noparse] will not be replaced with :)") is not remembered and I have to check that box every time I post, also it doesn't affect how other people's posts are displayed. On top of that, I have yet to see an "auto-emotify" function that doesn't regularly mangle text that isn't actually an emoticon, like source/config code etc. I'm not too opposed to text smileys, but those stupid icons annoy the crap out of me. Burn them with fire. As for the rest of the software migration, I've never been a big fan of vBulletin, [B][SIZE=1]EDIT:[/SIZE][/B][s]so I guess I'm fine with that[/s] but the new design looks like a horrible waste of screen estate. Maybe nice if you're browsing on an xPhone, but for those few who still use full-size screens this seems like a step in the wrong direction.

Awesome to see this taken up and continued. An idea I had for government funding was to simulate election cycles, ie. depending on which "party" has the upper hand, your program would get more or less funding over the next election cycle, the idea being that you have a budget you can rely on and maybe even overspend, but don't know how much resources you will have available in the next cycle. Of course "election results" would just be something like 20/20/60 chance for high/low/average funding levels. Knowing magico13, there would certainly be configuration settings for the exact values/formulas, so everything from broke micronations to prosperous world empires, direct democracy with weekly polls to one-party state with twenty-year plans, and the occasional revolution, would be possible

Presumably "RasterPropMonitor Core" installs the DLL without ModuleManager patches, in support of other mods that make use of it, while "RasterPropMonitor" installs those patches, and depends on "RasterPropMonitor Core"... that is, if you tell CKAN to install "RasterPropMonitor", it will also install "Core", but not the other way around.

Then let me chime in as yet another "lucky" one. Part of your impression may lie in the fact that users who don't suffer crashes, don't post about their experience very often. I've been playing KSP since one of the first public releases, and rarely had it crash on me. It does happen, but usually either a) because Squad hasn't yet released the usual two to three "hotfixes" after a new release, or because I borked a mod install. FYI I'm playing KSP on Linux, using Wine in the early days, and the native client since when it became available. I can only recommend getting to know your system as close to the bare metal as you can, and in my experience, Linux is and has always been more cooperative in that regard than the increasingly locked down, comfort feature-laden commercial alternatives. Of course that doesn't happen in a day or even a year, but is an ongoing process. I've had my first computer experiences in the early eighties and am still learning - please don't take it as bragging, but to illustrate my point. PS.: Ubuntu is not "Linux"

It wasn't my intention to make you run a central weather server for the entire community The idea was to have a separate process on the user's own machine, but outside of KSP itself, in order to get rid of Unity's restrictions. Of course that could then potentially allow to run the weather server process on another machine, but it would come more as a side effect. I can see how inter-process communication can be a tough nut to crack though. And of course you have already considered all that, I just wanted to put it out in the open to free up the headspace

This mod seriously has the potential to become the FAR best Kerbalspace Weather System Having this run on a home computer, through Unity, with the proper application "running in the background" is actually working in your favour, there is no control environment for the weather you create... it's not like you're trying to use Unity to predict tomorrow's weather on Earth. Mad props for attempting this. I can already see the temples the Kerbals erect to appease their new weather god. - - - Updated - - - Just an afterthought when I reread your post... what if you externalized the simulation, and connected to it via some messaging system, such that you weren't restricted to Unity, or a single thread... you could even run the sim on NASA's supercomputers As long as the sim uses a cross-platform environment, you wouldn't even be bound to Mono.

I'd expect the game to take a screenshot at, or as close to, every specified interval. I don't think taking a screenshot would interfere with timewarp at all, only the other way around, in that maybe the requested intervals can not be met. If so, fine, use the closest available. Optimally, include an option to reduce the time warp factor as much as needed to get to the desired granularity. Ideally the minimal interval between screenshots would be one frame, and the option to use the new-ish high-res screenshots. A screen recorder is not always the best option, or sometimes not an option at all. If I specify one screenshot per frame, I'm prepared and willing, and fully expect, to not have fluid 120 FPS in game, but have one screenshot for every single frame that has been rendered. I may want to up my resolution to some ridiculous value, so I can post-process the single-frame images later, for the purpose of creating animations, and FRAPS wouldn't cut it for that. Call it a unique selling point of your plugin

Using the '%' operator should be the default, it modifies existing entries, and if none exists, will create it. Use no operator only to explicitly create another entry with the same name (and an implicate numbered suffix), which you don't want unless you know exactly what you're doing. Most people use the '@' only because it was historically the first operator MM had and it has since become self-propagating and, as some rumours go, sentient.

I wish it wouldn't. While I just commented on disk space not being an issue in another thread, consider what if every mod includes every dependency in its download archive. Also consider what if your mod depends on another mod that depends on a third mod, or what if one of your dependencies updates... A list, or better yet a list of links to, the dependencies in the opening post, like you already have, should be sufficient. Other than that, looking forward to some canyon flying EDIT: Point in case: