Lisias

You must define "outdated". There are some mods made for 1.3.1 that are still working flawlessly, even on 1.8.x

Hi, @Ser. I issued two pull requests into your github: https://github.com/SerTheGreat/NavInstruments/pull/1 - adding the Dessert Airfield into the ILS, as suggested by @Sppion1 above ; https://github.com/SerTheGreat/NavInstruments/pull/2 - fixing a weird thing that started to happen to me today. I don't really understand the issue, but the patch fixed it to me and apparently this is consistent with some similar issues I found on the Net. Cheers! Try pressing just Alt! The code that handles that click looks only for Alt. Alt+Ctrl has a special meaning on some X11 Window Managers, I think your keystroke is being intercepted by X.

I'm working on some entries for the Around Kerbin in 80 Minutes Challenge. Making a working new design is already hard enough, but making one that lands easily is the worst part. It was a perfect approach, except by being a bit too high and hot - after [redacted] minutes flying at Mach [redacted], descending from [redacted] meters high in so small time demanded too much from the control surfaces on an airplane now with a heavy nose. The previous craft (that managed to accomplish the same stunt) had more control surfaces... Obviously I occluded the craft as I didn't applied her yet to the challenge. (no Kerbals were - permanently -- injured on the stunt after the quick-loading) As you can see, had KSC be 5 meters lower, I think I would had landed her! I managed to explode the craft ONE METER BELOW THE TARMAC!!! And got a perfect addition to my "Perfect Landings that Didn't Happened" Album Collection! Well.... I had made so many rounds around Kerbin due these... "hard landings"... that I don't need the Map anymore, I know where I am by looking to the ground! And now, I'm going to do it again. Should I try to do it blinded this time?

I'm toying with this concept, but concluded that any gains are marginal and easily occluded by the problems. The Mk2 parts are lifting bodies, they add some lift, so they add the equivalent parasitic drag. Oh well, you can easily compensate it by adding a smaller wing and taking advantage of the lift (as you will suffer the drag anyway).

Well, it's a bit laborious, but yeah, you can do it. You will ending up doing manually what the Welding Tool needs to implement - and you will learn by trial and error what needs to be learnt (see my previous post for the link to that thread about Module Part Variant!). Please share your findings here! It will help to implement the thing!

Yep! One thing I like to do is just copy & paste the KSP dir into a backup, and then after updating, copy everything (but Squad/ and SquadExpansion/ !) from the backup's GameData to the new instalment (as well the saves/ too!). Be sure to copy and not to move (hit ALT, so you can see a "+" signs on the icons being dragged). Of course, if you use CKAN, just let the tool do it for you. Scale Safe!! (had I mentioned today that I strongly advise to use S.A.V.E. ?)

It's a bug on the prefab on KSP 1.8.0 . Nothing bad happens, other than making your life a misery while trying to use the controls. Please upgrade to KSP 1.8.1. Not only the UI widgets, but some other annoying glitches were also fixed:

Finally! This is my (valid! ) entry for the Challenge, on the Thunder Division. Craft available on Kerbal X and the (full) Mission Report is here. This craft flew 48 Passengers and 2 Crew at 1.3Km/Sec average around Kerbin in 54 Minutes from take off to full stop on landing. A hand-full, random, screenshots: Due the touristic nature of the flight, no maneuverer over 5G was allowed. Think on the children! Damn.... Too high, too fast! But everything ended well. By a tad... Technically, the craft stopped on the runway =P, just a tad after the paved part of the runway... - Please tell me it's ok, this is the FOURTH time I do this Challenge with this vessel! (first one, I used parts from SXT by accident, the second I blew the craft due overheat - 1375 m/s is too much! , the third I run out of fuel but made a marvellous landing, but empty tanks is against the rules). — — — DISCLAIMER — — — TweakScale was used on Wings, Control Surfaces and Landing Gears -- -- -- MISSING PICTURE -- -- -- Forgot to include the SPH Picture here!

No, due licensing and political issues. They need to hire the guy to do the job for them, otherwise they would be using non exclusive assets on the game, what it's bad from the business point of view - just imagine Simple Planes using the same MK2 models as KSP? From an old fart developer, I need to tell you that most (but not all) Add'Ons around here are crafted by non professionals. Some of them abuse Unity in a way that Squad can not dare to do so, as they pay for support and by doing such stunts, the Unity guys would [insert your non forum compliant favorite expletive here] them big time. When you pay support to someone, you do what they say - otherwise they are not responsible for the outcome. And corporations work by paying people to be responsible by the outcome. So, even if the licensing allows, they need to rewrite the thing to meet their constraints - and so we have again the problem of hiring workforce not only to built the thing, but to maintain it too as KSP evolves. What's another source of problems, as Squad, apparently, is having a bad time on evolving the product without breaking a lot of working things - switching Engine's version is already hard enough, but I think there's a lack of methodology (perhaps due cultural issues) on their process that ends up with a lot of loose ties on the final product, with the consequential breakage on the field. It's a insightful though. Congrats.

I can only speculate, but there're a kind of shortage of professionals able to carry such jobs. Writing games demands some skills not usually valued on other fields of the trade, and writing space computer games demands yet more unusual skills - as advanced maths. Most people I known or get in touch never laid a foot on a College, and the ones that did usually stayed away from Calculus and Algebra, focusing on social and political classes as Project Management. I can count using my fingers the guys I known that really studied Software Engineering, what to say about Advanced Calablculus and Astrophysics? (google about STEM crisis and similar wording) And once you find such a guy, well... You need to hire him somehow. The game industry is not exactly known to provide a good quality of life for the employees together a good payment and convenient working models (of course, there're honorable exceptions) - so hiring talented and experienced old farts are somewhat tricky, making hard to build an heterogeneous team with different talents that would sustain a self-learning, self-improving culture.Homogeneous teams tends to close themselves in a self-reference, self-indulging culture, usually ending in disasters. Blaming Unity is an explanation, not a solution - but boy, Unity just don't help on it. The atrocities these guys pushed on us are.... laughable sometimes. But yet, you are only the victim on the first time - from the second strike and beyond, you are an accomplice of the problem. (had I mentioned self-indulgence recently?)

So you are abusing the gears. You need MOAR GEARS wisely placed on the hull to correctly spread the load. See, this is used on real life: If you are a TweakScale user, the current 2.5 Beta are scaling (stock) gears correctly, if you want to try it. On the other hand, there's nothing wrong on hating such "engineering challenges" neither - so that patch above applying KSPWheels on the stock parts is also a valid way out for your problem.

I think I'm the only one that likes the new gears? Adjusting the springs and the dumpers are needed too on real life, and I enjoy such engineering challenges. What I think it's missing it's a decent automatic adjuster. The automatic settings are the one to be blamed, not the gears itself - once you set them correctly, they works.

Look again. https://github.com/net-lisias-kspu/New_Horizons/releases/tag/RELEASE%2F2.0.1.1 Also keep in mind that this is on the KSPU hierarchy - are things I'm doing for me for fixing things by me (since all of them being "Unofficial"). It's essentially the forks I use on my own gaming. Use at your own risk. http://ksp.lisias.net/add-ons/Unofficial-Initiative

Try an EAS Strut linking each engine to the main fuselage. I think the engine weight is too much for that wing.

"I have a bad feeling about this." - Luke Skywalker, Hans Solo, Leia et all. Star Wars.

The funny thing is... It's not that hard. We need to learn the rules in which the VARIANT are applied, then apply them manually on a temp config, and them weld the temp config into the target one. The datum "mass" should be added, the datum "scale" appears to replace if the config has one, resources too and so on. The hard part is to learn and apply such rules. What I do with meshes? Replace or insert it together the config ones? We are lucky enough that someone already made the worst part, to document the thing so we don't need to try and err our way on it. But, yet, someone still need a good amount of free time to implement that on the Welding tool.

The problem is that some parts depends on the VARIANT to get his real data. From TweakScale, I learnt that some parts are defined more or less as follows: PART { name = fancyPants mass = -1.2525 <yaddayaddayadda> VARIANT { scale = 1.0 mass = 25.00 <yaddayaddayadda> } VARIANT { scale = 1.5 mass = 30.00 <yaddayaddayadda> } VARIANT { scale = 0.5 mass = 15 <yaddayaddayadda> } } So, in order to get the final mass of the part, you need to apply a VARIANT first.

WITHDRAWN. I just realised I used a part from SXT and another from AirplanePlus by accident! I will fix the mishap and apply again.

It's the other way around! The problem is the current instalments! Joe Kerbal has NFA and TweakScale 3.4.3.10 . I (think) will issue 2.5 with NFA on its own Plugin, under a new CKAN netKan file. Suddenly, TweakScale is not patching NFA anymore, Joe Kerbal needs to download and install a new Add'on - otherwise his savegames will be kaput on load. Manual installers will download the file by reading my announce here, or by using KSP-AVC where I added the option to show the CHANGES where the need to install TweakScale Companion for NFA (or something like that) will be advised. And I advertise S.A.V.E. on almost every post of mine (and I just did it again!) - so I have the manual installers already covered. CKAN users, on the other hand, rarely are aware of an update, CKAN does everything automatically. This guy is the one that will be caught with his pants down on the transition. That's my secret, Captain! I'm already burnt! I AM one of these guys that had their savegame tampered by this mess I'm trying to prevent. More than once. I'm still trying to fix my career I started on 1.4.3, as half the Add'Ons I was using were broken, half of them broke something else when fixed, and the remaining ones don't works on newer KSPs . So I'm focusing again on 1.7.3, fixing and backporting fixes to be run on 1.7.3 so I can finish my god damned career!!! I have a personal moral guidance: I don't do to people what I don't like it's done to me. I don't like my savegames being corrupted, neither updates that breaks things fortuitously and/or without warning. So I try to my best effort to avoid doing that to people. I have a slight advantage on some authors around here - I don't get any money on this. So, I'm not compelled to break my rules to prevent any loss of "revenue", being it patronage or plain donations. So I don't have strings attached, and I'm free to do what's right. And keeping long date, faithful gamers happy, paving the way for them keeping their savegames healthy and working until the day they feel comfortable enough to update KSP (or not, you can bet your mouse TweakScale will support again 1.3.1 and 1.2.2!), is the right thing to be done. So I will do it. We loose users faster and easier than we gain new ones, sir. We do better than the "competition", or users flee. That's the magic word: collaboration. Unfortunately, things are not better enough to expect it - but, granted, nowadays they're better enough to hope for it. But, yet, this is a problem related to TweakScale only - so it's kind of unfair to expect other people to solve it for me. Before asking for help, it's wise to have a proposed solution for it first - and then allow the fellow Kerbonauts to work on it to make it better if needed. Otherwise, I would ending up being forced to accept half-baked solutions that would only delay a proper solution for my problem - what's, frankly, I think it was the usual way in the past.

And that's the problem. The user needs to know he/she have to choose them. He/she fails to do so, and the savegame is corrupted on the next load. There's yet a new possibility... An CKAN Plugin. I need to study who this stunt works, however. I don't share your optimism. CKAN itself is also a source of glitches, and it's convenient to avoid creating new ones. The problem is exposition: TweakScale has a huge user base. 1% of failure on a small user base can be acceptable, but 1% on a huge user base would render me handling an absolute number of problems way bigger than is manageable (or acceptable). And, looking above, you will see that I already need to promote some hurt to get things tight around here. I need to minimize the pain, otherwise people ends up giving me the finger!!! Allowing savegames to be broken is a sin around here, we need to remember that people runs the same savegame for years sometimes. They invest a huge amount of their free time (a very expensive resource for them, due scarcity) on that savegames. We screw their savegames, they screw us sooner or later.

This can be arranged.... Reach this guys and ask them!

There's a way out if this, but it will need close cooperation from CKAN guys: hot patches on the CKAN data files to "teach" CKAN about the MiniAVC V2. CKAN allows Plugins to be added - I don't know the details of this thing, but with a bit of luck, a Plugin can be written allowing you to hot patch the installed Add'Ons metadata that contains MiniAVC V1 to be replaced by MiniAVC V2. You probably would be able to replace V1 by V2 on the Add'On installing too. Assuming that CKAN Plugin is possible, the AVCUpdater is unneeded for CKAN users. And non CKAN users has no problem with CKAN, and could use AVC Updater without hassle.

Me too. Not exactly on the most pleasant way, however. Yes. An "Add-On" (as it WAS used on the Forum's menu until the last update) is... a Add On. It's the correct term, IMHO. And if you check the Forum Sections, whoever created them thinks like me: https://forum.kerbalspaceprogram.com/index.php?/forum/4-add-ons/ Around here, using "Mod" is problematic. A lot of people call the Moderatos as "Mods" too, and this is absolutely terrible on a product (and a hell of a source of confusion for me on my first months here!). Each thing needs to have only one name, and each name must be associated to only one thing. But, apparently, this Forum is moving towards making confusion official. Well.. It's their job, not mine! I can only hope they know better than me. Yep, it's what I think too. However, the transition will be a hell of a trauma. Using NF as example: as soon as I deprecate the NF patches from TweakScale, everybody that uses NF add'ons will suddenly have all they crafts files unescaled. Worst, the living ones on the savegame too. The ideal solution would be CKAN having "conditional dependences", ie, if you have Add-On "A" and Add-On "B" installed, so CKAN will install "C" automatically. That would solve my problem for good, but there's nothing like this as far as I know. So all I can do is to "recommend" or "suggest" Add'Ons, but even that is not conditional - and would not make sense to recommend or suggest the NF Patches to people that doesn't have NF installed. Currently, I'm toying with the idea of creating a mini package system for TweakScale - something that would known about the existing (homologated) patches somehow and then would stop KSP from running if something is missing, indicating the place to download/install the missing patches. But all of this is terribly brainstoming yet, I didn't even create an Issue for it yet. Nope. I used NF as an example because they are, currently, one of the most "problematic" ones to be externalised due popularity and fragmentation. I solve the problem for NF add'ons, I solve the problem for everybody else. Good to know you plan to support them. This is the reason I plan to create these "Add'On Add'Ons" thingy (meta-recursion, yeah!)

Clever idea. However, the problem is on the input part of the algorithm - the Welding tool has some code to handle VARIANTs, but it's incomplete - I'm guessing that at the time of the write, there were no enough samples of this thing to make a working solution (at the 1.4 times, only one part had the VARIANT, I bet my mouse Squad was wetting their feet on this). You need to get rid of the VARIANT before applying the weld. At present state, that code is useless because different parts have different meanings for a VARIANT, and by welding them together, you ended up welding tomatoes as it were apples. I think that a better solution was given by a fellow Kerbonaut some pages ago: create the welded part without VARIANTs - the tool should "consolidade" the present state of the part and then generated a "UNVARIANT" part using that configurations.

If you compile the thing using dotNet 4.x, nope. KSP 1.7 and older uses Mono as runtime, and it understands only dotNet 3.5. But if you compile it using a dotNet 3.5 compiler, it would work both on 1.7.3 and on 1.8.x, as dotNet 4.x understands 3.5 code. In a way or another, the Welding tool chockes with parts with MODULEPARTVARIANT, no matter the KSP you are using - this is can be a problem from 1.5.1 onwards, where MODULEPARTVAIRANT started to be widely used on stock parts.