Lisias

This will not happen. ARR is ARR — there're some loopholes in the law that can be exploited to do some maintenance, but they are shady and probably non forum compliant, so it's good as nothing for us here. I understand that SMCE transferred the rights he planned to, and if he didn't do it further, t's because he didn't wanted to do so, and probably never will. More important than learning Unity is learning 3D modeling and texturing. I remember reading that the configs for the parts are under a permissive license (this information needs to be validated, I'm talking from memory, and my memory fails sometimes) so in theory it's possible to launch a replacement Add'On with the same configs but all new art. I could use some help on KAX too, my 3D modeling and texturing skills are amateurish and my time somewhat scarce nowadays to invest on it. But first things first. My advice to you is to learn a good (and preferable free) 3D Modeling tool. I'm using Blender, by the way. Unity goes second, there's no real point on using Unity without 3D models to work at first place...

That's my point. No one should agree or disagree with me. They should agree or disagree with the PR/guys. Where are they? Good products don't sell by themselves - don't believe on this lie. Products are sold by what people think from them. You have a good history of excellent services ? Your customers will do the PR for you. Otherwise you need to hire some PR guys. The best product on the World worths squat to me if I don't know it exists - or I don't know what it can do for me!

IMHO, Mission Builder is the feature that could do a lot better with some support from the PR guys. It's a hell of a interesting feature, it's a way to allow players to create their own content in a technically safe and supported way. They are going to the right direction, I think. But there's a thing called inertia - it's exactly the same way a rocket launches: 80% of the energy budget is expended on reaching and stabilizing an orbit - from there, everything is cheaper. I think that MH is the way to go - but it needs MOAR BOOSTERS. I said 85%, not 100%. But yet, you are right. There's no space for complacence on this industry. We bork? We fix or we fail. Rockets have a very small tolerance for glitches,, by the way. But yet - that 15% of local failures would be way easier to detect (or, at least, not to hide under Unity's carpet) and fix was not that huge unprotected surface of attack given by the flaws of the engine. I'm not excusing them. I'm explaining what I think it's happening.

That's the catch. We are not helping them. We are helping ourselves. I would really appreciate that by helping ourselves we end up helping SQUAD too - but, see, this is not a hard requirement.

You #BlameUnity and you will be right about… 85% of the time. Hard to criticize them for doing that. However, Good 3D Engines are expensive. You pay serious money for support, or you pay serious money to people that does it for you. So I think you are on the right track - unholy agreements on the top brass of two companies to push a bad product is not uncommon at all (Microsoft anyone?). I hope we don't get involved on some kind of UnityGate. You are not wrong, but IMHO you are right on the wrong way. In the past, the workmen were responsible for choosing their tools. Now, someone above the guy is the one that choose the tool - however, there's a break rupture on the chain of responsibility here - the one that calls the shots is not the one being blamed by the bad results. It's almost schizophrenic : the workmen manages to get something from that bad tool, managements gets the glory. The tool is so bad that he could not get the needed result, workmen gets the fallout. And management lives to ruin another day. Of course we also do screwup a lot. Kraken knows how many times the team had to burn the midnight oil for something I had borked marvelously - but this is the difference: good workmen screws up, good workmen take the responsibility and fix it as soon as it's possible (what's not the same as soon as you wanted). This sacred chain of events fails miserably when one, just one person on that chain of responsibility is allowed to walk away from his borks. From this point on, workmen spend most of their time defending themselves from each other instead of doing their jobs. Politics, IMHO. Ditching Unity on the input stack in favor of a freely available open source solution will play havoc to Unity's image (as they need our help on this, uh?). I said before, and I will say again: using Unity on the beginning of the project was not a mistake. KSP would not reach what it reached using C++, I have to shove my proud somewhere else and admit that C# played an important role on this. But the time to find alternatives is more than due. The World is going UNIX for good. Even Microsoft (with the Linux subsystem) had yielded to that - not to mention MacOS and PlayStation (FreeBSD derivatives). If Squad doesn't does something soon, someone else will - and this guy will harvest what was seeded by KSP. No one works for free. We always want something back - Open Source is about the Stone Soup (yeah, I'm that old), not about 'working for free'. People work for something - and it's better for everyone when everybody knows what each other want. Worst. It's dangerous. Every hour a good developer spends trying to fixing Unity and Squad's screw-ups, is an hour he/she is not improving the game - or enjoying themselves doing enjoyable things. What's defeats the reason we bought the game at first place. Given that most Add'On authors are not professional developers, and the ones that are, do not necessarily have the skills to lead a project, it's reasonable to conclude that a lot of problems will arise from the Add'Ons themselves (as most as from Unity, I say). Relying on this scene to provide a vital, core business feature (INPUT DEVICES, BY KRAKEN`S SAKE!) is, essentially, feeding the competition.

Smart guy. In God Code, we thrust! (everybody else pays in cash!)

I believe they do, and place bets on the contents. At least, it's what I would do. Someone needs to baby-sitter the continuous integration services, and bets was how we decide these things at my time. Mail servers are particularly vicious. :-P

YES. But not with Module Manager 4. You need to use Module Manager 3 in order to work. I will spare you the sordid details of the problem, just thrust me. Detailed information about the fork I know for sure is kinda working is here: It only support 1.3 style parts - i.e: it will not weld correctly parts with MODULEPARTVARIANTs. Other than that, it works. I don't know about the working status of any other fork - perhaps they are working too, and since some people didn't liked too much this fork of mine they can be a better option perhaps. So you need to try it for yourself. Backup your savegames - just in case.

I gave some thinking on the thing, and realized that I don't need to provide a new interface for the users. Just a new option for the Authors. This reduces the troubles to be solved by half. So, I have the following proposition to you: PART[fuelTankStreteched] // FL-T400 Fuel Tank with Streched Variantes { <blablabla> <blebleble> <bliblibli> MODULE[TweakScale] { type = stack defaultScale = 1.25 VARIANT { name = stretched scale_x = 1.0 scale_y = 1.15 scale_z = 2.0 exponent_scales = x,y,z } VARIANT { name = more stretched scale_x = 1.0 scale_y = 1.50 scale_z = 4.0 exponent_scales = x,y,z } <and so goes on> } } Adding "VARIANTS" to the TweakScale section, where Add'On authors would add the desired variations of the base part with the stretching he/she wants. The scaling exponent to be used would be the same specified on the parent TweakScale, but the dimensions to be used need to be specified to cope with the bidimensional and mono-dimensional scaling (to be applied to solar panels, for example). Once the VARIANT is selected using a new Tweak on the Tweakables Menu, the user still can apply the "user" scaling as he always did. I'm unsure if I should allow "TweakScale/Variant" to be injected on preexistent parts, however. It still doesn't copes with the texturing stretching, but that can be fixed later -the problems can be solved one by one. Assuming this would be a problem to be dealt. @linuxgurugamer. what do you thing of this solution? — — — POST - EDIT — — — https://github.com/net-lisias-ksp/TweakScale/issues/43

I had read the post, and what you explained is not there. I don't know SEP neither KIS intrinsics, but I know very well the breakage that patching partnames using wildcards can do, since my intervention. Thanks for your attempt of correcting what appears to be a mistake, however. Gave me the chance to reforce my message. And to file a enhance request perhaps? Since spaces are being used on patches (besides being not exactly a best practice), wouldn't be better to create a meta-char to match exactly a space char on part names and prevent the risk of the wildcards as a kludge to overcome this?

Exactly that That would not apply the patch, also, for anything matching the pattern [AKI<any_char>GolfClub]? I got a nasty savegame corruption once due an Add'On doing something similar, and ending up patching a lot of unrelated parts. There's really a need for using a space on the name? Why not "_" or "-" ?

What makes the thing yet more important to be analysed by me. TweakScale currently complains about negative mass, but doesn't know when this happens due a TweakScale patch or not. If there're more situations where this happens, I want to give a peek on them to be able to know when I should intervene and when I don't. Supporting my own Add'Ons is already work enough, I don't plan to support other people's work.

Here, I fixed the fix for you. (in brackets and italics)

When about 50 of that guys listen to that one, yes - or you are out of business. Common business, welcome to Mass Entertaining. Be worried is not a problem - as long fear doesn't come together. Be worry is a wise thing when handled correctly. Every good aircraft pilot worries to make a mistake and take the plane down - and this is the reason so few of them goes down.

Temporary measure, I promise. Sooner or later (place your bets on latet, however), they will be supported. That was a finding! Could you please send me your KSP.log and Module Managre caches? If possible, here: https://github.com/net-lisias-ksp/TweakScale/issues/42 Your help will be hugely appreciated!

You see, X64 Unity appears to be still a crock. I have strong reasons to believe that the Linux problem on the input devices affects Windows too - but are masked by the kludges inside windows to cope wth x32 and x64 binaries, Check pages 3 and 4 of this:

It's more a game design decision than a inherent 32 bits problem - they decided to keep all textures in memory, even when not needed on the scene, to prevent loading times on flying. Our main problem were chipsets, not CPU. The x86 had 32 bits for data bus but had 36 pins for memory addressing - what renders 64G of theoretically addressable memory. However, all the chipsets of the era only implemented 32 bits addressing and, worse, usually split the addressing space in two, lower half for memory, upper half for use by expansion cards. (it's where the GPU memory is mapped to be accessed by the CPU). Would be using MIPS, SPARC or even ARM as mainstream home computing, we would not be suffering from this. That said, in 2011 (when the first KSP versions came to public) 32 bits was still a thing. We are talking Windows XP era here, and the 64 bits XP never got mainstream - you publish a 64 bits game, you shut yourself out of 50% of the market share! However, given the design decisions, I agree that 32 bits support should be ended with 1.3.1, and the 1.4 era should be 64 bits only.

Yes. Ubiowelding. However the current forks are outdated, at least until the moment. There're a lot of info on this thread: The less bad one appears to be my personal, interim fork. It's not working on 1.7 as I was Informed, but you can weld things on 1.5 or 1.6 and use the welded parts on 1.7. I didn't really confirmed this yet. https://github.com/net-lisias-ksp/UbioWeldContinuum/releases You need to install this too: https://github.com/net-lisias-ksp/KSPAPIExtensions Module Manager 4 changed something important (besides trivial) and no Ubiowelding can work with it. You need to use Module Manager 3.

I don't like using my money on anything unless I need to do so - as anyone else. But I also realize that I can't eat money, I don't enjoy money, and watching my account using Net Banking is way boring, no matter if there's money incoming (rare) our outcoming (usually). So I concluded that I need to expend some money on eating and Leisure (no, Larry, keep your suit - I'm not talking to you). Since money doesn't fall from the skies (mostly) neither grows up on trees (never), I have to spend a lot of time working to earn it. And this makes my Leisure time somewhat scarce (Larry, shut up!). And so I'm prone to invest some more money on it due that. Besides all the problems we had in the past year, KSP is way the most funny, entertaining and challenging game I played in decades. It's so good, besides being terrible sometimes, that I'm even spending a good part of my leisure time trying to tackle down the terrible things that bitten me last year. But I have a problem: I'm not the only one that needs money for eating and entertaining. Squad's dudes do also. And so, in order to have them (or anyone else!) working on a game so I can enjoy it, they have to face the exact same problems I do : they have to spend most of their time doing things that earns them money. Since I need this game ongoing so I have what to do on my free time, I need that guys to keep earning enough money so they can spend their working time on it. So I pay for game, including MH - even by not really enjoying the Missions - at least for now. I think that most of the people complaining about this are young people that are not used to have scarce Leisure time (Larry - get out of here!), but have very scarce budgets, so is kinda understandable to see some complains on the matter. But… really, some grown-ups should know better sometimes. Hi. TweakScale dude here. Yeah. That one. Coding is easy. Software Development is hard. That's the way it is. Every single major change on the game leaded to breakage and this was unavoidable not because it's impossible to change without breaking something (sometimes it is, but not always) but because people are resistant to change, and usually they reflect this mental posture in what they are doing - include coding. The changes on 1.7, at least from the TweakScale point of view, had the same impact I had on 1.6.x : Zero. Not because there weren't changes, but because since 1.5 I conceded to the fact that things change and I'm taking precautions to prevent at least the nastiest breakages. You can't have the cake and eat it too, so the price we pay for this prevention is some lateness on supporting new things: "if I don't know what's this, I don't touch it". Just now I'm finishing support for most of 1.6.x series of new parts (not because it was hard, but because a very important sanity check needs to be implemented and I postponed too much the remaining tasks - my mistake). So, yes. Devs took that into consideration. Marvellously from my (somewhat limited, granted) point of view.

Jokes apart, there're really risks for serious damages. I foolishly installed what would be 2.4.1.1 (and to check another thingy, I didn't was aware yet of the potential problems) on my Career installment, and everything worked fine for some time - until I installed an old Add'On. Dude, this dud sas didn't had recent backups when i realized the breakage it had done, and I spend the whole week fixing the mess by hand - I was lucky for being able to recover from the damages, but I also became a sort of expert on the thing (surprised? ) so everything ended well. But let me tell you: while using this Beta, keep constant backups. Use GIT and manage changes on your "saves" folder, use Apple Time Machine, anything. I need to detect exactly all the ways that things can bork due the :FOR change before risking it on the mainstream. And this is a needed change by itself, as a lot of headaches will be prevented by jumping on the :FOR ship .

Fellow Kerbonauts, TweakScale Beta 2.5.0.2 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. 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. — — — Post edit — —— The rationale about the Wanring can be found below:

I see the reasons behind your rationale, and they are solid as rock. But rocks can be eroded by water, given enough time. The main problem on the console is that they are similar enough to PCs to make a direct porting to them look easy, but they are not similar enough for effectively deliver that except on the simplest use cases. But this is going to change in a way or another (and perhaps both ways) as the new Console generation is already knocking in our doors, and I expect that the lessons learned in the 1.4 series reflects on the next KSP iterations - not only on the internal design (performance) but also on demanding for Unity's responsibility on his product (or plain ditching them for a better solution - and better solutions exists, some even aiming to replace Unity).

Not exactly. IR will be somewhat less popular, but the source is available and new tricks can be derived from it - and now that there's a canonical implementation, there's no need to worry about not breaking legacy. I wonder if a kind of "Infernal Robotics Light" would be possible, allowing savegames using the Classic Infernal Robotics to be used with the DLC instead of the IR guts. Otherwise, I see a long way to go until IR became really unneeded.

My forked worked on 1.3.x and 1.2.2 but I carefully avoided calling any functionality that wasn't present on 1.3 (1 2.2 was plain luck). Once you add decent UI you will lose 1.2 and 1.3 compatibility, however. you can't have the cake and eat it too.

Due a really sunny day I had to reschedule the beta release. I will still publish it until the end of the night. Venusian local time. Seriously now, I will compile, pack and publish it more or less 1500Z (my local lunch time) - unless my day ends up being another Sun on my Beach. the Tweak Scale code appears to be stable (I only need to code a new sanity check, but it's possible to update the DLL later without messing any tests). What's bugging me is how Add'Ons will behave once TS start to use the :FOR thingy. Some are already using :AFTER or :BEFORE, these ones will be fine . But the MM LEGACY ones I expect to cause breakage. the tests will be simple: shove a bunch on new and old Add'Ons, start KSP, play a little, and then zip the KSP.LOG and the Module Manager caches (all of them, don't bother picking only the changed ones). Exit, shove more, delete some, restart. To the extent of your patience. Thx in advance for the help