velusip

Did you try pressing "R" to change the type of symmetry?

Hello Kerbals, One of my controllers is not shown in the AFBW controller listing. The log shows unity detecting everything, and the mod is "Loaded" and "initialized" without any errors. However, when the AFBW window is open (Ctrl+L) the framerate drops to less than 1fps. I won't be able to get around to debugging this right away, but I can at least assume there is something fishy regarding the configuration for CH pro pedals. This is the only useful bit from my log for now: /dev/input/js0: driver version: 2.1.0 (20100) /dev/input/js0: fd 46, buttons 16, axes 5, name raphnet.net WUSBmote_v1.3 /dev/input/js0: axis 0: raw 0, mapped 0.000000 /dev/input/js0: axis 1: raw 0, mapped 0.000000 /dev/input/js0: axis 2: raw 0, mapped 0.000000 /dev/input/js0: axis 3: raw 0, mapped 0.000000 /dev/input/js0: axis 4: raw 0, mapped 0.000000 /dev/input/js1: driver version: 2.1.0 (20100) /dev/input/js1: fd 47, buttons 19, axes 5, name CH PRODUCTS CH PRO THROTTLE USB /dev/input/js1: axis 0: raw 0, mapped 0.000000 /dev/input/js1: axis 1: raw 0, mapped 0.000000 /dev/input/js1: axis 2: raw 0, mapped 0.000000 /dev/input/js1: axis 3: raw 0, mapped 0.000000 /dev/input/js1: axis 4: raw 0, mapped 0.000000 /dev/input/js2: driver version: 2.1.0 (20100) /dev/input/js2: fd 48, buttons 19, axes 5, name CH PRODUCTS CH FIGHTERSTICK USB /dev/input/js2: axis 0: raw 0, mapped 0.000000 /dev/input/js2: axis 1: raw 0, mapped 0.000000 /dev/input/js2: axis 2: raw -19932, mapped 0.000000 /dev/input/js2: axis 3: raw 0, mapped 0.000000 /dev/input/js2: axis 4: raw 0, mapped 0.000000 /dev/input/js4: driver version: 2.1.0 (20100) /dev/input/js4: fd 49, buttons 0, axes 3, name CH PRODUCTS CH PRO PEDALS USB /dev/input/js4: axis 0: raw -32767, mapped 0.000000 /dev/input/js4: axis 1: raw -32767, mapped 0.000000 /dev/input/js4: axis 2: raw 0, mapped 0.000000

So I arrive at KSC this morning only to find it is barricaded. I was able to smash a window and get into R&D, but the door is barricaded from the outside. I can only assume this is the work of Kerbal rights activists. Probably something regarding cloning or recognizing clones as people, I'm not sure. Some time back, during a station building missio,n we ended up with Jeb staring at Jeb on a spacewalk -- an accidental cloning, I don't want to get into it -- regardless, I'm locked in/out/whatever. Enough about that, onto the solution: I contacted payroll about adding a second entry for Jeb in the books. Thus recognizing clones as people and ensuring any payroll disputes are handled, but I'm still locked up. I'm considering climbing back out the window, going into hiding for a few years, and starting a new space program under a different corporate identity. Here's our mission history as per my company laptop. Any help is appreciated. http://sprunge.us/TQDY

See thread http://forum.kerbalspaceprogram.com/threads/100793

When you say stock volumes are bonkers you mean they are too high? In that case, why are the few existing RF volume configurations for plane parts generated with such a high multiplier? Or did you mean that the stock volumes are too low and required a higher multiplier to account for all the empty space? I'd like to fill in the blanks in the RF volume config for all these new stock parts. I just need to know some of the rationale that went into the plane parts which already have RF volumes defined (mk2Fuselage, et cetrea). I tried using some Blender plugins to calculate volume in the stock parts as a starting point. I will then subtract volume based on some assumed/imagined internal structure based on the stock crash strength, and further subtract what other systems might occupy the part internals (cockpit, life support, electronics, pumps, solenoids/servos, et cetera). Since several of the models are poorly made, I can't get an accurate volume from Blender (perhaps someone else has more experience summarizing subtractive geometry to yield fine detail). In the meantime I will just overlay simple geometry and add up an approximate volume.

There's a long thread here, but perhaps someone can point me toward the rationale for setting the tank volumes as they are? e.g. Most of the rocket fuel tank volumes seem to be merely multiplied by 5 to yield the realfuels volume. However the volume of spaceplane parts and adaptors are variable from 8.33 to 13.3. It doesn't seem to be related to crash strength or structure, part scaling, and I can't accurately calculate part volume, so I'm not sure why these values exist. Anyway, a whole bunch of new tanks need to be added, and I'd be happy to help, but I just need info. Here's the incomplete chart I generated by parsing the stock files and comparing to the provided module manager changes: mono O2 liquid volume crash multi "nacelleBody" 40 "radialEngineBody" 40 "adapterMk3-Size2Slant" 1125 1375 "adapterMk3-Size2" 1125 1375 "adapterSize2-Size1Slant" 360 440 "adapterSize3-Mk3" 1125 1375 "adapterSize2-Mk2" 360 440 "adapterSize2-Size1" 360 440 "adapterMk3-Mk2" 900 1100 "fuelTank1-2" 1440 1760 16000 6 x5 "miniFuelTank" 5.735 7 62.5 6 x4.91 "fuelTankSmallFlat" 45 55 500 6 x5 "fuelTankSmall" 90 110 1000 6 x5 "fuelTank_long" 360 440 4000 6 x5 "fuelTank4-2" 360 440 4000 6 x5 "toroidalFuelTank" 10 12.2 112.5 6 x5.07 "fuelTank" 180 220 2000 x5 "fuelTank3-2" 2880 3520 32000 x5 "fuelTank2-2" 720 880 8000 x5 "MK1Fuselage" 150 1900 20 x12.67 "mk3Fuselage" REMOVED "mk3FuselageLF_50" 5000 "mk3FuselageLFO_25" 1125 1375 "mk3FuselageLFO_100" 4500 5500 "mk3FuselageLF_25" 2500 "mk3FuselageLF_100" 10000 "mk3FuselageLFO_50" 2250 2750 "mk3FuselageMONO" 1000 "mk2FuselageShortLFO" 135 165 3600 50 x12 "mk2FuselageShortLiquid" 300 2500 50 x8.33 "mk2Fuselage" 600 5000 50 x8.33 "mk2FuselageLongLFO" 270 330 7200 50 x12 "mk2_1m_Bicoupler" 135 165 4000 50 x13.33 "mk2_1m_AdapterLong" 225 275 5900 x11.8 "mk2_1m_Adapter" REMOVED "mk2DockingPort" REMOVED "mk2pit_Standard" REMOVED* "mk2Cockpit_Standard" 15 45 "mk2pit_Inline" REMOVED* "mk2Cockpit_Inline" 25 "mk2SpacePlaneAdapter" 135 165 3000 x10 "mk2FuselageShortMono" 300 3600 x12

Updated the stock Inlets by clearing the dangling definitions (small versions of parts removed) and added the 3 nacelles. Might be incomplete, but seems to work well so far.

I think this crashes pretty bad with RealFuels installed. It complains about the resource types and then mayhem. This is pretty understandable, though.

Just a heads up, many of the parts now contain a small fuel tank for LiquidFuel (e.g. nacelleBody, radialEngineBosy, some cockpits), but this is not reflected in the overrides in RealFuels. I did a quick thingie and the results are in. This is how I got that list, just in case it's missing something. find . -name '*.cfg' -exec awk '/LiquidFuel/{ln1=NR;line1=$0} /amount/{ln2=NR;line2=$0} END{if(ln1&&ln2&&ln1 <ln2){print FILENAME, "\n", line1, "\n", line2}}' {} \;|sprunge

Okay, scratch anything I said earlier. Any information on how the Inlet configurations are defined? I mocked up some definitions for the missing inlets area (radialEngineBody = 5, radialEngineBodysmall = 1, nacelleBody = 5, MK1IntakeFuselage = 3), but I'm not sure how to derive appropriate TPR.

Porkchops in my KSP? It's more likely than you think. Awesome work, TriggerAu!

It was a problem with a missing intake configuration and defaulting to silliness. However, here's an unrelated/new problem when using RealFuels: After filling a fuel tank with only Kerosine (which by default contains resource definitions for LiquidFuel and Oxidizer), AJE's modified engines will not pull the Kerosine resource from that tank (or any similar tank). The engine will spool up and make some noise, but no fuel is consumed or thrust produced. Everything works fine when switching to a stock single fuel tank filled with kerosine.

Just noticed there is no intake configuration for the MK1Fuselage in AJE. I'm not sure what configuration would be fair or how you have been calculating it from the model geometry, so I have no input atm. edit: I'm just copying the nacelle config and dropping the intake area from 3 to 2. From eyeballing them side by side it appears about two thirds.

Perhaps the energy density is fine. I mean, I don't know what the units are in stock and I haven't been following on with the developments of RealFuels. It just didn't seem right when trying AJE with stock. It's hardly worth the effort to look into, especially since RealFuels is now updated (lol), but assuming the Mk1 liquidfuel tank contains less than 1000 litres of fuel: should this engine be able to throw it out the back so quickly?

This needs a Scott Manley video review.

I tried using AJE without RealFuels while it gets updated, but it doesn't seem to be balanced for stock engines. Fuel consumption and thrust are both way too high. Has anyone tried creating a sensible configuration for no RealFuels?

I've said it before, but I wanted to say it again. This mod is so good. It perfectly complements my play style of having an extremely hectic and simultaneous space program. Thanks to Trigger and all who have supported it.

Well, whatever you did fixed the lightspeed vessel disassembly. Back to FAR!

Even fewer can fix it for everyone. Any information on what messages were causing the crash? Even without knowing, how about serializing the client-server message from an object, then handle error checking during deserialization on the server? Anything that does not deserialize correctly is simply dropped. Any other kind of abuse can be dealt with at the firewall. For us Linux and Mac users we would rather use the console app. I will at least start fixing it up to meet certain usability standards and put up a pull request later. I also intend on using a nice code formatting scheme. (e.g. update .gitattributes, no tabs, etc) Also, any plans to fork through github? I mentioned this already, but your current repo does not retain the original chain. It's not a huge problem, but it's nice to keep a full record.

I noticed the server source is not provided in your new repository. I was banned from your server for sending a message that was too long. I'd offer to fix this, but your source is not present.

You broke the blame chain!

A little something for EVE Online players. You can use TriExporter to obtain nebula artwork and make it compatible with TextureReplacer. There's a mod for loading dds format directly, or use the attached script to convert to plain images. You can further composite some star textures over the nebulas this way, so that's nice. I don't really want to chat with CCP's legal department, so instead of posting anything I've made with their assets, here's what you need to do duplicate the work! From TriExporter the nebula can be found in: * dx9/scene/wormholes * dx9/scene/universe * texture/nebula The star textures can be found here: * dx9/scene/starfield/stars01_tile2 I noticed that some of the dds files in EVE are slightly different formats. You might get upscaled images with imagemagick, so pass in a scale of 50% where needed. if [ -z $1 ]; then echo "Usage: ${0##*/} <dds file> [<scale percent>]" echo "e.g. : ${0##*/} cubemap.dds 50%" exit 1 fi if ! type convert > /dev/null; then echo "Missing imagemagick program "convert"." exit 2 fi if [ -z $2 ]; then scale="100%" else scale="$2" fi convert $1 -scale $scale $compose GalaxyTex.png for i in {0..5}; do if [ ! -f "GalaxyTex-$i.png" ]; then echo "Failed to generate images." exit 3 fi done mv GalaxyTex-0.png GalaxyTex_NegativeX.png mv GalaxyTex-1.png GalaxyTex_PositiveX.png convert GalaxyTex-2.png -rotate 180 GalaxyTex_NegativeY.png rm GalaxyTex-2.png mv GalaxyTex-3.png GalaxyTex_PositiveY.png mv GalaxyTex-4.png GalaxyTex_NegativeZ.png mv GalaxyTex-5.png GalaxyTex_PositiveZ.png

No. The orbit paths of RSS users are not seen at all by non-RSS users. (Well, position might be visible when on the ground.)

It is a stock bug that has been around for a long time. Something about the new destructable launch pad and runway are making it more apparent on Linux builds. It's too bad that loading during launch is not verbose. This is the best I can do until I figure out how to make things more verbose: KSP v0.25 (Linux, 64-bit) - FAR v0.14.3.2 Flight State Captured Saving Achievements Tree... Game State Saved as persistent [Untitled Space Craft]: ground contact! - error: 0.041m Unpacking Untitled Space Craft Stagnation Pressure Coefficient Curve Initialized recalculating orbit for mk1pod: Kerbin rPos: [657184119436.949, 181017846892.654, -1153055725.19357] rVel: [16429588938705.5, 4525442203816.25, -28826368000] |17041474431351.5| recalculated orbit for mk1pod: the Sun rPos: [643583319705.133, 181072139550.429, -1153055725.19357] rVel: [16429536282545.8, -28826368000, 4525633362253.53] |17041474430005.3| [Progress Node Reached]: Escape [Progress Node Reached]: Kerbin [Progress Node Complete]: Escape [Progress Node Reached]: Flyby [Progress Node Reached]: Sun [Progress Node Complete]: Flyby setting new dominant body: the Sun FlightGlobals.mainBody: Kerbin Vessel mk1pod velocity resumed. Reference body: Sun vel: [16429536282545.8, -28826368000, 4525633362253.53] dT is NaN! tA: NaN, E: NaN, M: NaN, T: NaN getObtAtUT result is NaN! UT: NaN dT is NaN! tA: NaN, E: NaN, M: NaN, T: NaN getObtAtUT result is NaN! UT: NaN nearestTT is NaN! t1: NaN, t2: NaN, FEVp: NaN, SEVp: NaN getObtAtUT result is NaN! UT: NaN ArithmeticException: NAN at System.Math.Sign (Double value) [0x00000] in <filename unknown>:0 at Orbit.solveEccentricAnomalyExtremeEcc (Double M, Double ecc, Int32 iterations) [0x00000] in <filename unknown>:0 at Orbit.getRelativePositionAtT (Double T) [0x00000] in <filename unknown>:0 at Orbit.getPositionAtT (Double T) [0x00000] in <filename unknown>:0 at Orbit.getPositionAtUT (Double UT) [0x00000] in <filename unknown>:0 at Orbit.SolveClosestApproach (.Orbit p, .Orbit s, System.Double& UT, Double dT, Double threshold, Double MinUT, Double MaxUT, Double epsilon, Int32 maxIterations, System.Int32& iterationCount) [0x00000] in <filename unknown>:0 at PatchedConics.CalculatePatch (.Orbit p, .Orbit nextPatch, Double startEpoch, .SolverParameters pars, .CelestialBody targetBody) [0x00000] in <filename unknown>:0 at PatchedConicSolver.Update () [0x00000] in <filename unknown>:0 It looks like ground contact before the vessel is loaded. It could just be an issue with the way the logger works, but I'm quite sure that FlightGlobals.ActiveVessel.parts is empty upon the first run of Update() (maybe more than the first). While your mod may not interact with part state directly, FAR simulation does appear to run and values are set before the parts know where they are. Chances are some obscure values get accumulated early on in the simulation? This doesn't happen with NEAR, so that cuts down on the possible problem points. Not to say NEAR doesn't run early, I haven't looked. However, I don't use NEAR because it seems to cause problems with Deadly reentry and RealChute. I haven't looked into that much, but I might do some testing and post in an appropriate thread later.

I'm kinda stuck. I suppose I need to test on other computers. Anything launched on the launchpad has a chance to instantly smash the vessel and send the pod at impossible speeds with FAR. This doesn't always happen when launching on the runway (from SPH). Furthermore, reverting to launch puts the game in a strange state. I have a feeling this is related to a bug with how FlightGlobals.ActiveVessel.parts is managed during scene transitions? Some reports regarding that here: http://bugs.kerbalspaceprogram.com/search?utf8=✓&q=FlightGlobals Anyway, for nothing more than entertainment purposes, here's the screenshots and log: Upon launch I see my craft on the launchpad while things load. As soon as simulation starts, the next frame is this: http://i.imgur.com/jnvtQGE.png Broken state after reverting the flight: http://i.imgur.com/X7sERwg.jpg and http://i.imgur.com/T7PuqD5.png Log: http://sprunge.us/FXON This is with several other mods, but the same results with only FAR. Works fine with all other mods without FAR.