AccidentalDisassembly

Hi Angel, Small suggestions (fixes?) for the latest Buffalo (I am using the Buffalo from the Pathfinder download, but I assume the files are the same in the standalone). I am suggesting reductions in mass because of the dimensions of the parts, really - they're 1m x 1m x something, and the Buffalo Chassis (1u) of those dimensions currently weighs ~550 pounds. Seems a bit heavy. Maybe more importantly, though, the ratio in masses between the parts seems off: - The Buffalo Chassis (1u) mass could be halved to 0.125t - I think it currently weighs the same, dry, as the Buffalo Chassis (2u), which is 0.25t (and double the size, of course). - The Buffalo Chassis (end) mass should also be lowered, maybe. Slightly smaller part than the 1u Chassis, perhaps 0.11t? - Buffalo Half Chassis should probably then be 0.06t, and the quarter chassis maybe stays the same at 0.05t or gets reduced to 0.03t. Or not, up to you! P.S. - one thing I'm curious about: what are the relative benefits/drawbacks of surface attaching wheels vs. attaching them to the nodes on the side of the chassis? Is there any difference really, other than being able to attach wheels even when there aren't nodes (if you surface attach them)? EDIT: Also seem to be having an issue with wheels. The front wheels on this test rover are inoperative. They are attached using the nodes on the chassis under the cab:

Took the poll; I think some of the questions in there are very valuable, and I wanted to ask some questions of my own based on what I saw in the poll + what I see in the manual, since the poll reminded me of the many functions of TCA that I don't use. For the moment, the biggest question I have is about engine roles. I wonder if roles couldn't be simplified. Here's how they're described: A couple of things occurred to me here. The "Thrust" profile doesn't need to exist. TCA could assume that all engines that are active should be used to control all kinds of speeds, unless the user says otherwise. Only one option seems necessary here: Prioritize maneuvering or not. I am assuming the difference between Thrust and Maneuver exists for this kind of situation: A craft has two kinds of engine, and one is supposed to be used sparingly. An example would be maybe a craft that has big jet engines for hovering, and rocket engines (or smaller jets) either for lots of power quickly or so that changing the big engines around doesn't make the craft wildly overcompensate. You'd want the jet engines to do everything until they just couldn't, and then the rocket engines would kick in; or the little jet engines would be used for finer control than the big ones could provide. You might actually be able to eliminate all of those modes, including manual control, if the logic of TCA's pilot assist were reoriented slightly. I think there are a couple of assumptions which are safe: The user probably designs a craft with "modes" in mind and can figure out what to turn on and off to make them happen. Every time the user has TCA turned on, but not switched on full autopilot, it's because she wants something to be balanced. If it's a rocket, she almost certainly wants TCA to make the rocket go in the direction it's pointed on the navball despite unbalanced engines (like for a space shuttle setup). If it's a plane/helicopter/VTOL, she either wants TCA to do the exact same thing - compensate for weird engines so the plane's net thrust vectors will point "forward" - or she wants to do VTOL, STOL, or hovering. I think TCA can probably achieve all of those things and eliminate some complexity in the process, maybe. This is just me thinking out loud, so please don't imagine I consider this to be some sort of gospel. The logic might go something like this. It's just a slight reorientation of many of the ways TCA already works: A. The user sets up the craft so that she can turn on/off engines or groups of engines depending on what she's doing. B. Having TCA on tries to balance the engines on a craft so that it goes in the direction it's pointed on the navball, which covers unbalanced rockets, except if: C. VTOL (plane or helicopter or rocket, no difference) mode also gets turned on: TCA looks at the currently active engines on the craft and calculates how much thrust out of which engine, and what attitude, gimbaling, etc. would be necessary in order to make the plane go in the direction the user indicates. There are probably several different control schemes to determine what the user wants. I'm going to try to elaborate on one. All active engines are on the table, with the possible exception of being able to define engines that are used as a last resort/for maneuvering only. If there are any maneuvering engines on a craft, TCA uses those first, and not other engines, when the user wants the craft to do anything other than remain motionless. TCA looks at the direction the maneuver engines are pointed and figures out what kind of maneuvering it could actually do with them; if they aren't pointed backward, for example, it then falls back to "main engines" if the craft needs to move forward. Otherwise, there's an underlying assumption that the user knows which engines ought to be used when, and sets up action groups to turn them off and on as needed. TCA reacts/compensates according to which engines are available and/or by which ones are "maneuver only." TCA assumes that the rest state of the VTOL is a motionless hover unless the user has turned on full autopilot, in which case it's just an autopilot and figures its own stuff out accordingly. The point is to consider motionless hover the rest state while "VTOL mode" is on, and to try to achieve that with whatever orientation the user has the craft in, given the engines TCA has to work with and the direction they're pointing. An "oh crap" button could tell TCA to take control and do whatever it can to return the craft to a rest state, thereupon turning off "oh crap" mode and handing control back to the user, or something. One possibility for interpreting user intent: Pressing WASDQE does what it normally does, and TCA tries to maintain zero motion (gimbaling, max thrust, whatever) while respecting the user's choice of orientation (to help you land on sloped things, for instance). If TCA can't accommodate an extreme tilt, it tries to minimize movement, but slipping will occur. Since TCA is handling all active engines, it interprets the user's throttle value to mean "make the craft go in the direction it's pointed on the navball at a speed proportional to where I've set my throttle." TCA does whatever it needs to do in order to balance engines so that, if the throttle is at 50% (for ex.,) the craft goes in its indicated direction at 50% of the maximum speed that's achievable while making sure the craft NOT go in any other direction (like vertically, or sideslip). If there are wings, TCA would theoretically recognize that the craft isn't falling very fast anymore, and modify the max thrust of downward-pointing engines accordingly, using more or less rear-pointing engines to continue making the craft go forward. Really, though, in actual gameplay, the user can just turn off their downward facing engines and turn off VTOL mode when they're going forward fast enough to have lift. If there are no wings, the user just keeps VTOL mode on. Since TCA considers a hover to be the craft's rest state, two more keys are needed to tell TCA to translate the craft vertically, which is what happens now via the throttle keys when hovering with some combination of modes. Instead of the throttle - I don't know, maybe Z and X, which then woudn't work for max/min throttle anymore (while vtol modeis active). Dunno if that's possible. Depressing one of those keys (or something else) tells TCA to try to move the craft vertically while the key is depressed. The longer it's depressed, the faster TCA tries to make the craft go up. Same applies to going down via the other key. Letting up on the "descend" key tells TCA "I want the plane to stop moving downward now," and (unless other controls are depressed), TCA tries to return to a hover as quick as it can. An alternative would be to use the Ascend and Descend keys to incrementally change vertical speed, kind of like how the throttle works now when "Auto Throttle" is engaged. Maybe, e.g., press Z once for +1 m/s vertically, X for -1m/s. An additional button maintains a particular altitude, like the follow terrain function; with this turned on in addition to VTOL mode, TCA makes the craft prioritize maintaining that altitude if at all possible; Z and X now change what that altitude is. Throttle still makes the craft go in the direction pointed, but within the new limits established by maintaining that altitude above the TERRAIN, here. Or maybe there's just a button that says "maintain alt and speed" that's kind of like half-autopilot: craft tries to go forward at given speed and maintains altitude (above terrain or as an absolute number), but the user can still use A and D to change the craft's direction? You get the idea. An alternative control scheme: remap WASD to mean "translate the craft in this direction at increasing speed for the duration of the keypress", and some other scheme could be found for "move the craft up and down". Q and E could rotate the craft around the vertical axis or some such. Autopilot functions could also be used in this mode, and they would just take over the keyboard controls, essentially, and you'd have to figure out a good way of inputting values to the autopilot. I'd recommend Atmospheric Autopilot or Pilot Assistant for models, maybe. Maybe there could be an "Oh crap" button that tries to use engines The logic behind all of this basically eliminates the need for all of the "prograde +" and "maneuver +" buttons and whatnot, since the user could just point the craft where it's supposed to be pointed. They might still be useful in a full autopilot mode. End result: 3 buttons (or 4, with the "Oh crap, stop everything" button) for anything other than complex autopiloted maneuvers. Step 1: turn TCA on. Step 2: turn VTOL mode on. Step 3: maintain altitude button with option for terrain altitude if you want it. Really, all of this relies on the user occasionally realizing "Aha, I see I can't achieve VTOL at this angle, but if I tip around the rocket or the plane, TCA will try to make me hover." I think that's intuitive enough, no buttons/controls/knowledge of PID/whatever required, lots less settings to fiddle with to achieve the same outcome. You still COULD mess with all the prograde+ stuff if you open the "fine autopilot controls" window, or whatever, and what I'm saying does not require eliminating any functions, just a bit of re-kerjiggering. I just think there are only so many outcomes the user wants when TCA is turned on... Maybe I've captured them, maybe not. I'm not saying that these ideas are complete, it's really just an exploration of (maybe) a different way of thinking about the whole experience of using TCA. Maybe. Edit: Also, one more minor thought. Control over landing gear really should not be handled by TCA, it's annoying, sorry. Just let me control it as the user. In my experience, when testing craft especially, TCA consistently raises the gear at just the wrong moment, and it's not possible to put them back down as my test craft inevitable does a hard landing.

I'm not sure what else we could be talking about here, considering we're talking about a computer game, and I think that's the definition of a simulation. No, that's not at all what I said. What I implied is that you may have a different version of fun from other people playing the game. May. You said you didn't see what the problem is (why others might not see the mod in the same way you do), and I am suggesting that it's possible that that is what the problem is. Or not. I'm just going off of some posts. I also did not say that you deliberately complicate anything, just suggested that you might not be looking at the "issues" (whatever their magnitude) in the same way as others using the mod. Well, that's fine. Do what you want. I didn't ask me for a "make me happy" button, I just tried to explain some principles from my perspective. Yes, and I've seen airplane control panels. I've even used simple ones myself, in real life! And yet these are not real planes or real VTOLs, and their users are not pilots. They're playing a computer game. Yes, it requires some learning. The question is how much, and what kind. If you decide that the answers to those question are "a lot" and "technical", which you are perfectly entitled to do, because you are doing this for free, and if people want something different they can do it themselves, etc. etc. - there is absolutely no problem with that, but, again: it will explain people's reaction.

I think that that assumption is the heart of the issue. If you imagine that the purpose of the game is to be complex in addition to challenging (and fun?), it suggests that you enjoy complexity for its own sake. I would argue that, for the great majority of players of this game, it is not the complex means of arriving at an outcome that are pleasurable when we're talking about making a craft fly level and hover that ought to be able to fly level and hover. It's really the outcome that's interesting, because the pleasure is had in the design and use and achievement, not learning what a bunch of settings do (that are absolutely not immediately apparent, sorry). It is perfectly possible to make TCA do what the two groups DStaal mention want, and I don't see why the interface would be a really difficult question, either - there has to be a way to use the "show more controls when someone presses the 'advanced' button" technique, I suppose. I just don't understand, at this point, what the primary aim of TCA is. What is it for? Is it meant to be a VTOL configuration simulator? Or is it supposed to be a nice tool that helps people fly VTOLs and do lots of interesting things with them in KSP? If it's the latter, I think that implies that complexity (which is not the same thing as saying 'number of functions') is the enemy. EDIT: Maybe I should have said "autopilot configuration simulator that also does VTOL if you do the right combination of things" since, as you've pointed out previously, this does a lot of stuff that MechJeb does, but with the benefit of managing thrust from different engines and such. I guess my point is that it seems like the goal here should be (mostly) to simulate the effect of having an autopilot, not the intricacies of the system itself.

Hmmm... search for name = ilsCockpit. There are definitely two (well, in the version I downloaded, which is 1.8.5 from earlier...): they are in Spaces/ILSIVA and Spaces/ILSCockpit. Maybe I'm not understanding what the configs are doing though.

Fair enough, but at the moment they have identical name = XXXXXX in their configs, in case that actually causes any problems (I don't know, maybe one just replaces the other on load).

@taniwha, were you able to reproduce the bug I mentioned a few posts back, by chance? It seemed reliably reproducible for me, but it's also possible that the whole thing was some sort of undetected mod conflict...

Textures most definitely do not look like that for me; they look just fine. Are you using ATM? Fun patch for anyone interested - turns out you can re-scale the Stail parts slightly to make them into J-type parts: Also, perhaps of note - there are two internals in the Spaces folder that are each named the same thing (I think it was ils_internal or some such).

Okie dokie, it's nice to know at least that I'm not crazy!

In the beta release - there are duplicate tweakscale configs. Just FYI. Also, the 2.5m passenger cabins are placed ridiculously late in the tech tree when CTT is installed. Edit: Also, unsure if any parts actually use the textures in the Rocketry / OldAssets (or whatever the structure is, can't remember off top of head) folder.

Getting this error when entering and then hanging out in Mission Control : Loggitude: https://dl.dropboxusercontent.com/u/59567837/output_log_CC_nre.txt

I've noticed something with recent versions (maybe the last 2) of CC - when I'm looking at the now much longer contract list, for a period of time after going into the admin building, the list shifts around (seems like additions/removals). If I've selected a contract, it will get de-selected several times. It seems to "settle" after a while. Is this only me? If so, probably a mod conflict of some kind, or a funky contract pack...?

Is there no way to get it to play nicely with TweakScale, then? Would be pretty neat to be able to have both. Currently adding KRnD to a part with TweakScale, even if you don't research an improvement, will cause values for the part to revert to normal on scene changes, as I am sure people know. =(

Huh, weird - I can't click on any of the sliders / change any values, nothing seems to happen...

FWIW - this is what I get when pointing at a B9 Pwing and pressing "J": The copy of KSP I tried this on has: 1. B9 PartSwitch 2. Community Resource Pack 3. Firespitter (just the DLL and resource def) 4. IFS 5. Engineer redux 6. KSP-AVC 7. VesselMover 8. ModuleManager 9. The 3 Pwing folders included in the ZIP from GitHub Loggery: https://dl.dropboxusercontent.com/u/59567837/output_log_pwings.txt

Something goes pretty haywire when you have multiple TankTypes available on a given part via different typeAvailable within a ModuleFuelTanks module. What happens is this: 1. Add a second tank type (or whatever) to a part that is given the Default tank type already. In my hypothetical example, the part has 100 units to begin with, and the second switchable tank type is Fuselage, or 100% LF. 2. In the editor, when the part is placed, it will have 45 LF and 55 OX - as it should. The readout when you right click will tell you that it has 100 units total capacity (Volume avail. 0u/100u) 3. If you switch to the Fuselage tank type using the type chooser arrows, it should be 100 LF - but the original LF amount is retained. There will be 45 LF in the tank, but the readout will still say 0u / Tot: 100u. 4. Something like this happens when you switch from any tank type to another tank type containing at least one of the same resources. 5. So when you switch from LF/OX to LF, the LF will remain whatever it was to begin with. If you then switch to a third tank type that contains only MonoPropellant, and therefore has no resources in common with the last tank type, the amount of MonoProp that ought to be in the tank is calculated correctly. 6. Switching from LF/OX (45/55) to a tank type with LF, OX, and MonoProp will make the tank hold more than it should - Begin with 45/55, then switch: 45/55 are retained, and whatever monoprop that ought to have been added (let's say the tankType defines it as taking 20% of volume, so 20u) is added on top. Since the values for LF/OX are retained upon switching, you end up with 45LF, 55OX, and 20 MP. 7. The entire time, the tank's volume will read as <X units avail., probably 0> / Tot: 100u. 8. Switching to tank type that had nothing in common with the previously loaded tank type seems to bring values for stuff back to where they should be. Hope that describes the problem. You can replicate it simply by adding multiple tankTypes to any tank, making sure the tankTypes have a similar resource between them, and switching them in the editor.

Is it possible that FAR is changing the way in which my various crafts interact with water? I ask because I'm trying to pin down the cause of some weird stuff I've noticed in pure stock vs. my modded save, and because there seems to be an effect. E.g.: take a stock sandbox, fly the gull, land in water. You get something like this: Do the same thing in FAR and you get this: In the example with FAR, I modified wing mass so the whole craft weighs close-ish to what it does in Stock. Side note - is there currently any way to completely disable the way FAR messes with wing mass? Long story short, in FAR I find it very difficult to make a seaplane that will work, and it also seems to be pretty difficult to make one that goes straight in the water. Secondarily, when FAR is installed I also can't seem to get any kind of submarines to move underwater (engines and control surfaces seem to do nothing when submerged). Am I alone in this? What (if anything) is FAR doing to water...?

Indeed - cross sections are identical! With the right tweakscale settings they can match up very nicely.

Evident in your post are a couple of atrocious misunderstandings, FYI. 1. The fact that the issue with FireSpitter has been repeated many times means it is not a needle in a haystack; it is common. It's likely that you would have found an answer to your question without much effort, because it is common, and because you don't have to look through 78 pages to find it: only the last couple of pages in order to see if someone else has asked the same thing. The issue is that it is clear from your question that you didn't take the initiative in that respect. 2. The forum name of the person currently updating this mod is stali79. The name of the person who originally made this mod and posted the thread is K.Yeon. That means the first post of the thread does not belong to stali79. As a result, so far as I know, he cannot simply update the post on the first page. 3. It seems like you have a fundamental misconception of what to expect when updating KSP, because it appears you think KJR, MechJeb, etc. are a part of it - they are not. Squad is responsible for KSP, but they have no control over third-party modifications to the game. As third-party mods, KJR, MechJeb, FireSpitter and such must be adapted to the base game when it changes, not the other way around. You will forever be disappointed if you expect KSP and third-party mods (or any program and third-party mods) to continue functioning together when a bunch of code in the game is changed. When they do keep working well together, it's an unexpectedly happy occurrence. In light of all of that, what you say bout 1.1.3 not being ready for release doesn't make sense - except if you had mentioned wheels, of course, or minor bugs that persist in 1.1.3. Still, in the case of wheels, at least, Squad did the best with what was actually possible given their tools. I hope that helps you understand what you are asking for and why you would receive a peevish response on the ol' internet.

Give Atmosphere Autopilot a try first IMO, it might do what you want - or not.

OK, located a source for the 3x1 and 4x1 adaptors. It's here: https://www.dropbox.com/s/ajxeox95r50nfoj/LLL_MrWizerd_7_15_2014.zip

One issue I notice - the part configs in LLL-Extra/Parts/Structural/Adaptors point to nonexistent files in the LLL/Models/Structural directory. I know I had those .mu files and such at one point, they might still exist somewhere, but I sure can't find where I downloaded them from.

Is this a complaint? Well, then: rest easy, my friend, there's a solution! YOU go spend many hours building a wheel system from scratch for KSP, then provide it to others for free. If you're not willing to do that, then I wonder what you're hoping your comment will achieve. Do you want us to congratulate you on your clearly remarkable powers of observation...?

Just a suggestion - I think you'll avoid some headaches involving people asking you why parts aren't showing up if you remove the unnecessary first-level MoarMk1 directory (above GameData) from the zip!

FYI - the bundled version of ModularFlightIntegrator is not the latest.