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?

If you have some good well thought out ideas feel free to express them in the requests part of the forum, or if you feel so inclined, you could learn how to make them yourself.

I just want to bring awareness to the fact that this image was taken while the craft was upside down, reentering Kerbin's atmosphere.

The EDITOR is 64 bit. Helpful, yes, but not for us. Unless it comes with a host of 64 bit fixes as well. Meh This is where we can see some performance gains possibly, though I wouldn't get your hopes up for much more than 10% at most. Meh Meh Meh Meh Meh AFAIK this is not applicable to KSP's initial loading sequence Perhaps you missed Harv's post, but I think that while he didn't answer you directly, the answer is obviously no. They have far too much to be doing already to be pre-testing a new beta engine and dealing with those bugs, especially considering the minimal benefits it will provide.

Take heart guys, I've finally gotten myself set up to work on this again! https://github.com/Xaiier/TimeControl/tree/rewrite

Do you have any hard evidence of comparative tests where a similarly rated Intel chip ran with 1200 parts and your AMD ran with 300? No? Here's some: CPU Performance Database Thread As for your two suggestions: 1. What? Part count is part count, I don't see how the design of the ship matters. 2. No. Unity does not utilize any platform-dependent optimizations.

I've been sick pretty bad for about a week now, so despite my attempts to work on it, I haven't gotten much done. A wall of code is a painful sight to a cloudy mind. That being said, this is top on my priority list once I feel a bit better. (this isn't a sob story, just a bit of info, don't send me get-well cards ) I have been able to do a bit of thinking about stuff, as well as consider all of the suggestions that you guys have been made and discuss with other modders, and I've got a fairly good idea of what I need to do once I'll be able to do it. It hopefully won't be too much longer. I don't know how long I'll be able to stand watching you guys post about it.

By that logic, neither does yours. Or anyone's. Why are we here? I...I have no response to this. It's just blatantly sidestepping the point. Not to mention that we can assuredly know that it won't be just FAR implemented in the game. Not really. KSP has always been about trial and error in order to succeed. That you presume that it is expected for players to read "pages upon pages of physics" shows that you are approaching this entire argument from position clearly biased towards realism, and I don't think anything I can say will be able to change that. With that being said, I'm done with this topic until we hear news from SQUAD about their plan of action. There's no point in bickering until we have at least a vague idea about what might be coming.

If you actually bothered to read what I've said you would realize that in my experience it isn't so "apparent, obvious, and intuitive" as you make it to be. Remember that on these forums what we see is probably the top 10% (at most) of players who largely represent an outlier in the general population of players. You cannot base your assumptions upon the perceived competency of such a small, elite group. Any change to stock is going to affect the entirety of the community, and that is something that has to be considered. We are effectively a "vocal minority". We have already solved most of our issues with FAR, why is it necessary to force upon the majority a change in stock which we know will still not rival FAR and which in my experience, they aren't prepared for?

That's the issue though, nobody is arguing that it would be improved. Nobody is looking at this from the perspective of balancing the gameplay. That was the intent of my original post, to get those who support realism to provide reasons that realistic aero make KSP a better game without resorting to the "realism because realism" reasoning so often used, but it seems all that has resulted from it is yet another useless argument about the merits of realism.

Thats fine, thats why we have FAR. The ability for each player to customize their experience is one of the great things about KSP. That being said, there are a few things I don't want: -FAR being implemented directly into stock, thus removing the players choice (obviously someone could make a dumbed down aero mod, but that isn't optimal) -stock implementing a half-baked version of FAR which ends up screwing up the current stock design possibilities but still leaves FAR supporters unhappy -any significant change which would make FAR impossible, which is one of Ferram's main worries with the new aero. It would not take much for FAR to become technically unfeasible within the new system, and SQUAD hasn't been the best lately about making new features easily moddable.