BARCLONE

OK, first run with #280 (but without the FARext)... In the VAB In orbit The Delta-V is showing up again. Thanks, Sarbian!

Sarbian, Here's a screenshot of my VAB, and how MJ is acting. You can see only one line in the dV table with values, the rest are zero'd out. There are three engines on this rocket (notice the staging). MJ Delta-V Problem

Sorry, dtobi. I'm still getting an error dialog box with the "new" zips. What program were you using before now? Can you try using that archiver again?

Sarbian, https://www.dropbox.com/sh/xqjlmpxfeosl4v7/AABDYCCxgeIWzbvlFA6ym-ina Module Manager is 2.2.0... This has my last-recorded game save, the persistence file, KSP and Player logs, a copy of my MM "Parts Pilfering" file, my VAB craft files, and the "HallOfFame" files from FF. I'm not including the actual mod folders for the rest, since you probably have most of them. I've tried to keep everything reasonably up-to-date. As mentioned, I run the 64-bit version on Linux (Mint 17), but I have noticed references in the KSP log to the 64-bit version for Windows. Hope this helps.

Sarbian, I just looked through both my KSP.log and Player.log files, but I did not see any of the errors described by Jasmir. Several instances of ModuleManager throwing exceptions, but nothing from MechJeb. Jasmir's screenshot, however, is the same as what I'm seeing for the Delta-V window. In the VAB, it's a line of zeros.

Sarbian, Just installed 277... The caption at the top of the MJ dialog still says "2.3.0" instead of "2.3.1"... I tried installing both ways -- replacing the DLL, and installing a full package. No difference. The dV calculations are not showing up either in the VAB or out at the pad. I get a dialog screen, but either lines of zeros or no data at all. The game appears to "see" the engine has fuel in the tank, though, as it proceeds with a burn as normal. The vessel stats dialog showed "NaN" on several data displays just before physics kicked in, then changed to something readable.

Sadly, no. I've tried the "Wayback Machine" with no immediate success. I still have my copy of the zip file from 03-2013. That's what I've been using.

Nathan (and anyone...), I don't know if there's an active thread for those PlaCo shields, but I managed to get them visible and attachable in the VAB under 24.2, if anyone's interested. This "fix" is simple, but requires messing with the CFG files. Those PlaCo shields were created before the new parts structure was introduced. Create a folder under "GameData" called "PlaCo" Move all of the PlaCo folders from the PARTS folder into this new folder Open each CFG file and add this line as the TOP line: PART{ Add a closing } as the very LAST line Optional: add a line TechRequired=**** to determine where in the parts tree you think each shield should be available at. Restart the game, go into the R&D, and "research" the new parts to activate them SAVE the game Whether they still work or not, I don't know. But I figured getting them to show up at all was a good sign. I'm not a DRE user, but I do like the FX...

Kanada: Justin Kieber may be a national embarrassment, but the talents of Gordian Kerbalfoot more than make up for him... And if there were girl Kerbals, Kania Shwain ain't too shabby, either...

Error messages:

dtobi, I just DL'd the new files, and I'm getting the same error messages when I try to unzip them. Previous versions didn't give me any grief on Linux, so there must still be something corrupted getting in the archive.

RoverDude, I'm just starting to find your threads, so sorry if I've missed something important before making this post. I'd like to suggest a different approach to all of this. Instead of making the mod focus on a single compound, why not create a "framework" for handling any number of "plug-in" elements? Use the real-universe "Periodic Table" as a starting point instead of imaginary materials that "just happen to have all the properties we need". Each of the PT elements could themselves just be a CFG (maybe a PTE file -- Periodic Table Element) file with all of the properties, and the framework keeps track of them (like a database). The challenges this would introduce to the game would be 1.) to "develop" tools to detect each element, 2.) to "develop" tools that extract each element, 3.) to "develop" tools that refine/separate/combine these elements into useful resources. All similar to what we're used to with Kethane, but expanded to cover all of the real-universe elements. The challenge would also allow the inclusion of those "higher atomic number" elements that have been theorized, but never discovered "in the wild", just synthetically produced in labs for brief lengths of time.

dtobi, You need to look at the way the packages are "zipped". I'm getting the following message when I try to unpack each one: I'm not a MSWin user, I use Linux Mint 17, 64-bit.

Sarbian, MJ 2.3.0 -- KSP 0.24 -- Linux 64-bit Playing now for a full day... Need to report some consistent general goofyness in MJ behavior when running Career-Contracts mode. MJ AGAP doesn't want to control the throttle during ascent. It keeps the throttle at the game setting (50%) throughout the ascent, and allows the engine to run at the same setting in the coast-to-apoapsis phase. This, obviously, throws the apoapsis well above the desired altitude. Looked through the logfile on my latest run, and there were no ERR messages for any MuMech or MechJeb items. Looks like the latest FAR build is having a bad hair day, though. Bunch of NREs, but none appeared to be associated with MJ. The Toolbar integration is also having hiccups. If I have to "Revert To Launch" a bunch of MJ module buttons suddenly disappear. I can restore them via a trip through the tracking station. If I can spot anything directly MJ-related in the logs, I'll post.

Hehe, Nathan, you weren't kidding! On a lark, I just tried your recent alpha with ProcParts and got some bizarre results. It was fun for me seeing the outcome, as nothing was lost. FWIW, ProcParts makes three mods in my list that are not playing nice with 24 -- ProcParts, ProcFairings, and RealChutes. @e-dog, I don't know what others are experiencing, but I'm not seeing the size adjustment sliders in the right-click boxes. There seems to be enough room in the "gap" for three items, but I don't recall what the other two were. The extra radius slider is visible, though.

I don't suppose you could produce an "interim build" just to fix the compatibility issue, could you? Just to get us by until Swamp_lg gets back?

I think it's "supposed to be", but there are times it feels like only a 64-bit wrapper around 32-bit code.

I just had to do a complete re-build of my game and mods, as it was beginning to act seriously ugly. After repopulating a few mods, the LGAP has started working correctly. A new LKO Taxi did a proper de-orbit burn from 200 km, and the target indicator in map view followed the projected impact spot like it's supposed to. I'm suspecting either an incompatibility between MJ and one or more of those mods, or a full memory issue (very likely). Hopefully there will be a Linux build in 64-bit alongside the new Windows version... Just thought I'd share this tidbit of info, maybe there's less of a problem with some of these MJ modules than it first appeared. Sorry I could only share some good news instead of the bad you were so eagerly wanting to hear...

Just tried out this mod, and it smoothed out the launch of one of my 'heavy-class' launchers. It didn't experience the "pendulum" effect (MJ PID-control error corrections) during the ascent to orbit that I'd seen previously. Very nice!

Having played with the DAP for a while, I've noticed that if I try to engage too closely, DAP goes a bit nuts. But if I start, say, 45m directly in front of or at an angle to the target, DAP is all sweet and friendly (most of the time, not all of the time...). Is there an "optimum minimal distance" and an "optimal maximum approach angle" for setting up the DAP? Is this calculated for each set of docking vessels, or is there a "hard-coded" set of values in DAP?

You mean [gasp!] there are other games besides KSP? Actually, I understand fully. My other activity when I'm not screaming toward asteroids trying to slow down, or desperately trying to reach one with my remaining dV, is building RC airplanes from scratch. Quite therapeutic...

@smart013 -- I'm sure the LGAP will get some attention on these issues. Heaven knows I've mentioned some problems with it a time or two... Sarbian, one consistent thing I've noticed (at least with Kerbin landings) is the map view "projected target" doesn't get updated unless I've aborted MJ to do the final burn manually. If MJ is doing it, the target indicator (the blue one) doesn't move once it shows up in map view. It also pops itself onto the map far to the west of the target, instead of the intersect point of the orbit with the surface. MJ seems to take the data from the indicator when plotting out the last part of the burn, which is why it wants to burn pro-grade. Maybe this is at the root of the problem with all of these landing modes, whether at Kerbin or Moho, or some other body. Side note - Feature request: For better rendezvous, could we get an option about when MJ starts the velocity match burn? Perhaps something that allows MJ to begin the node burn earlier than the projected start time (typically half the burn duration ahead of the node). I've had occasions where I've screamed past asteroids at multi-hundreds of m/s at closures of less than 300 m, simply because the burn started later than it should (happens a lot) or because my ship's engine is a low-TWR type that takes minutes to bring the velocity down (instead of seconds). A checkbox to begin the burn at the full-burn-duration ahead of the node would be helpful; a slider allowing us to vary the time between half-duration and full-duration ahead of the node would be great.

I typically start at 200 km. Even when coming in from Mun or Minmus, or beyond Kerbin SOI, I settle into a 200 km orbit first, then do the LGAP. Right now, I'm trying to get my LKO Taxi to bring the guys home from a short hop around the block. My taxi is a familiar "Apollo-style" CSM, currently using the new Odin II pod. I've added the MJ module to the pod, so I don't have to use the AR202. The desired entry is standard fare -- I select PAD most of the time, then manually change the second group of numbers to 71.30.00, to put the target east of the pad. Then I engage the LGAP and let it run until the ship reaches 69 km, where I disengage LGAP and use SA to point the ship -RAD (nose-down). I then punch off the SM and set SA to RET GRADE until the re-entry plasma starts to form, then I go KILL ROT and let the ship drop. I'm using RealChutes with the trigger altitude at 12.5 km, so it deploys automatically. Using this sequence, I've generally dropped down on top of the center or just off the edge of the cape in the water. More often than not, my landings on non-atmosphere bodies work fine. Landings on Moho have been problematic, though. It's been a long time since I've tried landing out there, so I can't say right now what my results will be. I just want to get my home-bound pods to do a proper entry; I don't mind having to shift the terminus eastward like I described, it's the weird behavior with the fine-tuning burn that bugs me.

Sarbian, I'm playing with the latest (263) build... If I'm within a certain distance to the target port, the DAP is insisting on moving to the rear of a target before trying to align ports and move in for the approach. My crew ship nearly came in contact with the carrier stage (the docking target is under the fairing shroud) trying to reach the "starting point". The DAP needs some way to see if the projected "starting point" is in front of the target or behind it, and make a correction to always be in front, before making any move. Also, is there a way to "tweak" the approach angle to the target? Seems to me DAP is always trying to come in at an excessively steep vector. I don't see "real" spacecraft (like Soyuz or Progress) approaching the ISS this way -- they're always straight-in to the target. The LGAP is acting ugly when trying to pinpoint the VAB or the PAD for a landing on Kerbin. It begins the high-orbit burn OK, but the "projected landing target" positions itself on the map view far to the west of the desired location and freezes. When the initial burn finishes, the LGAP rotates the ship fully 180 (pro-grade) and burns the orbit back up instead of fine-tuning. The projected target never moves in all of this, which probably explains the burn to pro-grade -- LGAP sees the projected target is too far west, and is trying to move it east. It doesn't move, so LGAP keeps trying to compensate until all of the fuel is burned. ADDENDUM: If I take the LGAP off and "fix" the entry path manually, the "projected target" moves to follow the terminus. Apparently the "projected target" position gets updated if I do it manually, but not when it's on auto. Linux Mint 17, 64-bit...

Played with the new Philly unit today, did some practice touch-n-go's on a class-E. Worked fine. Thanks, dtobi!