gajbooks

Newest version, fresh install, and I hover my mouse over a 5 way resistojet and it crashes. No log output. Stack trace in spoiler. I am using several other mods, but I don't know why they would mess with a custom electric RCS?

Ok I'm confused now. For various reasons other than my game crashing.

Could you please make it so right clicking resistojets doesn't cause a CTD? That would be appreciated.

I completely agree. Radiators should be needed, but only in proportion to the vehicle. As in, you shouldn't be able to get away with a few tiny little radiators for your giant interstellar ship, but you don't need 200 tons either. I find the heat-based power limits on generators to be silly as well (Despite this being realistic). Reactors overheating and shutting down is a good mechanic, but engine efficiency being affected by the amount of radiators you have is silly too. On a side note, the EM engine does some rather odd things when used in timewarp. Changing the time warp setting to go faster results in a massive thrust boost until the number has finished scrolling to the new time setting. This may be a mod interaction, so don't go searching too hard if you can't find it. (TimeControl mod) As a general suggestion, I would rather have minor issues and usability fixed for the time being, rather than having the focus being on beamed power and other new features. Like the game sometimes crashing when I right click resistojets, radiators flying off, tweakscale working differently in opposite directions, mechjeb giving wrong information in regards to thrust due to this, and other things like lag that I blame on radiators and the mod despite having no basis for it besides the fact that stock parts run faster. It's also physics/game logic lag, and a 500 part stock ship launching through atmosphere has less lag than a 400 one in orbit.

I should clarify that I'm playing sandbox so the fact that radiators will be unlocked later is irrelevant and I'm only considering the most efficient ones. (As someone who posted before me realized, I might be relying on the incorrect VAB thermal helper?) To get the radiators to rip themselves off, put some automated radiators inside a fairing. Upon launch, they should be continually trying to deploy and immediately undeploying because they are stowed. Toggling their automation will make them extend. After they extend, clicking the "extend" button again will make them instantly jump to being undeployed and then deploy them again instead of retracting. I think I remembered wrong and they don't rip themselves off in atmosphere, but any time the fairing is deployed they immediately disintegrate.

I know it can be turned off, but turning it off right before launch results in the perma-extend bug and then explosions. Yes, real designs require more radiators, but this is KSP and needing 200 tons of radiators is excessive (and not to mention laggy). I know I can configure the button, but unless it's literally unfixable I'd rather not have to. I like the hotkey but it just pops in when naming things. By "limits" I mean that a single generator has a maximum possible energy output from a reactor. For example, when connected to an Open Cycle Gas Core reactor, a single thermal generator has a hard maximum of 1 GW thermal power. I'm aware that in reality you might not be able to cram everything in, but with the directly-connected-to-reactor requirement it gets sort of awkward to have to increase the diameter using tweak-scale.

Could you please for the love of everything fix the non-folding radiators that explode or disintegrate, some even when inside a fairing. The automation also tries to deploy radiators inside fairings, causing them to enter a permanently extended glitch state, resulting in their rapid unplanned disassembly upon takeoff. The thermal helper also shows up when you're typing in other text boxes. It's slightly annoying but an insignificant bug at most. It's also my personal opinion that it takes an excessive amount of radiators to cool things, and the power limits on thermal generators is a little silly.

I've looked through it some as well, and I have absolutely no idea why it's doing what it's doing. I made it write the contents of the Unity scene to the debug log, and it seems to create copies of all the textures and models for any part that has a WeaponModule or a MissileLauncher, which means all guns, bombs, and missiles.

I would like to report an issue. The resistojet RCS, when initially placed, doesn't have a selected fuel, which causes really bad things to happen like null pointers and major crashes. The properties also don't sync to symmetry. The Arcjets don't work at all, even slightly. (No, I'm not incompetent, the resistojets are exactly the same and work fine. Use a bit too much power if anything.) I'm also not sure if this is an issue, but Hydrazine has a stupid amount of Delta V with the nuclear lightbulb (I haven't tested anything else, yet). I see that it's crazy expensive for career, but it's imbalanced totally for sandbox. 20000+ m/s from one half-length tank and four double-scale spherical tanks. This weighs over 100 tons. I was bored so I sent it to another star. It'll be there in 8000 years and the reactor will be dead, but it'll be there (Until it falls back to Kerbol in several thousand more years). You say that so casually. Just watch out for black hole aliens that infect your reactor core like they did for those Romulans. I didn't want to merge that reply for a very good reason, KSP forum.

I fully understand that posts for "updates" is against the rules, but I have not seen a single post asking for an update. I have seen people repeatedly posting things because they can't read two pages back, but they were reporting a crippling bug and not just spamming "add moar gunz plox". On a side note, this mod didn't work on 1.1 either. It would also be helpful if the users knew that Baha knew the mod was not updated, and then some of this might be averted.

I logged the object names and that is what let me discover that it's the textures and models duplicating. Here are just a few lines that are around the base Browning machine gun part. There are duplicates of every line but I omitted them for space reasons. All BDArmory parts are duplicated in this manner, as far as I could tell. [ERR 13:34:54.821] bahaBrowningAnm2(Clone) [ERR 13:33:48.220] bahaBrowningAnm2(Clone) icon(Clone) [ERR 13:34:54.822] model [ERR 13:34:54.823] bahaBrowningAnm2 [ERR 13:34:54.824] shellEject [ERR 13:34:54.825] muzzleTransform [ERR 13:34:54.830] fireTransform [ERR 13:34:54.830] collider [ERR 13:35:37.249] BDArmory/Parts/browninganm2/tex_browninganm2 [ERR 13:35:33.598] BDArmory/Parts/browninganm2/model Some lines that are exclusive to missile weapons [ERR 13:32:43.428] ExpTex2 (Instance) [ERR 13:32:43.428] srbsmoke 1 (Instance)

I have this exact same problem. I think it's something to do with looking at the BDArmory tab for too long.

So, I figured that since BDArmory has a RAM leak, that I'd try looking at it (mostly just for my own learning experience) and see if I could fix it. After listing all the objects and assets in Unity when the leak is happening, I figured out that the parts are duplicating themselves (both textures and models) when viewed as an icon in the VAB. This only happens with BDArmory parts, not stock. Nothing in the BDArmory source has anything to do with part icons. I've looked around to see what could be causing it, but at this point I legitimately have no idea. I have no experience with the internal workings of KSP and I don't know what sort of issue would cause part assets to duplicate.

I mean its "supposed to" because the title says so, but there's some problem where looking at the tab in the VAB/SPH makes the game crash eventually (at least for a few people). Otherwise it seems to function fine.

Mech Jeb has a rover autopilot feature that has waypoints and stuff. It won't dodge missiles or anything but you could make tanks drive a pre-set path with guard mode on.

Yes, this is a definite issue. I wish that KSP had a debugger for plugins so I could find the problem myself, but sadly it does not.

Yeah, this is a big problem. I feel that gun turrets/lasers should prioritize missiles. As an extension to this idea, it would be great if there was a way to order different weapons to fire on different targets simultaneously. Say, each gun/missile individually can be set to "Vessels", "Missiles", "Both", or "User". Guard mode will fire "vessel" weapons at enemy vessels, "missile" weapons at incoming missiles, "both" weapons would act like the current ones (with missile prioritization), and "user" could only be controlled by the user and could also be controlled while guard mode is enabled. As an example, with a tank, you might want the 20 mm vulcans on anti-missile duty, the main cannon on anti-vehicle duty, and some manual g2g missiles that you can focus on while the tank defends itself. Possibly with minimum/maximum range sliders and Air/Ground/Both selectors. Another thing I definitely want is orbital targeting. This is probably harder than my first idea just because of the math involved. If these modes were implemented in the modular missile guidance then that would probably be better than specific missiles for each purpose. Ground to Orbit: Calculates an intercept burn, uses as much Delta-V as possible, and uses RCS to fine-tune approach. Some sort of orbital scanning system might be needed for locking targets. Orbit to Orbit: Like a normal anti-air missile, but predicts target motion orbitally instead of just leading the target and adjusting as needed. Orbit to Ground: Imagine Mech-Jeb's landing autopilot, but instead of landing nicely it hurtles screaming towards a GPS target on the ground. This is what I really want, because I've always wanted to make a fully armed and operational geostationary battlestation. Along with these a new autopilot mode might be needed: RCS/Engine thrust dodge, attempts to dodge missiles by swerving last minute using whatever thrust is available. Probably wouldn't work well for large ships but that's the point. It might be a de-orbit hazard, but I don't really see any other way of defeating missiles going at orbital velocities with the limited KSP load distance.

I think this has been mentioned before but not specifically as this. When in the BDArmory tab there is some sort of vicious memory leak that causes RAM usage to just go up and up and up and up and then crash the game. I don't know if this is helpful at all, but the more parts I have installed the faster the RAM usage goes up.

I'm playing in sandbox so I assume they should be maximum level. All of them except the radial and inline ones read as Graphene Radiator Mk 2, and the others are NaK Loop Radiators. (Another random thing I just found that isn't really a practical problem, is that hacking radiators into space with HyperEdit doesn't cause the Power Convected to reset)

I'm just going to make a little list of all the issues I have experienced, because there are quite a few. The number also went UP after I switched from 1.7.0 to 1.7.1. All issues are sandbox. Issues in 1.7.0 that may or may not still be in 1.7.1: All thermal engines refuse to switch propellant after FlameOut of one type of propellant. Nosecones can't hold combination fuels. Cannot move any type of depleted fuel to storage tanks. Thermal Power ratings in VAB information panels are completely and utterly wrong for all(?) reactors besides Molten Salt. (minor) Resistojets start with the propellant type blank, but switching fixes that. (minor) Molten Salt Reactor units are in MJ instead of MW in VAB. (minor) Mech Jeb causes engines to heat rapidly and explode with the fluttery control in translatron mode. This seems like a deeper problem with these engines and not really with Mech Jeb's behavior. Issues I know are in 1.7.1 that were not in 1.7.0: Electric thermal generators overheat immediately and require overkill-level radiators to keep above 2 GW for full power of a VASIMR engine with any sort of fission reactor. Fusion reactors are affected less. Electric generators for the Open Cycle Gas Core are inexplicably capped at 500ish MW no matter what scale they are. No indicator of max power for an electric generator in the VAB. Methalox ratios in the tanks are completely off from what the engine actually uses.

I'd appreciate this tip more, but I get 33 FPS on a GTX 670 and i7 3770K when a Kerbal X is sitting on the launchpad. I really hope 64 bit comes soon-ish so I don't have to deal with this horrendous OpenGL performance from Unity.

I think that Active Texture Management doesn't manage memory as well as OpenGL, and the "read only" option causes it to crash sometimes. I disabled that option and KSP has been relatively stable so far.

Does the clock in the upper left hand corner turn yellow when in-game?

Have you made sure KSP is running on the dedicated graphics card? Laptops are notorious for running games on the bad build in graphics instead of the dedicated card.

I had this problem before, and it went away after a driver update, but now it's back with a vengeance (Possibly after upgrading to Windows 10 and adding 8 more GB of RAM, or just another driver update I don't know which). The typical force-opengl works just fine and my game runs smoothly and KSP generally uses ALL of the available GPU RAM, and even shifts some data to who knows where (GPU RAM usage goes down at times). When switching scenes, every once in a while KSP decides to use more GPU RAM than I have, and crash the nvidia driver, usually crashing Firefox and itself in the process. I don't understand this, because when I fixed it by updating last time, GPU RAM usage happily went over the 2048 MB I had, up to around 2700 MB usage and was absolutely fine with no crashing of Firefox or KSP. GTX 670, newest drivers, 16 GB system RAM, Windows 10, newest KSP, a ton of mods (that worked fine earlier), active texture management might be worth mentioning.