Lisias

Yep. Problem is that by doing it, they are risking creating the failure themselves. Most of the backslash is coming from the pricing being asked. Had they published a very minimalistic demo by 10 bucks, you can bet your mouse they would having way less criticism. Software Development is way counter intuitive - the current state of affairs doesn't means necessarily that they screwed up. It probably means that their current customers are the Content Creators and not us, but then some pointed egg head forced the hand on publishing the thing as is and Kraken help us all. The Content Creators need tools to do their job, and if the dev team spends time polishing the engine for us before the Creatives have their tools, we would have no Content at all.

Good to know, and it's fine to me. But I would prefer that the P/R guys didn't started this fire by enticing us with this "day one" buzzword because, hell, the only way to do that right now is by violating the forum rules!!! Source.

Moving back from the KSPIE thread. — — — the "IXSMainHullReactor" worked fine (or almost) on my rig, the refunding were happening almost perfectly. I'm recovering almost all the 44.5M Funds, with an error of less than 1K Funds (I started with 45.000K and ended with 44.999K). The problem appears to be related to the huge amounts of Funds involved, I think we may be handling a float rounding error on this one. In time, it's the reason using floats on currency in Real Life™. I also tried the "MuonCatFusionReactor2", but scaling it down to the 1.25M of the Command Pod Mk1. Interestingly, I got the same problem on this one - I started with 100.000F and ended up with 99.999F - an 1F error. @GoAHead I think this is not a "problem" neither on KSPIE, IT or even Recall - this appears to be related to using floats for currency calculations! I can mitigate a bit the problem on Recall (by using decimals while handling currency), but I can fix it 100% because KSP itself uses floats, so this is beyound my reach: I can't fix it, all I can do is to minimize my role on the problem. I'm working on it. My apologies to FreeThinker by polluting his thread, I genuinely though this was a IT problem. @GoAHead, lets keep this on the Recall thread, please!

Dude, you nailed it! Thank you very much! This is not a problem on KSPIE, IT or even Recall. This is happening because KSP uses floats for currency computing. Lets handle this on Recall thread, as any mitigation measures will be implemented there. My apologies to FreeThinger by polluting his thread, I genuinely though this could be something triggered by IT on one of your PartModules.

Well, not exactly "Not a Problem"… From the Add-on Posting Rules: So… Not so modding friendly after all. The very initial efforts for modding KSP2 is in violation of the Forum rules for modding...

So, no public API and we are back to hacking the game as we did in KSP1. Not a problem, but I remember Nate talking about a public API and dismissing Manley's concerning about decompilations et all.

As long you don't try to create threads for background processing - or, if you do, you don't use any Unity calls. I'm not talking about lack of parallelism on Unity. I'm talking about threading being not the preferable way to do it - to the point Unity itself is royally screwing you if you have too much cores with too many threads available (see that link of mine about MONO_THREADS_PER_CPU). My point on my previous post. It can be useful when you have a lot of crafts scattered in the Universe, but managing colliders for near crafts can be slightly more complicated. You will, at very least, need to synchronise the threads before checking for collisions - what probably will waste any savings you got with the stunt on a low craft count gaming. Now I'm guessing - so taking anything I say here with a considerable grain of (iodized) salt. It's my understanding that in the same way the Unity's Update callbacks can be skipped under heavy load, so do the Burst jobs. At least, is what some posts on Unity forum is telling us. If you built a job to handle the fuel system, and the job is skipped by some reason, well… You have a faulty fuel system with a misbehaviour really hard to diagnose...

It wasn't told to us that they were expecting modders to jump in on day 1? How?

Well… This is a collateral effect of Refunding (ab)using the Resources in order to correct the mistake Stock is doing while refunding your craft on recovery. The thing calculates how much you should be refunded, and then creates a "fake resource" that will add or subtract an amount of resources priced in a way that in the end you get the refunding you deserve. I had noticed that resources were being correctly handled by Stock, the sole problem is not calling the "IPartCostModifier" on recovery. I had set the Refunding "meta-resource" to be invisible, but on recovery the game show it the same.

Make no mistake, I believe you. I had dealt with similar problems before - what makes me very uncomfortable is that a few of them just vanished from the surface of Kerbin, and I never diagnosed the problem neither understood how it happened. This could be a race condition - but this is wild guessing right now. I'm rebuilding the test bed, I will come back to you soon. — — POST EDIT — — I **confirm** that on my rig, KSPIE is not being affected by the but - or, at least, the part I used. See https://github.com/net-lisias-ksp/KSP-Recall/issues/60 for the details, screenshots and zip files. @GoAHead, please try to use the same part I used ("Antimatter Catalyzed Fusion Reactor", the kspiWarpCoreUnit2 on WarpCoreUnit2.cfg.) and see what you get. I may be dismissed KSPIE too soon, but if by any reason the very same part that works for me () will bork on you, then we have an environmental problem - and this is going to hurt a bit to diagnose...

Yes. Up and down. Humm… So you are telling me that the behaviour had changed? This is really uncomfortable. I'm redoing the tests tonight, I will edit this post with the results.

TL;DR: reactors from Interstellar Technologies are being misrefunded, but reactors from KSPIE - at least the ones I used on my testings - weren't. The affected PartModule is IntegratedThermalElectricPowerGenerator. Again, only the part configs from IT were triggering the problem on my tests, KSPIE parts using this PartModule didn't triggered the problem for me. On one specific test (using the rbug.craft provided) reproduced the misbehaviour using Interstellar-Technologies-ICFSC-Reactor, but when I replaced it with kspiWarpCoreUnit2, the problem was gone for me.

I was talking about a hypothetical concurrent physics engine - if you have many threads simulating different partitions from the world, you need to syncronize them before detecting collisions, otherwise you will get some pretty hard to debug bogus collisions due race conditions.

Nope, I'm very up to date. See this thread (it is less than a year old). I'm talking about the GAME, not the engine. Additionally: If you create MonoBehaviour script and do things in any Fixed/Late/Update() function, this runs on main thread. Most of the Unity API's are not thread safe. Meaning you cannot create seperate thread and interact with the engine API's. Source (April 2022) Yep, physics is generally not well suited for multithreading, unless you stop thinking serially and start to think "distributively". Different crafts on different frames of reference don't interact with each other and, so, dont need to be simulated serially. Even two different crafts in the same frame of reference but not touching themselves can have their physics calculated in parallel - as long your data structures are tailored for that. Detecting collisions are still a problem, tough.

I agree. KSP2 is going to take some time to get traction - we will get a burst of downloads, then a lot of fuzz about, and then some (probably most) people will get bored and will probably go back to KSP1 for "real playing" - or play something else, if they perceive KSP1 as a "dead game". KSP1 is not dead yet. It eventually will be, but not yet. Until there, I think it's wise to give it some attention and care - it will be still be played by lots of people in the near future - or none of them will be played at all, to tell you the true. Keeping people interested on KSP1 will help KSP2 on the long run.

I can't say anything about KSP2, but I know that is shares some things with KSP1 - as Unity. Unity games usually relies heavily on single core performance - Unity, or at least the part of Unity that KSP1 heavily relies on, is heavily built [optimised] around a non threaded paradigm. As far as I know, the Unity's physics engine is not multi-thread capable - but this may be a weakness imposed by KSP1 itself, where all the Universe shares the same Frame of Reference at a given instant. The weird thing about Unity, mainly 2019 at least, is that the more cores you have, the worst the performance gets - believe it or not. So, high frequencies, low core count CPUs are the best hosts for playing KSP1 and, probably, KSP2 too. Memory is simple: the more, the best. I think that there's a point in which too much memory may choke the Garbage Collector (mainly due it's being hindered by the problem I described on the link above), but I didn't reached it yet. Your main problem is VRAM. From KSP 1.4.3 towards 1.12.5, the main factor that screwed performance on my rig was the high VRAM consumption. Even lightly modded KSP1s are getting screwed lately when using 6GB VRAM GPUs due the excessive use of VRAM by KSP1 and, lately, PD-Launcher. I got very promising results on my really old MacPotato by downsampling the DDS textures on KSP 1.12.x - not to the point in which it performed so well as on 1.4.3, but still better (the new ground rendering introduced on 1.8.0 is also pretty heavier on my rig). But, this is KSP1. Let's talk about what I hope to get on KSP2: Multiple Frames of Reference simultaneously. With each main body having its own origin, everything under its Frame of Reference can be calculated on a separate physics engine instance, each one on its own thread, and so we can have some very perceptible improvements on performance on savegames with multiple vessels scattered on different stellar bodies. Seweing the different Frames of Reference together will be pretty complex, but it will worth the pain IMHO Whatever Unity did screwed on 2019 that ended up getting worse performance as more cores you have, I really hope they had fixed it on Unity 2021. This is just abhorrent. I have better performance and lower CPU temperatures by reducing the number of threads per CPU on KSP1 to a single one. It's insane. Better Texturing Quality granularity than on KSP1 Way better VRAM management than on KSP1 Running on Windows 10. Microsoft is heavily pushing newer hardware for Windows 11, no matter the performance specs of the rig If KSP2 manages to tackle down at least 3 of the points above, we will have a better experience on KSP2 for sure - and if your rig can manage 1.12.5 at max settings, it should be able to run KSP2 in my humble opinion. Eventually, at least. — — POST EDIT — — I rephrased a statement above. I think it's more… faithfull… to what I'm meaning. I hope.

Nope. Windoze only, sorry. There were an official statement saying the game would be launched on 2020. This is one of the points on KSP2 in which I'm terribly pessimistic. Multiplatform support is something that should be worked on since the very first commit of a project. As much Unity tries to abstract things, abstractions leak, and they leak a lot - to a point that most development teams give up after a certain point of development time. As a proof os concept, take the Client Apps for Steam, Epic and GoG. Only GoG really works fine natively on MacOS - all the others need a loopback filesystem with the case sensitive filenames turned off. A pain in the back, I tell you - and this is only one of the problems to cope with. I hope, but I don't expect, a native Linux and/or MacOS for KSP2. Ever.

I can't say I'm disappointed because since the pandemics I'm resigned to cope to a lot of changes on Real Life™, most of them for the worst. And I'm convinced that this is not going to happen only to me, I don't expect my life to be better (or too much worse) than anyone else's. So I kinda knew that KSP2 would have a somewhat bleak launching - people had too much high expectations for it (and I think I can include even the developers on this wagon). And I think this is OK- lots of things on my life didn't gone as I wanted, but some of them gone as I needed, so I'm counting my blesses. Sometimes it's not evident, but I'm deeply grateful to a lot of things that I didn't wanted to happen, but it happened anyway and they ended up being what I had needed to happen. And I think KSP2 is going to be something like that - not what we want, but hopefully enough to fulfil what we need: consensus is not something that makes everybody happy, but something which makes nobody angry. KSP1 started as a very humble game. It grown a lot in the process - not without a lot of pain. I expect KSP2 will do the same - it will, eventually, be a hell of a game in the same sense KSP1 became a hell of game nowadays - there's still an incredibly marvellous game buried on all that collection of bugs, and that's the reason I'm still digging on it. “The sculpture is already complete within the marble block, before I start my work. It is already there, I just have to chisel away the superfluous material.” Michelangelo Coding is the same for me. It will eventually succeed, as long we keep digging. And hopefully modders too. The scene needs new blood, with more time to spend on a hobby and less desire on making this a "profession". KSP1 had a vibrant, colourful and intense modding scene in the early days - shifting to KSP2 without bringing all of that back will be way less attractive than otherwise. Is KSP2 going to be an elitist scene like X-Plane or DSC, with add'ons made by companies and not rarely costing more than the game itself? Or it's going to be fun and anarchic as KSP1 was in the beginning? What's going to lure add'on developers to KSP2? Fun? Amusement? Self accomplishment? Or money? (money changes everything). Are we going to need to pay money in order to publish something around here? This is concerning me more than anything else - the game itself, I KNOW will be fine as long the developers have time and resources enough - smaller teams with less resources managed to provide us with KSP1, I'm pretty sure these guys are more than skilled enough to do the same to KSP2. (mistakes will be made, the same way some already had been - but, hey, we are still alive and kicking, right?) I like graphics, but I like playing more. I'm very, very impressed with games like Tiny Combat Arena and Juno: New Origins - they are incredibly fun to play even on a crappy machine like mine. And, yeah, I spent more money on software than on hardware - it's one of the reasons I didn't upgraded my rig yet!! This came to my attention too. I'm guessing that these dudes took advantage of the initial momentum to get funding for things they knew will not be funded later once the money started to flow and the pointed egg heads smelled the incoming money. It's a sad state of the industry the one we have for decades already: the "fake it until you make it" mantra is still on the vogue. Theres a lot of things you need to get fast, or you will not get them at all. A fear the same. I really enjoy (most of) the videos, and I liked most of the things I saw on KSP2 until this moment - but as much as I think I will enjoy the game itself (eventually), I enjoy eating and paid bills more. I'm on a budget, and the machine used by SWDennis on his KSP2 test drive would cost around a whole year of the minimal wage on my country - and all of that to get 20 fps? I understand it was a beta (or even alpha) release of an early access game compiled in debug mode and all that jazz but… Gee… 20 fps on a machine that is way beyound the purchasing power of about 90% of the population of my country? This is not exactly the best way to get some money from the product right now: you can give the game for free, it will be of no use if people could not run it. I would deduce 18 months from it. Pandemics screwed everything, and on my line of duty, I closely overviewed the effects on a whole country. I have nightmares until nowadays due that (falling) numbers, wars didn't screwed things like that - and I know what I'm talking about. Hope. IMHO, this is the real threat to this game. Everything else is just life being life and people doing what people do. Manley doesn't talk anything that could detract the game since the developers complained to him in the past that he was making them look bad. Manley stopped to do things too bold since them (or, at least, it was what I perceived) to minimize crashes on his videos. So I pretty doubt he would criticise it openly on a video. Lowne, well, this guy is a grown "kid' - on the most positive sense of it. It's one of the main reasons I had enjoyed this videos in the past - he is enthusiastic, contagiously enthusiastic. I doubt he even noticed any problem on KSP2 while playing, he was enjoying himself. Check ShadowZone and SWDenis. These ones are being pretty critical on the matter (also, on the most positive sense). "The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time."

NOTAM It came to my attention that some users may be having problems with scaled parts on SubAssemblies. I could not reproduce the problem using the latest TweakScale (2.4.6.23 at this time) and KSP 1.12.5 - at least, using Stock parts only. Interesting enough, I got a single situation where scaling parts with variants left me with the wrong Attachment Nodes. But it happened only on the first craft I created on the first time I loaded Editor. Once I saved a craft and clicked on 'New', the problem didn't manifested itself anymore. Didn't tested yet if launching the craft or just quitting the Editor (or the savegame) and reloading Editor would make a difference. Something to be checked later. History suggests that we have something wrong on the Editor. Again. But I didn't zeroed in the root cause of this misbehaviour yet, so it may be something related to KSP-Recall. No (new) misbehaviours were detected on KSP 1.7.3, I will check other KSP releases (as 1.11.2) later. Any user experiencing this problem, please report. Cheers!

Approximately 50% of the TweakScale downloads come from SpaceDock nowadays, and I set up CKAN to download from there. I only wished things on CKAN would not take so much time to pass trough. It's a whole month already...

Wow, someome from the dawn of TweakScale! Pleased to meet you! (I'm the current TS maintainer) About KSP2, I'm most interested, right now, on the minimum hardware requirements to run it. I'm not going to invest on a new Windows machine for a long time, and I want to know if the hardware I have now will be enough to run it!

Just to explain exactly what happened: you were bitten by the infamous KSP's Assembly Loader/Resolver bug. It's the thingy that keeps track of every DLL loaded, as well the Assemblies inside the DLL (C# DLLs are like zip files, a container for things, being that things the Assemblies, where Assemblies are a bunch of related code sewed together). What happens is that when something tries to load a DLL and it's not there, or the DLL it's there but it's corrupted somehow (as not being able to find dependencies), the Assembly Loader/Resolver enters into a inconsistent state and from that point, anyone trying to load a DLL or to use a thingy called Reflection from the C#'s runtime borks relentlessly. It happens that TweakScale makes heavy use of both thingies and, so, it's usually the whistle blower that yells about it. Had not this nasty Assembly Loader/Resolver bug be there, failing to load a DLL would only affect whatever was trying to load it (as, obviously, it was being loaded because it have something someone is willing to use). Since this RunSharp.dll one could be removed without consequences, it was probably copied by accident into the distribution package. KSP preloads all DLLs if finds in the GameData (unless they are inside a directory called PluginData), even if no one is going to use it. I'm guessing that this RunSharp thingy needs some dependency that was not there, and then borked being loaded, and then triggered the infamous bug on Assembly Loader/Resolver. Welcome to a very important class on Software Development: Configuration Management. Cheers!

Things are going to be even better when the CKAN guys finally aprove my entry! It's a month already in the making!!! https://github.com/KSP-CKAN/NetKAN/pull/9536

I like boeings!! here, I fixed it to ya: Humm… digging around, I found two that I can publish here: The ERJ-145 is known around here as the "Windows 98 jet", because its electronics need to be restarted all the time. It's also known as "Brasilia Jet", in a allusion to the EMB 120 Brasilia, which it succeeded. "Problem", Brasilia is also the name of a old volkswagen car from the 70s that for being cheap, it was very used on user's customisations - not all of them with a good taste. Note the two exhausts in the back - you shove 2 more wings on it and you have a ERJ-145!!!

This is too good to let it pass unchecked!!