Lisias

Theoretically yes. It would be accomplished by adding a scale for "CrewCapacity'. TWEAKSCALEEXPONENTS { name = Part breakingForce = 2 breakingTorque = 2 buoyancy = 3 explosionPotential = 3 mass = 3 CrewCapacity = 2 KSP handles nicely when there're more crew than available crew spots on IVA - it just populates the available ones and call it a day (made some tests in the past). But you will notice, however, that by scaling a part up you are stuck with the prefab's CrewCapacity. The part's crew capacity changes only by scaling it down (tested with Mk1-3 Command Pod). I had read in the past numerous reports on Kraken attacks by resizing CrewCapacity, however the scaling down use case appears to work fine. Mangling with the code, I lifted the scale up restriction to see what happens - dude, Krakens gone loose. The User Interface got erratic, the Resources for the part started to change as it were slot machines, you name it. However, the Crew Manifest got scaled correctly, I managed to populated the part with the extra Kerbals once, before the U.I. gone loony. It's probably something on the Editor, not on the Engine. However, the problem is a show stopper anyway, so no deal. Sorry. However, the Scale Down is working fine. A possible workaround would be define your part as the biggest by default, and allow it to be scaled down - the crew capacity will follow up without issues. On the bottom line: your instanced part's Crew Capacity cannot be bigger than the prefab's or the U.I will gone crazy.

That was an issue due the decision to build and refurbish the SRB on Utah.

IMHO the problem is not the cost of development, but the potential savings themselves. NASA budget is approved by the Congress, and congressmen get elected by bringing the pork home. The very Space Shuttle Program was constrained by this: a lot of technical decisions were taken on political criteria - as the booster's width! Once the program was running, savings would need to be achieved indirectly (as not painting anymore the external fuel tank, did only once on the first flight of Columbia) as trying to really optimize the vehicle would reduce the "pork going home". That would hinder NASA funding next year. Pure research and development are easier to fund on a new Space Race - that commandment from Trump to lay feet on the Moon in 5 years would probably keep NASA somewhat shielded from Pork Politics, as anything hindering this program would face direct presidential backslash. But then someone else would need to fulfil now mundane tasks, as provisioning the ISS. Again, relying on a foreign (and not necessarily friendly) nation to provide such critical role is terribly problematic on a strategic point of view, but also on a finantial one: the Pork is going overseas, no congressmen wants to be responsible to this! I expect that at least some SpaceX decisions end up having to secure some Pork to someone - but not to the point of undermine the profitability of the enterprise.

Check for rogue IR sources. Mobile cameras are great for this task. Also protect the circuit from sunlight - there's a lot of IR on sunlight, and glass doesn't block most of them.

This is from the time I could spend my whole weekend playing Guitar Hero.

1500 on Steam. But I stopped using steam for launching about Aug or Sep last year. I should had about 3k hours by now.

I would like to see that KSP.log of yours. It's more for curiosity than anything else, but with a bit of luck, I can learn something to be applied to TweakScale. I'm facing some patching problems, and I think this can be of use!

Yep, that I can do!

It depends. We use some definitions called SCALEEXPONENTS where the scales are defined by "per property" basis. You can scale wright by the square, and capacity by the cube while scaling electricity consumption linearly on a given part. You don't have to use integer as exponents, energy usually scales by 2.5 . Some scales are negative (heat). So it essentially depends on what the config author believe would be the ideal scaling for the part (or group of parts) - and it can change from one engine to another - stock Ion engine have different SCALEEXPONENTS than Jets. Some documentation can be found here, the most relevant aspects of scaling are there.

That's the spirit! Electrical engines have a lot of more torque too. This is something that should be modeled somehow. Firespitter is the ideal module for this, as it models power, torque and props (and not just "thrust"). I understand the reasons by some people prefers stock engines, but they are utterly inadequate for piston and/or propeleres engines. I need to find some common ground on it.

Don't worry. Anxiety is the most common disorder nowadays, and I have my share on it. Try to care a bit less about being annoying and thrust that people will tell you when it happens (believe, they do! ). Now and then a moderator hints in private when I do, and other than a small felling of being stupid, I'm unscratched. And to make things clear, you are not being annoying . We are brainstorming, one of the most important phases of any work. We throw ideas to each other and see what sticks. Some ideas are stupidly awesome, some are awesomely stupid, and most of them just useless. But without such brainstorming, we wouldn't know which is what. I'm exposing my plans, but between what I plan and what I can do there's a gap . Such brainstormings also helps to identify such gaps. This is just common businesses. You get used to it. Relax. Mine is worse - check my constant post editions Yep. Not sure how to avoid overlapping existing parts from other Add'Ons, however. I usually prefer to fix something that's already exists than to recreating something from scratch. Shoving hundreds of parts on KAX would make it hard to maintain, leading to bit rotting, what ends up hindering what we intend to do. So, my first approach is to fix what already exists, then work KAX to seamlessly copes with it (or vice versa). Bringing it to KAX is always an option, but one of the later ones. And niche parts can always be a companion Add-On, sometimes I play with the idea to make KAX something like an franchise. The B36 cockpit is a dream, it's something that I intent to pursue. Some other cockpits too, something like Super Constellation . The current Horizon has a lot of unexplored potential too. MK1 cargo bay is already available (don't remember the Add'On now). And it's pretty good. I think I saw a Huey cockpit somewhere, but if I'm mistaken or the existing one doesn't copes with Stock, this can be an option. Something that's lacking are boarding hatches. Real, working ones. The problem with wings and turbo jets is that there're a lot of them already on other Add'Ons! Not to mention the Stock ones, in which KAX aim to adhere seamlessly. Unless they are inherently flawed and can't be fixed (due being used as is by a lot of gamers, inducing inertia), I have some reluctancy on expending energy on them. Krakens knows how many energy will be needed just to complete what we already have!

Cold War is post WW2. Let's say between WW2 and Korea War? I have a deal with the previous maintainers, and I intent to keep up to my word: So, right now, we have a small collection of parts. All of them somewhat at the same style - except by a few ones, as the Vintage Propelators - they are the Black Sheep on this small herd. However, they are here to stay, so I will keep this going - I just loved these little engines. Wright Brother's airplanes, excellent! Now I need some Santos Dummont aircraft parts and we can start our little version of the 1st World War ourselves!!! (oh, yeas… rivalry. ) It's interesting to note that the 2M parts cope very well with Firespitter's Bomber ones. So we have another match to pursue. There're no jets, except the uncompleted jump-jet. And this one just doesn't fits - the first Harriers came to the skies only on the Sixties, on the Age of the Jet - that's exactly what everybody else has already covered. Unless we find a historic or practical reason to further develop it, I don't know what to do with it - no to mention the huge effort I expect to make this thing to work properly (animations!!). What I envision for KAX (and, remembering, the parts must "blend" to Stock ones - we are adding to the game, no replacing things) are parts that would allow us to fly things like: Experimental Aircrafts (well, this one will be hard to blend! ) Wright Brothers Santos Dummond Whitehead Gabriel Voisin Civilian Aircrafts Steel Biplanes Fokker F-2, Fokker F-32 G.A.L.38 Spirit of Saint Louis Boeing 247, DC-2, DC3 Constellation, Super Constellation Catalina! Military Aircrafts B-24 B-36 (I'm dying for a B-36 cockpit!!!) P-61 C-119 Some of the aircrafts above had born in the early Cold War years. But I pretty sure that you also aim beauties like the F-80 Shooting Star, F-89 Scorpion, F94 Starfire, or the F-100 Super Sabre - not to mention the F-86 Sabre and B-47 . And there're also the MIGs, that marvelous RAF fighters and V-Bombers. Problem is… They are jets. And there're already Add'Ons covering them. We would ending up getting a fat KAX, with very little value added… I will need some guidance on this. There're some electrical props on FireSpitter, there're some on KAX. I don't know exactly what you guys need - and we have to remember that we would need a electricity source to feed such engines! Good luck!

Oh, yes. The Vintage Propelators! It's some months since I tried them, so... KAX + Firespiter + TweakScale. Will be included on the Ships/SPH on the next release. I think they're a bit overpowered, but given the weight of the stock parts, it's understandable. I'm optimistic enough to believe we will have some wooden and canvas parts to match them.

YES! It works on 1.7!! :-) And the Thread Forum says ">= 1.4". 1.7 is bigger than 1.4, so it applies. And since I said >=, it means that it works too to 1.4.0. And 1.4.1. And 1.4.2. And 1.4.3. And 1.4.4. And 1.4.5. And 1.6. And 1.6.1. And 1.7. So I put ">= 1.4" and called a day.

Working. Some parts are not correctly implemented yet, but it's on me - they will work as is in any KSP version where Firespiter works. The sound issues were fixed - again, relying on Firespitter (didn't got the patience to make the thing work on stock sound engine - there's somethng ont he life cycle of the thrust that I don't understand yet - and since Firespitter works fine…). Yes. Inertia. At first, there was some issues to be fixed and I concluded it would be better not to spread my borks on CKAN. But then, the most notorious glitches are fixed, the one that remains… oh well, we can live with it for some more time. Had people not talked about them on this thread, I would removed them from the Stable releases, publishing them only on Betas. And I plain forgot about CKAN - I don't use the client myself, as it doesn't fits very well to my needs (and this is the only reason I forgot about it) - but the service is solid and strongly needed not exactly by the client, but for the infra structure it provides for guaranteeing the survivability of the Add'On as times goes by. I will check for any objections on the ARR material just to be sure - but other than that, I don't see reasons to do not publish the thing on SpaceDock, Curse and also CKAN other than some extra efforts. Firespitter saw some idle times on the past, and at that time it was reasonable that removing it as a dependency was considered a solution. However, coping with the Stock modules proved to be tricky when using Piston/Props engines. Things just didn't coped well - and i really tried. But in the end, what really fixed everything was rolling back to FSSoundEngines. Firespitter is not in the danger of becoming obsolete anymore. The present maintainer is accepting pull requests with fixes, and I'm providing such fixes as time allows. I planned to focus on that era I specified, but one thing is planning, other the reality. Once there's no one available fulfilling that niche, it wouldn't be a waste of resources to fulfill that need. I just don't plan to redo what's already done - unless a compelling reason arises. Time is a scarce commodity nowadays!

TL;DR: TweakScale doesn't properly protect itself from rogue patches. Some patch plays havoc, TweakScale happily complies injecting trash into the prefab and badly mangling (sometimes, in a very nasty way) the savegames. The best way to help people to write patches that doesn't stomp on TweakScale's feet is the Module Manager :FOR thingy - but this changes the current order in which patches are applied - most of the time, for good. But there's a least one situation in which old mods could bork, and again we have a nasty one. One of them is already detected (it happened to me), currently I'm asking for brave kerbonauts to further testing the beta version in order to detect more situations and so I can prevent them on the code on the final release. @TarTi, please send me your KSP.log and Module Manager caches after reproducing the behaviour - if possible, on this issue. This will help us both - if there's anything weird on the patches, I will detect and we will fix. If there's nothing, but I detect any problem, I will tell you and we can fix it.

Insufficiently implemented, I prefer to say. It could be better by adding things - and it's still time. Poorly implemented, in my book, is the support for Add'Ons on the Steam Workshop plugin - just shoving all the installed Add'Ons list blindly on the upload is as good as no information at all - and so, I think they should had just ignored the problem and let the scene handle it themselves (perhaps giving us a hook to fill the blanks). Insufficiently implemented is not necessarily bad, and it's less worse than poorly implemented things - you don't have to spend resources by doing the same thing again.

Right now, don't care about KAX. Care about learning. KAX is a niche Add'On. I don't plan to compete with SXT or Airplane Plus, but to fill some gaps instead. I also plan to keep Firespitter as a dependency (and it's the reason that I try to find time to contribute the fixes upstream, while toying with a personal fork of mine). Adding weapons to KAX is not exactly on my plans, but a companion Add'On would not be a bad Idea. KWX (Kerbal Weapons Expansion) doesn't sounds bad at all. But I think they should match KAX's role (see below). If you ask me, I intend to focus on early, pre-first war aviation and post second war aviation (First War is somewhat covered by Firespitter, but perhaps there's something to be explored on the Second?), but before the jet era. yeah, I like piston engines and Props. I plan to finish and maintain the electrical and jet engines already on the pack, but I think that Firespitter, Airplane Plus and SXT are already doing a decent job on these niches, so i don't have that compelling desire to exploit these further - unless we find historical evidences that they at least tried that on the historical time I'm focusing in. Yeah - I'm a frustrated aviator. I also ask you to consider carefully the license you plan to release such material. We have already some ARR material on KAX, and I don't intent to expand this. New material should be somewhat compatible with the current licenses used (CC BY NC SA would be good, I think, but I open to ideas) - but I'm being too forward. There're a lot of water to cross under the bridge until this. Just remember one thing, however: this is not a job, you will not get paid. We do this on the Stone Soup premises. Perhaps one more time would be even better. — — — POST EDIT — — — I choose to move unrelated responses to the following thread. Could you guys do any follow up there? Thanks!

I'm moving this discussion here, as this subject is way offtopic and I don't want to keep it on the original thread. @Angstinator , this is the sole reason - please don't think I think you did something bad or wrong! @OPBlue the same goes to you. Please understand, guys. Why any mod author would ever use this kind of bloody useless licensing is beyond me. There're a lot of reasons, some good, some not too much. What follows is a free brainstorming on the subject, i don't have the slightest clue about the real reasons from the author mentioned on the original thread. The guy/gal is a 3D Modeler, he/she wants to share some of his/her work but don't want someone using his/her work commercially to compete with him/her. So he/she shares it under a restrictive license to allow him/her to legally respond if someone tries the stunt He/she used third-parties work, and these third-party didn't mind to allow him/her to use the work (friendship or commercial partnership), but that other guy/gal doesn't want that anyone else use the work The guy/gal invested a huge amount of his/her free time, and hope to get some revenue from it later. The guy/gal had bought the art from someone else, and the original author made it clear that he/she is the only licensed user of such material The guy/gal did a huge emotional investment on the work, and he/she is finding a hard time to allow anyone else to handle it. Perhaps he/she is just jealousy, perhaps he/she just don't thrust anyone available to handle the work Perhaps anything else Nobody helped the guy/gal when he/she needed, so he/she doesn't feel compelled do give his/her work for free. And a huge amount of more reasons exists. I just scratched the surface of the matter. You are somewhat wrong. The Law cannot prevent someone of doing that, but it can surely make the guy/gal (and the site!) to regret deeply he/she did that - you can waste some serious money on the matter, even by not being guilty. Please be cautious. Some of us rely on that very same copyright law to make a living. I'm one of that guys. And I'm one that would probably file a complain if I see someone abusing the author's work. I'm not telling that I don't use that loopholes on law myself - I do. But I do it on a way that doesn't causes prejudice to the original author of the work. Everybody needs to make a living, you know. And some of us can be very vocal (and sometimes, even vicious) while trying to protect that incoming (or to prevent someone else making such a incoming at their expenses). That said, there're indeed some loopholes on the law that could be used to protected user's rights. But I don't intent to discuss such matter on this forum - this is private land, and they (Moderators) choose not to allow such discussion here. And for me, this is enough. Rights are not an individual effort. You can only have your own rights secured by helping to secure other people's rights. That said, I don't get why people uses ARR material without any kind of guarantee at first place. We, users, had drawn ourselves to a corner, and we are the only ones to be blamed. Yes, I'm including me on the equation. I got attached to some of ARR Add'Ons myself. I'm also somewhat heart broken with the situation, and I'm trying to figure out a reasonable and legal way to cope with the mess. However, sed lex dura lex. I cannot protect my rights at the same time I violate other people's. And had I mentioned that I make a living doing software? We don't know if it's permanently. But it's irrelevant anyway. The "cookies" belong to him, and he is free to do whatever he wants with his "cookies". It's his right. Well said, sir. I just don't agree with the "useless". Absence of evidence is not evidence of absence - we just don't know the author's mind on the subject - there're some very good reasons to do so, see above. The copyright expires in 70 years [after author's death - 50 in some countries]. A long time to wait, if you ask me. Thanks for the consideration, I moved the discussion to this thread for this reason, and I will ask moderators to move your posts to this too. It will be somewhat weird to publish a response before the questions, but… Whatever. This is KSP, we are used to space-time anomalies!

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!)