Eriksonn

So i am trying to create an orbit with nothing attached to it, and i followed this thread but i cant get it to work. Here is the code i have: Object = new GameObject(); Orbit = new Orbit(0, 0, 12000000 * 0.6, 0, 0, 0, 0, FlightGlobals.GetHomeBody()); OrbitDriver = Object.AddComponent<OrbitDriver>(); OrbitRenderer = Object.AddComponent<OrbitRenderer>(); OrbitDriver.orbit = Orbit; OrbitDriver.orbit.Init(); Vector3d p = OrbitDriver.orbit.getRelativePositionAtUT(Planetarium.GetUniversalTime()); Vector3d v = OrbitDriver.orbit.getOrbitalVelocityAtUT(Planetarium.GetUniversalTime()); OrbitDriver.orbit.h = Vector3d.Cross(p, v); OrbitDriver.orbitColor = Color.red; OrbitDriver.updateMode = OrbitDriver.UpdateMode.TRACK_Phys; OrbitRenderer.driver = OrbitDriver; OrbitRenderer.SetColor(Color.red); OrbitDriver.Renderer = OrbitRenderer; OrbitRenderer.upperCamVsSmaRatio = 999999; OrbitRenderer.lowerCamVsSmaRatio = 0.0001f; OrbitDriver.upperCamVsSmaRatio = 999999; OrbitDriver.lowerCamVsSmaRatio = 0.0001f; OrbitRenderer.celestialBody = Orbit.referenceBody; OrbitRenderer.drawIcons = OrbitRenderer.DrawIcons.ALL; OrbitRenderer.drawMode = OrbitRenderer.DrawMode.REDRAW_AND_RECALCULATE; OrbitRenderer.enabled = true; OrbitDriver.drawOrbit = true; I have a feeling that i am really close to getting it to work, and that there is some silly mistake that breaks everything.

so if i get this right this means that for a single antenna aimed at a single reflector the total range = antenna base range + antenna reflector bonus * reflector range, where the 3 rightmost dots on the diagram are the range of the large foldable reflectors?

hmm, so you are saying that i should use the large stock relay antenna to relay from kerbin to jool(for example) and then use NFE antenns in-system? works for me now that i know the intention. Also, what are those 3 last NFE antennas(or antenna-reflector combos) to the right of the diagram? are those some of the huge foldable reflectors coupled with something else?(would imagine so, as i didnt see any single antenna having at or above stats compared to the 88-88)

I recently got the NFT Exploration mod (so now i have almost the complete collection), and Everything in there is really cool, i like the tiny landing legs and the variaties of probecores and all of the small relay antennas and the reflectors seem like a neat concept. There is however one slight issue that i find with the new antennas: none of them are even close to competing with pretty much any stock antenna intended for interplanetary distances like the communotron 88-88, as i made a small probe with 8 ph3s, one RA-0-8 and a FR8 paired With a RFL-3 Array, and i didnt even get out do dres orbit Before my signal faded, and then my until then disabled 88-88 overpowered all of them massivly even though it was much smaller than the RA-0-8. So while these antennas seem great for in-system relays to rovers and probes and such, they are not good for interplanetary things, and as if i recall correctly, a relay only considers an antenna valid if it has enough range to reach kerbin on its own, even if there are other antennas on the same craft, so that means that most(not sure how many, but looking at the stats i belive most of them unfortunatly) of these new fancy antennas will be pretty much useless outside of kerbin soi.

Despite what it seems like, i have never actually done any manned moho mission ever, not even landed on moho in any way whatsoever, so good job getting there and back so early into the game. About overengineering stuff, i tend to do that in kindof the opposite way to most people, as i dont feel like "more boosters" really fit with my personality very much. Instead i tend to focus on effective upperstages and multi layered gravity assists. (I really like the near future mod that adds more ion engines and stuff) I also overengineer on my gravity assists and flight plans, i also use the principia mod for n-body gravity as that makes orbits so much more interesting in my opinion. So one can say that i overengineer my orbits instead of overengineering my rockets.

the new principia version doesnt work for me... The Principia DLL failed to load. Dependencies, namely the Microsoft Visual C++ 2015-2019 Redistributable (x64) - 14.22.27821, were not found. what should i do about this?

I kindof gave up on all of the advanced math for getting the geoids of arbitrary planets, and decided instead to semi brute-force it. To the left is Minmus and to the right is the geoid of Minmus scaled up by a factor of 3. https://imgur.com/sKiKgyj I have not yet implemented this in my little mod, as i want to see if i can optimize it somehow first, as it takes a few seconds to compute everything. And that will be even worse when i need to do it over all of the bodies instead of just minmus. Luckely i have recently learned to use multithreading, so that will definitly help to speed things up.

That was exactly what i ment, that the ship would need 10^3800 tanks, and the same amount of stages, as i assumed that each tank was staged off as it get empty. That is indeed almost exactly the average deltav per stage Not sure what you ment by expoentiall larger stages, as each stage is just a single tank, if it was becauce of the sun example, that was just a demostration of the amount of tanks required

in my first post on this topic, my math showed that you need 10^3800 stages, that is a 1 followed by 3800 zeroes, to put that in perspective, that would be like taking all the atoms in the entire sun, and making each one of those atoms into a whole sun, and then replacing all the atoms in each of those suns with xenon tanks, only then would you get somewhat close to the amount of tanks/stages that you will need

I kindof guesses that infinite fuel was allowed, but i enjoyed doing the math regardless, just to give a perspective as to how hard it would be without infinite fuel

Firstly i am abit confused by the sentance: as i dont really know if those things are allowed or disallowed, but assuming that those are not allowed there is a massive problem here: I think that you are underestimating the speed of light, as 300 million m/s is vastly faster than any normal speed that people are used to(and that includes all of the high speed crashes into the mun that would be considered very fast by non-ksp players) Just becauce i am that type of person i am going to do the math on how much is needed to get to that speed in the stock game. As much as i like them, i am going to ignore gravity assists, as whatever can be gained from them is completely negligable compared to lightspeed. I was at first going to write how i got to the final awnser, but that got longer than i expected, and was hard to read as i cant get fancy math notation here... Therfore i will just tell you about my final results instead. So if we assume a ship made entirely out of one ion engine and a bunch of the large xenon tanks, and we stage off each individual tank when empty, then the deltav for a ship with N tanks is approximatly 32961*log(N) m/s. I know that that equation seems kindof small, and it is, but the process to get it was not simple, and i did kindof give up slightly at the end, as the problem actually didnt have a nice mathematical solution, so i approximated abunch and got this, although this is a damn good approximation despite the amounf of guessing and trial and error that went into making it. Anyhow, lets get to the results... so if we want a ship with 300 000 000 m/s in deltav, we need e^(300000000/ 33785) tanks. This number has 3856 zeroes if written out in decimal form, and this is for the most effective spacecraft physically possible in the stock game. To put that number in context for a bit, filling the entire observable universe with xenon tanks will not even be close to the amount that we need, 10^80 compared to 10^3856. That means that we still have 10^3776 times too few xenon tanks. Oh and btw, the amount of tanks needed is very sensitive to the weight of the engine and the rest of the spacecraft, as adding an extra 300 kg of stuff to this Engine+tanks spacecraft(like for example a probecore, a few batteries and a few solar panels), increases the tank count by about 10^300

@eggrobin I have read through that link that you sent, but i have reached a dead end, as that whole paper seems to assume that i have the disturbing potential as well as the topography, and i only have the topography. But it should be possible to get the geoid with only the topography, atleast if constant density is assumed. I tried to do a brute force approach, but that was very slow, and i am not confident in its accuracy. Most of the papers i find on this seems to either use ground measurements of the gravity or computing other values that i dont care about, by using the geoid as a given. So i am abit stuck right now...

@eggrobin Ah, that makes sense. I made this little diagram for myself, and now it makes perfect sense why having the geopotential be equal to the terrain is a bad idea. Now i need to throw myself back into the sea of strange math(ie, the link you gave me) to find a way to get the correct smooth version of the geopotential

@eggrobin Hmm, so you are saying that having the geoid be equal to the terrain height is a bad approximation for a constant-density body? I will take a look at that link you gave and see if i can find something interesting. About the coefficients, I already guessed that the degree 1 coefficients were not useful as they would make the body have a center of mass that is not aligned to its rotation axis, and that makes no sense. So I have already removed degree 1 from my config output.(the one about Minmus that you referenced is abit outdated) That degree 2, order 1, I did not know was problematic, but i guess that i can remove that one too, if principia dont care about it either. (Although it would be interesting to know why it is problematic/doesnt matter) I am just using the Body.TerrainAltitude() function to get my terrain height, and i would strongly guess that for most bodies their center of mass is not necceraily aligned with their "origin" as the game sees it. As I have already removed the degree 1 component, I am not sure how much of a problem that is.

It actually has nothing to do with saves, it generates one single config file that then works on any save. I have put a small boolean variable in the settings file if one wants to re-run it as it needs to be re-run if the solar system changes(Becauce of planet packs and the like) I sortof fixed that by simply increasing the density of my sample points, so now that problem is negligable compared to the "usual" values that occur simply by the lumpyness of the planet/moon itself. (the "problem" is now about 10 times smaller than what the other values usually are)

I already fixed the config files, otherwise i wouldnt be able to make take those screenshots. But i apparently forgot to edit that question. I simply(the math wasnt simple...) get the terrain height for each latitude and longitude, and then use the "discrete inverse spherical harmonic equation" on the whole body to get the coefficents. This is the main code for this: for (int i = 0; i < ResolutionWidth; i++) { for (int j = 0; j < ResolutionWidth / 2; j++) { //get the longitude and latitude of the current point on the surface double Longitude = Math.PI * 2 * (i / (double)ResolutionWidth); double Latitude = Math.PI * 2 * (j / (double)ResolutionWidth); //get the terrainheight from the center of the body, scaled by radius double CurrentRadius = 1+Body.TerrainAltitude((j*360.0 /ResolutionWidth) - 90, i * 360.0 / ResolutionWidth) / Body.Radius; //a scaling factor that accounts for increased density of sample points close to the poles, and also for the total surface area of the body double AreaScale = (Math.Sin(Latitude)) / (ResolutionWidth * ResolutionWidth * Math.PI); for (int n = 0; n <= MaximumDegree; n++) { for (int m = 0; m <= n; m++) { //save the total scaling factor so that i dont have to use it twice //(TODO)as both the P and Normalization functions contain factorial terms that gets messed up if MaximumDegree>10, //i should "bake in" these functions into the for loops themselves, so that i can support higher degrees than 10 double Q = AreaScale * CurrentRadius * P(n, m, Latitude) * Normalization(n, m); //I am using a precomputed lookup table for the cos() and sin() functions to be more performace friendly. //A little optimazaiton never hurts ;) CosArray[n][m] += Q * CosTable[i, m]; SinArray[n][m] += Q * SinTable[i, m]; } } } } That is a good idea, as currently everything has the same degree. Once my mod can handle it, I will have to look at some higher degrees to see what the trend is. I am already ignoring Stars and planets like Jool as they have no surface and is perfectly round(interestingly though, my program did generate some low but noticable factors even for Jool, especially the n=2,m=0 cos factor was alot higher than any other factor for Jool, but still lower than any other body. It seems like the algorithms is biased to the poles for some reason, but the error went down significantly by adding more sample Points(default is now 200x100, but can be changed in the Settings.cfg)) That sounds good, that (probably) means that I wont need to worry about giving geopotentials to too many things at once.

Firstly, the main mod for this is the principia mod that I didnt make. My mod only adds some config files That principia uses. I am not fully done with my little mod either. I can still awnser your questions tho. a) It will (as any other orbit), keep orbiting when you are not looking. And can destabelize when you are not looking, so keep an eye out on sattelites in lower orbits- b) Yes, and it also depends on the "lumpyness" of the body you are orbiting. Minmus is quite lumpy and Gilly is even worse. The Mun and Ike are less lumpy, so they wont be as suceptible to this. I did some tests and it appears that a 30km orbit around mun is just barely stable enough to not collide, but a 50 km orbit is fine. Both of those options gets quite a high inclination after a while(maybe 5 degrees or thereabout). A 25 km orbit of Minmus seems fine aswell. Compared to the radius of each moon, the stable minmus orbit was further out due to the higher lumpyness of minmus.

I think that you could add it to an existing one(it wont crash or anything), but then you have to be real quick to save some of your stuff depending on where they are. On minmus for example, yes it gets messed up at 15km, but once you extend the orbit to 30km or so, it quickly gets stable again. So only very low orbits around very lumpy things will be at risk. So a low orbiting minmus sat might need fixing, but a space station around duna is probably safe. Even the mun is quite safe, becauce it isnt as lumpy as minmus, so a mun station is also probably good.

@eggrobinSo i think that i have finished my little mod for adding geopotentials to the stock system(or rather any system except RSS). It generates a single config file that links to the principia_gravity_model config that is used by principia for the RSS geopotentials. It generates up to degree 10, wich i think should be good enough, and as i am doing it for every body(everything is the default, although a whitelist is also an option) i dont want to have too high degree as i am not sure how performace intensive this operation is(i havent gotten any more lag than usual on max warp using this, so i think it is fine). In this image i am orbiting in a circular 15km orbit around minmus, but due to the hills and flats, the orbit gets destabelized, and eventually crashes into minmus. Here is the same orbit from the side, to show that it also affects inclination. It even works with modded planets/moons. This one has a very oblate shape, leading to a very high precession rate of about 40 degrees per orbit. Now i think that i will make my own thread for this little mod when i am feeling done with it(should be soon i hope), and then i can make a link to it from here. I hope that it is ok for me to do this and if you want you can maybe mention my mod in a more direct way, so that others can see it. Becauce i think that having stock geopotentials is a very neat and exciting thing to be able to have. I hope that this sounds like an interesting concept. Tell me if you have any questions about anything.

That is neither going to work, nor is it required, as the only thing my mod does is to generate a single config file for a much larger mod, so i cant test it on its own. And I also only wanted to see if it lagged noticible more with every body in the system having this feature. I have also already done it so that it does it to all of them, and i didnt notice any lag issues at all.

I actually succeded in getting my mini mod to work. I am so happy that i actually managed to do it. My sattelite is in a perfectly circular 15km orbit over minmus, and the flightplan says that i will crash in a few orbits, as the hills and flats of minmus messes with my orbit. Now it is time to stress test this feature to see how many bodies i can give this to without lagging too much.

I am not 100% sure that this counts as it is has nothing to do with cool looking space stations or anything like that(even tho that is cool too). But the thing that i am currently trying to do is to make a mini mod as an extension for the Principia mod(that mod that adds n-body gravity and such). Principia has a thing with RSS where it gives the Earth and the Moon what i call the "lumpy gravity condition", and for the Earth that means that it is slightly flattend due to its rotation as it is in real life. That means that if you have a sattelite in a high inclination orbit, the ascending and decending nodes will slowly rotate around the equator. And for the Moon it leads to low orbiting bodies being destabelized over many years, and will eventually crash into the surface. Principia will model all of these effects in RSS, but what i am aiming to do is to replicate this behaviour in the stock system as well. As for example, Minmus is very lumpy, so if i can give it equally lumpy gravity, the orbits around it should get very interesting. The main problem with all of this is that Principia wants a very special encoding for this lumpyness, and i think that i have finally managed to solve it. For this image, i have an image of minmus on the left, but on the right is my own small program to decode the special encoding that my mod spits out. And if You look closely, That ball on the right sortof looks like minmus, where the redder areas corresponds to the flats, and the greener areas corresponds to the highlands. What is so cool about all of this is that the special encoding enabled me to generate that right sphere using only about 40 numbers, instead of the 10000 i would need to get each height individially. And if you ask me, i think that giving lumpy gravity to minmus is quite cool.

@eggrobin Over the past few days i have been making a mini mod thing for automatically generating the spherical harmonics needed to allow some of the stock bodies to have geopotentials.(My current "test subject" is Minmus) At this point in time i have managed to generate a suitible(i think) config file with the same format as the one in Principia/real_solar_system/gravity_model. principia_gravity_model { Body { Name = Minmus geopotential_row { degree = 1 geopotential_column { order = 0 cos = 2.01267793181124960E-004 sin = 0.00000000000000000E+000 } geopotential_column { order = 1 cos = -1.67248927462036320E-003 sin = 2.96599647369928530E-003 } } geopotential_row { degree = 2 geopotential_column { order = 0 cos = 8.05394019210287260E-003 sin = 0.00000000000000000E+000 } geopotential_column { order = 1 cos = -2.80339441217786760E-003 sin = 1.38156354030291020E-003 } geopotential_column { order = 2 cos = -5.70133104974222470E-003 sin = 3.12729158537247910E-003 } } ...up to degree 10... However, i am now having 2 problems. One is that i dont know where to put this new file(i am calling it gravity_model_extension). Can i still have it in my own mod folder and somehow link it to the principia folder, i have tried adding an @ to the of start principia_gravity_model, but that didnt work either. Two is does my file contain enough information as is or do i need more? (as i saw that the gravity_model file contained lots of other information like gravitational_parameter and reference_radius. Do i need that too, or am i good with what i have?)

Although i didnt actually *make* Rega and its rings, i just moved it. Ant that also means that i cant use it without the kerbol origins mod, although maybe i can copy it but still... I didnt actually make it

The mods i used was most of the near future technologies mods atleast i think that those were most of the important ones, might still be a few "trace parts" from other mods too but the NFT mods is by far the majority