micha

Ok, after plenty more playing around and testing, I was mistaken. The patch does successfully prevent the experiment from being reset (ie, discard results), through its right-click menu, but it does not prevent the Processing Lab from attempting to clean the experiment after the data was transmitted. Relatedly, does anyone know if there is a way to prevent or disable the "Review Data" screen from offering some of the options (Reset, Keep, Process, Transmit)?

Hey N3h3mia, I said I had a patch (just need to test more etc - sorry, was 2am last night when I stopped..): https://github.com/mwerle/OrbitalMaterialScience/commit/a88ed83d047794a094392a1a3fa5571512a98236

Which begs the question of why Squad didn't just include Blizzy's toolbar. Or at least implement similar configurability.

At the beginning, sure. Give it another X years of development (where X can be thousands..) and it should be as ubiquitous as mobile phones or plane travel is to us today. Unless there's a physical restriction, anything desirable will eventually become mass market, given a long enough stable civilisation.

The best argument I've heard/thought about as to why (backwards) time travel is probably impossible is the following: tourism. Basically, we are currently eroding differences between cultures. Slowly, but surely. Give it another couple hundred years of easy and cheap travel for the masses, and it'll be difficult to tell where on earth you are. Same with time travel. No matter how controlled it is at the start, eventually it'll become mass-market. And eventually there will be irresponsible or greedy people who don't care about the ethics. Given a long enough future, the past will homogenise. So the reason it's impossible (or at the very least that the "trousers of time" argument is correct) is that we are living in our present. That is, we don't have access to time-travel. Or flying cars, or any of the other things we could reasonably expect a highly industrialised and advanced future version of ourselves to have brought back into the past on their tourist-time-trips.

Yes, fully agreed on your post to hide/optimise the loading of the assets during initial startup. But I thought the main point of your original post was for KSP to actually NOT load all of the assets in order to use less RAM, and only load in the assets as and when required. Which is why I made the point that in a game like KSP that is not really feasible since the player can switch between scenes instantly, whereas other games where the scene-switch is more controlled, the game can intelligently choose which assets it currently needs in memory.

*shrug* Just reporting what I noticed. My machine only has 4GB RAM, but I run Debian with Windowmaker which fully loaded only uses a couple hundred MB - so definitely not swapping even after loading up a medium-modded game (getting very close to using up my full 4GB though! Unfortunately the motherboard is so old it's not worth buying more RAM for it, will have to get a new machine at some point.) I put the speed improvement down to KSP loading LOTS of small files, and hence SSD reducing the seek time significantly. Can't remember what HDD I have (as in, RPM, will need to check) but it definitely isn't a specifically gaming/performance one. In either case it wasn't wasted money for me since my desktop now boots up in seconds too.. Actual sustained read/write rates aren't better with SSD, but seek time is practically eliminated. So copying a large file still takes roughly the same amount of time (assuming a reasonably non-fragmented filesystem), but reading/writing lots of small files is MUCH faster. The only issue slowing down loading on Linux seemed to be having the wrong LANG environment variable set (look in the Linux threads for details) - never noticed anything network-releated slowing down load-times on Linux. Not saying the issue isn't there, but I personally haven't seen it.

In most traditional games you have well-defined areas though and assets within those areas are known as well. Furthermore, moving between the areas is usually heavily restricted. Which all means the game engine can very intelligently load and unload assets as and when needed in the background without appreciably affecting the running of the game. So yes, they usually do have scene transitions - whether or not that is apparent to the user. KSP, being a sandbox game with mostly user-generated content (planes/rockets) and being able to switch between them at will irrespective of where they are or what parts they consist of means it does not have that luxury. Yes, startup could be reduced to only loading the assets required initially, but you'd still need to have most/all assets loaded before the player actually is let loose or you risk very slow switches between vessels and/or scenes as any assets not currently in memory need to be loaded in at the time of the switch.

I also like the idea of (permanently) buffing parts - but instead of (for example) an LV-45 becoming 5% more powerful/efficient/whatever after the buff, it should be unlocking an LV-45 Mk2 (and then a Mk3, Mk4, ...). Possibly have each revision also become more expensive. This way we achieve 2 aims which I think are critical: 1) existing craft aren't magically upgraded 2) everybody still plays in the same universe. (*) (*) That is, if I share a .craft which contains some upgraded parts, then everybody can fly that craft as intended (assuming they have unlocked those part upgrades). There is no disclaimer "oh, btw, this will only fly if you upgrade this part to such-and-such a level" which was the major outcry over the buffing system originally proposed for leveling Kerbals.

I like the idea of seeing Science Points as being the "High Score" of the game. Even to the point of once you get X amount of Science you've "won" (*)(**). After all, it's been announced that 1.0 will have "lose" conditions (run out of funds or rep), so what, if any, "win" conditions will there be? That'd also mean making tough decisions on your strategies - do you convert funds to science to get the higher score, at the risk of bankrupting yourself, or do you skimp on unlocking certain tech nodes and make do with a subset of available parts, etc. etc. * To avoid Rep becoming completely useless, maybe have to have X Science and Y Rep to "win". ** And it should, of course, be possible to continue playing afterwards. Perhaps people will set up a score-board to see the Science Point high scores (for stock / a given set of mods).

Depends on what you want in your game. The list of mods I personally play with is here. I would consider the following functional mods as absolutely essential: Kerbal Alarm Clock, Docking Port Alignment Indicator, Kerbal Engineering Redux (or MechJeb), Stock Bug Fix Modules, and possibly Precise Node. All others depend on what you want - more science, more pretties, more parts, ...? Here is a list of plugins and mods. Also check out KerbalStuff and Curse. CKAN does a pretty good job managing your mods.

Lovely pic, and nice station! But am I the only person on the planet who dislikes lens flare??? I mean, it's a side-effect of optical systems, not an actual (at least originally) desired effect..

Awesome!! Can't wait to try this out - the number of times I've throttled-up my space stations while renaming docking ports (and hence zooming off into the black beyond, leaving my cargo ship lonley in orbit) is beyond count.. Will you be adding this to CKAN? Oh, and another (semi-unrelated) thing, I was just about to lodge a bug against KSP about this. By the comments above, this issue is Linux-specific? Has it been raised and is Squad aware?

And this is why IMHO the stock game needs some sort of basic scripting and special background processing for long burns to allow for any sort of semi-realistic missions to targets which are further away. IRL probes are programmed to perform their hours/days long burns and ensure they stay on target during it as well. To ensure people still run short burns manually it should take some time to set up an automated burn, otherwise it'd just be autopilot all the way for perfect burns. During any long burns it should be possible to either timewarp or switch to other missions until the burn completes.

Odd.. the very first entry (Pioneer 0) has a status of "success", but the notes say that there was a launch vehicle failure and maximum altitude reached was 16km - so barely into the stratosphere... hardly a success if shooting for the moon! Edit: Apart from that, very cool article, thanks for pointing it out.

I used to manage my mods via a spreadsheet (Linky Here), but now I use CKAN for most mods (sorry, I know that's not the answer you're after), being an avid Debian-user I am very much spoiled by a good package manager. While CKAN's not quite there yet, it is quite usable in its current form. I'm hoping to contribute to CKAN once my work/kerbal balance switches back to kerbal a bit more.

Biggest speed-up for loading KSP for me was getting an SSD. Made a huge difference over a normal harddrive.

I agree, but as we don't (yet) have a way to move around and manipulate stuff using IVA it is the next-best thing. Anyway, it was just a thought to be able to carry multiple experiments up on a single launch without the ship looking like a sausage, and then be able to install the experiments on the station without needing to leave them docked and visible externally.

Doh! Yes, of course.. and I have no idea why I've been confusing KAS and US recently.. probably because I've just built and launched a couple of station modules which contain a large number of US KAS containers..

Although this is true for pretty much every <insert manufacture here> custom tools. Basically, complete format, then install Windows (or Linux) from scratch using clean media, and only add those bespoke drivers that are absolutely necessary for the hardware to function. Everything else is a royal PITA. As far as the other issues go, it would be interesting to see how they compare to other brands. Any large rollout will inevitably see issues; the interesting thing is whether the percentage of issues is significantly higher than other brands. PS. I don't have personal experience with Lenovo, so not defending them; just curious.

Get a cheap transfer cable if you just want to copy the data. Or you can turn them into external drives with an enclosure if you want to keep using them; only worthwhile if they are large though. Either option should only be a few quid off eBay..

I use KAS so not an issue for me. As a programmer, I also think it's better to reuse existing solutions as much as possible instead of duplicating effort. Perhaps you could collaborate with KAS to turn KAS into multiple modules - 1) the actual plugin to make it all work and 2) the various KAS containers and parts. That way you could rely on the actual functionality of KAS without requiring people to have all of KAS installed. I believe some mods use Firespitter in a similar manner. Personally I'd actually love for you to extend KAS integration and offer the various experiment modules as KAS wedges. Maybe something for me to have a play with if/when I get some spare time.. that way Kerbalnauts could actually install an experiment on a station by taking a wedge from a transfer craft and adding it to the station, rather than docking the parts. Anyway, keep up the great work

I like the idea of an in-game encyclopaedia that is filled out as the game progresses. Shouldn't even be that difficult to program in since the missions framework should easily allow hooking into the relevant game events. Effectively have hidden missions running (eg, Mun: flyby, enter orbit, map surface from orbit, perform X experiments in high orbit, low orbit, in various biomes on surface, ...) and as mission parameters get fulfilled the encyclopaedia entries are progressively unlocked. This ties in with another idea someone proposed which has evolving surface textures for planets/moons - basically the astronomers on Kerbin have compiled rough maps of each body but it requires actual visits to map out the details. Similarly there could be rough mass and atmospheric density estimates but to get the exact values requires measurements.

Going back to the OP's point, yes, I also think Kerbal Kareers should be stored as a separate value instead of being derived from their names. The exact mechanics of storing that is mostly irrelevant; in the save-file it should be human-readable, and in an optimised game-engine it should be a (set of) numbers. I also really like the idea of a Kerbal being able to learn multiple roles; especially in the early game before having access to the bigger command pods it'd be nice to have Kerbals with secondary traits. Or later if you want to send a light-weight mission requiring a mission specialist with at least a Pilot-Level-1 skill to keep control of the ship would be essential.

The site is "up" in that the web-server is serving incoming requests - in this case by replying with an error page. The problem appears to be the link between the front-end (web-page) and back-end (database server); specifically it looks like the login details for the database were changed on the database server and not updated on the frontend. Or vice versa. This is not something a tool such as DOJME.com is programmed to detect.