kujuman

I can play this game. Alright, well I think we can default to the standard as being a preponderance of evidence, since this isn't a criminal trial or anything, purely a civil matter. I reject your claim that I and my co-defendants bear the burden of proof, since this is a civil matter the preponderance can come from either side. Exhibit A: The video in question, time 2:30-2:33. Begin Transcript Maxmaps: "The game now defaults to fifty percent thrust on launch." End of Transcript I hereby rest my defense and further petition the judge to dismiss this case with prejudice.

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.

There's basically no chance this behavior would be in .24. 1) Even now, throttle setting per vessel is saved in the save file, so it would be restoring the save state. 2) If you're within physics range (you are docking...) then the vessel isn't reloaded upon switch, so it's not going to see any throttle applied. 3) There is testing that happens.

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.

If it's a big enough deal to add to an update and feature in the preview video, it's big enough to complain and debate about

That's why I don't think 100% throttle is the perfect behavior either. I don't consider 0% a "medium" because it doesn't give us anything, it's just sticking with less-than-perfect-but-better-than-many-other-alternatives. But that's just semantics Maybe have a setting (oh yes menu creep time) for "Start at Launchpad at Full Throttle" (true/false)? That plus a Full Throttle key?

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.

EverySpaceProgramThatHasEverExistedForEverAndAlways? Pork Barrel Rockets: We'll save your bacon, not much else Mass Fractions Sports Utility Vessels: Allowing soccer moms to pick up the team...from Gilly Asparagus Launchers: Drop'n stages like its the wild wild west

Do we actually know that? From Harv's dev blag #2 So...yeah, at worst we don't know, and they'll be in the next version. At best, we get them in .24 because procedural contracts were intended to be in .24 even before ca$h-mon€y (which is what I will refer to "Funds" as) became a thing. At super best we get completely new missions like sample return. Laying the groundwork is not "half-baked", it's intelligent. In the end, I'm waiting for the FAQ It's good that they're thinking about default throttle setting. I don't know if I want 100% to be the default. Maybe ideal behavior (for me) would be during ship load: If(LaunchAtPad == true) set throttle full or so TWR is no more than 2G. else //is spaceplane set throttle some amount (don't really care, maybe 0) if (vesselIsRover) throttle = 0 I do a bunch of launch-but-not-really-launches, so remembering to throttle down so I can quicksave would be annoying to me. I can imagine a happy medium is hard to find. Although we can throttle down instantly...maybe we just really need a full throttle hotkey?

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.

I noticed this too, and I agree totally. Perhaps a post launch total would be nice, or "This launch is 24% of total funds? But too cumbersome perhaps. My understanding the past year+ on this point was that new planets are waiting for 1) a discovery mechanic (if that's still on the roadmap) 2) performance improvements

I've seen this attitude before on the forum and elsewhere, and I just don't understand it. 1) MC was designed from the start to give us a taste of what career mode would be like. MC is a mod which gave players a preview of career mode before it was developed, not a game feature Squad copied because they had nothing else to do. 2) Why is the assumption that contracts will be "half-baked"? We honestly have no knowledge one way or the other, but I would lean on Squad doing a fuller job (even if it's just making modding it simpler) than MCE has been able to do, as much development as it has gotten. 3) April, May, June, July...yup, six months The real problem is that we're spoiled by the hundreds of actively maintained mods and hundreds of thousands of hours modders have probably put into the game. "We have mods for Missions, Squad should do something else." Um, like what? Spaceplane parts? New planets? Resource detection and collection? Better aerodynamics? Heating effects on reentry? Life support? Base modules? Parts parts and moar parts? Navigation utilities? Warp drives? New launch sites, both on Kerbin and off? Performance enhancements? Stronger joints? MFDs? Shuttle engine controllers? New effects? Ropes and winches? Yeah, there are mods for all of those, so Squad should just sit back and not work on them at all. And considering the growth of the modding community, Squad is basically unable to compete at something they should have a monopoly on. Rovers? Docking? Electricity? You may not know this, but these all existed in mods before they became stock. Heck, two separate docking mods came out in .17 which were buggy as hell but were proof of concept enough for Harv to spend an afternoon trying out his own version during the .18 update cycle. That's why we got docking when we did and not a few versions later. It's really unfortunate that there are so many players who never got to experience the game when it was a promise of things to come instead of the final development of those things, and that they don't really understand just how much the game is still in development because, for the most part, it feels very polished. No longer are the two missions that exist 1) getting to the Mun and 2) rescuing the pod that broke off your Mun lander (not the kerbals, the pod) using landing gear to sorta claw it in place. If contracts are to be even half as moddable as PartModules are, we're really in for a treat with the things the community comes up with.

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.