kujuman

All of the parts (repulsor included) have a stock ModuleWheel which is a container for the WheelCollider and all of the physics associated with wheels. The custom PartModules attached to these parts modify that ModuleWheel. There may be a way to force the ModuleWheel to collide with the ocean's layer (though I think he'd have to do something like ocean.enableraycastcollisions), but a better bet would be to calculate and add an up force on the collider itself. This second way wouldn't get WheelHit information, but I don't think the repulsors use that method anyway. So possible probably with enough work, but it's set up that way (AFAIK). Edit: A more hackish way that is so stupid it might work would be to dynamically create a collider at sea level under each wheel when over the ocean. I'm actually trying this now.

I really like this idea. I'd like to be able to fly the main KSC flags at half-mast too.

So what needs to happen (for the outside turn wheels) is for the wheelcollider proper to be forced down with the same force as the attached rigid part is forced up. There is no net translation force on the vessel, the outside wheel increases its force on the ground, and the body of the vessel rolls towards the inside wheel. To check, this is the same net result as increasing the spring force? I think so. I'm away from my development computer, but looking through the unity scripting API, there's an attachedRigidBody member of WheelCollider. I think for all intents and purposes that's the same as the main part collider. If you add a force to the attachedRigidBody and an equal and opposite to a force added to WheelCollder.collider (or whatever the actual wheelcollider is), this should produce the anti-roll behavio(u)r you're looking for. Of course, whether or not Unity lets you actually apply forces to these parts correctly is anyone's guess. I hope this helps, and good luck. If you need any help with lists, I can help, though they are pretty straightforward. Edit: I have a hard time judging dynamics (I don't know what the behavior should "feel" like), but here's a static test.

Ok, thank you. I didn't find a HL fuselage cockpit, did you mean the S2 Reusable Pod (it looks kinda like a space-shuttle with black tiles on the bottom)? I'm thinking it's a problem with that cockpit/config files because everything else indicates it should work fine. I've D/L'd and installed B9 and the K3 internals, and it seems to work fine for me :/ This warrants additional investigation. 1) Does it work in the stock cockpits?

1) Which version of RPM do you have? Are the other features working as expected? 2) Which command pod are you using? 3) Please describe "just isn't there" more. Is the display not cycling when you press the "A" key on the MFD? 4) You need toolbar/the standalone version to make the RPM version work. Are you able to use the HSI with toolbar outside of IVA? 5) This mod is very particular about where it gets installed. Is the folder "KerbalScienceFoundation" directly inside of "GameData"?

What it does is increase the angle of attack (AoA) of the flap relative to the wing. Increasing AoA will generally pass through three stages, in increasing amounts of AoA: 1) increase lift, 2) increase lift and drag, 3) stall the wing, massive decrease in lift, increase in drag. Long answer short: yes, you can fly more slowly unless your flap/brake max setting is too high. I try to keep my flaps centered around my center of Lift. If your flaps are behind you center of lift and they then create more lift, your plane will tend to pitch down. So flaps on the tailplane can cause your plane to nosedive. Spoilers on the tail will tend to do the opposite and pitch the nose up. "Flaps/Brake M..." is Flaps/Brake Max angle. Flaps get set in four settings. At flap 0, AoA is 0. At flap 3, AoA is Flaps/Brake Max angle. Flap 1 and flap 2 provide intermediate values. For simple aircraft, a good starting place for flaps is 40. If you use the FAR analysis tools you can tweak these values to get the performance you want. For a starting point I only use flaps on the wings unless I'm doing something special. An example of this: Sometimes my spaceplanes will have the Center of Mass shift very far forward when they are low on fuel. This can make keeping the nose up difficult. To solve this, I sometimes add positive value flaps to canards or negative value flaps to my tail plane. I hope this helps

Progress update for 0.4.0 -The RPM buttons that control G/S and runway are now configurable in the .cfg for each RPM installation (btnNextRwy = btnID basically) -The RPM display no longer uses RPM for text display, and now looks identical to the standalone version -Work is progressing on the "Add/Edit/Remove a Runway definition in game" feature. I have successfully saved runways created in code to a .cfg file, which would load next time KSP loads. --next major step is implementing the GUI to work with it. I know what I want to have it look like, so it's really just sitting down and writing it. should be fun The plan is to have the user enter a runway name and then move a vessel to the location they want the touchdown to be at. Heading and elevation will be automatically determined, unless the user wants to have manual values. the Loc beacon is planned to be located automatically 1km from the touchdown point. note: I'm not redoing how runways are defined, at least not until there's a reason to do so (like other types of nav aids). Cross-posted in the development thread.

Progress update for 0.4.0 -The RPM buttons that control G/S and runway are now configurable in the .cfg for each RPM installation -The RPM display no longer uses RPM for text display, and now looks identical to the standalone version -Work is progressing on the "Add/Edit/Remove a Runway definition in game" feature. I have successfully saved runways created in code to a .cfg file, which would load next time KSP loads. --next major step is implementing the GUI to work with it. I know what I want to have it look like, so it's really just sitting down and writing it. should be fun The plan is to have the user enter a runway name and then move a vessel to the location they want the touchdown to be at. Heading and elevation will be automatically determined, unless the user wants to have manual values. the Loc beacon is planned to be located automatically 1km from the touchdown point. note: I'm not redoing how runways are defined, at least not until there's a reason to do so (like other types of nav aids). Cross-posted in the release thread.

Yes, it does. At the very least, sound is a separate thread. I would not be totally shocked if the contracts checking system or the like can get its own thread. The bottleneck now is the physics integrator. It is a single thread right now is will be for the foreseeable future due to what are understood to be limits in Unity/developer time. edit actually, now that I think about it, I bet most mods are being run in that same thread (apparently parts of Mechjeb can run asynchronously). Someone who knows what they're doing might be able to write a guide for multithreading KSP addons.

After some testing it looks like the colliders only get their values reset after they leave contact with the ground. Which...is weird. As to the apply-a-counter-force option not working out for you, it does seem like this should be a proper way to do it. I think you were getting weird forces because of the " suspensionTravel" variable not staying where it's supposed to. suspensionTravel = (-mywc.transform.InverseTransformPoint(hit.point).y - mywc.radius) / mywc.suspensionDistance; When I was testing the medium wheel, this line would return values between something like 1.06 and -0.06, and I think it should only return 0 -> 1? I've not been able to actually test applying forces myself, but I hope this is promising research.

There are some days I play KSP where this is exactly how I feel

I took a quick glance at the code, and I have some general performance comments: creating lists of wheels and updating that list periodically rather than searching through the whole vessel each time (force update when vessel.Parts.Count() (I don't think this is a real parameter ) changes?), storing the partner RepulsorWheel as a variable (maybe a list if more than one?) in the RepulsorWheel class. This second part would make debugging this much simpler. So instead of float partnerSuspensionTravel; string partnerID; public void doSomethingWithPartner() { RepulsorWheel partner = find(wheelID => wheelID == this.partnerID); partner.suspensionTravel = this.partnerSuspensionTravel; } you get this RepulsorWheel partnerWheel; public void doSomethingWithPartner() { this.partnerWheel.suspensionTravel = someFloat; } It might save some RAM because instead of saving a float for partnerSuspensionTravel for each wheel, it saves a reference to a RepulsorWheel with partner. Or maybe not. I really don't know. A List<RepulsorWheel> with a length of 1 would only save a reference though. Anyway, I found what looks like the area of interest @ ~line 360 in the RepulsorWheels class. [FONT=Consolas][SIZE=2][COLOR=#0000ff][FONT=Consolas][SIZE=2][COLOR=#0000ff][FONT=Consolas][SIZE=2][COLOR=#0000ff]foreach[/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][FONT=Consolas][SIZE=2][FONT=Consolas][SIZE=2] ([/SIZE][/FONT][/SIZE][/FONT][FONT=Consolas][SIZE=2][COLOR=#2b91af][FONT=Consolas][SIZE=2][COLOR=#2b91af][FONT=Consolas][SIZE=2][COLOR=#2b91af]RepulsorWheel[/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][FONT=Consolas][SIZE=2][FONT=Consolas][SIZE=2] st [/SIZE][/FONT][/SIZE][/FONT][FONT=Consolas][SIZE=2][COLOR=#0000ff][FONT=Consolas][SIZE=2][COLOR=#0000ff][FONT=Consolas][SIZE=2][COLOR=#0000ff]in[/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][FONT=Consolas][SIZE=2][COLOR=#0000ff][FONT=Consolas][SIZE=2][COLOR=#0000ff][FONT=Consolas][SIZE=2][COLOR=#0000ff]this[/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][FONT=Consolas][SIZE=2][FONT=Consolas][SIZE=2].vessel.FindPartModulesImplementing<[/SIZE][/FONT][/SIZE][/FONT][FONT=Consolas][SIZE=2][COLOR=#2b91af][FONT=Consolas][SIZE=2][COLOR=#2b91af][FONT=Consolas][SIZE=2][COLOR=#2b91af]RepulsorWheel[/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][FONT=Consolas][SIZE=2][FONT=Consolas][SIZE=2]>())[/SIZE][/FONT][/SIZE][/FONT] [FONT=Consolas][SIZE=2][FONT=Consolas][SIZE=2] { [/SIZE][/FONT] [/SIZE][/FONT][FONT=Consolas][SIZE=2][COLOR=#0000ff][FONT=Consolas][SIZE=2][COLOR=#0000ff][FONT=Consolas][SIZE=2][COLOR=#0000ff]if[/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][FONT=Consolas][SIZE=2][FONT=Consolas][SIZE=2] (st.thisPartID == partnerID) [/SIZE][/FONT][/SIZE][/FONT][FONT=Consolas][SIZE=2][COLOR=#008000][FONT=Consolas][SIZE=2][COLOR=#008000][FONT=Consolas][SIZE=2][COLOR=#008000]//find my paired wheel[/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT] [FONT=Consolas][SIZE=2][FONT=Consolas][SIZE=2] { partnerSuspensionTravel = st.suspensionTravel; [/SIZE][/FONT][/SIZE][/FONT][FONT=Consolas][SIZE=2][COLOR=#008000][FONT=Consolas][SIZE=2][COLOR=#008000][FONT=Consolas][SIZE=2][COLOR=#008000]etc.[/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT] Am I in the right area?

I recall that at some point each part had its own orbital...stuff...calculated but that was removed. An interesting experiment would be to try and use non-craft merging physical connectors between vessels (like a rigid KAS) to see if you could see the effects in game.

It took me a few reads to figure out what you meant and not where my mind went. Although there was probably engineering to do that too. I know that feeling of figuring out something that no one else will even know was a problem It's part of what keeps me modding. And if you want new eyes on the anti-roll I volunteer to take a look.

Just curious as to whether or not your forum join date is indicative of your join date in the community. Because you've really missed out. Let's travel to the world of Feb 2012 and see what we thought was coming then, shall we? "Astronaut Complex : Hire and train kerbonauts Research and Development : Discover and Improve Parts (from a tech tree) Part recovery[3] Runway : to land on or launch from (placeholder implementation added) Spaceplane hangar : A secondary VAB, that allows for horizontal (belly-down) construction Mission Control Room : Create flight plans and take on missions and challenges Tracking Station: Keep track of orbiting objects and ongoing missions Observatory : Discover new celestial bodies to visit " " Asteroids" Oh yeah, no concrete objectives there And while I can't find it easily (because the forum changed platforms and got screwed up and such), I definitively remember thinking when I read the announcement that they were officially working on multiplayer was, "Yay, I thought we'd have to wait much longer before they worked on it". MP was always on the "nice to have, but we're working on it dead last if feasible" list.

the most important mods are invisible. ModuleManager was a Godsend.

I have MM .cfg files in the 0.3.1 version to make the screens work in the KSOs. I don't know if the buttons work because the naming of the RPM buttons is hardcoded at the moment, but I expect to change that in the next version. If you're looking to do more than just write your own .cfg let me know and I'll see what I can do for customization etc.

I'm not sure what you mean by this?

Just an FYI, 0.3.1 will probably drop later tonight. It is intended to provide preliminary support for KSO and RPM 0.17 it's up Note that all of the buttons may not work for KSO and RPM 0.17 yet. Testing revealed that a 7.5° glideslope works well for both the KSO and KSO Super25 in stock aerodynamics if both shuttles are empty.

back in the day (say around .16, .17) one could tell the day a release was to occur because HarvesteR would start answering a bunch of questions and responding to posts in the forums, presumably while waiting for a build to finish. I haven't noticed this to continue though

Unless you're trying to land on the Island runway...more testing makes me think it's a few degrees off. I'll fix it in the next update. I'm planning on making this able to work all in game in a few versions, but for now it can be done manually. Create a new .txt file with a name ending in _rwy.txt . Two examples would be MyRunways_rwy.txt or DunaBaseEast_rwy.txt Move a plane/rover/rocket on the ends of the runways, and use another mod to get the latitude and longitude Enter your runway's information into the file in this format: Runway { ident = My Runway North-East //the name which will show up on the display hdg = 45 //the heading at touchdown body = Duna //name of the body the runway is on altMSL = 176 //this is what your altimeter says when you're landed gsLatitude = -0.096779520816 //the Latitude of the touchdown point, you can get this from many other mods gsLongitude = 285.382598358845 //the Longitude of the touchdown point locLatitude = -0.09677440548751 //the Latitude of the far end of the runway locLongitude = 285.379943637873 //the Longitude of the far end of the runway outerMarkerDist = -1000 //no marker, if positive distance prior to the touchdown point in meters the marker sounds middleMarkerDist = -1000 //no marker innerMarkerDist = -1000 //no marker } Move your *_rwy.txt file to GameData/KerbalScienceFoundation/NavInstruments/Runways/ You're done! Switching vehicles should load the runway into the database. Yes, I'm just using a background handler for the display. The buttons on the MFD are hard coded at the moment though.

Hmm, speculating on things in .24? I can play too Maybe we'll see sample collection. And by maybe I mean I think it's not unlikely. And a right click interface to send those samples to various containers located around our vessels I think it'd be nice to have moving parts finally added, but that would probably not be for a while.

public beta v0.3.0 released! check it out at http://forum.kerbalspaceprogram.com/threads/85353-0-23-5-NavUtilities-ft-HSI-Instrument-Landing-System-v0-3-0-%2AJuly-9-2014%2A

NavUtilities for KSP Featuring Instrument Landing System and Horizontal Situation Indicator Standalone and for Raster Prop Monitor NOTE: Standalone version is a popup window, but the information displayed is the same Adds a horizontal situation indicator with integrated ILS functionality to a popup window or your RPM cockpit. The standalone version can be accessed (along with the options page and custom runway page, for controlling the current runway and GUI scale) via the App Launcher. ILS style localizer, glideslope indicator, distance measuring equipment, and backcourse indicator. Outer, Middle, and Inner Markers are fully functional, with the audio cue volume controlled by your Voices volume setting (WARNING: Middle and Inner marker audio cues are high pitch and, depending on your settings, may be loud). Currently, volume settings will not update when in flight, but going to the space center should update them. The window GUI auto hides when you enter IVA. Current runway and glideslope selection remain synced between the standalone GUI and the version for RPM. Included selectable runways: KSC 09 KSC 27 Island 09 Island 27 VAB Helipad East VAB Helipad West Administration Helipad Included glideslopes range from default 3° to 25° More runways and glideslopes can be added via config file or in game. Helpful images of 0.4.0+ features Please note that if you are using KSI MFD, you can also select the HSI by cycling between this and the landing screen. Thanks to Tahvohck! DOWNLOAD the newest release 0.6.1 (update for KSP 1.1) from SpaceDock Copy the contents of GameData folder into your main KSP/GameData/ folder. The other files are not required for the plugin to function. Note for users upgrading to 0.4.0+: you should remove the folder RPMHSI which was used in prior versions. Note for users upgrading to 0.5 RC3+: you should perform a fresh install. Be sure to save your custom runways file. Raster Prop Monitor works standalone, however for RPM integration you need: Module Manager 2.2.0 by sarbian or newer RasterPropMonitor v0.18 by Mihara or newer Included support for: Kerbal Space Industries MFD 1.2 by Hyomoto Kerbin Shuttle Orbiter System by Helldiver & Nazari1382 ===v0.6.1=== April 20, 2016 *Updated for 1.1 *Added variable handler support for RPM (see Wiki on Github for documentation) *Marker Beacon audio volume was moved from Voices to UI *To bring up the settings window, Mod+Click (Alt+Click in Windows, Option+Click in OSX) the AppBar icon, no longer right-click *NavUtilities windows should now auto hide and restore when the player presses F2 *New Feature: HSI now works with stock waypoints (from contracts) and Waypoint Manager (special big thanks to Ser!) ===Some intermediate version...=== *Added an internal prop module for analog HSIs *Analog internal prop model included; model and textures by nli2work *Window positions should be persistant *Reorganized and renamed files to help prevent a possible KSP loading bug *Added a shortID field for runways *Reintroduced optional ToolBar support, to enable you need to edit the line "useBlizzy78ToolBar = " to True in settings.cfg (may still be buggy) *FIXED: marker audio now plays at the intended volume *FIXED: high latitude fix from Virindi is now included ===v0.5.1 RC 1 Changes=== June 3, 2015 *Updated for 1.0.2 *Added demo version of Primary Flight Display (only for RPM for now), including: -Easy-Read Attitude Indicator -Radar Altimeter (Automatically functions below 750m) -Speed -Altitude -Vertical Speed (meters/minute) -Throttle setting indicator ===v0.4.3 Chang[FONT=arial]es=== Oct 12, 2014 [COLOR=#000000]*Added the Administration building helipad to the included runways. It is an example of a "custom runway". [/COLOR][COLOR=#000000]*Compiled against KSP .25 [/COLOR][COLOR=#000000]*Removed requirement to use Blizzy78's ToolBar mod, now supports stock App Launcher [/COLOR][COLOR=#000000]~Current Users of the ToolBar [/COLOR][I]may[/I][COLOR=#000000] still be able to use it if they overwrite the existing NavUtilities install (untested) [/COLOR][COLOR=#000000]~NavUtilLibGUI.dll is also now no longer needed for upgrading users (it interfaced with the ToolBar) [/COLOR][COLOR=#000000]~Left clicking the App icon will start the HSI, right clicking the App icon will start the settings window[/COLOR][/FONT][COLOR=#000000][FONT=Noto Sans] [/FONT][/COLOR] ===v0.4.1 Changes=== *GS now only works within 25° of the centerline *Localizer now enters a fine mode when close to the runway ===v0.4.0 Changes=== *RPM keys are now softcoded to prop.cfg file definitions. This should allow much more flexible adaptation of the HSI to various RPM props. *RPM now features same text overlay as standalone, including runway elevation. *Included MM configs updated to reflect this *Removed RPMHSI folder, moved RPMHSI.dll to main folder. *Complied for 0.24 -New Features: *Custom runways from in game. Position your vessel at the desired touch-down point and either use auto heading and elevation or use your own (auto based on current vessel's orientation and elevation). Custom runways saved to separate file. Custom runways can be deleted in game. The custom runway GUI can be accessed from the Toolbar. *Hotspots in standalone (popup) HSI allow the user to change runway, glideslope, and close the window. Your mouse is in the correct area when ~an arrow appears (→)for runway & glideslope. Left click to go to next item, right click or MMB click to move back ~the text "Close Window" appears for closing the window ===Changelog v0.3.1 July 9, 2014=== -Added missing MM cfg for Hyomoto's RPM -Added MM cfg for KSO + KSO Super 25 -Added MM cfg for RPM 0.17 Basic screen KSO and RPM 0.17 not fully supported yet. RPM buttons may not change the runway or glideslope. You can use the settings window (from the App Launcher) to change them, however. Software License: © 2014-2016. All rights reserved. Permission is granted to any current, former, or future members of the KSP community (e.g.; non-professional modification makers and forum members) to update, maintain, use portions of the code, and/or release derivatives provided that 1) the new work is solely to be used as a modification for Kerbal Space Program (and future versions thereof) and 2) the new work is freely distributed and may not be sold or exchanged. Artwork License: Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License Source hosted at GitHub Alt Download at GitHub Development Thread

As long as it's not being moved while connected, it should be fine. The stock 1.25m inline docking port extends outwards, and there are a few mods with similar functionality. A more hackish way would be to have two docking modules with different nodes, and just toggle them with the animation? Unless of course I'm interpreting this incorrectly.