Lisias

Interesting… At first, I though I had forgot to check the viable zone of the craft before drawing it, but I just confirmed on the source that I'm checking it, I'm checking against Vessel.load before attempt to draw it. So my best guess to this point is that you found a borderline situation: the craft entered into Physics Range in the exact same moment DOE checked if it was loaded or not, and we got a race condition. (hummmm) Yeah, I think I need to put something on the FixedUpdated handler. One of the speed ups I made was to remove the mesh building phase from the FixedUpdate (as it was before), and besides this handler is called fewer times then Update, it is called from the hottest code on the Game, the Physics Engine. But now I realised that there was a reason for using the FixedUpdated. I will need to rework a bit this thing - shoving everything on FixedUpdate is not an option, I will not put render time code on the Physics Engine loop. In the mean time, you can ignore this. Other than spamming the KSP.log now and then, nothing serious happens as the drawing code aborts the execution on this situation. https://github.com/net-lisias-ksp/DistantObject/issues/12

As a matter of fact, I know some people where these would be an improvement….

Oukey. Working on it. (nice avatar, by the way! I'll grab some beers tonight in your honour! ) — — POST EDIT — — @WhatALovelyNickIt's not a conflict with TweakScale, it's exactly the other way around: [ERR 15:55:10.011] AssemblyLoader: Exception loading 'Romfarer': System.Reflection.ReflectionTypeLoadException: Exception of type 'System.Reflection.ReflectionTypeLoadEx 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 <8861f4ca916d41ddac4d879a32ad34b2>:0 Additional information about this exception: System.TypeLoadException: Could not resolve type with token 01000004 (from typeref, class/assembly ImageEffectBase, Assembly-CSharp-firstpass, Version=0.0.0.0, Culture= This is happening because Romfarer.dll was built with a older version of KSP's Assembly-CSharp (or perhaps Unity, but it's pretty unlikely) that have a method or atributte that it's not available anymore on modern KSPs (usually a protected one, as public ones are easily spotted). This is one of the very few situations in which a recompile may help. This is borking on you because from now on TweakScale relies on a custom AssemblyLoader to locate its assets, but this custom AssemblyLoader relies on the health of the Stock AssemblyLoader (I'm not replacing it - sometimes I think I should), that has a bug that once a Assembly fails to load due a Reflection error, everything else will have problems too. With the Romfarer.dll source code I can compile a working copy for you (assuming the license allows), but right now, since this thing is not being loaded anyway, you can delete Romfarer.dll from your GameData. It's just cluttering your installment and triggering misbehavirous on Stock (poorly maintained, sadly) AssemblyLoader. This thing is not working for sure.

The only "Universal True" about Life is this one: "Death and Taxes". I'm managing to avoid the former until this moment, but I never scored on the later...

What's Romfarer.dll? Please give me a link for it, I will give this a peek. (dirty secret: most of my code neither - I only publish what works!!! )

Yep, it's (more or less) the same problem. There's no (apparent) difference form the code point of view between a planet's atmosphere and a star's heliosphere (and sunglare), it's essentially something being drawn before the body it belongs (or over it, as it appears to be the case of the Sun). The atmosphere, for sure, it's not a sphere englobing the planet (as it is on real life), but a circle with a fancy paintjob being drawn before the planet is rendered over it (yeah, KSP is cheating!).

Hi dude, I think your problem is something else: see my previous post: I'm using Airplane+ normally on KSP 1.12 - but I didn't installed the old Firespitter that came embedded on it. Try to remove the GameData/Firespitter on your game and install the latest Firespitter. It worked for me. Alternativelly… Did you tried to use CKAN? It handles this mess for you!

I didn't changed the visual effects itself, but I found some performances improvement opportunities on the code, and explored them. With a bit less of load on the CPU side, perhaps the blinking became slightly "blinkier" perhaps? Humm... I will give this a try - you are running KSP1.12, right? (I need to ask, this thing run down to 1.4.5 at least! ) The only part of the code that could be involved on the mess is the VesselDraw, that needs to keep track of every living vessel in the viable zone (750 km on default). So I hooked into the GameEvents to be aware when a craft is destroyed and when it's changed. What you describes implies on a GameEvents frenzy, with a craft being destroyed and many new ones (the surviving root part and attachments, and the debris) being created. This would surely fire a MeshEngine creation fest if you aren using DrawVessel with anything other than Target Only... But, yet, this was a use case I tested.... Perhaps I need to try a more robust test session.... let's see what happens... — POST EDIT -- I ran a test. TL;DR: nothing obvious on DOE, it may be something else, perhaps being triggered by DOE... Note the debris! --------------------- The problem is that the atmosphere is drawn before all planets, not before its planet. And the flares are drawn after the planets (for obvious reasons). So a simple solution for this is out of question. I'm cooking a stunt to kinda brute force my way into this problem: I will try setting the transparency of the flate as a function of how 'buried' it is on the atmosphere. I would love to raycast my way out of the problem, but I doubt the atmosphere has a collider So I will need to check the radial of the flare related to the camera, check the radial of the atmosphere, and check if they merged. Not sure how smart is this solution, but it's what I managed to think about for now.

It was until recently if you have a Steam account and know your way on the Console. There's a cool tutorial on how to do it on Steam Community called "How to Download Older Versions of a Steam Game", but some images on that page may not be Forum compliant, so you will have to google for it (hint: type "How to Download Older Versions of a Steam Game" site:steamcommunity.com — including the quotes). It's from Mar 25, 2017. However… Things may be changing fast. Since some time, the download_depot protocol is changing no one sure knew why until recently, and the Steam Client is not able to download some depots. On KSP, this meant not being able to download anything below 1.2.2 (not to mention 1.4.3, the best Unity 2017 version for old potatoes that want to play with Mission History - on 1.4.4 the increased PQS cache plays havoc with rigs with 512MB of VRAM or less). Last month the SteamDB guys (the main and most important resource for fetching the hashes for the download_depot) published something about. This link also suggests a very handy tool for doing that, other than the Steam Console and manual hunting for the hashes as I was doing until 1.12.2 (damn… ). Apparently Valve is not going nuclear on the subject, and the new API is meant to prevent unauthorised access to sensitive content (why the userid of the downloader is not checked against an ACL is beyound me), as was published here. I downloaded down to 0.22 from Steam once. Then on last December (if memory serves me well) I realised I could not anymore - but with the information on the links above, I think you will be able to do so.

TweakScake 2.4.6.0 on KSP 1.3.1 Test Case KSC is facing a shortage of parts for new crafts and maintenance of the current ones due the ongoing global supply chain crisis, and the increasing P/R events scheduling the Fab Four to raise funds is pushing the current fleet beyound its safety margins. With Dr von Kerman terribly busy on repurposing available parts to compensate the shortage and Bill away of the Engineering due the preps for the talks, Gene reluctantly charged Jeb with the task to design and built a new small commuting airplane so the First Crew could attend the events without risks. The only constrain was the parts themselves, only the simplest and older parts available on stock could be used as the scarce newer ones are reserved for the Missions - Kraken knows when the current crisis will be solved! "Gene, we have some of these KSP 1.3.x era parts available on the warehouse - they are pretty dated, but they still kick SAS. I can build something cheap and really fast if we could use TweakScale, I heard that Doc Wernher had recently pulled it out of Experimental for 1.3. What do you say?" "Sounds good, Jeb, but the 'really fast' part of the stunt worries me a bit. Please remember this is a commuting vehicle, not an interceptor or fighter!" "Trust me, Gene, I know what I'm doing!", said Jeb grinning from ear to ear, and finished already turning his back and rushing into the Engineering with "What could possibly go wrong?". And then vanished yelling "GUS!!! GUS!! We have some fun ahead!!! Bring the snacks!!!" "Famous last words", sighted Gene. "Kraken help us, Jeb is on the Engineering..." was his thoughts while walking into Mortimer's office to check the insurances... And, so, TweakScale v2.4.6.0 (now being able to run from KSP 1.3.0 to KSP 1.12.2!!!) helped to repurpose old KSP 1.3 parts and make them useful again! And being a craft designed by Jebediah…. Full album on my site. craft on Kerbal-X.

Announce Some Companions were updated! TweakScale Companion for Visuals was rebranded to TweakScale Companion for Frameworks . SystemHeat is currently Work In Progress, stay tuned, @ProgorMatic! The rationale is that the Frameworks are going to be supported too by 3rd parties, and so users of these frameworks may not have any of the PKMC Core installed! The following Companions were updated to cope with the new TweakScale 2.4.6.0: TSCo-FS (Firespitter) TSCo-KIS (Kerbal Inventory System) TSCo-PKMC (Post Kerbin Mining Corporation) Now TweakScale provides dynamic loading services for the Companions, and so now it's safe to just install everything (disregarding if the target add'ons are installed or not) without problems. These Companions were updated to use these new facilities. The rationale, for people interested, is that CurseForge and CKAN don't handle "sub-packages", so I need to shove everything and the kitchen's sink on a "über package" with everything (and the kitchen's sink). Renaming them in order to be installed as CKAN and CurseForce likes will clutter the GameData with a lot of directories with artefacts that are, in essence, closely related as they are essentially extensions for TweakScale - and maintenance is easier this way: delete GameData/TweakScale, delete GameData/TweakScaleCompanion, download new packages, unzip them on GameData, and you are updated. Try to do that with 15, 20 Companions each one on its own place on GameData... Of course, people still willing to cherry-pick only what they want to use will still be supported on Github (and I suggest KSP-AVC for keeping track of them). Downloads here and in the OP. — — — @WhatALovelyNick, this is not (yet) the updated I talked about with you, this is something I was working the whole month and the reason new patches were delayed. Happy Scalings!

ANNOUNCE Release 2.4.6.0 2.4.6.1 is available for downloading, with the following changes: Breaks the 1.4.4 barrier! Now TweakScale supports from KSP 1.3.0 to the latest! #HURRAY!! Resurrects the AutoScale feature. Use CTRL-L to activate/deactivate A HotKey collision with a 3rd-party add'on is a Known Issue. This will be tackled down on Issue #202. Updates KSPe.Light.TweakScale to 2.4.0.4 ATTENTION!! : Users of the following TweakScale Companions must update them immediatelly, as this release breaks binary compatibility (i.e. they will not load!!): TSCo_FS TSCo_KIS TSCo_PKMC TSCo_Visuals And yes, this is working!!! See OP for the links. Highlights Full support from KSP 1.3.0 to the latest You install the package, something doesn't works, I will fix it! No questions asked! -- other than "what gone wrong?" This is the pinnacle of 2 years of heavy and intensive planning - that was completely useless, because I didn't managed to follow a single line of the planning!! (damn, what a mess was this development, wasn't KSP-Recall??). However, I won't use this on KSP 1.3.x on ongoing savegames, just in case. I don't have savegames from the 1.3.x era, so I can't thoroughly test the new patches on a living (backup'ed!) savegame to double check my synthetic tests on KSP 1.3.1 . New savegames will end up being beneficed by the new patches as I revise and backport new versions of Add'Ons to KSP 1.3.0, but ongoing savegames gain too little to nothing on using TS 2.4.6.x - unless you are lazy as me and want one single package for everything! (not to mention using new features on previous KSP versions - you know, I still play 1.4.5 now and then...) Selective persistence on saving craft files From 2.4.5.4, a long time wished feature (the task was created on late 2019!!) is finally reaching the mainstream after being tested inhouse for half the year: TweakScale now omits its data on parts with default settings when saving craft files. This new (and unexpected) feature is meant to declutter your craft files from unnecessary TweakScale sections, preventing your crafts from being flagged as using TweakScale when all your parts are plain vanilla sized! This will save you from creating special KSP installments when participating of challenges where TweakScale is not allowed. Now you just can save the file normally and publish it without that pesky TweakScale config sections lingering on the file without doing anything useful. This feature works on every KSP that have that Upgrade Pipeline thingy that will recreate the default TweakScale data from the prefab when it doesn't find it on loading. TweakScale does not activate this feature for KSP versions without this thingy for obvious reasons. Even users of older TweakScale versions will be able to load the craft files (the heavy lifting is done by the Pipeline) - so this feature is 100% retro-compatible. There's a proof of concept on Kerbal-X where a craft with all parts unescaled (but the miniFulelage) is available for downloading. By inspecting the craft, you will see that only miniFuselage has a TweakScale section - but, yet, the craft will load fine on your KSP 1.12.2. There's another version made on KSP 1.4.5 that you can use to test the feature on previous KSP versions (make the Pipeline sweat!). Click on the "Version 1 of 2" thingy on the upper left part of the page. TweakScaleExperimental support for parts and modules From 2.4.5.2, TweakScale is starting to support, as possible, all KSP modules - and not only the most visible ones, as well parts. In order to pursue that goal without risking your ongoing savegames (as changing Exponents will unbalance your designs, potentially ruining your crafts), some parts and modules scaling are only available on Experimental mode. Such mode will patch almost all KSP parts and modules (but Serenity/Breaking Ground as this one will be tackled down later, see the backlog for more information), including some that I'm unsure should be scaled - not to mention Exponents that I'm pretty sure will need some rebalancing. In order to toy with these parts and modules, you need to create a directory called TweakScaleExperimental in your GameData. The directory may be empty, it's enough to have it on GameData so Module Manager will register it, satisfying the :NEEDS that enable such patches and Exponents. Please only enable these patches on disposable or non valuable KSP installments. These patches are going to change for sure in the near future, and these changes will be incompatible with savagames created with the previous set of Experimental patches. Standard mechanism to control TweakScale availability From 2.4.5.0 and up, it's possible to deactivate TweakScale on some (or even all) parts by patching or on the user interface without affecting living crafts on the savegame (or even already existent craft files). A patching only feature can lock up TweakScale on the current state, making easier to create artefacts to automatically reconfigure a savegame for Challenges with specific rules. Again, without affecting existent crafts or savegames - once the craft is launched, it's not affected by these options. See the Documentation for details. Formal support for KSP from 1.3.0 to 1.12.2 From KSP 1.3.0 to KSP 1.12.2, every single version of KSP is formally supported. You find a bug, it will be fixed. Eventually. TweakScale 2.5 aims to bring back support for KSP down to 1.2.2 (exactly how, is still work in progress, but it's feasible as being demonstrated by some Unofficial forks of mine). Parts with Variants Variants that change Cost and/or Mass are now fully supported, but TweakScale is struggling to support Parts with Variants that changes Attachment Nodes. I had planned to withdraw TweakScale support from such parts as I did in the past, but then I realised that most Version 2 parts from already scalable parts (as Terrier...) would had TweakScale withdrawn, and this would render some crafts and savegames corrupted. Since most of these parts didn't misbehave on a noticeable way, I decided to just let it go as is for while. Just a few stock parts are misbehaving into a noticeable way, and these parts are (until the moment): The Mastodon engine The Structural Tubes T-12 T-18 T-25 T-37 T-50 And probably more, as Add'Ons starts to use such feature. The only workaround at the moment is to descale these parts before applying the variant and then scaling them again. Alternatively, just detach and reattach the misbehaving parts. A proper fix is Work in Progress, and is expected to be released. Soon™. Deprecating Patches Support for all non Squad parts are on a deprecating status and will be definitively removed on TweakScale 2.5. The TweakScale Companion Program will be the source for supporting third-parties add'ons. It's advised to install the needed Companions as they reach Gold status. Sanity Checks Parts using Firespitter's FSbuoyancy needs the latest TweakScale Companion for Firespitter, as only the Companion has the specific code that knows how to handle it. Embedded Firespitter Support is on Deprecating status anyway, so soon the TSCo-FS will be the only way to support Scaling on FireSpitter. Overrules A overrule, as the name says, is a patch the overrules TweakScale (and anything else) in order to make things "broken" in a deterministic way. A complete essay can be found here. Hot Fixes A Hot Fix is a hand crafted patch that fixes by brute force patching problems, forcing the original intended result for a given KSP installment. The difference from an overrule is that Hot Fixes don't break compatibility with sane installments, so you can start new savegames and share your crafts without worries. A complete essay can be found here. New Scaling Behaviour A new TWEAKSCALEBEHAVIOUR, ModuleGeneratorExtended , is available for parts using ModuleGenerator that wants to scale the INPUT_RESOURCES too. This feature wasn't introduced directly into the ModuleGenerator's TWEAKSCALEEXPONENTS to prevent damage on Add'Ons (and savegames) that rely on the current behaviour (scaling only the output), as suddenly the resource consumption would increase on already stablished bases and crafts. Just add the lines as the example below (the output resources scaling is still inherited from the default patch!). @PART[my_resource_converter]:NEEDS[TweakScale] { #@TWEAKSCALEBEHAVIOR[ModuleGeneratorExtended]/MODULE[TweakScale] { } %MODULE[TweakScale] { type = free } } WARNINGS Keep an eye on the Known Issues file. — — — — — This Release will be published using the following Schedule: GitHub, reaching first manual installers and users of KSP-AVC. Right now. CurseForge, Right Now. SpaceDock (and CKAN users), by Wedsday night (with luck) The reasoning is to gradually distribute the Release to easily monitor the deployment and cope with eventual mishaps - and some issues on Day Job ended up leaking into this week that I was hoping to be an easy one...

From L.K.O.! It's a "Spy Sat" using Tarsier's telescopes! Use Haystack to select a target, Set Control from Here on the telescope (so it will pinpoint the target as one would expect) and use the SAS!

Thanks! Ouch… I'm a bit overloaded these days due day job and a new add'on I'm maintaining (DOE, do you want to give it a try?), and my scheduling for doing patches ended up being pushed back. But… Since we are here…. I giving a pick on the work you did, and you really tried hard to do it right! Congrats! But… It's a really harsh work, the number of the parts is overwhelming and, as any other human being (including myself), you forgot some parts, or ended up with patches without naming the part, and a lot of small errors that every human being (including myself) do now and then - and when we have hundreds and hundreds of parts to be patched (and reviewed), even a small error ratio of 1% means many errors to be hunted and fixed. Well… It mostly worked. There're some glitches here and there (and as I said before, it's normal). About the DLL, you probably forgot to add some reference. Let's make a deal - I will work on the remaining PKMC patches this weekend, and by Monday (probably) we will have a beta release of everything including these ones so you can check against what you did and see where you missed something. This is the best learning process I know. You probably forgot some TweakScale Behaviours. The heat exchanges are something that will only work fine if you activate the TweakScaleExperimental on TweakScale, because some Exponents (the "magic" that makes thing happen transparently) are still in development. Working on it!

Copy whole atmosphereCurve! The following patch worked for me: @PART[JetEngine] { MODULE { name = ModuleEngineConfig #/MODULE[ModuleEnginesFX]/atmosphereCurve { } } } It gave me the following on the MM ConfigCache: UrlConfig { parentUrl = Squad/Parts/Engine/jetEngines/jetEngineBasic.cfg PART { name = JetEngine module = Part author = Porkjet // yada yada yada... MODULE { name = ModuleEnginesFX engineID = Cruise // yada yada yada... atmosphereCurve { key = 0 10500 0 0 } // yada yada yada... } // yada yada yada... MODULE { name = ModuleEngineConfig atmosphereCurve { key = 0 10500 0 0 } } MODULE { name = ModulePartInfo originalPartName = JetEngine } } } The # is the copy command. The first "/" says to look for a subnode from the current "root" one (on my case, the JetEngine PART). And the rest is straightforward. Cheers!

Well, so I believe that fellow Kerbonaut is not going to help. The link you provided on the earlier post provides a "skin" to be used on a spherical mesh. But the SkyBox is made with 6 flats surfaces, forming a cube (since the name, SkyBox). This is going to need some serious math, as we will need to transform each pixel from a spherical coordinate into a flat one. Or, simplifying things, we need to "render" the sphere with the universe's skin and then render 6 projections using raycast, each projection being one if the sides if the cube used by the SkyBox. It's like a raytracing rendered photo, but the raycast is fired from inside the sphere to the pixel of interest, instead from the pixel into INF of its normal. This problem was already solved uncountable times, including by me 20 years ago when I studied raytrace and radiosity (when this thing was still a novelty). Problem is… It was 20 years ago, I don't remember a thing!!! Let's keep this cooking on vapour some time, this is getting interesting...

Hummm… Didn't thought of that. I need to fire a raycast from the camera to the body, and suppress the labelling if there's anything between... https://github.com/net-lisias-ksp/DistantObject/issues/9 https://github.com/net-lisias-ksp/DistantObject/issues/10 Ouch! I missed that too!! https://github.com/net-lisias-ksp/DistantObject/issues/8 Cheers!

There's nothing "special" about KAX, I just use the latest Firespitter. Ignore the Firespitter folder on the distribution file (ignore the ModuleManager too, never install more than one in GameData, and never use an older version!), download and install the https://github.com/snjo/Firespitter/releaseslatest FireSpitter and it should work fine - it did on my rig (on KSP 1.12.2) at least. (this is one of the reasons I don't think distributing dependencies on the same file is a good thing)

That's the problem! If TweakScale can't, so they can't neither - because they would use the very same mechanism and, so, they would be blocked the same - unless they use some internal KSP feature I'm not aware, and so I want to be aware of that! On the bottom line, it's not up to the game engine to impose limits to the content creators - others than the ones needed to keep the engine healthy. Limiting the size of the crew on editing time to save the Editor from coping with this I consider undesired (because reading the crew size from the living part instead of the prefab is incredibly easy), but understandable (they would not want to add a test for this use case on the Quality Assurance). Limiting the size of the crew while launching the craft doesn't protects the Editor from any problems, and prevent the content creators from doing something that I already had proved the game engine can cope without problems. It's a harsh work, but someone has to do it!!!

This time it's something else borking on you: [LOG 22:10:29.042] Resource tantares_sp_full_friction added to database [LOG 22:10:29.043] CodeAssetLoader: Compiling all code assets [LOG 22:10:29.047] ExperienceSystemConfig: Added Effect 'DeployedSciencePowerSkill' to Trait '#autoLOC_500103' [LOG 22:10:29.048] ExperienceSystemConfig: Added Effect 'DeployedScienceExpSkill' to Trait '#autoLOC_500105' [EXC 22:10:29.052] NullReferenceException: Object reference not set to an instance of an object GameDatabase.CleanupLoaders () (at <cd473063d3a2482f8d93d388d0c95035>:0) GameDatabase+<CreateDatabase>d__71.MoveNext () (at <cd473063d3a2482f8d93d388d0c95035>:0) UnityEngine.SetupCoroutine.InvokeMoveNext (System.Collections.IEnumerator enumerator, System.IntPtr returnValueAddress) (at <12e76cd50cc64cf19e759e981cb725af>: That's something missing or broken on your KSP. (This happened because to speed up things on loading, Squad had to wave some try-catches (a handful but very CPU consuming programming technique). So if something goes badly inside a thing we call "hot code" (something that it's used many, many times and so we need to do things fast there), the whole game just gets stuck.) Problem is that DeployedScienceExpSkill is a stock thing, so it's something else that handles Science blowing up. The last thingy added successfully to the database was tantares_sp_full_friction , so I searched for it on the patching log to see what's processed after it (not a rule, but sometimes this can help to sort out the problem): [LOG 22:10:28.977] Config(PHYSICMATERIAL_DEFINITION) TantaresSP/resources/tantares_sp_physics_materials/tantares_sp_full_friction [LOG 22:10:28.977] Config(EXPERIMENT_DEFINITION) TantaresSP/resources/tantares_sp_science_definition/EXPERIMENT_DEFINITION [LOG 22:10:28.977] Config(EXPERIMENT_DEFINITION) TantaresSP/resources/tantares_sp_science_definition/EXPERIMENT_DEFINITION [LOG 22:10:28.977] Config(EXPERIMENT_DEFINITION) TantaresSP/resources/tantares_sp_science_definition/EXPERIMENT_DEFINITION [LOG 22:10:28.977] Config(EXPERIMENT_DEFINITION) TantaresSP/resources/tantares_sp_science_definition/EXPERIMENT_DEFINITION [LOG 22:10:28.977] Config(EXPERIMENT_DEFINITION) TantaresSP/resources/tantares_sp_science_definition/EXPERIMENT_DEFINITION [LOG 22:10:28.977] Config(EXPERIMENT_DEFINITION) TantaresSP/resources/tantares_sp_science_definition/EXPERIMENT_DEFINITION [LOG 22:10:28.977] Config(EXPERIMENT_DEFINITION) TantaresSP/resources/tantares_sp_science_definition/EXPERIMENT_DEFINITION [LOG 22:10:28.978] Config(EXPERIMENT_DEFINITION) TantaresSP/resources/tantares_sp_science_definition/EXPERIMENT_DEFINITION [LOG 22:10:28.978] Config(EXPERIMENT_DEFINITION) TantaresSP/resources/tantares_sp_science_definition/EXPERIMENT_DEFINITION [LOG 22:10:28.978] Config(EXPERIMENT_DEFINITION) TantaresSP/resources/tantares_sp_science_definition/EXPERIMENT_DEFINITION And I think we may have a confirmation: there's something missing or broken on Tantares. You need to seek help from the Tantares maintainer. I ditched Windows 10 years ago, I can't help. Sorry. Cheers!

You perhaps, but not other people. Forcing your way of playing into people is not the best way to make friends. I would understand such limitation on Editor, because Editor needs to know how many Kerbals the part support to draw the slots - by Editor could take this value from the part instead of the prefab, but whatever. But there's no such limit on flying time. And, again, if the problem would be the number of available seats, the criteria should be applied on the prefab itself too. Anyone can shove 100 Kerbals on a MK1 Cockpit using a patch, but TweakScale can't shove 3 by scaling the cockpit up. Again, sounds arbitrary and unneeded.

This is going to be somewhat dense and technical, so I suggest to anyone reading this to grab some popcorns. That's the history: OOP may be messy sometimes, but it's still to this moment one of the best approaches for controlling complexity - and a Game Engine is anything but simple. But OOP has a drawback (there's no free lunch, the complexity always "leaks" to somewhere else), OOP makes the initialisation and the deinitialisation way too CPU intensive. Objects has a thing called Constructor, and the runtime call this Constructor every time you say "new" to a class. And once the system became more complex, you have Objects inside Objects inside Objects in many, many levels - and each one of them needs to have the Constructor called when the Top Cat, I mean, the Top Object is instantiated (the technical term for what happens when you do a "new" to a class). Once an object dies, the runtime does the same, but calling the Destructors this time. And again we have lots and lots of CPU time being used on cascading calls. On C# things are yet a bit more messy because you don't "kill" objects, you abandon them until the Garbage Collector realises there's an abandoned object lingering around and goes for it to free the memory. Unity choose a different approach for this problem: realising that most objects are initialised to a same state (i.e., have the same initial values once instantiated), they choose to "run the Constructors" on building time only once (instead of every time the Object is created) and save the state on a blob, that so would be injected inside a "fast track constructed" object. A memcpy is way faster than a lot of calls doing settings and gettings scattered on the heap. Obviously, this also has a cost: these Fast Track objects can only have a "default constructor" (i.e., the Constructor must not have any parameters), as a Constructor with parameters will create at runtime a State that it's impossible to precompile at building time (you would need a blob for every possible values - or combinations of values - of the parameters of the Constructor!). The collection of every premade blob for every Game Object is called the prefabs - pre-fabricated objects. And this makes loading and initialising things a lot faster (as long you obey by the rules). And this is where things get interesting on KSP - Since the very first release, KSP was fiercely intended to be modded. And Fiercely is the keywork here - every single measure or idea that could improve moddability was tested and some were implemented. One thing that makes harder to mod a game is… the prefab!! How to safely mod a part, if their data is carved on stone on the prefab? And how to mod a modded part without screwing up everything? Just imagine two guys trying to change a part at runtime at the same time, one undoing what the other did... Yep. Terribly messy. And so the KSP's creator decided to wave a bit the speed of the prefabs (remember, there's no free lunch - and you can't have the cake and eat it too!) by waving building the prefab at the game's building time, to create the prefabs on loading time! Every time you boot up KSP, instead of reading a giant blob full of prefabs, KSP loads its essential bundles (with some prefabs already premade) and then go hunt for Config Files on the file system. These config files are then "compiled" and used to create the prefab of the parts of the game. Once the game is loaded, Game Objects are "cloned" (as instantiate is not the correct term anymore) using these prefabs built at load time. And this is the reason KSP is so moddable - you don't need to decompile the prefab of a part, change the values you want, recompile and then replace somehow the original blob with yours (and then hope for nobody else trying to do the same on the same part). You just change a Config file, or write a new one, and voila!! A changed or new prefab without the need to recompile the whole shebang! #HURRAY!! So, and going direct to the matter now, when you take a Cockpit from the Part's Pallet and attach it to another part, KSP does that process I described above: it clone the part, inject on it a copy of its prefab (to fast initialise everything), and then attach the part to that another, and now you have a new living part to use. My kludge with the Crew is exactly that: if I write a patch to shove 100 Kerbals on a MK1 cockpit, KSP will happily allow me to shove 100 Kerbals on the MK1 Cockpit, completely disregarding the number of seats of the IVA. But if TweakScale tries to do the same, KSP will reject it. But, hey, you don't need to trust me on this, you can verify yourself! Shove this patch somewhere in your GameData (I suggest __LOCAL, so you can localise it easily and remove the stunt later): @PART[*]:HAS[!MODULE[KerbalEVA],!MODULE[ModuleAsteroid],!MODULE[ModuleComet]]:FINAL { @CrewCapacity *= 100 } And see what you can do now: 12 Kerbals (still have 88 slots available) on a MK1 cockpit - and the thing has only one seat. Github issue: https://github.com/net-lisias-ksp/TweakScale/issues/44 Last time I bored to try the stunt here.

ANNOUNCE Release 2.1.1.5 is available for downloading, with the following changes: Über refactoring Creating a shareable MeshEngine Decoupling PartModule details from the Engine Now it can be extended by creating new DLLs, instead of recompiling the thing! Adding (preliminary) support for ReStock To tell you the true, just a more thoughtfully implementation of Stock MODEL sections. Significant performance enhancements and CPU savings New Render Mode to allow smooth transitions at the cost of memory. Vessels are not removed from the cache, unless destroyed May use a lot of memory! Option to show the names of all visible bodies Use <ALT> while RightClicking the mouse. Guys, this is the real deal - all the work on the Experimental releases (more some late minute fixes and adjustments) are consolidated on a formal Release! (this is also the last time I use the SpySat to take the pictures - I'm learning my way on Cameras, next release I will use something else!! And a screenshot using the hint from @rextable: See OP for the links. — — — — — This Release will be published using the following Schedule: GitHub. Right Now. CurseForge. Right Now. SpaceDock. (By Saturday, probably, as I need to push some changes on NetKan) The rationale is that Real Life bitten me this week (again!), and I ended up pushing ahead some tasks (as CKAN)

I disagree. I can shove how many crew I want on the part config, the game engine let it pass. It only throws the exception when the current crew size is bigger than the prefab, not when there're more Kerbals than seats. And I can even mangle the prefab at runtime to overcome this less than happy decision, the only criteria is the current crew size being larger than on prefab - mangling the prefab kinda work around this BS, but by doing that I would screwup everybody because is known to squash the data on the living part config using the prefab when loading a savegame. I want to build a bus, Kerbals would travel on their feet! There's a lot of 3rd-parties add'ons without enough seats on the used (stock) IVA, and there're some add'ons that just don't provide a IVA at all (as the bus parts I built for me). If the game engine would be counting available seats, I would (reluctantly) agree - but I can type 100 Kerbals on a MK1 capsule's config if I want, things will work fine the same. So there's no real reason to disallow doing that programatically. If the KSP engine can accept a config with more crew than seats, why not from a PartModule? This sounds arbitrary and targeting. I will give this a peek tomorrow in the morning. It can by anything, but at least I can try to rule out TweakScale before escalating it "upstairs".

WAIT! Did you used CKAN to install this stuff??