Lisias

And that's exactly the problem: we learnt our lesson. We start to see History repeating itself, we will jump into the obvious conclusion, even if prematurely. There's zero benefit on telling us they aren't doing anything KSP if they are not doing it. If they are, there're some drawbacks. At very least, we will know the communication between devs and management is so bad as it was on the old team. === == = POST EDIT = == === I reconsidered. If they are, indeed, not doing anything KSP, it may be their best interest to prevent the potential userbase's hope to grow strong, not only to avoid disappointment on them later, but also to prevent the new IP owner from "surfing" in their hype...

You may want to check this: https://bitbucket.org/net-lisias-ksp/ksp-tools-public/ in special: https://bitbucket.org/net-lisias-ksp/ksp-tools-public/src/master/src/ksp/metadata/ Every single part, with every single PartModule, from every Steam available KSP ever released. With DLCs. On a Python data structure (hopefully) easily usable. As a bônus, a lint for CFG files - but this is offtopic here . You may be interested on the CFG parser, based on the taniwha's but (IMHO) improved - granted, I didn't implemented any converters for craft files...

If the information leaked soon enough, and Dean Hall got word about, it would be logical to grab whoever he could the fastest they could because otherwise he would risk having the personal being recruited by the IP buyer (assuming they would want to work on the Franchise, of course), or just to any other employer - making the recruiting harder and more expensive. Not to mention that he started to recruit people for his project way before the sale announcement, essentially 20 days after the layoff were announced. Bonus track: So, IMHO, DH probably had already plans to do a KSP replacement for some time and, being seasoned on this industry, I'm absolute sure he predicted correctly the outcome just by... buying and playing KSP2. Since this dude knows how to run a Game Studio, it's logical to infer that he added 2 + 2 and concluded that "it's now or never", as building up that team 6 months after the layoff would be, well, essentially impossible. About the timing of announcing KSA... Marketing. He surfed on the PD's buyout trend and managed to get even more visibility if he announced it before or later. If they would not be allowed to talk publicly about a hypothetical IP acquisition by RW, then JPLRepo essentially disobeyed the order by... talking about a hypothetical IP acquisition by RW. Since he's still employed , I think we can assume he could talk about - or, at very least, nobody told him to avoid touching the subject. So, and assuming he was allowed to talk about, we have essentially two possibilities: It's true, RW didn't bought the IP (damn) It's a lie. JPLRepo (by his own initiative or perhaps induced to do it without being aware - i.e., someone lied to him) lied to their potential consumer base. A really, really, really really bad move and poor judgment. It would undermine the credibility of the one of the front-man of the project. And I don't see any benefit on doing that - but, hey, I don't have any insider information, it's not impossible that by doing it they prevented a worse problem. It happens. But I just can't imagine something, at this stages of development, that would worth this price. In a way or another, since I don't have word of anyone denying or confirming what was said by JPLRepo, it's my understanding that it's RW best interest to keep people thinking this way and, really, this is the only thing I can be sure right now.

There's also Orbiter-Forum. Worst case scenario, we can invade their beach*. The whole problem is that Discord is being used for something it is not, a Content Management System. A Forum is, essentially, a CMS that promotes interaction between the readers. Discord, at best, is a Instant Messenger with extra features where you end up getting the worst of all worlds. Here in Brazil, the trend is WhatsApp - I'm part of a lot of retro-computer enthusiasts groups. Initially, we used to gather together using mailing lists (damn you, Yahoo!, for killing the YahooGroups!), but then Facebook came and literally killed all of them. Now, Facebook have some advantages, and as a CMS, its Groups is not that bad (nowadays) - it can even be good sometimes. But due political issues, most people on the retro scene (a good fraction of them old farts like me) got fed up with how some things are run there, and decided to gather on WhatsApp instead. TL;DR: the Brazilian retro-computing Scene is dying on Dementia. All the huge content we used to rely on YahooGroups was essentially lost, near 40 years of invaluable content, some of them created by people that made history and aren't with us anymore, lost in the local mailbox backups of some diehards like me. A very small part of that content migrated to Facebook, but now this content is locked inside a walled garden, and if Facebook goes kaput, we will lose it too. And anything posted on WhatsApp is lost in days to never be reached again - and I kindly ignoring the privacy problem. At least, Discord allows you some privacy - as long you don't use it in your mobile, neither register your phone number on it. At least until the company behind it doesn't goes bankruptcy - the word I have is that they are not financial healthy (they never got profitable anyway). On the long run, I think people will end up learning (being by love , being by pain, everybody ends up learning what's right). But until there, I'm afraid the current generation will be on the receiving end of the "Information Highway".

Humm.... So your problem should be something else, and my initial guess was wrong. Or perhaps not! Anyway, your rig ran for more time this time, you managed to start a flight: [LOG 08:02:03.295] [HighLogic]: =========================== Scene Change : From FLIGHT to FLIGHT ===================== and the rig worked for about 20 minutes, this is the last entry in your KSP.log: [LOG 08:23:54.874] [FlightGlobals]: Active Vessel is in atmosphere. Cannot save. Again, instakill. Nothing more is logged on KSP.log, the mono runtime just ceased to exists. Problem... The Player.log couldn't dump the stack!! ========== OUTPUTTING STACK TRACE ================== RtlLookupFunctionEntry returned NULL function. Aborting stack walk. <Missing stacktrace information> ========== END OF STACKTRACE =========== This was a first. But the error.log brought some light to this mess: Unknown caused an Access Violation (0xc0000005) in module Unknown at 0033:00000000. <yada yada yada> Write to location 0000028B00000000 caused an access violation. Context: RDI: 0x0000028e1c482540 RSI: 0x0000028c6e650000 RAX: 0x000000f7233ac2b0 RBX: 0x0000028e18269c60 RCX: 0x0000000043131100 RDX: 0x000000f7233abf60 RIP: 0x0000028b00000000 RBP: 0x000000f7233ac450 SegCs: 0x000000f700000033 EFlags: 0x0000000000010206 RSP: 0x000000f7233ac210 SegSs: 0x000000f70000002b R8: 0x0000028c59ed2000 R9: 0x0000028c6e650000 R10: 0x000000f7233abf70 R11: 0x0000028c6ba57bc0 R12: 0x0000000000000000 R13: 0x00000000ffffffff R14: 0x0000000000000001 R15: 0x0000028f43131100 <yada yada yada> Stack Trace of Crashed Thread 19276: ERROR: SymGetSymFromAddr64, GetLastError: 'The specified module could not be found.' (Address: 0000028B00000000) ERROR: SymGetModuleInfo64, GetLastError: 'A dynamic link library (DLL) initialization routine failed.' (Address: 0000028B00000000) 0x0000028B00000000 ((<unknown>)) (function-name not available) ERROR: SymGetSymFromAddr64, GetLastError: 'The specified module could not be found.' (Address: 000000F7233AC220) ERROR: SymGetModuleInfo64, GetLastError: 'A dynamic link library (DLL) initialization routine failed.' (Address: 000000F7233AC220) 0x000000F7233AC220 ((<unknown>)) (function-name not available) 0x0000028C4E202B5B (UnityEngine.CoreModule) UnityEngine.Mathf.Lerp() 0x0000028B685C97EA (ModularFlightIntegrator) ModularFI.ModularFlightIntegrator.UpdateAerodynamics() This is somewhat stunning because.... how in hell the game crashed trying to load a DLL after 20 minutes of gameplay? Anyway... I don't know if ModularFlightIntegrator is the screaming victim or the perpretator, but it's involved for sure. Additionally, there's this thing: Module 1 C:\Windows\SYSTEM32\xinput1_3.dll Image Base: 0x00400000 Image Size: 0x0001e000 File Size: 107368 File Time: 2007-04-04_215422 Version: Company: Microsoft Corporation Product: Microsoft® DirectX for Windows® FileDesc: Microsoft Common Controller API FileVer: 9.18.944.0 ProdVer: 9.18.944.0 And this DLL signature is the exact one that screwed @JoE Smash's life (I'm pretty sure you had read it already), and this is what solved his problem: I suggest to rename the Plugin's one to xinput1_3.dll_org instead of removing it, so you can easily undo the change if things don't get better. If things don't improve by trying the DLL stunt, undo the changes and remove ModularFlightIntegrator (and anything that depends from it) to see what happens. If removing the MFI your rig is fine again, then we will need to buy a bigger shovel before digging (I found someone telling that it may be related to locked inputs?), as I found a lot of complains about crashes involving it. === == = POST EDIT = == === Just to err to the safe side, I checked the MFI version you have installed, and it's the latest: ModularFlightIntegrator v1.0.0.0 / v1.2.10.0 Checking the code, I found that this 1.2.10 version solved a problem related to Principia and FAR: https://github.com/sarbian/ModularFlightIntegrator/commit/03f07cd6e498ed003f84ee97ce976430e6447256 And you have FAR installed: FerramAerospaceResearch v0.16.1.2 And I think it's exactly this one: https://github.com/dkavolis/Ferram-Aerospace-Research/releases/tag/v0.16.1.2_Marangoni Make a copy of your entire rig, and on the copy remove FAR and see what happens. Chances are that we have a regression between FAR and MFI...

I checked the Singularity code, and I think that now I know what's happening; the singularity add'on only draws an event horizon (or a worm hole) to an existent Celestial Body directly "on the canvas", it's a visual "only" code without any kind of physics interaction. What's happening to you is the effective Celestial Body used to "hook" the black hole is "tiny", way smaller than the event horizon and the accretion disks. And since these visuals are merely... visuals... without any effect on the Celestial Body itself, DOE keeps doing its business looking only into the Celestial Body, unaware of any event horizon or wormhole being drawn around it. I suppose that I can write a "plugin" (like it was done for Kopernicus) to allow the Flare drawing code to hide the flare if it's behind a "imaginary" sphere centered on the Celestial Body itself, and so "pervert" the game engine to accomplish the occlusion without trying to do the hard lifting myself using math. I will give this some thoughts in the next weeks. https://github.com/net-lisias-ksp/DistantObject/issues/52

ANNOUNCE Release 2.4.8.8 is available for downloading, with the following changes: Fixes (AGAIN) a regression on handling attachment nodes, thanks Kraken affecting only KSP 1.4.3 (and almost surely 1.4.0 to 1.4.2, but I didn't bored to check). Special attention and caring were taken to do not change anything on support for any other KSP. Finally fixes an embarrassing bug that where doubles were being squashed to floats. I do not expect any change the default scalings, but people using some dramatic customisations on really big and really small exponents should see some improvements. Removes some (TS unrelated) sanity checks when a CKAN managed installment is detected TweakScale is, from now on, blindly trusting CKAN on keeping the running environment sane, only yelling when it's directly affected. Updates KSPe.Light.TweakScale to 2.5.4.5 Reworks Issues: #307 Attachment Points are not being scaled (or being reset) after changing the Variant. I'm playing KSP 1.4.3 just for the lulz, but - as usual - I found something "interesting"... I detected that Issue 307 somehow caused a regression. But only on 1.4.3 (not complaining, but... What the heck?). This release fixes that. Additionally, when TS is installed from a CKAN downloaded package, and it detects CKAN, it does not checks the KSP runtime environment anymore. From now on, TS will blindly trust CKAN about the sanity of the installation, complaining if and only if something that it's definitively going to hurt TweakScale is detected. This behaviour is easily tweakable, just edit GameData/TweakScale/TweakScale.cfg to activate or deactivate the "readiness" of the installment - the rest of the package is, literally, the same for manual installers, CurseForge and SpaceDock packagings. And we are not dead yet. Scale safe!!! (and keep launching) Known Issues There's a long standing issue on TweakScale™ about scaling ModuleEnginesFX's plumes - some engines' plumes is just not scaled, while others scaled pretty badly. It's something that never worked right on TweakScale™, and it will only be really fixed on TweakScale™ 2.5 (when this thing goes gold) The best workaround (and also the reason I'm dragging my feet on this) is to use SmokeScreen or Waterfall. For SmokeScreen, you need: SmokeScreen itself. Real Plumes (to enable SmokeScreen on Stock parts) Additional Part Sets and Add'Ons may need specialised support not included on Real Plumes. For Waterfall, you need: Waterfall itself. StockWaterfallEffects (to enable SmokeScreen on Stock parts) Additional Part Sets and Add'Ons may need specialised support not included on StockWaterfallEffects. See Issue #27 Disclaimer By last, but not the least... This Release will be published using the following Schedule: GitHub, reaching first manual installers and users of KSP-AVC. Right now. CurseForge. Eventually. SpaceDock. Sometime after CurseForge. Unless someone besides me still plays on KSP 1.4.3, no one really needs this release. So I will take my time on pushing this to the upstream so I can evaluate some runtime checkings being withdrawn when installed under CKAN.

I don't have a clue if the Chinese will manage to pull this one, but... Impressive. It's a copy of the X-37, but at the same time, isn't. Completely different roles. I really think USA should seriously rethink the way they are planning the current and future LEO missions... They may be the ones creating new technologies, but they are risking getting behind on making them profitable. It's about the money. It's always about the money! For comparison:

Hummm... So this is the problem? I had though the the problem is the flare being drawn on the black hole itself, what's obviously.wrong. The planet behind the black hole is being flared because DOE is not being able to determine it's cloacked from the current point of view. I need to check how singularity works. Ok, this is officially a change request. I will come back to you by night with whatever I found. Don't hold your breath, however, I have some duties already on the pipeline for today. https://github.com/net-lisias-ksp/DistantObject/issues/52

If this is the target audience of the game, then I suggest to brace for impact - the reality is that the content creators will get fed up pretty quickly and leave. Physicists and Engineers have better things to do with their life than repeating ad nauseaum the same information in a "public square" in hopes of being heard. Imagine Einstein trying to explain Relativity on Time Square yelling to the public, competing with guys yelling about how the End of the World is coming. Same thing. This Forum was key for the success of the Franchise by the same reason Books and Periodics were the key for the success of Science itself. You don't do Science on the mess of a Public Square.

Humm... so the feature is working. What I think it's happening I'd that you are not being able to determine correctly the celestialBodyName of the singularity. I will give this a try by night and come back to you.

I'm not being able to find the post, but someone (I forgot who) told us that someone that had worked on KSP2 and now on KSA (but I'm not sure if my memory is working, so I prefer not to nominate him) said on Twitter or Reddit that they had no relation with the KSP buyout. I managed to find this, however: Where Kerbart said something about. The "Not my circus, not my monkeys" is related to that post that I'm not finding where the information was posted. I'm still looking on it, I will edit this post when I find it. ======== POST EDIT Found it! It was JplRepo and it was on Discord! (Well, whatever I have, it's not dementia... )

Destiny Calls, from The Rinn. Discovered them this week, listening to Jamendo webradio on VLC. Classic, competent Melodic Metal, played with competency. Not something "revolutionary", but pretty good. === BONUS TRACK ===

Agreed. But, yet, the consequences would be vastly less deadly then otherwise. I was a urbane cyclist about a decade ago in Sao Paulo, way before the bike lanes were implemented around here. And let me tell you something, I had seen some really near misses right on front of me - like when once a bus pushed a woman into the sidewalk making her to fall pretty nastily. She got hurt, and one of the guys that were cycling with her pursued the maniac, and was almost killed too because the bus driver tried to push him the same, but into the faster lane on the street. Had anyone be driving behind them, the cyclist would be dead. Problem: the bus had to stop on a red signal and... Boy... I will let what happened after to the reader's imagination. Then the bike lanes were created, and everything would be fixed, right? (sigh). Nope. Now motorcycles speed up on the bike lines unchecked, and even some small cars do it sometimes. It's literally safer to bike on the slow lane, but not so safe as on the sidewalk because now and then some maniac like that bus driver I mentioned above shows up. Me? I stopped biking. I'm not suicidal.

Higher than we would like, but not a sure thing neither. Tencent was, in theory, ruled out because the RocketWerks guys openly said they are not working with the KSP IP, and since Tencent is one of the RW funders, it would be expected that if Tencent had bought PD, they would be the ones to receive KSP rights to work with. But there's also Embracer, and even Microsoft was mentioned on a point (they bought Minecraft, after all). In a way or another, all the possible educated guesses based on the currently available data apparently are already on the table, I think we need some more (verifiable) news from this point. Being absolutely frank about, anything, absolutely anything can happen at this point. Including nothing.

Not exactly a bug, DOE is doing what it's meant to do - Name Celestial Bodies. Apparently Singularity is kinda (ab)using the CelestialBody concept to do something else and, so, fools DOE. Try this patch to see if it solves this glitch: @DistantObject:FINAL { @DistantFlare { @CelestialBody { @ExclusionList { name = <name of the celestial body you want to do not flare on Singularity) } } } This should prevent DOE from flaring it.

But, yet, only one of them was profitable. Ironically enough, exactly the capitalist one is going south in a way we didn't see since the collapse of the USSR. Something to think about.

Hi. Without the KSP.log (and if you are getting a Crash To Desktop - CTD - the Player.log) there's pretty little about what can do! Publish these files on dropbox or something.

Deactivating temporarily http/2 and serving only 1.1 would not be a viable workaround? Long time ago, Safari was the one getting some heat due http2 and they worked around the problem by deactivating http2 on nginx.

The luck was mutual. HarverteR was willing to quit and pursue the project somewhere else. Without Squad, it's uncertain if he could manage to gather traction for the project - a Marketing company is good on... Marketing, and without good marketing professionals, this project probably would not had the visibility it needed. Without HarvesteR, Squad would not had the chance to score a big hit, that so could be used to leverage the company. They may had pulled themselves out of the game business, but make no mistake: Squad, the Marketing Company, is bigger that they would be without KSP.

Hummm... You know, it may be a routing problem, indeed. I just got bitten by a CloudFlare 1015 error message ("You are being restricted") clicking the Reload Page while getting the NGINX error message. Interesting enough, I never got the 1015 while clicking Reload on that white blank page that I get sometimes. This may suggest we have more then one problem biting our collective arses: The blank page, that by some reason is not being counted on the hits per minute cap (that fires up a 1015 in our faces) A NGINX 500 message, that are being counted on the cap. Wild guess, but... Are the Forum's server currently under a rotating IP scheme or something like that? The server rotating IP before warning CloudFlare may be the white blank page explanation (if CF could not hit the target server, it would not count it on the cap), while if the CloaudFlare is warned about the new IP before the new frontend is ready, CF would get the NGINX error message and, so, will consider it a successful hit and count the access into the cap. You know... This may be a configuration problem on the Docker or LXC or whatever is being used as a container nowadays.

Well, I'm unsure if I understood the term "beholden". I think it would be unwise for TTWO to bring to themselves the burden of over watching NDA's for things they had sold, and AFAIK it's not worldwide enforceable to silently transfer NDAs to new parties - exactly to prevent you from being surprised by a NDA lawsuit from someone you never heard of. When Siemens Mobile was sold to BenQ, I had already signed a NDA to my boss (were were a contractor), and my boss signed the new NDAs to BenQ - so, I never had the chance to say "nope" to see what happens. And later, when Siemens VDO was sold to Continental (karma!!!) I was, again, working as a contractor and so my boss signed the new NDA's and I was still bounded to my to him. What I don't know what would happen is, for example, a VDO employee quitting before Continental buying them. For what I understand, that employee could not had their NDA automatically transferred to Continental without signing in accordance, and I don't have the slightest idea what would happen if the dude just plain refuse it. And, well, there're people working for them on all the World, right? Different countries, different legislation, different rights. Given some pretty nasty consequences of that huge amount of unemployed developers lingering around, I think this is going to take a bit. I expect a lot of nasty new legislation being pushed ahead by exactly these "publicly traded companies beholden to shareholders" (again, what I should understand for "beholden"?) to protect their turf from them.

I'm getting back to my senses and, so, the Kerbal that lives in me decided it's time to salute the Kerbal that lives you. The premise is simple: what we can do about with this Dream Chase alike thingy to attend the (currently planned) Mün Station in the most cost/effective (and safe because... Tourism!) way possible? Well, looking again into the inspiring project I found the Shooting Star attachable service bay! Couldn't be more Kerbal! First things first: an attachable, disposable service bay to allow the LKO Shuttle to reach the Mün, rendezvous with a Station and go back - ideally without refueling, as fuel would be a very expensive resource there until I manage to establish a ore refinery on Mün. And I came to this, it was pretty straightforward to tell the true: Not bad, and costing only 26,109F (with consumables, only 2,185F more than LKO) and (assuming landing on KCS with fully depleted consumables), 25,292F on recovery. And I won't even need to ditch the service bay, with a bit of fuel on the nose, she managed to land with it attached! Problem. Besides being able to reach and dock to the (planed) Mün Station and getting back, there's no hope for a circularisation on LKO before a reentry, and you will need to rely on aero-braking for that, i.e., kiss sweet tourists money bye-bye on this configuration, the KSC Tourism Department will never approve such maneuvre with civilians aboard. So Tourism will demand in-situ refuelling, what may reveal itself too much expensive until I manage to establish a Münar ore refinery - but, until there, at least I will be able to cheaply rotate crew there. Or not... Boy, I got screwed by this one. I tried to reuse the LKO Launcher that, besides tricky to fly, worked. But couldn't - no matter what I do, the damned thing always ended up needing: Moar trust; Moar boosters, but then the thing loses control due that damned Shuttle's wings and I have to throttle down the engines, increasing the fuel consuption due the gravity toll; Moar engines, but then I need even moar fuel; Moar trust again, or she will not leave the ground; Rinse, repeat, get MOAR screwed again. Apparently I managed to hit a very finickle and unstable sweet spot for the Orbital Crew Vehicle, and utterly failed to find another one for the Münar variant. Getting fed up of processes and cyber-safety and compliance and what else (don't ask!! ), I concluded that it was time to let Jebediah Kerman meddle into the R&D facilities to let him give to the engineering team his insights about the problem: to pursue the possibility of making my LKO Crew Shuttle reach the (planed) Mün Station and get back - in a cost/effective and safe way. Of the most it can be done when Jeb is involved... What could possibly go wrong, right? And then Jeb saw this on Youtube (Kistler Fully Reusable Launch Vehicle): And then Jeb did this on R&D: And... The damned thing works. However, as it's usual On the Kerbal Way™, the price tag is a bit eye watering, 70,138F, giving us a cost per seat of (70,138F - 25,292F) / 6 = ~7,474.34F . Ok, still less than the cost per seat from the SkyLab Crew Rotation Vehicle, but yet... Full details and craft downloads here.

Kistler 1, a Fully Reusable Launch Vehicle. That enjoys trampolines. It was supposed to be a Space-X competitor. Apparently, landing huge rockets on chopsticks isn't the wildest of the ideas after all...

You have a asymmetric CPU (that E-Core & P-Core) thingies. KSP (as a matter of fact, I think it's a Unity borkage) have problems while running os these CPUs, as something inside it assumes that all threads perform the same and in your CPU, code running in E-Cores will perform slower than when running on P-Cores - it's a Russian Roulette, sooner or later something important will be run on a E-core while something else needing it will run on a P-Core. Chech how to configure Affinity in your rig and tell Windows to use only E-Cores when running KSP. I think this will solve your problem.