Lisias

To tell you the true, they are obliged to delete personal information, not the account. As long as they delete/change data enough to make impossible to associate you with the content, they had fulfilled the European Law. As a example, you can demand a company to delete links to a news page about you, but there's nothing stating about deleting of the news page itself. Source. So, it appears to me that locking the account, changing the username to something like "unactive_<some_random_number>", and then blanking all the profile data but keeping the posts it's enough. Keep in mind that by using the Forum, you already granted irrevocable rights about the content you post here - so I don't think you will find grounds to force the deletion of non-personal content over a sue, even on Europe.

Early Bird already plans to integrate to KAC - currently, I'm not exactly sure about how the best way to do that: Contributing to Early Bird in order to implement the planned integration Add the feature directly to KAC Early Bird already handles all the math (including provisions for tilted axis planets), so keeping this functionality on it is appealing - I'm a Follower of the Sacred UNIX way. :-) But adding the feature directly into KAC would save the installation of one extra add-on, and we would have a one less point of failure - as it appears to me that add-ons long term maintenance can be an issue for this eco system. Well... It appears that a short-term solution is not available yet. Time for the Plan B. :-) Thanks.

Hey, I read the wikis! :-) It's not my fault I have memory issues and forget from where some parts are! (yeah, it's about that Construction Krane! =P ). =D =D

IMHO Sary should be between Jool and Eeloo, as "our" Saturn is located somewhat this way. A proportional orbit would be a good idea, so eventually a Kerbol equivalent for Uranus and Neptune would convive with Saru.

/me too! =D Bleh, there goes my "surprise" - this AddOn is so good that everybody had the same idea. =D What just demonstrates the well defined concept and implementation, @Angel-125! Congrats! In time... I have "yet another" feature request. (please advise if I'm annoying). I think it would be a good idea to have Hangar Decks and Fligh Decks with the same size of the HL-10M Dirigible Section. This would make easier symmetrical designs on multi-hull vessels with different functionalities. As a example, on the picture below I had to put two Cargo Lifts in sequence, as I need this hull to be the same size the other and I only have HL-10L sized Hangar Decks to be used on the other side. A HL-10M Flight Deck would also allow me to put flight decks over Cargo Lift without stunts like what I used over mines.

What I did in KSP today? I don't have the smallest clue what the hell I did!!! Still trying to figure out what happened... =P

I'm afraid you will have to find it for yourself. Open Source/Free (as in beer) Project developers rarely have financial resources to test the project on all the intended hardware targets - they rely on the user's feedback in order to do that.

You downloaded THIS release, right? Using the latest works only on 1.3.1, you need the release tailored specifically for 1.2.

First things first: we need to be sure about it, otherwise we would mangling things where it doesn't matters and ending up with two problems to solve. :-) 1) backup everything. Copy the whole shebang to another directory, and zip it to be sure the contents are whole and preserved. If the worst happens, we can also start again from scratch. 2) Move everything but Squad from GameData. Fire KSP. This will assure you that the KSP is working and your hardware is in working condition for it. 3) Move ModuleManager and RSS to GameData. Since RSS appears to be relevant to you, you put it in first so if I'm right, the memory will be exhausted later with a less important mod. 4) Move back things slowly, until the crash starts to happen. Try to remember what you move back since last successful KSP fire up, otherwise you will have to restart from scratch. Been there, done that. :-D 5) On the Settings, set the Texture to "Half size" or even less. 6) Try again from where you stoped and see if you get further in the process. There're still other possible problem related to memory, when the ammount of add-ons together, blows up the available working memory. When the heap grows, the O.S. tends to use the swapfile to "make" memory for KSP, and this makes things really slow on the long run when you exceeds too much your physical memory. This also could explains subtle halts once the game finishes loading. And there's the "static" memory (memory used to hold configurations, code and also textures - the VRAM holds textures being used, but the textures are also stored in process RAM to be available when you launch something that needs it). But, usually, this blows up on our face when KSP is still loading.

My opinion is that Squad, currently, is doing the "right thing" about a history background. There are few gains by restricting possible developments in the future. One thing that I think can be done are DLC's with "short histories", that can be tied together, but with the less past baggage possible to avoid restricting future developments. For example, if by some reason it's "official" that Kerbals lives underground, this would restrict an official DLC that delivers a city. I would propose something as the Asimov's short histories about the Three Laws of Robotics, and suggest avoiding something as Foundation. :-)

If the game crashes before creating a log, it's not Module Manager's fault for sure. It only kicks in after the log is created and populated with some messages. I saw the video. It's a Unity's issue. When you blows up the VRAM available memory for textures, this is exactly what happens - KSP just closes under your face. Only a O.S. Crash Report can tell this for sure, however. Try this: move all the add-ons to another directory (leave Squad's and Module Manager), and bring them back a few each time while starting KSP to see what happens. I expect a series of successful launches until the "last drop" happens and Unity crashes. I suggest you move back your add-ons in relevance order, so when the crashes happens (and then you reach the point in which you must delete the last add-on, and ignore the remaining), the add-ons that you must give up will hurt less. :-)

There's another "trick" on copyrights that sometimes helps. Some authors changes the license over time. If you manage to get a copy of a previous work licensed with the permissive license, you can use them besides the newest version having a restrictive license. Keep in mind, however, that if challenged it's up to you to prove that you are using a previous work licensed under the permissive license. (It's always up to you to prove you are using correctly licensed material, but this is far easier with recent works).

I'm not that harsh on 1.4.3. It's working (almost) fine right now for new game saves and a moderate amount of add-ons (let's say, about 20 or 30). But if you have ongoing missions on 1.3, I recommend you to keep playing 1.3 for while, and firing up 1.4.3 only for the new missions. There was a few (intentional and unintentional) changes on 1.4.x that rendered some key (for me) add-ons problematic or useless and created a lot of nuisances on some others. The more add-ons you have, biggest the chance you reach the "critical mass of nuisances" and get burnt by them.

Give Konstruction a peek.

yeah, I just diagnosed this too. That's an interesting bug, however... Mainly, because I just didn't believed that ClickThroughBlocker would be the trigger - I insisted on searching everywhere else for some hours before realizing that the 1.6.4 update was the smoking gun. If we manage to get a minimal setup where this happens (I'm running 116 add-ons right now, and I'm really afraid to apply combinatorial analysis on this!), I think that would be a good idea pursuing the root cause of this problem. Not necessarily to fix this specific issue, but to know what to avoid in the future: I'm going to add ClickThroughBlocker in everything I have here.

Hi, There's a Plugin that shows the current (local) Solar Time? I want to plan my activities on different planets/moons using the Sun as reference. Usually, electric hungry activities would be executed near the local midday to take advantage from the higher solar light incidence on the solar panels. "Early Bird" helps when I want to wait to the sun rising, but more than often I want to be alerted when a vessel (in any planet) reaches a specific local solar time (usually 10:00 AM, so I would execute the electric intensive activities until local 14:00, and the rest of the daylight would be reserved to charge batteries for the night).

Error 0xDEADBEEF: The System got angry with the Application and killed it.

You need Hooligan Labs Airship.

Barely, and probably unpleasantly. And don't even think on trying Mission Builder. If you really want to run KSP on this "potato" (forum slang for weak machines), IMHO you will have to downgrade KSP to 1.3.1 or even 1.2.2 to have fun. Trim down all video settings to the minimum or you will get 2 to 4 FPS on reentry and other graphic intensive situations. Disclaimer: I never tried this stunt, things can be somewhat better or worse as stated. In a nutshell, I won't.

As an example about what to expect on huge vessels/stations/bases, consider my current status quo. This is what I get after editing/trying/crashing =P one vessel of mine after 6 to 8 hours: Yeah. 18 Gigabytes allocated on a machine with 16G of RAM (and almost 1G "wasted" as memory mapped I/O, BIOS, etc, what renders about 15.4G of useful address space). HALF of that memory is compressed by MacOS, and I don't have to explain how this hinders FPS. Anyone used SoftRAM or any other "RAM doubler" utility for the Windows 3 on the 80's? Same thing. =/ Well, time to restart KSP. This is what I get after restarting KSP and loading exactly the same craft I was editing: Take your own conclusions about the matter. Curiosity for MacOS X users. This is what happened while I typed this post: There's no CPU or GPU in the world what would give us good FPS with this stunt Apple shove us by the throat.

Not big (or weird) enough to cause so much trouble, IMHO. Currently, I'm inclined to suspect the Garbage Collector. This craft contributes, but doesn't appear to be the real culprit of the situation, only that "last drop". As I use to say, she is only the "victim that screams". Try this: move EVE, SVE, Scatterer and PlanetShine out of the GameData. Run KSP and Measure your Scenario. Then move back one at at time, taking measures each time. Move them out, and move them back in different order if you find the mood. You may want to use GCMonitor on the measuring (I made a quick report on using it, good info). This should pinpoint the Module (or Module combination) that appears to trigger your problem. Also, try Spectra. It's what I'm using on my crappy MacMini. POSTEDIT: Humm... Planet Shine... It reflects the nearest body's luminance on the vessel. It's a nice suspect for the problem, as the processing is increased as new vessels are out of rails - each one must have their luminance recalculated every frame.

Yep. It's the Unity's mangled GC. This is not going to be "fixed" in the short run, as the current Mono's GC halts everything when active. And as faster is your machine, more garbage per second it produces - and as more memory you have, more garbage is accumulated before the GC became active. Oh, yes... And Unity leaks memory - so as the time passes, KSP allocates more memory to do the same thing and eventually Windows start to swap, lovely when garbage collecting. =/ You can postpone it, but not prevent it. The new machine will improve this numbers for sure, but you will still get these performance drops sooner or later. The trick is trim the situation to get acceptable FPS on the worst case.

I know. The FX series have a terrible IPC (Instructions Per Cycle). But not that much terrible - the OP said it got 25 FPS on one scene (not good, but not terrible), dropping to 12 (bad) when a specific vessel enters into the physics' range. Another thing in which AMD is not that good (including Tyzen - almost 8% behind Coffee Lake) is the memory controller, and since KSP is more memory intensive than CPU (most of it is written in Mono anyway), identify the bottleneck will definitively help on choosing the right CPU. KSP is not exactly CPU intensive. KSP is low optimized - Mono compiles CSharp into CIL, and the runtime interprets CIL into native machine code. This kind of stunt is more memory than CPU intensive - bigger and faster cache gives better performance than higher IPC here, as most of the time the CPU will be fetching CIL opcodes and data from memory instead of executing VM's instructions (I'm ignoring the JIT, better CPU will help on JIT). What parts and modules do you use on your skycrane? Then "random drops" is the Garbage Collector kicking in. It will happens too on any other CPU, as its Mono's (and Unity, as they changed the GC) specific. More memory can help you more then more CPU here. Diagnosing the steady drop to 12 fps when the skycrane in being computed will help us to guess your system's bottleneck, and then you can choose a system that would minimize this bottleneck.

On the KrakenWobbling Summoning Part Configuration I found that not all parts "glue" to the Dirigible Sections with equal "stickiness". In special, the HL-10 Gyro Ring doesn't hold well when an very heavy part is attached to it on one side, and the thrust is "felt" from another. The solution is to put the heavy parts on both sides as the pictures show: Figure 1: The Wobbling Summoner Observe that on this configuration, the HL-10 is attached to the main hull, followed by a "Super Lithium Battery" teakscaled to 10M, what renders 160Tons of mass. Attached to the Battery there's the Tail Cone (or the Nose Cone). This configuration will make the vessel wobbles terribly no matter how you autostrutted the parts, or how many struts you shove on them - 160Tons appears to be simply to much. The wobbling is so severe that 1/3 of the Battery insiders are visible from the Main Bridge while flying, so severe is the displacement. Figure 2: The solution: Note that on this configuration, the heavy part (the battery) is attached to the main hull, then the HL-10, and then the Tail Cone (where the engines are). The same must be done on the Nose Cone: you attach the Battery into the Dirigible Section, then you attach the HL-10, then the Nose Cone - doing otherwise will summon the KrakenWobbling. I didn't tested attaching the HL-10 on the inner Sections as there's a huge hangar on my vessel, and the HL-10 would block it. So... Yeah. This is what was preventing me to get rid of the "autotrut everthing to Root" stunt. My previous design kind of worked - what was happening is the HL-10 problem, that made the main hull wobble so terribly that the gondolas attachments were collapsing! Even with struts (that were collapsing themselves!). Attaching Gondolas Well, with the 'Keel" working, I could attach the gondolas successfully into the Hull without "autotruting" then to Root or Heaviest (what I consider cheating). I accomplished that by building the gondolas "on the ground", unattached, and then autostrutted every one of them to the GrandParent (without rigid attachment). This made the gondola pieces firmly tightened to each other - exactly as we would built them on real life. The Root Part of this "subassembly" is the "local" CoM. However, since KSP craft's data structure is a tree, the subassembly will attach to the main hull in only one place - and then the extremes would be "spaghetified", with the extremes hanging. Since the gondola's mass is almost negligible compared to the main hull, the main hull doesn't wobbles, but the gondolas start to move as worms being fried! =D Of course, autostrutting everything into Root would solve the issue - on the cheating way, what I don't want to do. The stock EAS-4 Connector is not strong enough, so I had to add a pornographic amount of struts to keep the thing in place. This was raising the part count, what would make me have to cut out something nice after. So I gone for shopping, and found Impossible Innovations (link to unofficial package, recompiled to 1.4.x), that added "Iridium Struts" to the game. They worked fine as I wished! Or almost, as the gondolas were bouncing when the vessel moves attitude. =/ Well... That made me think: on "real life", we do not attach struts to the "skin" of the attached parts. We strut things into the "spine" itself! So... I autostruted the strut to the Root! :-) This is not cheating IMHO, as the strut is simulating the bolts that tie the appendices to the vessel's main spine. Since some gondolas are huge, I had to use bolts in strategic places. I choose to "bolt" the Bison Stabilizer Legs, so all the other parts are held into place by the Leg's part. And since the Leg's part is bolted into the "Spine", we have a somewhat real life solution kerbalized, I mean, hammered into the game. =D This stunt fulfilled my requirements: made the thing sturdy, but not impossibly studier. The main structure can be abused and will twist due the abuse, as a real life ship would. As follows. Proof of the Concept: Abusing the Ship. Few things ruthlessly destroy our most beautifully designed crafts as much as... the Time Warp. So, I timewarped to 4X to see how she handles, and she bent due the thrust! Also note that the Gondolas are being pushed out from the Hull by the stress, but they are not wobbling (I should had made a video...). I wonder how she will behave when the secondary hulls are attached... After deactivating the time warp, I had to turn off the engines and to activate SAS. The ship "waved" (not wobbled) for some time, and then came back to be a straight, sturdy platform! interestingly, having two reaction wheels (one in each extreme of the vessel) helped (instead of making things worse as is documented in many tutorials). When turning the reaction wheels off, the waving easing was slower. Also note on this last picture the "bolting points" where the "Iridium Struts" are holding the gondolas attached to the Keel, instead of magically "glueing" everything as it was casted from a solid. This next picture was taken 2 seconds after the last. Observe how the gondolas had came back to their position instead of wobbling around. If I stress her enough, something will probably break - as it would in the real life. I need to do some more tests to confirm it. By moving aggressively the control surfaces on high speeds (she reaches ~55 m/s at this configuration), the hull "waves" similarly. Using SAS alleviates the twisting a bit, but not completely.

Well... More Quick&Dirty tricks from Lisias.. :-) I have good and bad news. The bad news are here =D, the good news follows. I finally managed to stabilize the central hull of my ship! None of the gondolas (lateral or ventral) are bouncing anymore! I still have to use "Unbreakable Joints" on launching, but after that you can deactivate the cheat. The ship accelerates and moves without spaghetification! =D I managed to do not use autostruts to Root on everything: Keel (Ship's Spine) is simulated by Autotrut all the HL Dirigible Sections, the Hangar Sections, the Nose and the Tail into the Root - and the Root is the central Hangar Section, exactly at the middle of the Vessel. The Rigid Attachment was also set to On. This make the "main hull" behave as it were constructed around a Spine. All the Elevators and Flight Decks does not use Autostruts neither Rigid Attachment. All the Gondolas Sections are Autostruted to the GrandParent, and without Rigid Attachment. They were created separately, with the Root Part on the "local" Center of Mass and then merged into the Main Hull craft file. So they're not "magically welded" into the Root part. And so they must be "attached" to the "Spine" somehow All gondola's connecting trusses (used on the lateral gondolas) are autotrutted to Root and Rigid Attachment to On Also simulating attachment to the "Spine" I also found a Part configuration that "promoted" wobbling. Avoiding this configuration made wonders to the vessel. I will detail these things in the next post, as this one has already too much pictures (it appears to have a limit on the pictures you can post on a single post).