Lisias

"We didn't checked our staging…" — POST EDIT -- Already said. I did a search for "stag" on this thread before posting, but the new posts weren't indexed on the search engine as it appears…

I second that. And there's the Science Mode for people not willing to deal with money, and this model worked fine IMHO. It's not a mutually exclusive choice, you can have both playing paradigms on the same game - KSP¹ did it at least.

Convair Model 49. Really, these guys were the precursor of the Kerbal Space Program - they would love this game, no doubt!!!

Hi, TweakScale maintainer here. There're some reasons for TweakScale not being ported right now to KSP2, but the main ones are: TweakScale mangles pretty heavily with the code (by using Reflection) and with the Meshes, IVAs et all. I'm serious, TweakScale can do a lot of damage, and it should not be lightly ported to a new platform without understanding how the new platform works internally, well beyound an hastily published API. Do you think the wobbling in KSP2 is bad? Just try to imagine them being scaled by TweakScale… Exponentially! TweakScale really mangles heavily the part's definition, and there's no support for that yet on KSP2 AFAIK. Damn, even the Mod Loader was hacked by 3rd parties, no one have the slightest idea on how Mods will be loaded on the final KSP version. Doing anything now will risk throwing away a lot of development efforts, that right now is being better used on improving TweakScale itself, what will allow us to have a better TweakScale tomorrow for KSP2 too. There're some legal constraints in the legislation I live in (and, to tell you the true, the citizens of a few other countries too) that may harm me, unless we have formal permission from PD or IG. Extracting and API by Reflection and publishing it without permission is not allowed on some Countries (like mine), and until the KSP2 API is published by the owners (as the KSP¹ is nowadays), it will not be wise for me doing anything on KSP2 yet. I'm not playing KSP myself, the thing doesn't run on any machine I own presently, so even if all the reasons above would not exist, there's still the hardware problem to tackle down.

Don't bother. I'm revamping the Companion for Aircrafts, and the original NeistAir were reworked, and I also added your parts. As a hint for the reason I'm doing it, I'm going to change some things on TweakScale that **mostly probably** will break legacy patches, and with the most important (at least by me.. ) part sets under the Companion Program, such revamping will be a breeze for me. But if you are in a hurry, check this: https://github.com/TweakScale/Companion_AirCrafts/tree/dev/GameData/TweakScaleCompanion/AirCrafts/NAP/patches (i don't remember if I already included yours, but I will double check it tonight to be sure - if by morning you don't thing your parts there, kick me in a PVT message and I will do it! ) As long the patches are used by you, I don't mind you going ahead and incorporating your patches on the add'on if you prefer - I kindly ask you to avoid using "FINAL", so when the new TweakScale rules kicks in, the Companion will be able to rework the patches without breakage! Cheers! — — POST EDIT — — yeah, I already did the patches! https://github.com/TweakScale/Companion_AirCrafts/issues/3

It's By Design. The files on [KSPBASE]/GameData/DistantObject/PluginData/Settings.cfg, are default values and should not be editable by user. I define the default values based on Support issues, and I set these values in a way to minimise them. The values on [KSPBASE]/PluginData/DistantObject/Settings.cfg are settings global to the game (i.e., not respective to a given savegame) and to computer (performance - these settings should not be moved to a different machine where performance may be different), and this file is where the User Settings for DOE are saved. When not present, a new one is created using the former one as template. I changed these values, saved (clicking Apply), quit KSP, restarted KSP, and reloaded the SaveGame, and the user Settings were not reset as you described. I Opened and Closed the Settings Dialog many times, restarted KSP, the Settings file was not reset in any way. However… You would not had the trouble to report this just because, you are pretty accurate on describing the results - so I guessed that your report of how to reproduce the problem can be the problem. And then I realised that the mentioned Dialog's widges, when you open the Dialog by the first time on a game session, were in effect loaded with the default values - but since I was not clicking on the Apply button, these values were not being written on the file. So, yeah, you found something but instead of describing on how to reproduce the misbehaviour, you tried to diagnose the problem in the blind, and reported what you thought was the problem instead of describing accurately how to reproduce it, what would helped me to diagnose the problem sooner - not to mention that I almost dismissed your report as "Invalid". I will work on it today (probably at night). This is, indeed, a very annoying bug because you will reset these values every time you decide to change something completely unrelated. https://github.com/net-lisias-ksp/DistantObject/issues/38

Removed some duplicates. Added or updated: AAW Arc Aerospace's Wyvern (*) FSX Firespitter Extended (*) HT Benjee’s HabTech (*) HT2 Benjee’s HabTech 2 (*) IR/N Infernal Robotics/Next (*) LBPP Large Boat Parts Pack (*) MPR Moderately Plane Related (*) MRS Modular Rocket Systems MSRC Mini Sample Return Capsule NAP Neist Airliner Parts PHP Porkjet’s Habitat Pack (*) RE Real Engines RS+ Restock+ (==) RSP Restock+ (==) SMCE Spanner Monkey SMM SM Marine (*) TIRP Tokamak Industries Refurbished Parts (*) UDKLD UDK Large Structural Components US Universal Storage (==) US1 Universal Storage (==) US2 Universal Storage II (==) USII Universal Storage II (==) New Symbols. Links to the TSCo where this data is being tracked and versioned.

Since I like the cartoonish look & fell of KSP¹ (seriously - but I would like to see clouds and weather on it, matching the current look & fell), obviously my opinions about KSP2 should be taken with a grain of salt. I kinda like it, but I would prefer it being more cartoonish in general - I don't want photorealistic green critters being blown up in terrible crashes in a photorealistic way. I want to screw up things without getting my subconscious peskying me with guilty because the consequences of my mistakes are too real from what I would get on Real Life© . Additionally, there's also the Uncanny Valley theory, that says "humans prefer anthropomorphic agents, but reject them if they become too human-like." Things start to get realistic, our brain start to reject what we see because our brain stops to perceive it as something similar to people and instead perceives them as perverted version of a person. Once the thing improves to be near perfect, our brain stops rejecting it. Same happens to 'reality' - we go along pretty fine with simulacra that resembles a bit the reality, but if the thing gets too near the reality (but without being perfect enough), the rejection kicks in until the thing reaches the next level of perfection. All that impressive photorealistic mods for KSP¹are impressive per se, but as we stack them together the rest of the game, we start to fell unrest about - and I think this is what @K33Nwas meamin on this post: So, in a sense, KSP2 "not so great" visuals are more adequate to the game - as long some excess are removed (as I said, I really enjoy the KSP¹ cartoonish look & fell).

When I was younger and stupid (now I'm older), I got my dirty pawns on a jet-ski, on a remote location upstream Manaus. Oh, great, beyond the arms of the law! I could have some really fun, right? So a big boat passed around upstream, right on the center of the Rio Negro (where the stream was stronger) making a hell of a ripple on the water. And I though to myself "it's now or never, let's do some jumps!". And, boy, that damned jet ski could be a old yamaha, but it jumped good - I don't have the slightest idea of how high I jumped, but everything that goes up, goes down and down I gone. At least I didn't broke anything (not the jetski neither my legs), but it hurt a lot - couldn't have a seat for days! Do you know when I ever did that stunt again? In the next day (told ya, stupid…), but with a sensible less acceleration this time - I settled with a meter or two as "fun enough".

I, obviously, disagree.

Well, this is (more or less) my take:

Without a description of the problem, it's usually hard to diagnose something. But you got luck this time, the problem is pretty obvious and a old "friend": [ERR 23:19:04.786] AssemblyLoader: Exception loading 'ScrapYard_ContractConfigurator': System.Reflection.ReflectionTypeLoadException: Exception of typ at (wrapper managed-to-native) System.Reflection.Assembly.GetTypes(System.Reflection.Assembly,bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <9577ac7a62ef43179789031239ba8798>:0 at AssemblyLoader.LoadAssemblies () [0x000e6] in <4b449f2841f84227adfaad3149c8fdba>:0 Additional information about this exception: System.IO.FileNotFoundException: Could not load file or assembly 'ContractConfigurator, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one File name: 'ContractConfigurator, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' System.IO.FileNotFoundException: Could not load file or assembly 'ContractConfigurator, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one File name: 'ContractConfigurator, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' There's a DLL on ScrapYard that needs Contract Configurator (surprisingly the DLL is called ScrapYard_ContractConfigurator). Buy you don't have Contract Configurator installed, and so this situation triggered a nasty and insidious bug on KSP on a thingy called "Assembly Loader/Resolver" (just the thing that we need in order to have our DLLs loaded and made its Assembly assessible…). From this point, everything else that needs to load a DLL or needs to use a thing called "Reflection" start to bork relentlessly, and TweakScale and the Companions make heavy use of that. You have two options to solve this problem: Install Contract Configurator Manually delete the file D:\Steam\steamapps\common\Kerbal Space Program\GameData\ScrapYard\Plugins\ScrapYard_ContractConfigurator.dll from your game. By doing any of these, you will get your rig fixed. Cheers! P.S.: In time, this is a problem on CKAN, not TweakScale. I could help you this time because I have some free time now in the morning, but when I'm busy, I will prioritise TweakScale issues by obvious reasons. [LOG 23:19:22.047] [KSPe.Light.TweakScale] Version 2.5.2.0 /L for TweakScale. **UNSUPPORTED** due CKAN [LOG 23:19:22.079] [TweakScale] Version 2.4.7.3 /L As a rule of thumb, if the thing was working, then you ran CKAN, and it stopped working, it's a CKAN issue, and you should ask for help on CKAN thread as there's something obviously wrong on CKAN or in its database (as they are installing things without the needed dependencies, breaking the game due that Assembly Loader/Resolver crap).

Swimming to Otoh Gunga, from the Star Wars Phantom Menace OST. (it's on the video credits, by the way!!! )

Yep, that's the point. The best people for the job tend to avoid such controversial practices. There's a reason Open Source licensed material usually survives the challenge of time (Doom, Quake, etc - but there's also the underdogs, like Abuse.* Interesting, decided to compile it and plat a bit, it's 10 years since the last time I did it...) while commercial, closed source material usually goes to abandonware sites - if much. But since we don't know what's happening on T2, we have essentially two choices: 1: Doing nothing, and just wait for the better. Frankly, we are a bunch of add'on Authors. Sitting on our hands and waiting for someone else doing the job is not exactly on our D.N.A. 2: Keep pushing the campaign. If T2 will not ever release the Source, there's really nothing to loose by keeping doing it. Add'On authoring is already a lost fund undertaking for the most part, so why worry? It's just the same thing, but using a browser instead of an IDE. If T2 is considering the release of the Source, what damages talking about will cause? At very least will help to stuff some reports on the meetings. Additionally, people came and go on companies. The one that would be blocking the idea now someday will be promoted (or fired), and their replacement may be more inclined to consider the idea - but only if aware of the idea. How to make any potential future decision maker (currently not on the loop) aware of the idea? By pushing it ahead, as we are doing here. In a way or another: Not talking about do no damages, but do no good neither. Talking about do no damages, but there's a chance that it would do some good. The choice about what to do is logical. — — POST EDIT — — * And the thing still works. Wanna play Abuse on a modern Computer? Download 0.8 from http://abuse.zoy.org/wiki/download Download the Source tarball from https://github.com/Xenoveritas/abuse/releases Rename <dir>/macos to <dir>/macOS if you are on MacOS with case sensitive file system. Follow the instructions on the BUILDING.md

Yeah, I should had given some context. I received this one on Telegram, I think, and so I didn't had a URL to share. The history is that instead of pulling a lever to lower the stairs, the crew (by mistake) ended up pulling the one that releases the tail's bonnet. The message didn't mentioned the aircraft model neither the function of that bonnet - perhaps maintenance? But it would be also the alternate exit as you mentioned too. Or both.

There's something else that we need to consider: Epic more or less at the same time did a huge giveaway for the KSP base game - essentially for free. So, even by being true that Steam players are getting bored on KSP (and this is true), we don't know how many new KSP players are still playing it after getting it for free from Epic. On the grand perspective, usually this doesn't matter so much because Steam still have about 70% of all the Market Share (or at least it had last time I heard about), but once we start to get into niche games like KSP, when a few hundreds players make a difference, then we can't be too much sure about the matter by only looking on Steam. There's still a trend happening, and Steam is one of the tools we can use to proper infer it - but always with a grain of salt. There's also that tragicomical PD Launcher - I bet that a lot of KSP users choose to ditch Steam Launcher and started to fire up KSP directly just to get rid of that crap.

Humm… interesting. Let me explain a bit what I think it's happening: Unity uses a layered model for the screen. It's like having many different screens being painted separately, and then someone stacks them one over the other, sorted by priority, before sending the thing into the framebuffer where the bits will be converted into a frame that it's sent to the Monitor. Conceptually, it's not different from this: Well, by analysing the code's history log, I concluded that the layer used by painting the flares were decided kinda by trial and error in order to avoid screwing up 3rd parties, at the same time it tried to avoid being screwed by them. This is the reason I didn't managed to hide the flares behind atmospheres - the atmosphere of a planet is on the lowest plane, with the planet being drawn on a layer above the atmosphere's one. I just didn't managed to move the flares to a lower plane without making them plain vanish at all from the scene - I suspect that I inadvertently moved the flares to a plane behind the skybox (or exactly in the skybox's plane, with my flares being painted first, and then the skybox just overwriting the flares on painting). Parallax, apparently, may be drawing things on the same plane DOE is using to draw the flares because by some reason the trick you did induced the flares to be shown again. Apparently Parallax doesn't need to re setup its things on every scene change, and so DOE gets a chance to draw it's flares again after a scene change. The problem I have now is to find time to dig into Parallax code in order to understand what it is doing and where, so I can think on a way to work around it. Your hint about restoring DOE's flares on scene change surely will help me on such work around, if not on a proper fix - perhaps DOE is the one doing things weirdly after all, perhaps Parallax is the one doing things right and I'm on its way. In a way or another, I will need some time to dig on the Parallax code to understand it. Cheers!

Of course I can't, I'm a skilled Software Developer, not a fortune teller by Kraken's sake! I will not risk my name and my career on shady practices, not matter how much I like this freaking game - this is the only thing I can say for sure about the future. But the Source will flow in a way or another - it only happens that depending on how it will happen (or it's happening), I will not be involved. As a matter of fact, this is already happening, you know? But Forum rules prevents such discussion here - perhaps you should dig a bit on Reddit?

Gladly. You may not be fully aware, but KSP¹ has an awful lot of bugs. People are touting KSP¹ because KSP2 right now is even worse - KSP¹ at least is working more or less fine for the majority of the users. For now. But the landscape is changing, and it's changing a lot. For starters, as people start to buy that new "hybrid" CPUs (and AMD is following suit on this), weird bugs are starting to raise due some really, really stupid decisions made in the past (not only on KSP¹, but also on Unity - things are really going to get that ugly). Things are going to go South pretty fast in the next months as these new CPUs are getting cheaper and more people start to use them on KSP¹. Not being bad enough, we have now another GPU problem. By some reason that caught even me with my pants down, old GPUs are coming back on Steam, see the GTX 1660 - not exactly a decent GPU for serious gaming nowadays - got a 1.86% increase on the Steam user base, by the numbers of the last Steam Survey. This thing doesn't have even 8GB VRAM, it have a relatively puny (by nowadays standards) 6GB VRAM - hell, I have reports of 6GB VRAM users getting screwed by that tragedy called P.D. Launcher when used on a modestly modded KSP¹ rig. But yet, it's the GPU that most earned "market share" on June, being Steam Deck (another not exactly top notch GPU powerhouse) coming in second. There must be a reason NVidia decided to cancel pressing wafers for the 4090 line, right? Do a quick research on the threads I had created in the last 3 or 4 years, and you will find me complaining about threads, memory and VRAM for some time already - KSP's memory footprint had grown together the backlog, adding insult to the injury. KSP¹ have almost 8 years of a pretty heavy backlog of bugs badly handled or just ignored, and the only two add'ons I'm aware that are trying to minimize the damages are no enough: One, in an excess of optimism, is making lots os changes on the game guts - without being fully aware of unintended consequences (and almost surely aggravating the crisis I described above). Other, in an abundance of caution, just can't do the needed white box testings fast enough - besides being able to diagnose some pretty interesting bugs nevertheless. One of them plaguing users since KSP 1.2.2, and it's not impossible it's the root cause of a lot of gambiarras made as time gone by and that ended up creating a log of grief due the colateral effects. The list of technical debits are only growing since the first Big Unity Change on KSP 1.4.0 (from Unity 5 to 2017), and the situation didn't improved too much on the second one on KSP 1.8.0 (from Unity 2017 to 2019). The rollercoaster is starting to go down from this point, I fear things will start to happen pretty fast sooner than later. In the mean time, KSP¹ still have a lot of highly skilled enthusiasts around, even people working on space agencies around the World (not to mention a lot of technically skilled and field experienced professionals, as yours truly). But there's a catch - professionals can't risk being caught dealing with shady practices. Hell, NASA's trainees can't swore in public (more details here) damnit, what to say a software engineer being caught with something that is being called Piracy around here? Right now, and unless someone else step up with a better idea, Releasing the Source Code (even in a shared source style license) is the best way to give KSP¹ a better chance to pass trough the hurricane that is approaching - from the technical, political, public relations and legal point of view. Assuming, of course, that there's still people enough around willing to contribute as Pro Bono (because it's pretty unlikely that such people will do Charity Work for any profit pursuing Company, what to say to a hugely funded one). The Source NEED to flow.

An elegante song, from more civilised times. Deceiver of Fools, Within Temptation. It's interesting hot History repeats itself.

I'm not surprised.

Their loss.

The source was already "released", the Genie is out of the Bottle. There're already bootleg copies around, probably made by some practices that I'm not allowed to mention on this Forum. All you need is the right contacts, or the will to redo the job yourself - and a complete disregard for the Forum and Squad. The only ones with the hands tied are people like me, willing to stick with the good Side of the Force.

Wheels. KSP physics style - and, yeah, surprisingly similar!