NavyFish

Quick update, showing off the new target port text and cycle buttons. In other news, it may be easier to custom name docking ports on-the-fly than I had initially thought. That's still low on the list of must-haves for this release, but it might make it! The priority right now is really figuring out the best way to display the target hud overlay, but I had to take a break on that front tonight as I was feeling burnt out. My artistic patience is much thinner than my patience for code Anyhow, enjoy!

Nice, thanks for the feedback everyone! I too liked TMS's crosshair, so much so that I made one just like it. It just didn't stand out enough. But I'll keep trying. I hear the feelings that the spinning is too 'arcadey' for some, and I can understand that. @Diomeda: I haven't tried color pulsing yet actually. I'm using an orange texture and was just modifying the alpha channel. I'm going to re-color the texture white so I have full control over its color programmatically. Perhaps color pulsing will do what alpha pulsing did not! @LameLefty: The marker displays regardless of anything obscuring the port. I suppose I could use the same "CDI Reverse Sensing" logic (when the CDI lines turn red) to determine that the camera is looking at the back-face of the port (i.e. it's on the other side of the target ship) and then change the color or icon to indicate this. Will test. P.S. Heh, thanks VaportTrail. Learn Something every day.

Check it out: http://sourcedreams.net/spin.html There seems to be some 'hitching' of the spin effect... I'll be looking into that. fixed Feedback would be appreciated!

So, I'm nearing a solution for the hud icon. It's a pretty standard orange diamond reticle. I've tried to make it more pronounced by 'pulsing' its alpha value, and making it grow and shrink. The pulsing wasn't particularly eye-catching, and the growing/shrinking felt a bit ugly. What I'm now doing is spinning it. It draws your eye to it very effectively, but doesn't seem as obtrusive. Thoughts? I'll see about posting a quick demo video..

Eventually, yes. Probably not for this upcoming release, however. Several other things to do before then.

I wonder if he has a text file on his desktop, ready to copy and paste that block of text every fourth or fifth page..

I just created a new aircraft, without making your final proposed changes, and the problem is gone! The engines do not display EC as a tweakable. Huh. I hadn't realized that parts which had already been created wouldn't be affected by the MM cfg. Does this make sense, or are things getting weird? Anyhow, problem fixed! Great success! Thank you for your help, both of you! -Navy

I do have the B9 fixes for .23.5. Added the following to a cfg in my GameData folder: @PART[*]:HAS[@MODULE[ModuleEnginesFX],@RESOURCE[ElectricCharge]] { @RESOURCE[ElectricCharge] { %isTweakable = false %hideFlow = true } } Unforutunately, it didn't work. The engine in question still displays electric charge as a tweakable. The Modules section of the part's .cfg is as follows: MODULE { name = ModuleEngines thrustVectorTransformName = thrust_transform exhaustDamage = False ignitionThreshold = 0.1 minThrust = 0 maxThrust = 225 heatProduction = 600 useEngineResponseTime = True engineAccelerationSpeed = 0.12 engineDecelerationSpeed = 0.21 useVelocityCurve = True fxOffset = 0, 0, 1.13 PROPELLANT { name = LiquidFuel ratio = 1 DrawGauge = True } PROPELLANT { name = IntakeAir ratio = 21 } atmosphereCurve { // Based on Isp/TSFC data from NASA EngineSim, and Kerbin atmo. key = 0 1625 0 2.25E+07 key = 7.5E-06 1772 0 0 key = 0.0006 1492 0 0 key = 0.11 1668 0 0 key = 1 1440 -375 0 } velocityCurve { // Based on Fnet data from NASA EngineSim, curve fitted with MuMech CurveEd key = 0 0.56 0 -0.0003 key = 230 0.52 0 0 key = 687 0.7 0.0011 0.0011 key = 1030 1 0 0 key = 1260 0.5 -0.004 -0.004 key = 1430 0 0 0 } } MODULE { name = ModuleAnimateHeat ThermalAnim = jet_turbofan_heat } MODULE { name = ModuleAlternator RESOURCE { name = ElectricCharge rate = 5.0 } } RESOURCE { name = ElectricCharge amount = 0 maxAmount = 0 } } The hot rocket's MM cfg for the relevant engine has the following: @MODULE[ModuleEngines] { @name = ModuleEnginesFX //engineID = rocketengine runningEffectName = powersmoke directThrottleEffectName = powerflame !fxOffset } @MODULE[ModuleEngineConfigs] { %type = ModuleEnginesFX } I'm new to the whole part module thing, but perhaps instead of ModuleEnginesFX, I should use ModuleEngineConfigs in my 'fixer' cfg?

You're a genius..! I'll test shortly (currently in-game and my loading process takes ~5 minutes, so I'm going to hold-off for now). Will report back! -Navy

@ferram4: I just built a simple aircraft using only stock parts (haven't uninstalled any mods, same exact KSP install as before), and the editor analysis successfully plotted a graph. I loaded the .craft I sent you and systematically removed parts until the graphs worked. Turns out it's the engines - they are showing NaN electric charge, until I adjust the slider, after which point the graphs work again. The engines keep reverting their charge to NaN, oddly, so I have to do this every time I want to re-plot. The engines are the TFE731 Turbofan, part of the B9 pack. Stock jet engines do not have this problem (they don't even display electric charge as a tweakable). I definitely have the .cfg file posted earlier in my GameData folder, so it doesn't seem to be fixing the electric charge bug, which is almost certainly the source of the FAR editor analysis problem. It looks like this is not a FAR-specific bug, but probably a B9 one. Hope I didn't waste your time looking for a bug in your code. I'll probably make a post in the B9 thread, but for the sake of completeness (and in case someone else experiences this glitch and comes across this post), are there any further suggestions for fixing the NaN electric charge bug, specifically on B9 parts? -Navy

Both good points!

Pics for reference:

Looking for aesthetic inputs: I've got the HUD selected port indicator working. Currently I'm just overlaying the alignment indicator (orange circle) over the targeted port in world-space. I'm playing around with pulsing it's transparency, etc, but I'm not totally satisfied. Does anyone have any suggestions for the aesthetic? Pictures would be helpful! Regarding Raster Prop Monitor - I'll look into it. Eventually, yes, definitely. But right now there are a few other things in front of it on the to-do list. If you're curious, that list is currently: Hud Diamond over selected port [working, now just picking the aesthetic] Integrate port cycling into GUI [currently I'm using separate window & button to cycle. Need to integrate this aesthetically into the DPAI itself] Toolbar optional integration / update to latest version Update Alert Icon [a-la Kerbal Alarm Clock, Blizzy's Toolbar, etc. Notifies you when an updated DPAI is available] Filter out different sized ports Filter out shielded ports Raster Prop Manager Ordered by priority. -Navy

Here you go: http://www38.zippyshare.com/v/17145205/file.html Please note, I'm using B9 with the community fix for .23.5, which can be found here: http://forum.kerbalspaceprogram.com/threads/66020-B9-0-23-fixes?p=907484&viewfull=1#post907484 Thanks for looking into this!

I am indeed using 13.1, with FerramAerospaceResearch.dll having a date modified of 4/11/2014 : 11:24 PM and ferramGraph.dll on 2/18/2014 : 5:47 PM

@ferram4: Hello, me again. I'm still having the error where the editor analysis will not plot anything. As recommended, I created a .cfg file in GameData with the following text: @PART[*]:HAS[@MODULE[ModuleEngines],@RESOURCE[ElectricCharge]] { @RESOURCE[ElectricCharge] { %isTweakable = false %hideFlow = true } } Like last time, the first FAR Error seems to occur when it encounters "winglet3", Aerodynamic force = NaN. This error then propogates forward. I've uploaded an output_log.txt here: http://www74.zippyshare.com/v/99753960/file.html The error occurs at line 123219 in the file. Please let me know what further information I can provide! Thanks, -Navy

I've added the information about a lab being able to store multiple copies of the same data on the wiki: http://wiki.kerbalspaceprogram.com/wiki/Science This is such incredibly useful information!

Gents, Thank you for the team effort. Awesome! I won't be in a position to test out the fix until tomorrow morning, but am excited and confident to do so. I'm sure it's been said countless times already but - excellent work on this mod. It's inspiring to see how much of an impact one mod can have on such a core element of gameplay. -Navy P.S. - I'm assuming one should drop this text into a new config file "EngineElectricChargeFix.cfg" (or similar) file under GameData? asking mostly for others' future reference.

output log: http://www1.zippyshare.com/v/11465606/file.html (click the orange 'download now' button)

Sure enough, there are a whole slew of errors in my output log: FAR Error: Aerodynamic force = NaN AC Loc = 10.94645 AoA = 0 MAC = 1.587 B_2 = 1.695 sweepAngle = 0 MidChordSweep = 22.1 MidChordSweepSideways = 0.1689623 at winglet3 FAR Error: Aerodynamic force = NaN AC Loc = 9.932593 AoA = 0 MAC = 1.6 B_2 = 1.963 sweepAngle = 0 MidChordSweep = 12.09 MidChordSweepSideways = 0.1016958 at B9.Aero.Wing.SW.Canard.2-3x1-6m This continues for several thousand lines, after which point I get: DivideByZeroException: Division by zero at ferram4.ferramGraph.GridInit (Int32 widthSize, Int32 heightSize) [0x00000] in <filename unknown>:0 at ferram4.ferramGraph.SetGridScaleUsingPixels (Int32 gridWidth, Int32 gridHeight) [0x00000] in <filename unknown>:0 at ferram4.ferramGraph.SetGridScaleUsingValues (Single gridWidth, Single gridHeight) [0x00000] in <filename unknown>:0 at ferram4.FAREditorGUI.UpdateGraph (System.Single[] AlphaValues, System.Single[] ClValues, System.Single[] CdValues, System.Single[] CmValues, System.Single[] LDValues, System.String horizontalLabel) [0x00000] in <filename unknown>:0 at ferram4.FAREditorGUI.AngleOfAttackSweep (Single M, Single pitch) [0x00000] in <filename unknown>:0 at ferram4.FAREditorGUI.GraphGUI (Boolean tmp) [0x00000] in <filename unknown>:0 at ferram4.FAREditorGUI.ActualGUI (Int32 windowID) [0x00000] in <filename unknown>:0 at UnityEngine.GUILayout+LayoutedWindow.DoWindow (Int32 windowID) [0x00000] in <filename unknown>:0 at UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style) [0x00000] in <filename unknown>:0 (Filename: Line: -1) Mass: NaN S: 48.25777 MAC: 1.925892 I'll post the log in a moment so you can check it out.. upload speed here is quite slow and it's a 13mb file. Thanks for the fast response!!

Hello folks. I've recently started using FAR, and all I can say is wow. What a difference! I seem to have a bit of a bug on my hands, however. The Editor Analysis graphs won't plot anything, either via sweep Mach or sweep AOA. I've tried all varieties of upper and lower bounds, flap settings, updated the CoL, etc. No joy. Any advice? I'm using b9 with the .23.5 community patch, could this be the issue? Also using KW Rocketry and KSP-Interstellar, but that's about it for part mods. -Navy

That's in direct contradiction to what GoatRider just posted. Who's right? I'll test tonight and post my findings if no one beats me to it...

Any idea what happens if a kerbal on EVA clicks 'Take Data' on a lab with multiple copies of the same data? Will he only take one copy of each? If that's the case, then instead of having to land the heavy mobile lab back at kerbin, it could be placed in a parking orbit and several shuttle craft or SSTOs could be used to ferry the data down for recovery. Also, if built properly, the lab could remain in orbit and be docked to the next science expedition, saving precious mass on the next launch.

What was the second MPL for?

That sounds about right, though I've also never modified or created a part module so there might be a few hidden snags. Regardless, the ability to name ports is sounding cooler each time I consider it. As always, time is the factor which determines whether or not this will make the next update, but if not, then I could see it coming out in the one following that. As far as interface is concerned, I'd probably look to add a rename button to the right-click GUI both in editor and in flight, and have that name reflect in both the right-click GUI as well as on the DPAI when targeted. On an unrelated note, is anyone having issues with the precision of the indicator or any of its symbology? How about any confusion over the 'back hemisphere' (red CDI lines) mode? Any other 'core' functionality bugs/comments/requests? Finally, I'm happy to report that I finalized the the logic for port cycling last night. My favorite aspect of this is that the closest port is automatically targeted whenever a ship is first targeted. I like this so much that I may add a 'target nearest port' button on the indicator, so you can retarget as appropriate with a single click on the DPAI as you navigate around a large station. Thoughts? "Dock Safe" -Navy