Eriksonn

Members
  • Content Count

    131
  • Joined

  • Last visited

Community Reputation

178 Excellent

2 Followers

About Eriksonn

  • Rank
    Ion thruster repair man

Profile Information

  • Location Array

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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?
  2. 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)
  3. 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.
  4. 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.
  5. 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?
  6. 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.
  7. 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
  8. 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
  9. 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
  10. 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
  11. @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...
  12. @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
  13. @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.
  14. 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)
  15. 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.