Xaiier

That would be quite difficult if not impossible. It also wouldn't help much, as the collision detection is a majority of the processing.

It would in theory be possible to put a vessel in the static state that it is in during warp, but this would result in it not having collisions with other objects. It's an idea that's been tossed around before but there isn't a good solution.

For those interested in why I haven't been able to work on this, the reasoning is twofold: 1. I simply don't have the time. I am studying to be a CS major and as such more coding in my limited free time is less than exciting. I have schoolwork and other projects which are priority for the time being. 2. I no longer have interest in KSP. A large portion of what drove me to work on this was to be able to use it for myself, and as such I have no desire to continue work now that I no longer play KSP regularly. This is not to say that I don't like KSP anymore, but rather that I have exhausted my interest in it due to the sheer amount of time that I have invested in it. I chose the MIT licence with this possibility in mind, and I see that some have already taken up the slack and tried to fix bugs and keep it updated. While I would like to revisit this in the future, I cannot definitively say when. I originally started this project by taking over DEADBEEF's original code and improving upon it. Likewise, I would love to see somebody take my functionality and improve upon it further. I would much rather see this live on under someone else and be useful to the many people that have enjoyed it than have it die because I was unable to continue work on it. Consider this official approval to take over the project if you like. Good luck, Xaiier P.S. If anyone has specific questions or needs to get in contact with me, I am still active in the KSP IRC channel and other affiliated channels.

Obligatory

Can you do my homework? Take my exams? Because that's currently what is stopping me from working on this. Stupid priorities.

The only significant change between 0.90 and 1.0 in my department is the addition of the warp-to-node option. The code for it is actually already in the game, just not implemented by Squad, and I've already made use of it as a warp x time feature. Assuming they don't change that code, there shouldn't be any issues porting over to 1.0, so there's no need to wait on anything.

I was unable to replicate this behavior. I'm not sure what is causing it, as logically this mod shouldn't allow that to happen unless KSP itself was bugging out somehow (which is possible). I'm going to need more information in order to diagnose the problem.

I was reading through this going "wow" and then I saw this...brb cleaning up the remains of my jaw off the floor...

What I meant to point out is that such a thing is on the lower bounds of what one might consider a superintelligent AI, as it really only has the intelligence aspect, without any sentience or morality. In fact, such a thing could barely be classed as intelligent, the simplest form is basically just an advanced management and coordination program, which is only superior due to it's speed at comprehending and processing a large amount of data.

Someone linked those articles in the IRC chat a few weeks ago. I found them interesting, but they are largely just a rehashing of ideas that have existed for the last ~60 years or more. Science fiction and pop-culture have been playing with the idea for a long time now, and a lot of very smart people have tried to predict our impending doom or whatever it may be. The simple fact is that superintelligent AI is not the thing we need to worry about. What we do need to worry about is a super-advanced, technically non-intelligent system which has a defined task or goal and the means to accomplish it. Such a thing could easily happen in the timeframe these articles suggest, and it will assuredly happen before a true artificial intelligence exists. In this regard, we're looking more towards something like "Skynet" in that it has one task (the protection of earth) and the means to do so (robot army & control of all computers). Such a thing would be significantly more dangerous than a superintelligent AI because it would have all the speed and efficiency of one, without any of the superior intellect which allows for the chance of it being benevolent (unless of course, that is its task), or acting of it's own accord. Things like this already exist in military applications, such as drones which can autonomously choose targets and engage without human intervention. One way to imagine such a thing is through Keith Laumer's science fiction novels on Bolos (http://en.wikipedia.org/wiki/Bolo_%28tank%29). Initially beginning as computer assisted tanks, they became more and more powerful over time until they were nearly unstoppable war machines capable of dealing with any threat, completely autonomously. Such a thing, minus the artificial intelligence, is well within the realm of possibility of being created in this century. While they may not be the extinction level AI's predicted in your articles, even a single mistake with one would have disastrous consequences. As such, I don't think our real issue is creating a computer which outperforms us in every way. All we have to do is create one which outperforms us in one way, and then give it too much power.

Aerodynamics calculations do not take up a significant portion of the processing load. There is no need to consider outlandish solutions to solve a problem which doesn't exist.

Yes. What surprised me is that it is such a complex system in there to try and avoid clipping into the terrain and probably also to help with the animation. It's arbitrarily random and rather annoying if you want to place a flag in a particular direction, as even with my explanation you still can't really control which way it goes.

So I delved in and figured out the arcane magic which drives the flag placement system. Here's what happens, in simplified, comical form: The kerbal looks at the ground in front of him, taking note of how steep the ground is in that direction. Kerbal flag placing guidelines mandate that in order to prevent injury, flags may only be placed on ground the same height as that on which they are standing. The kerbal looks exactly 40 degrees to the left, taking note again of the ground height. Kerbal flag placing guidelines are very specific about this. Failure to do so may result in spontaneous combustion and/or death. The kerbal repeats the last step another 8 times, in order to properly survey his surroundings (it is not explained how said kerbal is able to do so without actually turning all the way around, though our leading theorists on the topic believe their large helmet secretly disguises a number of rear mounted cameras at 40 degree intervals) The kerbal then looks over his notes, and chooses which of the 9 directions he surveyed based on how flat the ground is in that direction. The kerbal turns towards that direction, and places the flag, ensuring that the extension of the flag is away from him. Kerbal flag placing guidelines mandate that flags only be allowed to extend when pointing away from helmets, to prevent injury from being knocked in the head. Note that the 40 degree intervals will sometimes result in the kerbal choosing a point which you may not think is the closest counterclockwise-turn point, as it is possible that it will sample a direction which is slightly high, slightly low, and then continue on and sample a closer to flat direction about 180 degrees from there. This is likely what causes the seemingly random behavior of placement. It is also worth noting that this is also why the flag placement is always off by a few degrees from being perfectly perpendicular to the slope.

Some people intuitively try to design for aero...some don't. Depends on personal experience really, though in my experience it's been the latter.

I can confirm that this happens on Windows (stock). The key to triggering this bug is pressing the enter key while in the name box, which triggers the save with the ship as-is. A potential solution might be to scan for such ships and delete them, perhaps by checking the ship size, which is always 0, or checking if any PART nodes exist. In my testing deleting the file externally fixed the editor functionality. The .craft: ship = Dingleberry version = 0.90.0 description = type = VAB size = 0,0,0 EDIT: Actually, you might be able to directly nuke the method by poking with EditorLogic.fetch.shipNameField and removing the method callback. I'll leave the implementation to your capable hands...er...claws?