Lisias

This are simpler than it looks, but I agree.. This one is going to be pretty painful to me to diagnose and fix. Completely remove <KSP_ROOT>/GameData/TweakScaleCompanion/Frameworks/TestFlightCore from your rig, I will work on this by night!! Note to myself: Something is inducing KSPe to load TweakScakeTestFlightCore again and again and again. Doesn't looks like a bug on KSPe, because the other Companions (and TweakScale itself) heavily uses the very same code to load other DLLs, I need to understand why just TweakScakeTestFlightCore is being hit by this problem! [LOG 14:53:01.598] [TweakScaleCompanion.Frameworks] TweakScalerTestFlightCore Version 0.4.0.2 /L BETA is loaded. [EXC 14:53:01.889] StackOverflowException: The requested operation caused a stack overflow. System.IO.Directory.InsecureGetCurrentDirectory () (at <9577ac7a62ef43179789031239ba8798>:0) System.IO.Path.WindowsDriveAdjustment (System.String path) (at <9577ac7a62ef43179789031239ba8798>:0) System.IO.Path.InsecureGetFullPath (System.String path) (at <9577ac7a62ef43179789031239ba8798>:0) System.IO.Path.GetFullPath (System.String path) (at <9577ac7a62ef43179789031239ba8798>:0) System.IO.Directory.Exists (System.String path) (at <9577ac7a62ef43179789031239ba8798>:0) KSPe.IO.Directory.Exists (System.String path) (at <58fb44557e3d487fa13c42bddbc423e1>:0) KSPe.IO.Path.EnsureTrailingSeparatorOnDir (System.String path, System.Boolean blindlyAppend) (at <58fb44557e3d487fa13c42bddbc423e1>:0) KSPe.IO.Path.GetAbsolutePath (System.String path, System.Boolean iKnowItsDir) (at <58fb44557e3d487fa13c42bddbc423e1>:0) KSPe.IO.Path.GetAbsolutePath (System.String path) (at <58fb44557e3d487fa13c42bddbc423e1>:0) KSPe.IO.Path.GetFullPathInternal (System.String path, System.Boolean iKnowItsDir) (at <58fb44557e3d487fa13c42bddbc423e1>:0) KSPe.IO.Path.GetFullPath (System.String path, System.Boolean iKnowItsDir) (at <58fb44557e3d487fa13c42bddbc423e1>:0) KSPe.IO.Path.GetFullPath (System.String path) (at <58fb44557e3d487fa13c42bddbc423e1>:0) KSPe.IO.Hierarchy.Calculate (System.Boolean createDirs, System.String fname, System.String& partialPathname, System.String& fullPathname) (at <58fb44557e3d487fa1 3c42bddbc423e1>:0) KSPe.IO.Hierarchy.SolveFull (System.Boolean createDirs, System.String fname, System.String[] fnames) (at <58fb44557e3d487fa13c42bddbc423e1>:0) KSPe.Util.SystemTools+Assembly+Loader`1[T].TryPath (System.String path, System.String[] subdirs) (at <58fb44557e3d487fa13c42bddbc423e1>:0) KSPe.Util.SystemTools+Assembly+Loader.buildSearchPath (System.String[] subdirs) (at <58fb44557e3d487fa13c42bddbc423e1>:0) KSPe.Util.SystemTools+Assembly+Loader..ctor (System.String[] subdirs) (at <58fb44557e3d487fa13c42bddbc423e1>:0) KSPe.Util.SystemTools+Assembly+Loader`1[T]..ctor (System.String[] subdirs) (at <58fb44557e3d487fa13c42bddbc423e1>:0) TweakScaleCompanion.Frameworks.TestFlightCore.Startup.loadDLLs () (at <62a0aa40e0184c68893c50c4fc5781d7>:0) TweakScaleCompanion.Frameworks.TestFlightCore.Startup.Start () (at <62a0aa40e0184c68893c50c4fc5781d7>:0) System.Reflection.MonoMethod.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, S ystem.Globalization.CultureInfo culture) (at <9577ac7a62ef43179789031239ba8798>:0) System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) (at <9577ac7a62ef43179789031239ba8798>:0) KSPe.Util.SystemTools+Assembly.InvokeOrNull (System.Type t, System.Object o, System.String methodName) (at <58fb44557e3d487fa13c42bddbc423e1>:0) KSPe.Util.SystemTools+Assembly.LoadAndStartup (System.String assemblyName) (at <58fb44557e3d487fa13c42bddbc423e1>:0) KSPe.Util.SystemTools+Assembly+Loader.LoadAndStartup (System.String assemblyName) (at <58fb44557e3d487fa13c42bddbc423e1>:0) TweakScaleCompanion.Frameworks.TestFlightCore.Startup.loadDLLs () (at <62a0aa40e0184c68893c50c4fc5781d7>:0) TweakScaleCompanion.Frameworks.TestFlightCore.Startup.Start () (at <62a0aa40e0184c68893c50c4fc5781d7>:0) System.Reflection.MonoMethod.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, S ystem.Globalization.CultureInfo culture) (at <9577ac7a62ef43179789031239ba8798>:0) — POST EDIT -- Yeah, I was the trigger of the problem. I tested the damned thing on a "dirty" development rig and didn't noticed the problem - I was allowing the thing to be loaded on TS 2.4.7x, besides that loadadable DLL working only on 2.5 . However, that would had triggered an Exception on the LoadAndStartup call, not an Infinite Loop - this call **is not recursive**. Anyway, it's fixed and I will publish a new Companion UberPacket release today.

SpaceDock just applied a pull request into CKAN, I think they are aware at this time. Frankly, I'm pretty embarrassed on this one. I virtually forgot to click on the "Publish" button all this time.

Wow… Look for the unity's Log (see the OP to know where to fetch it - if you are on Windows, it's named output_log.txt, I think). There's something really screwed on your rig right now!! — — POST EDIT — — @Comrad_501, found this on the KSP.log: MiniAVC v1.0.3.2 Older versions of MiniAVC is known to play havoc on modern KSP. Search and Destroy all occurences of the file 'MiniAVC" on your rig and try again. It's my understanding that CKAN should be filtering these files (or, at least, I remember someone talking about this). Did you installed something manually recently? — — POST POST EDIT — — Nope! It's TweakScaleCompanion.Frameworks.TestFlightCore again! Completely remove <KSP_ROOT>/GameData/TweakScaleCompanion/Frameworks/TestFlightCore from your rig, I will work on this by night!! (working hours). Why it caused such stack dump it's a mystery to me right now, the code should just complain about not being able to load the DLL, not to induce the whole system to this abhorrent tragedy!!!!

Krap. Please send me the (full - remember to quit KSP before copying it) KSP.log after reproducing the problem and I will check it again.

Well. being nitpicker, chess computer game is a simulacrum. The real life chess game is a "virtual". (unrelated to "virtual reality" as the term is being used).

Working. — POST EDIT -- Damn, I forgot to "publish" the thing. Fixed

Apparently the watering down tendency is not specific to KSP2. Some Cities:Skylibes die hard fans are also complaining a lot about this on reddit: Let's see what happens. From my point of view, I don't have the slightest problem on easy modes on games - just let the hard mode available for whoever wants to brag about playing on it. The best of both worlds.

Oukey, it's some time already since the crapstorm from Unity Technologies, and some people are talking about their experiences on the transition on Reddit. Interesting reading. TL;DR: some people are managing it, someothers didn't got a grasp on it, and some others could not afford the time to migrate. Not really a surprise, but it's interesting to see their reports. One of the most interesting talked about Road to Vostok, the developer decided to ditch a ongoing game in Unity to Godot - with success!

Unfortunately, the developments is frozen until I manage to publish TweakScale 2.5 . The current 2.4 doesn't have the support I need to do things right, so you will not be able to even compile it right now. Problem: time and... well... proper cooperation from some distribution channels. I wasted all my free time on my last window of opportunity earlier this year handling problems from 3rd parties, and the next window to retake such actives is the next Seasons.

Frankly? I think they are way under documented - some people just don't get the grasp on it without some help. You can't use the same heat management on a base in the Laythe's night on a base on EVE's midday! The game simulates even the Sun's flux! This is not a heat problem, this is nasty bug on initialising internal data. It only happened to affect. heat on you, but it also affected mass in the past. There're many external factors that could lead the heat system to misbehave, don't misunderstand the effect with the cause! You will find a good example of this here: https://github.com/net-lisias-ksp/KSP-Recall/issues/25 - I had screwed a little tiny detail on ChillingOut (a hack to fix exactly the problem you are describing, when related to some old parts). I agree. "Buying" astronauts, additionally, leaves me with a bad taste on my mouth. You diagnosed the problem yourself. The Rails-In, Rails-Out code is buggy, not the heat system. Switching scenarios is a full load of the whole scene, not only the craft. Had you reported this bug? It may explain a lot os misbehaviours, it's pretty probably that this rotten code on Rails-In/Rails-Out would be screwing more things. Since what KSP version you detected this problem? This is a problem on the simulation - it happens something similar if you use timewarp with the craft on an atmosphere - the quantum of the simulation is too big to proper simulate the heat transfer. It's the reason the timewarp is handicapped when you are inside the atmosphere. Dumbing down the heat system due a flaw on the timewarp is similar to remove atmospheric flight due it. -- POST EDIT -- On a second thought, this time warp problem can be even related to using floats. On a larger quantum, the values involved get bigger or smaller enough to start to be rounded, and one of these rounding eventually happens on the worst possible way. Not different from what happens on recovering Funds from crafts with really, really, REALLY expensive parts (only possible with mods) that I had also worked around on KSP-Recall. In time², remembered this other borkage of mine about the loading problem I mentioned above. Hell of a hack, but it worked (almost) very well! https://github.com/net-lisias-ksp/KSP-Recall/issues/26

Because a single craft need to be a tree, so if you are going to merge two crafts, one of them need to be rerooted in order to keep the final result still a tree, otherwise your data structure will degenerate to a graph, and then you are screwed. Struts are a hack to allow multiple nodes on the same tree but in different branches to "connect" - but these parts still need to be on a tree, otherwise they wouldn't be reachable by the traversing algorithm. On a pretty abuse of language, you can think on Struts are being "GOTO's" used on a structured program: you still need to follow the code's flow until you reach the GOTO. There's a line in need to be draw about expectations: There're the KSP¹enthusiasts that want a better, enhanced and more polished KSP to play with. There're the gamers in general, willing to try something new and easily reproduce some of the stunts they see on KSP¹ videos on youtube but on a less demanding framework. The first group IMHO will be pretty disappointed with KSP2 and I'm betting they are the reason the reviews on Steam didn't reverted the trend of bad reviews (besides 0.1.5.0 being a pretty solid update on the technical point of view). The second group will probably enjoy KSP2 very much, as soon as they are able to play the damned thing. Knowing in advance what you expect from KSP2 will surely help on foreseeing what you will think of it once it is, finally, feature complete.

Since this is a paid, closed source add'on, I think you will need to reach the author in his Patreon page as it's very unlikely someone around here will be able to help you on this one.

And probably trash collectors and dustmans too. Someone has to get rid of all the features KSP2 is lefting behind.

Given new information (for me at least) given on this very thread, I need to agree with you that KSP2 can't even be a half-baked Roguelike anymore, what to say a RPG. But the idea is not mine at all: From the unavoidable Wikipedia, "A role-playing game (sometimes spelled roleplaying game, RPG) is a game in which players assume the roles of characters in a fictional setting. Players take responsibility for acting out these roles within a narrative, either through literal acting or through a process of structured decision-making regarding character development. Actions taken within many games succeed or fail according to a formal system of rules and guidelines.". All the basic elements for turning KSP into a RPG are (were) there since KSP¹ (see the numerous mission reports on this very Forum). We had even a prototypical character development, and even traits - that unfortunately were never really explored on the main game but were on some add'ons. But the game never developed into that direction, granted. However, with the most interesting parts of the game being watered down, I agree that (ab)using KSP2 as an RPG will be less compelling. — — POST EDIT — — As a matter of fact.. I'm wondering what it would take to create an Add'On that would turn KSP¹ in a somewhat clumsy but still de jure et de facto RPG…

Because the problem isn't always on the code, sometimes it's on the requirements. For example, the crafts in KSP¹ are internally Trees. Make it simple to code and previsible to determine how many iterations you will need to run over it to do something, but it has a serious drawback: it limits horribly how to design a craft. Graphs are perfectly for the job, we could design our crafts around spars and spines using Graphs, it's a way more flexible data structure! So we rewrite the thing to use Graphs, and now we can't keep stable FPS no matter what. Problem: Graphs are way less previsible than Trees, we need to keep track of the nodes we had ready visited because we can get there again multiple times by multiple routes. Not being bad enough, this also hinders paralelism because all workers need to share the list of visited nodes and so this list must be synchronized. And then we go back to Trees because you can open a thread to each branch, knowing in advance how many work each thread will handle and there's no need to share runtime data between the threads. Our crafts are crappy again, but at least we can fly them.

Well, I'm a software developer myself and I can say that, sometimes, a fix to the problem causes more damages than the problem itself and so we code the problem back. It happens way more than we would like.

Nope. Underused use cases on Stock KSP. Before continuing, let me answer a question that I let pass trough: False (or at least I didn't found a use case where this is true until nowadays). Parts with ModuleResourceConverter and/or ModuleResourceHarvester does that when they find a part with ModuleActiveRadiator or ModuleDeployableRadiator on the craft, but only using that kind of heat they produces internally themselves. So, in the end, the Radiators are not able to dissipate heat from any part of the craft, only from themselves, after absolving heat by conduction from the parts they are attached to - some parts dissipates they own specialised heat from themselves when they find a Radiator on the craft. Now, bear with me: even if we would be talking ducts and coolant here, if you have a very, very hot part between the radiator and some other part on the other part of the subtree, this would behave more or less the same because that very, very hot part would overload the coolant as it passes by it, and from this point the coolant would be perverted into heating that poor part on the other side of the oven. As an example, if we have a NERVA between the radiator and the cockpit, the cockpit should be a sauna due the coolant, not besides it. More over, we care differently about different aspects of the gameplay. I beg to disagree in both instances. I reserve cordiality to people being cordial to me - on the other "use cases", I go direct to the point without mincing words. (My) rudeness is a large step ahead, I concede being grumpy.

Yep. But as a matter of fact, only now with 0.1.5.0 we (apparently) have a game that is really playable, essentially we have now what should had been delivered in January. Until now, the technical development were in focus because this is what was preventing the rest of the game to be evaluated (if not plain being loaded). NOW we are in a position to start evaluating the gameplay (before, something usually crashed way before). But, given the information I'm getting in other threads, I need to warn you: some aspects of KSP2 are way different from KSP¹ except on the most basic use cases. Casual players will probably not notice any difference, but seasoned users surely will - and this may not be exactly a positive outcome (IMHO, it's not).

Removing waste heat. Waste heat is vastly unexplored by Stock KSP, but some mods make good use of it, and I created a few parts for myself that creates huge amounts of heat and, so, should be used sparingly or a adequate radiator must be placed on the craft - without any parts with low conduction between then, or that part will ended up exploding. Additionally, if you are near a heat source (like orbiting the Sun near enough), you will need radiators (placed on the shadows of the craft for better efficiency) to prevent it from eventually overheating and explode by themselves. I suppose this trick would be useful on EVE too, as long you keep the radiators on a shadow (this one I never tried - yet).

I had already did, se the Val Barbecue craft. No need to do it again, but I can upload the craft somewhere if you want. About the ISRU, their "Core Temperature" thing IS NOT part of the KSP's Core Heat System! It's part of the ModuleResourceConverter . AGAIN, we are not talking KSP's thermals here, this is a feature specific to ModuleResourceConverter. This PartModule must be looking for any operating radiator in the craft and then subtracting its specific "Core Temperature" thing when finds one. The ModuleResourceHarvester used on the drills looks the same, but I'm still investigating. In a way or another, your initial claim: is just wrong the same. The radiators absorb heat from the connected parts, exactly like I explained. What we have on ISRU and Drills are specialised PartModules that create "another kind of heat" used only by themselves, and they "withdraw" this specialised heat when they detect parts with enabled ModuleActiveRadiator or ModuleDeployableRadiator modules attached. You took the behaviour of two PartModules and generalised them (incorrectly) to the whole game. — — POST EDIT — — The radiator efficiency is different when it takes light from the Sun, and when they are on the shadows - just forgot to mention.

Jesus Christ, man… Do you really BELIEVE in what you are talking? Shove the Radiators on both extremes of the craft, deploy and retract them alternately and watch the Convection Flux, Conduction Flux and Radiation Flux values changing accordingly. THESE are the thermal simulation we are talking about. The Core Temp from the Converter is simulated apart. Let do another test, let's fry Valentina this time (Jeb is already dead, right Manley?): Fire the engine, start to barbecue the Cockpit slowly (or the skin temp will reach max too fast and the thing will blow up killing Val). Heat the cockpit the most you dare without screwing it. Try to reach an equilibrium, where the skin temp stops rising, or do it slowly. Extend the near radiator. See how the Cockpit core and skin temps starts to decrease slowly. Now retract it. Extend the far radiator. See how the Cockpit core and skin temps starts to decrease slower than the previous one. Now redo the tests with the PAW for all parts involved and monitor the Thermal values. Observe as the fuel is consumed, the far radiator is less efficient on cooling the Cockpit (as the thermal mass of the fuel tank between them is decreasing, screwing the conduction). The same doesn't happens with the near radiator, as we are not consuming the monopropelent. You just don't know what you are talking about. WORST, you are unable to even do the proper tests in order to check about what you are talking about - you are COMPLETELY in the dark about this subject. — POST EDIT — I stand corrected. The dude is not completely in the dark, he's misguided and gone to the wrong path due jumping into conclusions without further investigation. Me and @PDCWolf are talking about oranges, he's talking about tangerines.

Definitively, absolutely, NO. This is NOT how KSP¹ works. I don't have a clue about how KSP2 will work, I'm basing my argument on what I'm reading on this (and the host) thread, but KSP¹ I KNOW HOW IT WORKS, and it's not like that. The Radiator dissipates heat from the part it's attached, and once that part gets cooler, the hotter parts transfer heat to it by conduction. The heat flows from the hotter parts into the cooler parts across the craft. Even the WIKI's description says something similar to that. And this information is easily verifiable by simple craft on the sandbox. ALT-F11 and the Debug menu are your friends. Unless I can trust the information you are providing, it's really hard to keep this discussion ongoing - on some things I need to trust you because I don't have any other reliable source of information to double check them, and right now I'm reticent on exercising such trust. (the rest of the post will be evaluated after my lunch - now I need to double guess any information you provided, because I lost confidence on what you are stating) Please enlighten me where I was dismissive or deflecting about your arguments. Without some solid examples, I'm afraid I'm unable to identify them by myself.

quoting myself, again: But, with new information gathered on this thread, I'm considering being wrong about the RPG thingy, as even as an RPG, the game appears to be considerably watered down.

That's the idea! I don't care how the features I'm interested are implemented, as long the end result of the simulation gives me the illusion of working as I was expecting. It's the reason we call these things "simulations" and not "emulations". We play Flight Simulators, not Flight Emulators (go play RC on the garden if you want a Flight Emulator ). By the looks of this thread, KSP2 is simulating things in a way that breaks the illusion I'm used on KSP¹. Ergo, it's not a KSP¹ sucessor, at least for me - there're a lot of shiny new things on KSP2 that are not present on the predecessor, but I can live without them (heck, I'm playing 1.4.3), but KSP2 also misses some details that are exactly some of the reasons I enjoy KSP¹ . Ergo I'm not willing to play KSP2. Making a parallel with your abstraction, imagine that in a new release of your game, someone decides that your approach is too much complicated and decide to "enhance the user's experience" by removing the cloud of bullets, and instead projecting a death cone from the origin into MAX_RANGE, randomly killing anything inside it beyound a MIN_RANGE. Superficially, it would work the same from the killed pilot's point of view - but on the other hand, you will not be able to simulate things like this (what your approach is able to!): The Fighter Plane That Shot Itself Down It may or may be not acceptable by the players, it will depend on how they are playing the first version of your game and, so, by their expectations about the sequel. Every abstraction is, by definition, wrong - but they are still useful under the constrains where they are viable for your solution: depending on how and where you abstract something, you will lose the ability to simulate some aspects of the target being simulated. You can't have the cake and eat it too. Agreed. For a coherent and constructive discussion, we need to: Agree on the terminology, otherwise we will not establish a communication. KSP2 is a Indie game, by the way? What's an Indie game after all? Recognise that the other side is entitled to have a opinion that perhaps needs some polishing, but is not be necessarily wrong just because you don't like it.

It should be working now. I forgot the repository on private status, my bad. Cheers!