Lisias

The Retro Computers enthusiast inside me is screaming desperately (And yeah - I have a working TI99 myself - with speech and a MiniPEB!) the KSP enthusiast is trying to shout "Kudos" over the screaming.

Nice craft! The problem with Munar Industries is that I don't know what the problem is. Yet. It an be something bad on my own set of patches (some mishaps got through, and I'm fixing as I find them). But there can be also happening on a third-party Add'On (they bork too! ) and then Munar Industries would be the Screaming Victim and not the Perpetrator - and then this stand-up guy us still lingering on your installment waiting for the victim to get back! In a way or another, I need to get my filthy claws on the problem. i will do it ASAP. But you can try - as long you don't start a savegame (new or old), nothing bad happens. With some luck, the new Sanity Checks would get something interesting and help me on the process. — — POST EDIT — — @Critter79606 , I found the problem, fixed it, and proposed a pull request to the maintainer. In the mean time, you can download this file and replace the current one (if not deleted yet) on installment. Click on 'Raw" to download it. "Safety First, CASE, remember!"

Fellow Kerbonauts, TweakScale Beta 2.5.0.7 TEST RELEASE available on the Issue #42 pn the Github. I'm kindly asking for any brave and crazy kerbonaut to help looking for new issues due the changes on the default patchs (the :FOR thingy). And yes, I'm asking twice. This new release has all the fixes I'd be working on since the last one, plus some others - including correctly scaling wheels. Now the Rover Max is usable even at 400% scale. Be aware that crafts with scaled wheels built with this release will probably not behave correctly on any other version of TweakScale (downscaling the wheels will be a problem, as they will be weaker now). Any information needed for the testing is (or will be as I realize I forgot things) on the issue itself. Binaries will be posted on the Issue too (and in no other place). Thank you! WARNING This can break your KSP, ruin your Windows, kill your pet, offend your mom and poison your kids. By the Holy Kerbol that enlighten us, please use this only under my instructions, and only if I ask you to do so! Twice. TweakScale strongly advises you to use S.A.V.E..

Yes, this is the right place. And my apologies for that mandatory "go here" button. I added a Cancel button on the next release. I'm sorry that you was caught on the Kraken Feast, but unfortunately you are on the risk group: users of classic Add'Ons. The B9 and MarkIV problems were my fault, and these are fixed already on the Github, pending a release -I'm working on it right now, by the way. Unfortunately, the Munar Industrie's Modular Fuel Tank Expansion was not tackled down yet. Since you are the second one to get hit by this issue this week, I raised the priority on the backlog. What's happening is that we kinda lose control on patching. There're more than one guy patching the same parts, and not everybody is following the best practices on it. The net result is parts with damaged TweakScale data. Such damage tamper your craft and savegames in a way that when things got straight (or damaged further by another patch), your flying crafts suddenly rescales on the fly - with very nasty consequences. This is the reason I declared this problem a **FATAL** and got a bit pushy on inducing people to complain here. Right now, your best line of action is to: Replace the following TweakScale files: GameData/TweakScale/patches/B9_HX.cfg with this file. Click in "Raw" then download the artifact and replace the offending file with it. GameData/TweakScale/patches/MarkIVSystem_TweakScale.cfg with this one. Same thing Delete the following file: GameData/MunarIndustries/MFTX_TweakScale.cfg This will keep you safe while I cook the 2.4.3.1 release, to be published in a day or two. You are somewhat crazy, you can use the 2.5.x Beta Release series - but be advised that there's a chance that these Beta thingies be even worse than the current problems by now. The good fixes are being back ported (2.3.4.1 will have some), others are not tested enough - keep an eye on this thread for the next hours. In a way or another, I strongly recommend using S.A.V.E. This would had saved my sorry SAS some months ago when I realized this set of problems on my own career game.

I'm not an Unity expert, but it's my understading that Joints are the way to keep parts working together. You can set that Joint to be impossibly strong and make things act as one, but the physics engine still handle them as two parts. You really need something as UbioWelding to create a derivative part with the characteristics of that two at the same time. As far as I know, it's the only way. That said, it would be very interesting if the game could "compile" the parts marked as "welded" on launch. You would not need to create custom parts and rebuilt the craft with them. And you could share the craft without sharing the welded parts. This would be a game changer.

Asynchronous and Concurrent Garbage Collection is a terribly complicated and convoluted code. And it makes things even less predictable. Java has G1 since many years ago, and yet high performance video-games avoid the runtime. It's interesting to see people telling that C# will solve things by using solutions from Java, which people says is unsuitable to the problem. Forget anything they told you - every single feature of the C# runtime that is being promised or even delivered was already implemented in Java in the last 10 years - some more than 10 years. And yet, Java is not the first choice for most game development. Technical debts deeply buried in the design of the runtime. There's no other way to go, people need to acknowledge the limitations of the technology and work around it. Waiting for others to fix the mess is rarely (if ever) a proper solution for a problem.

Rule 35: you may not post implicit content neither.

Remember this one? I'm finding my way on it. Almost.

Last @Ger_space reply on that thread is July 9. About 11 days, less than two weeks. You know, people have lives to live, bills to pay, sometimes we get sick, sometimes we need to travel. This doesn't means the the Add'On is unsupported.

Very long. Sega Saturn abused that concept, mainly because it was designed over Sega's arcade mainboards. At that time, multiprocessing were the only way to extract all the juice they needed from the silicon. About being hard.. yeah, it is. As anything that really does the job the best way it's possible. ABS brakes. Automatic pilots. Space flight. Moon landings. Operating Systems. AAA Videogames. While the core business of the thing is inherently different, the software that does it share all the same concepts. It's hard. But designing and building skycrapers and airplanes are too. And yet, we do it. Things should be simple as possible - but rarely are easy or simplistic.

Yep. but things does't needs to be this way forever. Unity was born optimized to run on "high speed, fewer cores" paradigma. It relied mainly on co-routines for some parallelism. Things changed. Currently, we are favoring "not so high speeds, but many cores" instead. You can get way more results on a 2GHz machine with 8 cores than from a machine with 2 cores running at 4GHz - as long you design your software accordingly. Given the probable AMD dominance on the near future, the more cores/less speed paradigm should be taken seriously from now on. How this can be applied to KSP? By, somehow, allowing big crafts to have their physics handled concurrently by more than one core. Nowadays (and unless something changed since the last time I was told about it), each craft is handled by only one core - so your biggest craft will determine your frame rate, not the quantity of CPUs available. This works better on a higher speed/lower cores paradigm - exactly what is being leaved behind nowadays.

You guys makes me feel… Kerbal. What I manage to get is more like things like this:

To tell you the true… There's a memory management approach that I think it could be used to get an acceptable common ground. Mark and Sweep (Mark and Release for old farts that used to program in Pascal or Modula). There're mainly two kind of memory allocations on a 3D engine as Unity: persistent ones (used for meshes, textures, code and static data) and temporary ones (used for meshes transformations, dynamic texturing, and all kind of temporary memory as the one used on "foreach" loops). That temporary ones are the problem. At 60 FPS, each frame you draw will consume a fraction of the memory as temporary data - and almost none of "long term persistent" ones. At 120 FPS, you double the temporary memory allocation for doing the same job (one second of the game). And this is why I recommend people to use the lowest FPS they can be comfortable using - to lower the demand for that temporary data and relief a bit the Garbage Collector. But I digressed. If all that data being allocated for temporary tasks each frame, instead of being drawn from the HEAP managed by a GC, could be drawn from a Mark/Sweep one, you could simply get GC out of the equation on the FPS thingy: on the beginning of the frame, the Engine would Mark the current position of the Pool, and let things eat the memory as they please. On the end of the frame, the Engine would Sweep all that memory back to the pool. Things in need to allocate "persistent" memory would need to ask it explicitly from the GC managed pool. To have both managers alive at the same time, one of them would need to consume memory bottom up, while the other top down - the the GC, at the rare occasions it would need to be called, would need to carry some extra tasks to compact the memory under its control to keep it out of the way of the Mark/Sweep engine. Of course things will not work so easy on Real Life, but yet, it's an plausible way to minimize the impact of a GC dependent language on a Real Time, Mission-Critical task as rendering a 3D World on a heavily memory hungry game.

Yep. You are not a programmer. CPU is a finite resource - you use CPU cycles on something, you can't use that cycles on anything else. And when some CPU vendor suddenly has to disable a crucial performance feature on their CPUs due bad decisions on the past (I'm talking to you, Intel!), then suddenly a lot of CPU cycles are not available anymore and things that used to work fine now don't. The problem with home made Add'Ons is that very few people are skilled programmers able to take the best design and implementation decisions - and the ones that are, most have very little sparing time in order to check their decisions against a nasty and harsh entity: Reality. You can't have the cake and eat it too. And one size doesn't fits all. These simple phrases resumes the worst problems software developers have to face in order to get the job done - on an environment that's changing everyday, and not necessarily for the better.

Well., finally some fun on working on TweakScale! I'm gradually fixing and restoring some long time deactivated or unfinished support on TweakScale. And besides not always working as I expect, true is that this is rendering some good laughs these days. Expect some news on TweakScale thread soon!

By plain changing an already stablished behaviour, things that is being unnoticed will start to be noticed, while things that is already noticed will be silently fixed. Historically, unnoticed things starting to be noticed cause nasty consequences that are hard and cumbersome to handle while potentially breaking currently played savegames. I already have my hands full of those that need to change to prevent KSP to crash, so I'm reticent to introduce a new one when another solution is available - even if less convenient for some people (including me). Add'Ons that doesn't support TweakScale needs support for TweakScale instead of blindly adding new behaviours that can break savegames that use Add'Ons that support TweakScale with the current set of rules. I agree with you that perhaps it would be better if it had be implemented from the beginning, but since Stock parts never used this feature, this passed through and now things are how they are. That said, I'm not expecting that Add'On Authors will do the job for me. Please list to me the set of Add'Ons that need this and I will gladly add a patch myself, or propose a Pull Request for the ones that already have it and need this change. The new behaviour is currently implemented and tested on this issue. Third Party Add'Ons that need my intervention will be tacked down on this one.

That caught me with my pants down. I don't see a need for a ModuleGenerator that consumes resources with ModuleResourceConverter available - but things are what things are. I'm surely out of context anyway. I have a concern about stablished behaviour. If the module is able to consume, so it's a fact that TweakScale needs to scale the behaviour. But since it never has scaled it before, and since Stock doesn't use it (and then most people follow suit on it), changing this now on a minor revision is unwise, as a lot of people suddenly will have their resources being consumed way faster then before. What about a new TWEAKSCALEBEHAVIOR? A "ModuleGeneratorExtended" for the ones willing to use it this way, but without affecting people that never had to cope with this before?

Dude, my career savegame had 182. I managed to drop it to 172, and I'm still fighting Sometimes, it's a third party Add'On that messes up, and we end up solving the problem by "fixing" the Screaming Victim and not the perpetrator. Since I'm using MK3SE on my gaming, and I think I have this too there, I will pursue this for sure in the near (hopefully) future. 1) Some Add'Ons choose to pack the dependencies on the distribution ZIP to make things easier to manual installers. As long as they have a .version file pinpointing to the correct place where updates are published, I don't see really a problem. I can't talk for any other Add'On Author, but I stick to the License - if the License allows, the permission is already granted. Things get hairy only when the Add'On being packed is tampered somehow (with local fixes on the patches or code). While some Licenses allow it (and, so, such permission is already granted), the Packager must state clearly that such Add'On was modified, and should support him/herself the thing - otherwise, people would file bugs to the original Add'On Author/Maintainer, what's inconvenient to say the least. 2) Exactly, you nailed it. But TweakScale is not always involved, there're third-party patches (most of them somewhat aged already) that apply patches for parts that TweakScale does't supports, and then that older patches change some Add'On part that got TweakScale support from the Author on a later date. And then we have a Kraken Feast. 3) :FOR is to be used to the "Canonical" Maintainer of the Add'On/Patch. Since TweakScale directly support some Add'ons itself, I'l use ":FOR" on these parts soon. :NEEDs, so, is to be used by everybody else. Check the Orthodox Development Branch - you can check the Beta Releases Issue for the most recent Betas if you want to take some risks and help me on the testing! I didn't releases these new patches yet due a somewhat numerous quantity of Add'Ons that would break with then, and this is precisely the reason I'm implementing the Sanity Checks and Warnings et all before doing it. I need to pave a way out of the mess, or people's savegames will be broken...

I finally got myself together on this issue. What's happening is that Module Generator doesn't consume resources. It generates them from nothing, and that's it. You can check this on the only two stock parts that use it: ./Squad/Parts/Electrical/RTG/RTG.cfg ./Squad/Parts/Utility/launchClamp1/launchClamp1.cfg What you need to to appears to be doable using ModuleResourceConverter. Check ./Squad/Parts/Resources/FuelCell/FuelCell.cfg for an example.

With external seats having now ejection functionality, how hard would be to add this to the Add'On?

Today is this one.

Obligatory mention. In order to pretend this is on-topic, I want to remember that KSP is built in C++ and C#. Two of the horses below.

That would need more knowledge than MM has (and need to have). Sometimes such duplication is wanted (as an array of sections), sometimes it's not. We would need to tell MM about it. I have a similar problem on some Sanity Checks for an Add'On of mine. Sometimes a datum can be zero, some other it can not (or KSP capsizes) - so there's no generic rule that can be applied, you need to specialize for each datum. And this can vary module by module. So it appears to me that this task need to be performed by the modules themselves.

Hi. I would had answered sooner if you had posted it on TweakScale Thread. I have a workaround for these parts on this post: You can also download the fixed patches direct from the repository, and overwrite the current ones: https://github.com/net-lisias-ksp/TweakScale/blob/dev/emergencial/2.4.3.1/GameData/TweakScale/patches/B9_Aerospace/B9_HX.cfg https://github.com/net-lisias-ksp/TweakScale/blob/dev/emergencial/2.4.3.1/GameData/TweakScale/patches/MarkIVSystem_TweakScale.cfg (click on 'Raw" and then save to your harddrive). These files are to go to the next TweakScale revision, 2.4.3.1, that will be issued in the near future.

If the thing is not working, how the performance can be inferior? Nice catch. I had forgot about this. I remember that once I set all DLLs I found on GameData to be "-w" (not writtable) and by some weird reason KSP didn't worked on my Mac until I shoved the "+w" back. It happened too when I tried to run KSP from another user than the one that's the owner of the files (probably due the default "G-W" permissions). We posted at the same time. You hints me that it was, indeed, a file access permissions problem (not necessarily the one I mentioned above)