cyberKerb

Can someone help out and list the (SMA) Semi major axis of Cercani? I figure the data would be in the Kopernicus files but I'm unable to download the mod at work at present and wanted to do some calculations for a mission while I'm waiting for some code to compile.

Heh - figured it'd be something like that. In my research I saw the "egg-bot", but also ran across it's clone called the "sphere-bot" doing a good job on ping pong balls. It did run through my head that given a secure enough mount you'd get most of the surface area, but I was looking for cheap and accurate "enough". I don't think you'll have too many issues getting the sharpy all the way to the shaft holes at either end. The radius of those holes should be plenty to get a good grip and not have to just rely on the flat foam friction hold that the egg-bot uses. Good luck with the design and hope to so see your progress pictures! Separately, I might actually see if I can try the sphere-bot thing too - I've got a spare UNO that I can pull from (another) stalled project), but I'll need to grab a couple of small NEMA 8 steppers (about $15ea), a pair of drivers and a 1:5or6 gear shaft reduction to get somewhere in to 1200 step range for accuracy. I've got a stack of the 9gm servos from my remote control planes laying about and that most of what I'll need I think. All that's left is a solid mount and maybe getting an optical encoder just so I know I can get a project working with it (wouldn't strictly need it though)

Just as a response for how I've so far planned to print of the ball, I was thinking a subassembly like the eggbot, but all manual. With a few gear reduction ratios for the ball to rotate very slowly, I'll be able to get a pretty accurate positioning on when the paint pen would lift or go down. The pen arm would be on the axis as the rotation of the ball, but I'd have an height adjustable set of 8 "bumps" rotation axis where the ball is connected and sitting under the pen arm. This would set the negative space when I want the pen lifted as the ball is rotated around it's axis. (It's at this point I wish I could draw a model of the idea to better communicate what I mean *sigh*) Best I can describe is to take a big dinner plate and stick a small saucer on that plate at the edge so large place circle has a saucer sized "bump" protruding over the edge. A little bit of trig maths will get the the angles needed for the paint stick to be at a correct angle to the balls surface for the higher latitude lines. The length of each line would just be a function of which latitude I'm at. Thankfully in KSP all the longitude line are mostly solid with 8 gaps for the numbers. And then there's the hard bit. At the moment, I'd have an accurate ball with all the lines on it. (At least for home use - I'll happily recreate it accurately if I have to personally take it to space myself ) Best I could come up with to do it cheaply was to use dry transfers. I've used them before, but the shear number of them is the issue I'm facing with trying to place them all - 25 for latitudes and most of those 3 digits and then 4x32 for the logtitude number and most of those are double digits. So rough guess would be 381 individual numbers. Still might go with your route with CNC - as I'm getting stepper motors anyway, but I might wait the standard 3 years before I pull the trigger on that Heh! No prob on the parts - you gets your working first! I'm sure you'll have plenty of sim-pitter asking for help in the future if you set precedent here. At any rate, I'll guess the CNC first job might be making the frame/arm/clamps for a spherebot so you can get a good print on your spray-paint primed spheres.

I guess it would depend on why you're doing the Navball project in the first place really. If the goal is to get the game numbers/dials off the screen and into physical readouts, I'd do the airplane altitude indicator only because it would match the game and you'd constantly flipping between numbers. If the goal is to be able to NOT look at the screen GUI and know where you are or if you a more 'realism inclined', then you'd probably want to go for the 8-Ball approach, no? That way you'd be interpreting the numbers as intended for the situation you are in. Having said all that - I'm not sure what help you need when the solution is obvious, wouldn't it look cooler if you had both to represent Surface mode & Orbit mode?

Hahah! Glad to know even you had issues with that design element. Using the original picture you posted way back when, I understood the design element for the internal motors, I struggled to understand how the ball mounts while allowing a slipring function somewhere (Apollo design aside). You probably know the loop in logic - I need a pivot point at the other side of the stepper, but it can't move relative to the arm that holds it, but it can't move!, but I still need a pivot point!, but...but...but... etc... Trying to work that out is what drove me to google like crazy for slipring variations with/without flanges and other ways that combine a pivot point and a slipring. All that and I ended up coming back full circle when one of my searches found the 2017 updated thread. *sigh* All that for trying to work out how to made the slipring act as both a mounting point for the bottom external pivot shaft (ie that doesn't move with the cage, but does move relative to the ball) as well as a... well... slipring. Congrats on your efforts to nut out that problem. Based on those images, I'm guessing you're going to have some sort of counterweight on the bottom half of the sphere to even up the balance when you rotate the (unseen) cage axis? I already spotted the other slipring in your previous posts that is likely to be the one you mount on the cage to the base/computer connection. It looks like to took the 12wire option - how mony of those did you end up using? 4 per stepper? Any internal lighting planned? Lastly, just wanted to marvel at your technical drawings. I've tried a few tutorials with stetchup and still haven't gotten my head around doing 3d drawings. Just need more time and practice I thinks.

Noice - The bit I'm keen to see is how you're going to mount the slipring and still have a pivot shaft to mount the ball to that axis. Were you mounting the ball with only 1 attachment point with the stepper and slipring on the same side, or were you going to use the stepper shaft on one side with the slipring on the other side of the ball as to pivot points? In my own research I found a hollow slipring, but it was doing my head in which bit rotates and what is fixed to which part. Love your project and wishing you all the encouragement I can send

nice - I like the idea of using the dual shaft stepper to centralize the weight in the ball. Would love to see pictures on the setup as you've currently got the internals whenever you get around to it as it'd be interesting to see how much your planned layout change from the original pic from a few years back.

Ok @Booots - I did a quick test - at (5,000Mm) (around Moho solar orbit) - I had a small 13tonne satellite with an LB100 needing only 2117EC to initiate. After that it uses 4.23 EC/s I moved that dinky little satellite into it's gravity-well limit and the EC to start up was about 5000EC and 10EC/s to function. I made a copy of the same sat and stuck it around Sarnus (from OPM mod) which had the same EC start up and usage costs as I had it close to the Gravity well limit. The final piece was to see what the cost of a jump from well inside Moho solar orbit to Sarnus (23,400km) would cost - total Karborundum cost: 59.2. I repeated the same test to Cercani (Other Worlds Mod) with the LB100 at 2,258Mm orbit (close to Troni solar orbit) Beacon startup cost = 1784EC usage was 3.57EC/s Jump from Sun orbit to Cercani (2,258,000km) cost 96.14 Karborundum - but I was shooting off at escape velocities due to no velocity matching. Note: None of the Beacon enhancements were active for any of the above calculations. For a final test, I did the last jump from sun to Cercani again with all Enhancements active: Grav-well limit was 2,810Mm startup was 6,424EC Usage was 85EC/s jump was 112 Karborundum - and that jump match velocities with the destination beacon. All up - all costs in EC and Karborundum seemed quite reasonable to me, but that's just my fast and loose testing. If you want, I can test something specific if you like. What have to got that needs almost half a million EC to start? Is there an d-class asteroid attached to that ship? To be honest, I was expecting the Karborundum Jump cost would be a bit higher for the much longer Cercani jump and not just double the cost to Sarnus. I'll have to do a proper check with something more likely is a career save and use a 200 tonne ship and see what it would cost to jump that the same distances. 13 tonne tiny Satellite from Sun Orbit (5,000Mm) to: Sarnus (23,400km) - 59.2 Karborundum Cercani (2,258,000km) - 96.14 Karborundum Just thinking mod-ability - a suggested change to the mod would be to have the ability to change Karborundum jump cost calculations via a config file or setting page? Somehow be able to cusotm the jump cost calc formula to have more bias on weight or distance or (heh) adding a funds fee - whatever combination that goes into those calcs that someone might want to tweak. Follow up - any more thoughts on the gameplay elements of the techboxes and trying to get around not always using ALL of them the moment they are unlocked? Random thought - maybe have the option to make the techboxes into part "upgrades" that are available via contracts and have to be serviced in situ via external vessel. That would mean the first few jumps would be hairy and unmanned having to cope with the lack of velocity matching. EDIT: OK - thought about the above idea a bit more and on second review it's not too bad. The proposed option would be so a Beacon could only be upgraded from a right-click context menu button that can only be seen when accessed from a ship that is not part of the Beacon. eg (*Install MGU*) To avoid the simple hack (of the above idea) by decoupling an existing ship that was launched with the beacon; the upgrade button would only be available when a contract drops for the upgrade that also has a contract requirement parameter that the ship doing the upgrade is newly launched. All the above is just an idea that might be an optional how to make the of ESLD techbox functionality engaging, rather than slapping all of boxes on every beacon launch. With the techtree able to be unlocked fairly quickly, you'd have all the techboxes in no time, so why launch a beacon without any of them? The upside would be that you've be able to utilize contract parameters to govern when / how a beacon got upgraded. Hey, you would even go the Kerbal Academy route where contracts are available all the time, but a player has to spend funds to take the contract. It would prompt both the beacon use as well as upgrade beacon functionality in an incremental / stepped fashion as I think might of been the original intention of the mod. Having it as an option configurable setting, like what I've seen other mod makers do via the game difficulty setting (eg, DMagic mods), would still give those people that want to play with the parts their way available and not be forced to use the mod with all the good toys locked behind the proposed contract "pay-wall".

Would this Mod help? I've not used it much so far. I'm still early in restarting my career again so haven't got into station construction. That 30% reduction in science hurts more than I was expecting.

Awwwww... an here I was hoping to have some busy skies while I build a base. Thanks for the info though @Zhetaan - regardless of the disappointment, it's probably better to know this upfront and learn from those who have gone before me. Any idea on what the deletion altitudes would be for the bodies mentioned? Are we talking hundreds or thousands of meters? I'd hazard a guess at a thousand of so, but I guess some trial and error is in order to find out is no one knows the details.

Found the GIF as well as some other reddit posts of the subject: - Oh I could watch this gif all day AND laugh at it in amazement every damn time.

Ahhh! Thanks for the expanded info. I found where I was getting the maths wrong - I was taking the GM and multiplying it by the mass of the body. (I was thinking G*M) No wonder my numbers were showing up huge. Thanks for the correction As for the idea, it's definatly not my idea as I remember someone here posting an awesome gif (here or reddit can't remember) where they perfectly timed a Kerbal on Minmus getting shot forward, to when a craft was speeding by REALLY quickly and ended up matching speeds in a few seconds while flying a few mtrs from the ground. I figured this might be an interest way to recreate something like that. If you know of the gif - please post a link as I've forgetton where it was. I think the title was something like - "oh, hai"

Thanks again - quick question, what numbers were you using to get μ for Minmus? Ah - nevermind - found a shortcut - this wiki page here gives the semimajor axis and I can get the rest of the formula from the body wiki page easy enough. Ok - thanks for that I've now got all I need to plan a base set up... I'm wanting to have the 'satellites' buzz through a repair facility at orbital speeds Only catch is I can only do it on these locations. Everything else is excluded due to either atmospheric drag or SOI limitations: Ap Pe Gilly 84,270 10 Minmus 715,870 10 Dres 1,464,470 10 Eeloo 1,367,370 10 Should be a fun challenge to set these up while taking into account the terrain before and after the Pe point

Wow! - that was both quick and amazingly confusing (just to me as I'm not a math guy) I'm still trying to search the wiki to find some of the parameters you've mentioned for the above formulas. I also got lost in wondering if some of the numbers from real world (eg Gravity 9.8m/s/s2 etc,,,) still translated fine into this calculations Maybe I should refactor the question.. . Given a pe of 10m above the Minmus flats (which I'm guessing would be 0m alt or should I be calculating this from the center of Minmus and working out what the sea level "altitude" is relative to the middle of Minmus?), where would the Ap be so the same point was flown by each orbit. (ie Geosynchronous - albeit highly eccentric) EDIT: Ok - tell me if I've got close - here's my workings: Minmus Wiki says a = orbit period is 1077311 seconds r = Radius is 60,000 2a - 2r - 10meter Periapsis = 2,154,622 - 120,000 - 10 Apoapsis = 2,034,612 Mimus SOI is 2,200k - so this would work I think.. (how'd I do?) EDIT2: Not good - I reread the maths and 'a' isn't orbital period - your post said a = Semi major axis and wiki says that's 47,000k Redid the same equasion and ended up with 93,879k ap which would be WELL outside the SOI - so I'm guessing I'm SOL

Just wondering if any maths / rocket surgery people out there that might be able to point me in the right direction for formula to work out the following for an airless body in KSP. The question I'm trying to work out is for the bodies in the game that allow a Synchronous orbit, and given the limiting factor of SOI of the body, how close could I get to the surface with a vessel using an Eccentric Geosynchronous orbit? ie something like a Molniya orbit that had the same sidereal duration as the body it was orbiting.

Does this post help?

I'll give it a look this weekend

I saw an example post in Science [X] thread for getting it to ignore certain experiments But I saw a follow up comment that might suggest it doesn't work. I've not tested it, but at least it gives you a point to start from *shrug*

Not sure if you'd be willing to try your test again with Port Roll (ie "roll force") at 2 or 3 before you try docking? (you have it at 0 in both pictures) I'd be interested in see if "option 3" that I mentioned in the below post might be what you're after? Just a note that post is only based on my own experience and testing with this mod and it seems to be repeatable from my side with no issues. However, unlike you I don't use the "Compress Part (Rotate)" as I've also found it's frequently kills stations - but not always - and of course it sometimes works too. Now, I find I never have to worry about rotating parts as I get the angle I want anyway.

Thanks for your efforts on this mod Galileo I can't wait for Kopernicus to be fixed, as playing with this mod without terrain scatter feels like I'm missing 90% of the stress I normally have while playing this game with SVT installed. I've gotten so used to having to weave around terrain scatter that I find the calm of roving in straight lines... ummm.. disconcerting.... In all seriousness though - no rush and no pressure meant from this post. Just figured I'd let you know I'm still enjoying the work you have done and I'm having an immense amount of fun!

Hah - Awesome work @NeoMorph! I was looking at your old thread and ended up doing my own investigations and stumbled over the 12wire adafruit SlipRing which I figured would be good for getting the power / signal inside the ball. (might be what you pictured a few posts back) Anywhoooo, while looking at other stuff for ideas to replicate your efforts, I found the new 2017 thread and I'm quite excited to see that work continues. Your research and effort have been fantastic and I've gotta applaud the effort. If you do release plans / details in teh future, I'm pretty keen to replicate your efforts (maybe not so much the BoM One question: I saw you originally were using NEMA 17 steppers, did you end up staying with that size or change later on? I was looking at the small version and wondering if the 20mmx30mm steppers like those seen here might not have the torque needed for the project?

Ability - 12) Bill, Valentina, Tedus, Jebediah, Nimzo, Dilsby, Melbe, Clauselle, Sarge, Kernel, Lisa, Bob (1 Cuteness - 12) Clauselle, Sarge, Melbe, Tedus, Lisa, Valentina, Nimzo, Bill, Jebediah, Bob, Kenlie, Dilsby (1

Hmmm.. I've only just discovered this and it looks awesome for the same reasons you created it. I only just started using OPM too. I'm actually thinking about abandoning my career game to restart with this pack. I'm currently playing with the following contract packs and they seem to mostly work fine. Anomaly Surveyor (Nightingale) Bases and Stations Continued (LemonSkin) SCANSat (DBT85) Unmanned Contracts (Spacetux) Rover Contracts (Spacetux) Grand Tours (Spacetux) Field Research (Nightingale) Interplanetary Mountaineer (Syntax) Would you have any advice on which packs would be good to keep active (if any) while still not having too much overlap with the missions in the Career Evolution pack? I figure the following four might be good to keep as it "looks" like they aren't covered. Anomaly Surveyor (Nightingale) Grand Tours (Spacetux) Field Research (Nightingale) Interplanetary Mountaineer (Syntax)

Great mod! Love it and congrats on the work done with the release. Just an idea for possible expansion... (Highly likely outside of scope though) Instead of just White or Orange suits - would it be possible to have an option to integrate with the TextureReplacerReplaced mod so that you can set what suit texture specific levels get? Maybe even multiple promotion levels?

I figure this is from the AnomalySurveyor.dll throwing an error on startup and not loading [ERR 18:43:31.723] ADDON BINDER: Cannot resolve assembly: KSPUtil, Culture=neutral, PublicKeyToken=null [ERR 18:43:31.725] ADDON BINDER: Cannot resolve assembly: KSPUtil, Culture=neutral, PublicKeyToken=null [ERR 18:43:31.728] AssemblyLoader: Exception loading 'AnomalySurveyor': System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded. at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0 at AssemblyLoader.LoadAssemblies () [0x00000] in <filename unknown>:0 Additional information about this exception: System.TypeLoadException: Could not load type 'AnomalySurveyor.MonolithParameter' from assembly 'AnomalySurveyor, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. System.TypeLoadException: Could not load type 'AnomalySurveyor.MonolithFactory' from assembly 'AnomalySurveyor, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. System.TypeLoadException: Could not load type 'AnomalySurveyor.MonolithParameter+VelocityHandler' from assembly 'AnomalySurveyor, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. System.TypeLoadException: Could not load type '<>c' from assembly 'AnomalySurveyor, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. System.TypeLoadException: Could not load type '<>c__DisplayClass35_0' from assembly 'AnomalySurveyor, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. System.TypeLoadException: Could not load type '<>c__DisplayClass35_1' from assembly 'AnomalySurveyor, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. I had little to do this Saturday night so I figured I'd grab a fork from github to see if the AnomalySurveyor.dll would compile. Not sure if this is right, but after I removed the KSPUtils references that was no longer needed (rolled up into CSharp reference I think), I was getting errors for the 6 lines regarding FlightCamera.fetch.setTarget My C# isn't great, so I have not idea what to change so it will still work. I only figured I might be able to help, but I got out of my depth quickly so I'll be patient and wait for Nightingale to get around to it and no rush. Thanks for all your work on Contract Configurator and the separate contract packs! I still daydream of "one day" making my own pack that involves adding assets via Kerbal Konstructs to hunt down and having a somewhat story based progression that probably wouldn't even get close to what this pack does. The amount of work you've done is awesome and very much appreciated and enjoyed thoroughly.