Jump to content

Search the Community

Showing results for tags 'kerbnet'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • General
    • Announcements
    • Welcome Aboard
  • Kerbal Space Program 2
    • KSP2 Dev Updates
    • KSP2 Discussion
    • KSP2 Suggestions and Development Discussion
    • Challenges & Mission Ideas
    • The KSP2 Spacecraft Exchange
    • Mission Reports
    • KSP2 Prelaunch Archive
  • Kerbal Space Program 2 Gameplay & Technical Support
    • KSP2 Gameplay Questions and Tutorials
    • KSP2 Technical Support (PC, unmodded installs)
    • KSP2 Technical Support (PC, modded installs)
  • Kerbal Space Program 2 Mods
    • KSP2 Mod Discussions
    • KSP2 Mod Releases
    • KSP2 Mod Development
  • Kerbal Space Program 1
    • KSP1 The Daily Kerbal
    • KSP1 Discussion
    • KSP1 Suggestions & Development Discussion
    • KSP1 Challenges & Mission ideas
    • KSP1 The Spacecraft Exchange
    • KSP1 Mission Reports
    • KSP1 Gameplay and Technical Support
    • KSP1 Mods
    • KSP1 Expansions
  • Community
    • Science & Spaceflight
    • Kerbal Network
    • The Lounge
    • KSP Fan Works
  • International
    • International
  • KerbalEDU
    • KerbalEDU
    • KerbalEDU Website

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start



Website URL



About me



Found 19 results

  1. KSP Visual Calculator Online tool that assists in playing Kerbal Space Program I have released a new tool for Kerbal Space Program to help players visualize and plan missions in-game. This calculates the delta-v requirements for a mission, and also CommNet constellations. For delta-v calculations, players can select multiple planets/moons as checkpoints and have the dv requirements automatically calculated for them. For CommNet constellations, players can add spacecraft with specific configurations of antennae, and then drag the spacecraft and planets around to mimic an in-game situation they would like to analyze. All spacecraft are linked with colored lines when a connection is established between them, showing their signal strength. Online tool: https://ksp-visual-calculator.blaarkies.com/ Checkout the github repo issues tracker Some details about the usage: Delta-v requirements are measured as best case scenarios. If you are not an Ace pilot yet, use the "margin of error" preferences control to add some safety to the final results. The trip details are a good way to learn optimal orbital mechanics When using the "Efficient" route mode in preferences, you might see extra visits in your journey because in total they will require less delta-v On the Delta-v Planner page, the location of planets on screen has no effect on the calculations. Feel free to move them around to better visualize your mission Antenna calculations have been tested against 30 in-game test scenarios with full accuracy Orbits in the app are not elliptical, and not in 3 dimensions Most orbits in-game are nearly circular anyway; inaccuracies are minor For CommNets, it does not account for any inclination in orbits. Most in-game orbits are flat enough (relative to each other) so that straight line distances do not differ too much due to this, but in certain situations like Pol <-> Bob this can be more obvious
  2. I think initially having limited information about celestial bodies and having to orbit and scan them first is a really good idea from ScanSat: generating 2D maps and high resolution 3D overlays shown directly on the celestial body. Telescopes should also help with this as the game progresses. Is there any use for KerbNet as it was in KSP1? I found hunting for anomalies kind of interactive / interesting and annoying at the same time. Maybe automating the process like ScanSat does and then analyzing maps / overlays would be better. Also I think a tool like the Trajectories mod should be in the game as a high tech part to unlock. And I have not seen anything about spiraling orbits displayed in map view (as KSP2 should display orbits that change while under constant acceleration, and maneuver nodes should care about where the acceleration phase starts and where it ends). PS: Are we going to have a system similar to Research Bodies where we progressively discover celestial bodies (and improve the way they look in map view) with telescopes? Any info about these topics?
  3. This is my first serious foray into using KerbNet, and I'm not sure if this is a bug or if I'm just not setting up or doing something correctly (probably the later). I have a probe in orbit around the Mun; it has M700 and M4435 scanners functioning, with both Rovemate and MK2 Drone probe cores; but KerbNet display appears to only show Ore mode. When I click the 'Cycle Display Mode' button in the upper left corner, nothing seems to happen - I see no noticeable change in the display, as illustrated in the Kerbnet Wiki. - just Ore mode. Likewise in the Tracking Station, regardless of the Cutoff % setting, the Color and Style buttons change when I click them, but I see no apparent change in the Mun display. I see the few random waypoints I set, in different colors, but they don't change either (not sure if they're supposed to or not). And based on my reading I thought I'd see a couple of anomalies on the Mun, but so far nothing, just a few Unknowns out beyond Minmus.
  4. On my 'Survey and Scanning' probes I usually include a Rovemate, as it has 100% anomaly detection, as well as a 'normal' probe core for control and Narrow Band and/or Orbital Scanners. On many occasions it would be useful for me to have independent Kerbnet windows open for two or more cores and/or scanners (on the same vessel) at a time. As it is it will only switch the window contents to show whichever I select. Not a game breaker, but a very useful QoL tweak.
  5. So currently in KSP I've been flying an airship around Kerbin, with one of my objectives being to seek out anomalies. For the purpose of pinpointing those anomalies, I launched this satellite to polar orbit: My problem is, despite playing KSP for almost two years now, I really have no idea how Kerbnet works, or how I can use it to my advantage. This is probably evident in my satellite design, because I added that survey scanner even though I didn't intend to scan for ore at all. I know the approximate location of the anomaly I want to visit, but I've gathered that in order to pinpoint it and add a waypoint I need to use Kerbnet. So, some help please?
  6. I was browsing the interwebs a while ago and found this interesting communications network design that works around the annoying orbital drift bug (is it a bug? I'm not sure) by utilising four comsats in eccentric orbits instead of the normal synchronous orbits. I couldn't find where I saw the original diagram, so I knocked this up in five minutes on Paint - I hope it gets the point across. (Note that this is looking at the planet from directly above the north or south poles). There's a few things I was wondering about this setup: 1. What is the probability that you are in contact with the space centre? 2. How likely is it that you are in contact if the orbits are more eccentric or less eccentric? 3. What are the advantages and disadvantages of this setup?
  7. Ok so as you know from the title my kerbnet dose not seem to work correctly. Every time I pres kerbnet access I get a screen saying it’s offline. I have 100% signal strength and direct connection to the space center. As far as parts that would influence this I have probodobodyne for a probe body (that took to long to spell) and two narrow band scanners the only mod I have running on this is TweakScale which can change the size of the parts but I don’t think that would influence it thanks for even reading this
  8. Hi guys, I've been setting up evenly spaced triangle orbit satellites at 120 degrees for my network and can get them at exactly at 120 from each other without any deviation. But every six months-year the phase angles either rise or drop by .01 degrees and decades later my little triangles are all messed up. I know it's because my apoapsis and periapsis are just barely not matching but damn it's hard to get the apoapsis and periapsis that precise. Has anybody else had this issue?
  9. I have a problem. Recently, I launched a relay into stable polar orbit around Kerbin, and even though I'm below 600,000 km AND I have the M700 Survey Scanner, I still can't seem to cycle the Kerbnet view mode to resource mode. How can I access resource mode in Kerbnet? I'll post some screenshots below of what I'm trying to get across. This is the mode I want to see: Resource mode. This is a picture of my satellite: This is my satellite. This is my connection to Kerbin and my altitude: This is some information.
  10. Hi, I am currently having an issue with the KerbNet feature as of the 1.3 update. Prior to the update, I could use KerbNet with any probe body with no problem. Now, all I get is this when I open up the access window: The only mods I have installed are Kerbal Alarm Clock and a planet pack, but KerbNet worked fine with these same mods in 1.2.2. Does anyone know what I could do to fix this? Thanks in advance! edit: solved, kopernicus is currently having some issues with scanners, just gonna have to deal with it.
  11. Hello again fellow Kerbals. I have a rover that I have been testing around the KSC and I have been trying to learn how to use the Kernet aboard my Rovemate. I have located a "?" mark on the Kerbnet that when I am on top of it just happens to sit right in the middle of my crawlerway. My questions are: 1. How do I interpret this map? 2. How do I figure out what the question mark is? 3. What can I do with this info? Here is a picture:
  12. Hello All. I have seen threads mentioning the Kerbnet and how it detects anomalies. I have a rover with a rovermate probe body and I have seen where this should allow me to use the Kerbnet. Is this a mod? If not how do I access it?
  13. Step 1: put a satellite in Kerb-o-synchronous (geostationary/geosynchronous) equatorial orbit. Step 2: once in desired orbit, push 'V' until in "chase camera". Step 3: play your favorite space themed ambience music. Step 4: push F2. Step 5: profit. Working on putting a little video together to share here shortly. It's times like these that remind me how much I appreciate this game and its developers. 400+ hours deep and it's the little things.
  14. Hello, So far the farthest I've ever been in KSP is a Mun landing, Before going to Minmus I plan on starting some sort of network around Kerbin, But I don't know how to start one. I to lonely
  15. So, I had dabbled in SCANsat prior to 1.2, but now that Kerbnet is here I'm quite content with the stock solution. I'm presently living happily with Kerbin and Mun each having a triplet of relay satellites. Having over a dozen probes other spacecraft with probe cores, sometimes anomalies show up... And sometimes they don't. It seems as though one given probe sees a handful of them, another probe might see the same ones or different ones. I found one on the Mun and landed near it - the lander probe core never saw it no matter how close it was, but the surveyor that marked it with a waypoint spotted it from the SOI change on. I'm wondering if this is limited to a vessel or a core. I.e. if I have 30 probe cores on one craft, am I more likely to find more anomalies, or would 30 separate probes do the trick? Does anything reset them so it's prudent to check again later? Do different cores have better odds? Do the old ore survey scanners come into play? Why isn't there a KSPedia page that gets me pointed in the right direction with definitive answers? Despite the rant, I'm mostly just curious. I'm excited to start finding some of the easter eggs I've never seen for myself, but I just wonder what it'll take to be sure I've got them all. Prior to 1.2 I've only ever spotted the closest few to KSC and one Mun arch. Today I've found the Armstrong Memorial with the help of my probes - yay!
  16. The Boffins have not been idle despite it having been a long time since the Circus did anything. No, they've been hard at work testing and tweaking stuff for the next chapter of the Glorious Kerbal Space Empire. Their current project is to develop a kOS script to facilitate the deployment of what they call "Moonsats". In the Circus concept of communications networks (see the link in my sig), there are 2 general species of commsats: Main Relays, which have huge antennae and are in highly eccentric polar orbits over the central body in each planetary system, and Moonsats, which are in moderately low circular orbits, usually but not necessarily around moons of the central body. There usually needs to be more than 1 of these latter per "moon", and they need to be spaced neatly, and that requires more math than the Boffins want to do manually. Thus, the goal was to make KAL9000 (actually the name of the computer part in kOS) do crunch the numbers for them . Anyway, the project has gone from the drawing board to partial implementation and successful completion of early milestones in the course of today. The Boffins are feeling a little proud of themselves so decided to show off what they've done so far. And here it is: Really, that's all it does right now, just calculate and display those 5 particular numbers, only 2 of which are really important at the moment. But that was the main challenge. The rest of the project should be somewhat simpler as it traverses known ground. Today the Boffins had to learn more about the "anomalous rectums" (actual technical term) of orbits than they ever wanted to know . There's a non-negligible amount of code and a lot of research behind this simple display. The idea of the whole project is as follows: A carrier vehicle (CV) with 3 moonsats aboard gets into an elliptical orbit at the desired inclination around the body the Circus wants to hang a network on. At this point, the kOS script is activated. The kOS script figures out a good altitude for the moonsats to orbit the body and adjusts the CV's Pe to that altitude. The kOS script determines the orbital period for a circular orbit at this altitude, then multiplies that by 1.33333 to get the desired orbital period of the CV. The kOS script calculates the Ap needed by the CV to have that orbital period and adjusts the CV's Ap as needed. Once so adjusted, the CV releases 1 moonsat per orbit, each of which then circularizes at the Pe of the elliptical CV orbit. Because the CV's orbital period is 1/3 longer than that of the moonsats, each time it or a released moonsat reaches Pe, it will be 1/3 of an orbit behind the previous moonsat, so they end up evenly spaced and able to see each other around the body. To accomplish this, the Boffins broke the project up into phases: Phase I: Develop the basic algorithms for computing the required orbital parameters, in such a way that the same script can be used at any body with a reasonably large SOI. Just print these numbers on the screen and test their validity by performing the necessary maneuvers manually. This is actually the only important phase because the system is workable at this point. The later phases are gravy. Phase II: Add the ability to deploy n >= 3 satellites, and add automation so the CV performs all maneuvers itself. Phase III. Write a separate program for the moonsats so they can tweak their own orbits automatically. Today, the Boffins are please to report that Phase I is complete! It's that output which appears in the pic above. The process starts by determining a "good" altitude for the moonsats. This has to be high enough that they can see the adjacent moonsats sharing the orbit without the planet in the way, plus have some margin of error for imprecise maneuvers getting there. For the 3-moonsat problem, this altitude is determined as follows: The desired quantities are the line CS (for calculation purposes) and also CS minus the radius of the planet (orbital altitude for maneuvering purposes). The length of the line CF is arbitrary, whatever you think gives enough clearance between the edge of the planet (and atmosphere, if present) and the LOS between adjacent moonsats. In Phase I, the Boffins chose 120% of the body's radius. This turned out to be just a tad too short in practice, so will be increased to 150% in the next round of testing. In any case, for the 3-moonsat problem, Triangle CFS is a 30-60-90 right triangle so with CF given, calculating the length CS is just 1 trig function away. The next step is to calculate the orbital period for a circular orbit of radius CS. Just plug the numbers into Kepler's 3rd Law: T = SQRT[(4 * π2 * R3) / (G * MP)] where T is the period, R is CS, G is 6.673 x 10-11, and MP is the mass of the body you're orbiting. Simply multiple this value by 1.3333 to get the period of the CV/s desired elliptical orbit. It was at this point that the Boffins started running into all the "anomalous rectums" and thought they were going to have to do a bunch more calculations using them to figure out the CV/s desire Ap by way of the semi-major axis. But fortunately, the Boffins figured out a shortcut after a chance reading of a footnote buried deep in dense pages of complex equations. That life-saving footnote said this: "A circular orbit with a radius equal to an elliptical orbit's semi-major axis has the same period as the elliptical orbit." The Boffins already now had the period of the elliptical orbit so could plug that back into Kepler's 3rd Law (above) rearranged to solve for R, which in this case would be the semi-major axis of the CV's elliptical orbit. R = [(T2 * G * MP) / (4 * π2)]^(1/3) Then, because the planet is at one focus of the ellipse, the altitude of the CV's desired Ap would simply be: Ap = [( 2 * SMA ) - CF] - the body's radius. Wow. That wasn't so hard, thanks to the shortcut Anyway, with all these numbers determined, the script simply printed them out as shown above. All this worked fine at Kerbin in an equatorial orbit but to really test Phase I, the Boffins sent a wad of 3 moonsats to Mun and had them arrive with a 60^ inclination. Here they all are still attached to the CV en route to Mun. And here they are being deployed, all being flown manually using the numbers calculated by KAL9000 using the script. You can see the CV is in a slightly elliptical orbit with the 1st moonsat in place and the next in-process. With all 3 moonsats in place, the Boffins de-orbited the CV. As it turns out, 2 of the moonsats can't quite see each other and the others are borderline due to their orbits being a shade too low. As mentioned above, fixing this is just tweaking 1 scalar value so really isn't important here. What is important is that the Boffins managed to code this script without any egregious logic errors, despite not knowing much about fancy orbital mechanics, and that the algorithms work well enough to provide good results even with substantial rounding errors (for clarity in the display of the numbers) and the imprecision of manual flying. So now the Boffins are celebrating with their traditional whiskey and wondering if it's even worth the trouble to go on with Phases II and III.
  17. Two questions about different scanners; 1) When you use KerbNet on some of the more advanced probe cores, they have the ability to detect anomalies. How do the mechanics of this work? Is there a one off chance of detecting an anomaly the first time you fly over or land in a new biome or does KerbNet recheck on each orbit/touch down? 2) I've been using a Surface Scanner to keep track of my position on my Mun Rover as it travels towards the South Pole. The display looks something like - Biome: Highlands, Lat 63.484 S [-1.108 N] Lon 140.008 E [2.444 E] . . . . . . What do the figures in the square brackets after the Lat and Lon mean?
  18. kOS-SCANsat is an Addon to kOS kill Kerbals in new and exciting ways. It allows you to use the inaccurate data provided by a low resolution scanner to be used for mission planning**. It is designed to provide a "realistic" way to plan your missions and forces*** you to scan your landing side before you send a lander. Features: Low and High resolution altimeter scans Biome scans Resource scans slope data (and highly inaccurate slope data for low resolution scans) KerbNet Scanning of the current vessel. (only for biome and altimeter) ** you should bring a KerbNet compatible scanner with you, so you can prevent the worst. *** actually it doesn't remove the magical geoposition:terrainhight suffix, but using that is now considered cheating Requirements: KSP 1.3.1 kOS SCANsat Full Documentation: Documentation of the API Downloads: Get the latest release here Source code is here
  • Create New...