Lisias

Support for Real Fuels is not done yet, it will be available when I finish the respective TweakScale Companion. I don't have the slightest idea about the reason RF and TweakScale worked 12 months ago, and I didn't changed anything related to it in the mean time. Whatever it happened, happened by a 3rd party (perhaps a change on RF that I didn't detected, perhaps a 4th party interfering somehow). In a way or another, this will be implemented on the next TweakScale Companion release, so there's no need to keep such diagnosing from your part. Humm… Since we are here, there will be a catch… The TSCoFuel will probably only work with the next TweakScale 2.5 release - I will not further develop the current 2.4 for obvious reasons, but I will keep 2.4 available for some months in parallel in case someone can't use 2.5 for a reason or another (and then I check that reason and fix it on the 2.5).

Humm… Weird… Let me see what can had gone South from my side... (hack, hack, slice and hack again) Nope, I didn't changed anything from my side, and did a superficial peek on RealFuels and I think they didn't neither. Do you have some other Fuel Switch installed? Things usually go South pretty badly when more than one Fuel Switch is installed on a part (as B9PS and FSFuelSwitch), and TweakScale withdraws itself from these parts to prevent a major borkage...

ANNOUNCE Release 4.2.1.0 is available for downloading, with the following changes: New Action to turn on whatever is the current mode at the moment The Toggle Action was correctly labeled (and localized) Less confusion on Editor when configuring Actions Enhanced API to make easier 3rd parties interactions The different modes toggles now really toggles the Light no matter what is the current mode. I finally got some time for really playing KSP again, instead of squandering my free time on diagnosing problems, and then I realised that some small details on Aviation Lights could be slightly improved. So I did it. Downloads on the OP. This Release will be published using the following Schedule: GitHub, reaching first manual installers and users of KSP-AVC. Right now. CurseForge. Whoopsie™. SpaceDock. Whoopsie™. The reasoning is to gradually distribute a potentially Support Fest release in a way that would me allow to provide proper support if anything else goes wrong.

Commercial use are, well, "tolerated" - we would not have parodies otherwise (like Star Wars vs Spaceballs). But, it also bring liabilities to you - Ok, you can try to exploit it commercially, but if you lose a Fair Use claim on a Court, you will pay some damages based on the money you earned on the stunt. Unless you are willing to make a living from this thing (and, so, will have a budget with money reserved for legalities), I suggest you to avoid commercially exploiting anything you do under the Fair Use. And this includes Patreon and "Donations" - without filing a Section 501(c)(3), you need to even pay taxes over these "Donations". Only Non Profit Organisations can receive Donations, for everybody else the name is "Funding".

Ah, that's the magic: you already have it - but there's no way to access it under EULA and Forum Guidelines. However, the Fair Use Doctrine says that if something is installed in your computer legally, you are entitled to access it the way you want - what you are not allowed is to redistribute the material, as this would be Copyright Infringement. So: If you had legally bought the game; If you find a way to reach the 3d model respecting the EULA and Forum Guidelines; If you have the skills to transform the material into something that fits your needs; You can't outsource it, as this will mean you will send IP protected material to 3rd parties to be transformed, and even if that 3rd party had bought the game the same, they would not be able to send you back the changes under EULA. You can adapt the model to be used on blender and make a video with it - again, you can't redistribute the model neither your derivative, but you can use it on a movie and publish it on Youtube legally, for example. You will be still subject to a takedown if P.D. doesn't like what you are doing with their Intellectual Property but, really, this is valid for everybody that publishes a video or even a ScreenShot - the work is yours, but the I.P. still belongs to P.D. and if you do something that they consider deleterious to the I.P., they are entitled to ask you to put it down no matter what the material itself is. So having access to the 3d model by knowing how to access it by reading the Source Code will not give you any unethical edge over anyone else (what's not the same when someone uses shady practices to accomplish that), neither P.D. will lose anything by allowing this to happen legally because, well, people are already doing it on the wild - and without bringing direct benefits to the Franchise, as these works can't be published here on Forum.

As a rule of thumb, unless you are playing com a completely vanilla KSP, you should install and keep updated the TweakScale Companion ÜberPaket (downloads on this page). It's published on SpaceDock, so there's a chance that it's indexed by CKAN (but I don't know if it does). The ÜberPaket consolidates all 3rd party support on a single and convenient package, and it's smart enough to only activate the support that it's needed (so it's safe to install a package for a thing you don't have installed), and this is the Stable version of the Companions - everything available only as a discrete package on Github is something that are still under testings and I'm afraid to push into the ÜberPaket for the mainstream until further testings prove it's safe. On this specific case, the Companion for Fuel Switches (once it's completed) will be available only on github for a couple months until I'm confident that the thing will not play havoc with the mainstream. Cheers!

Who by the click lives, by the life will be clicked!! @AlamoVampire!!

I can't make promises about deadlines, but I hope to have at least this one finished in the next 4 weeks. There's already code written, but my window of opportunity early this year was squandered by unrelated problems and then Real Life© kicked, and then I had to stop whatever I was doing. Keep an eye on this page: https://github.com/TweakScale/Companion_FuelSwitches/releases It will have a release when MFT and RF are finally implemented - I usually publish early access releases on that page for a couple months before pushing it into CurseForge and SpaceDock, embedded on the TweakScale Companion ÜberPaket. Cheers!

That was, actually, pretty cool!!

And here we have yet another fellow Kerbonaut caring for the Franchise and not willing to commit to shady practices to reach their goals. In the mean time, some other without this ethical problem keep (ab)using the EULA and Forum Publishing rules… Seriously, this Community needs the KSP's Source Code, or it will be shadowed in the long run but these not strictly ethical people - the next step is creating their own Community, what may not be a so distant problem as one would think… (hint: Discord).

Welcome! I moved the discussion to the TweakScale's thread. Cheers!

Moved from another thread. Unfortunately, yes. I do not support CKAN anymore. This doesn't means you are on your own, TweakScale IS SUPPORTED, so any problems you get while using TS will be diagnosed and fixed. But I will not handle problems created by CKAN itself, as that horrible breakage that happens when CKAN mess up things and renders TweakScale unusable (most of them are caused by KSP itself, but yet…). These problems are time consuming to diagnose and fix, and I'm barely have time to support my own add'ons these days, I need to adjust my workload somehow. So, if TweakScale was working and then you ran CKAN and it stopped working, this is a CKAN issue and you should ask help to the CKAN guys. I can help if I have time available, but absolutely no promises I will ever be able to respond a post about. If TweakScale is misbehaving, or is issuing Warnings or Errors about Parts, then this is something related to TweakScale and I will gladly help you on whatever I can to have your problem fixed. As a Rule of Thumb if you managed to reach the Main Menu and only there TweakScale starts to yell, it's a problem related to TweakScale. Please report and I fill fix it. if TweakScale yells before you reach Main Menu, then this is 99.95% of the time a problem unrelated to TweakScale, and I suggest you reach first the CKAN guys for triage - if they diagnose a problem on TweakScale itself (there're still that 0.05% of chance), I will fix it. Cheers!

Oh, no. I already handle CRUD (Create, Read, Update, Delete) features all the time at Day Job™, I don't want to handle SQL statements on KSP too!!! Ok, serious now. That was the most sensible statement of the whole thread (including my posts). Kudos! Eternal Mishaps of the Englishless Mind. Understood. (now I need to decide if I agree with that, but that's a fight to be fought another day! )

Hi, TweakScale maintainer here. This is not a problem on RealFuels, it's just lack of support on TweakScale on handling Real Fuels. This is currently Work In Progress here: https://github.com/TweakScale/Companion_FuelSwitches/tree/master/Source I'm working to push this thing into the wild this month! Cheers!

There's an ongoing discussion about what the term "Kerbal" should mean (here). Some people thinks we should see the Kerbals as a highly advanced civilisation, others as janky, others (me) just want to have a good time playing with them and that's it. But… There's a trend thinking that we should treat Kerbals as they would be Humans, and while I was thinking about, this marvellous sweet history passed trough my timeline: How a Marine guard refactored a Tomcat into a convertible. This is not about technology, it's about pure human behaviour, "innovating, adapting and overcoming" an amusingly sequence of mishaps into a Rectangular Pieces of Paper Storm of epical proportions. Delicious. https://theaviationgeekclub.com/the-marine-guard-that-inadvertently-jettisoned-the-canopy-from-a-parked-f-14-to-sit-in-the-tomcat-cockpit-the-missiles-aboard-1-aim-54-1-aim-7-and-1-aim-9-did-not-have-the-pins-but-were-not-damage/ Art imitates Life. The Kerbals are like us (and vice versa).

PEGI 16, more likely. And you will need to ask PEGI for your answer, as I'm only the messenger. But at least their rationale can be easily found: This rating is applied once the depiction of violence (or sexual activity) reaches a stage that looks the same as would be expected in real life https://pegi.info/what-do-the-labels-mean

Would you be paying a bit more of attention on what me and other people are posting, you would conclude that I didn't quoted 90% of your post because I didn't had anything to add to it. From my very first post on this thread: And such you did it. I only quoted the part of the post in which I had something to reply to. Lower your guns, please. I beg your pardon?

These bits a bit out of scope, so goes on a spolier live by the sword, die by the sword… Anyway, I think we can conclude that both extremes are bad. Autostruts can be useful, I wish they weren't dirty cheap - I pay nothing by using them, neither the craft gets heavier neither. And I think they should cost Funds and they should cause penalty to the vehicle's mass. It's what we get when we reinforce real life structures. I remember once using AutoStruts on the Struts in order to get the result I wanted - simulating spars, stringers, spines… You name it. But then they removed the Autostruts from the Struts and some of my crafts never left 1.4.5. (sigh). Even KJR I find useful (to make that monstrously heavy ships from the SMCE add'ons), but I wish I could selectively use them on some crafts and not on others. It's the only complain I have from it. Whatever they do on KSP2, I hope they allow us to selectively use it or not on a craft by craft basis. You see, even us, humans, behave like "Kerbals". You need to read some histories from the WW2 era about how military used to have fun, all of them - from army to navy, including airforce. Some Navy dudes, on Vietnam, once decided to bomb someone using a toilet. No kidding! The History of Human Inventions are littered with "Kerbal" designs, both the stupidly awesome as well the awesomely stupid ones! For every thing someone ever did on KSP, someone on Real Life™ has already designed, tried or at least thought about - my aircrafts are interestingly pretty similar to the soviet ones, by the way (both the good as the bad). You are wrong. There're parents doing real parenting in the World, not to mention secondary damages, as losing partnership opportunities (as was done with Kerbal Edu - no Educational Institution will deal with PEGI 18+ titles). You also can't advertise PEGI 18+ games on medias intended for kids and teenagers, and so on. Unless you are really targeting PEGI 16 and up, it's really a bad move doing anything that makes you get such classification. I, obviously, disagree. The argument in dispute was about wobbliness and how it would "kill the game". I had shown you two games with wobbliness and one without, and that and only that was my argument. Lack of wobbliness didn't made Juno get an edge on KSP (both on them), and the wobbliness didn't plummeted KSP¹ user base once Simple Planes and now Juno happened. Additionally, it worths to mention that Juno recently published an update made in collaboration with ESA, something similar to what was done in the past to KSP with NASA and ESA. These games have more similarity than you are implying. We are not telling there's no problems on KSP2's wobbliness. We are telling that completely removing wobbliness is a bad move, at least without a proper substitute. Two completely different things.

I'm a player, not a game publisher or designer. I think you completely misunderstood the meaning of the post. But since we are here, there's this little nice game where rockets never wobble. It's called Juno: Origins. So we have a game where there's wobble, another where wobble is still in heavy need of work, and a third where there's no wobble. What games are making more money to their publishers is left as an exercise to the reader. I like the idea, but on the other hand I think they need to carefully weight how much reality they want on such crashes, otherwise they would risk a PEGI 7 or 12 (worst case scenario, PEGI 16 but I think I'm pushing it a bit too much). For the sake of comparison Bean NG.drive, where very realistic vehicles crashes in a very impressively realistic way, use Crash Test Dummies instead of "living" characters, and yet it got a PEGI 16 classification. No kidding, the rationale appears to be the abuse of real life vehicles in a realistic way. KSP¹ is PEGI 3 and IMHO IG should do whatever they can to keep such classification on KSP 2, or at very worst a PEGI 7 - and, so, they need to avoid too much realism on how the vehicles are R.U.D.ed. So, too much realistic crashes should be out of the menu - not to mention the Kerbal's fate: on KSP¹, they don't "die", they "poof", got a Missed in Action on the Hoster and two hours later they "respawn" as "Available". That said, there's nothing preventing them to sell a DLC with realistic crashes, implemeting what you are asking. The game itself keeps a PEGI 3 or 7, and people old enough buy the DLC. The best of both Worlds.

I don't necessarily disagree with that. I want something, being the wobbliness better than nothing. You see, I think this is the Elephant in the Room. I had bough Juno Origins. Pretty nice game, I play it now and then, but… By some reason, I come back to KSP when I want to have some good hours of fun: doing something stupidity awesome, or most of that time just awesomely stupid - as long it's something that I could curse while laughing, or laugh while cursing. This is the reason I spend so much time playing and modding this game. I don't have absolutely any objections on going "serious" (it's the reason I have so many aviation mods on my rig, from ILS to VOR, not to mention GPWS as an example), but even when I'm playing "serious", there's a ludic background on the play (like, hey, let's distribute some diapers to the PAX instead of vomit bags - #JebediahFeelings). I see these KSP2 videos and I like what I see as long it's someone else playing. But I'm not seeing me playing it for more than an hour. Hell, I have already Juno (with its astronauts) and Orbiter (not even that) for "serious" play and it's days since I fired up Juno, and months since I fired up Orbiter by the last time. The Kerbal's "goofiness" is what makes the harsh path to the success palatable for me. Suggestions are welcome. How about something like this? Not to mention aircrafts, how something like this? (the craft had a chute, no traumatising events on the video) And how you suggest the game should support the user's diagnosing for such problems, once they happen? I'm not being picky, I'm trying to open a brainstorming session. Yep, the Elephant in the Room I mentioned above.

Every single game I ever played has a set of rules and constrains, and you are punished somehow by not respecting them. Granted, every single one of them so have settings or hacks so you can cheat your way on the game. I don't have the slightest problem on having these rules and constraints being deactivated for people not willing to cope with them. I just don't want them permanently removed from the game. Doing what I intend by compromising with such rules and constraints are part of the fun. As a matter of fact, my only complain about the autostruts (other than a bug on it since 1.2.2) is that it's dirty cheap. It should cost you both money and mass by using them, as it happens when you reinforce a structure (as using bigger spars on an airplane wings). Yes. My game, my rules. I don't try to tell you how you play your game, I don't see why I should let you tell me how to play mine. We will need to agree on disagree on this one. And let the users vote with their money. Hint: check the majority of screenshorts and videos around.

The problem we are facing here is that "wobbliness" happens when we abuse the part's strength. I don't mind replacing wobbliness with something else, as long the limits and constrains are there, forcing me to rethink the designs to cope with them. But what would be a good substitute for it? But that's the point. There's no wobble in real life, but we don't build rockets and places in real life as we do in KSP neither. The problem remains: how to simulate and punish bad, structurally unsound designs? Kerbal is meant to mean whatever the player wants them to mean. Players liking janky designs will see Kerbals as janky. Players liking "real life" designs will see Kerbals are realistic. Players liking alien style designs will see them as a highly advanced civilisation. And so go on. Most people like to have a good laugh when playing, and so a janky Kerbal tech is usually the way most people go. There's a reason the lowest tech batteries resemble D Batteries - because it's fun this way.

Crash to Desktops are usually something inside Unity itself, and so KSP.log can't log it most of the times (the process dies before KSP can write something into it). We need the Player.log from Unity, and finding it it's a but messy. Unity tells where to find it on this document: https://docs.unity3d.com/2019.4/Documentation/Manual/LogFiles.html TL;DR, you will find yours on %USERPROFILE%\AppData\LocalLow\Squad\KSP\Player.log where is %USERPROFILE% usually C:\Users\<your login name>. False alarm. Principia loads native X86 DLLs manually, but it places them on a directory which makes KSP thinks it's an C# Assembly, and so it borks trying to loading it. Since this DLL is not an Assembly, the bork happens before entering the critical section inside the Assembly Loader/Resolver where things go South, so nothing bad happens. It's nothing but an annoyance, but if the Principia guys rename the x86 directory to PluginData/x86, KSP will not try to load such DLLs and this will save us a error entry on the KSP.log.

With all the due respect, Matt Lowne is an ophthalmologist, not a rocket scientist neither a game designer. If your rocket is wobbling, you are doing something wrong. The alternative is punishing bad designs by just collapsing them and letting the gamer trying to figure out what they did wrong. That said, I'm not a fan of wobbling by itself, I want something to punish bad designs as well the abuse of the parts' limitations, being it wobbling or not. But if you remove the wobbling, you need to replace it with something else - perhaps flexing of the rigid bodies? I surely want my wings to bend under higher loads instead of just snapping out once their limit is reached, and now that the wings are a monolithic block being procedurally generated, we don't have wing bending anymore (and this is bad). And whatever this wobbling replacement would be, it needs to be "auditable" so the user can diagnose the problem by analysis and thinking (and posterior trial and error) - but without demanding the user to get a rocket science degree first, this is still a game, not a training simulator for professional rocketeers.