DoctorDavinci
-
Posts
2,810 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by DoctorDavinci
-
-
Still haven't learned my lesson concerning brakes but I made it in under 7 minutes with a top speed of 90.2 m/s
... Gotta do that again but this time the objective is to not smash into the small pyramid
-
17 minutes ago, Snark said:
The main suggestions are:
- Liberally include code comments, like, a lot. How much is "enough" is subjective, of course, but just for comparison, here's a typical source file of mine to give an idea of the amount of comments I like to use, myself.
- Avoid really long blocks of code that go on for pages and pages-- if it's more than will fit on a screen or two, consider breaking it up into smaller functions.
Rationale for the code-comment thing: It'll make your life easier.
- It means you're less likely to self-inflict bugs on yourself by getting confused about "what did I mean when I coded this". It's easy to write code that's meant to do one thing, and then come back weeks or months later and read it and think you meant something else and get caught up in your own assumptions.
- It means that other people can read your code much more easily too, which means that if you ever need to ask for help, it's a lot easier to get it. It also means that anyone inclined to debug your mod themselves, and/or look at your source code, will better be able to understand it and more likely to spot problems (e.g. stemming from mistaken assumptions or whatever).
- It means that when you do have a bug, and you're trying to track it down, you'll be able to follow the logic flow of your code faster and more reliably, and incorrect assumptions will tend to "stick out" more.
Rationale for the break-it-up-into-smaller-functions thing is much the same. Pretty much the same benefits as the above.
I've actually started on this about a month ago or so ... I had one class that turned into over 15000 lines of code lol
There is a ton of stuff I need to separate into their own classes and also a bunch of repetitive code in there ... I was going on the concept of getting it to work first and then start cutting it up into pieces
Anyways, thanx for the suggestions and help with this target distance issue ... I also managed to fix some spawning issues (holokrons spawning underground), challenger placement problems (vessels crashing through the surface while being moved to the challenge start pos) as well as fixing the scoreboard and score detail menu
I think it is time to do as you suggest above and buckle down to refactoring .... Sitting at over 28000 lines of code now so it will probably take awhile lol
But it's all working ... we now have a challenge creator mod for KSP
I'm going to package it up and post a new release, do a bit of Dakar racing and then dive into cleaning up my mess
Thanx again
-
1 hour ago, Snark said:
Interested in some friendly coding style advice/suggestions from a grizzled old coder, which may help make life a bit easier for you? (I ask first, because no desire to pontificate unless you're actually interested. Not everyone is.)
I am always up for learning new things ... Just not so keen on comments such as found on the first page of this thread
Anyways, looks like I fixed it ... Although I couldn't get the code you posted to work correctly, weird numbers coming out of what I wrote
I instead did a bit of digging and came up with two methods to achieve the proper distance ... the first using a modified snippet of code mashed together with another snippet of code I found on Stack Exchange and the other, more interesting, is by using System.Device.LocationSystem that is in .net 4.7.2 as it has a direct method specifically made to do distance checking (probably for mobile devices methinks ... or something like that)
I went with the first option in the end and it seems to be spot on and I would prefer to see what the code is doing instead of relying on outside functions to do the work (mainly so I can understand what is going on) ... Although the displayed distance still has a minor error due to my using Math.Round on the distance to 1 decimal place (I'm also splitting the difference with the two altitude values ... adding them together and dividing by 2)
Quotepublic static double Radians(double x)
{
return x * Math.PI / 180;
}
public double GetDistance(double lon1, double lat1, double lon2, double lat2)
{
double dlon = Radians(lon2 - lon1);
double dlat = Radians(lat2 - lat1);double a = (Math.Sin(dlat / 2) * Math.Sin(dlat / 2)) + Math.Cos(Radians(lat1)) * Math.Cos(Radians(lat2)) * (Math.Sin(dlon / 2) * Math.Sin(dlon / 2));
double angle = 2 * Math.Atan2(Math.Sqrt(a), Math.Sqrt(1 - a));
return angle * (FlightGlobals.ActiveVessel.mainBody.Radius + ((FlightGlobals.ActiveVessel.altitude + _altMission) / 2));
}I haven't tested it at the poles, only near the Desert Airfield, but from the looks of it the error I was seeing in the distance is fixed
-
4 hours ago, Snark said:
Thanks, I appreciate the full context... but I find the code pretty hard to follow (there's a lot of stuff in there, with lots and lots of nested clauses in one big monolithic block, and no code comments). Fair 'nuff if that's your comfort zone
... just makes it a bit harder for others to follow (well, at least my tired old brain, anyway), particularly if the reader doesn't have the broader context of the overall design of the mod.
Not really a comfort zone thing, more like I have no idea what I am doing as I am no computer scientist or coder for that matter ... Totally self taught with a little help from some friends
4 hours ago, Snark said:Though, if you don't mind my asking... any particular reason you're using latitude / longitude / altitude for all this stuff, which imposes the the need for trigonometric conversions? For example, Vessel.GetWorldPos3D() hands you the XYZ coordinates as a handy Vector3d right there. Not sure what your "target" is (a vessel? something else?), but if you have a way of getting its world position as a Vector3d, then that would solve your problem for you right there:
For example,
Vector3d vesselPos = FlightGlobals.ActiveVessel.GetWorldPos3D(); Vector3d targetPos = whateverTheTargetIs.SomehowGetWorldPos3D(); double distanceToTarget = (vesselPos - targetPos).magnitude; // All done!
If what you have is just latitude / longitude / altitude, and you don't have a way of getting the XYZ coords directly, then yes, that's what you'd do, yes.
To give you a bit more context, the original idea of creating OrX Kontinuum was to not have to hard code missions into OrX - The Loot Box Controversy (I turned KSP into a first person shooter ... I really wanted a zombie mode for KSP
) ... However now OrX K has turned into a challenge builder (Geo-Caching, Short Track Racing, Dakar Racing, BD Armory challenges etc..) with a custom encrypted save file that can be shared with other players (a custom save game, if you will, that can be merged into a current game on the fly while in the flight scene)
The challenges are built while in the flight scene with the HoloKron system I created ... This system is what creates and encrypts the .orx file that contains coordinates for gates that were placed as well as vessels that were spawned while building (including the vessels themselves) and a bunch of other data such as the challenge type, starting coords, stage coords etc....
Then there is a spawning system that takes that data in the .orx file when a player competes in a challenge and uses it to spawn vessels, HoloKrons, stage gates etc... when a player gets to within a specified distance .... This is the main function of the distance checking is for (BD Armory challenges also have some additional logic for triggering the guard mode, activating engines, turning on the AI pilot etc...)
There's a few more goodies in OrX K such as the beginnings of W[ind/S] (wind for sailing and hang gliding challenges ... yes, it works quite well) as well as a working Scuba Kerb for scuba diving with your kerbals (including bends and nitrogen narcosis
)
4 hours ago, Snark said:Vector3d vesselPos = FlightGlobals.ActiveVessel.GetWorldPos3D();
Vector3d targetPos = whateverTheTargetIs.SomehowGetWorldPos3D();
double distanceToTarget = (vesselPos - targetPos).magnitude;^^ This ... I didn't even think about this at all although, as mentioned above, I don't know what I am doing
I can just create a Vector3d for the target pos from the coords in the .orx file and then use double distanceToTarget = (FlightGlobals.ActiveVessel.GetWorldPos3D()- targetPos).magnitude; ...... yes?
Does the .magnitude return a value in meters?
-
I don't want to strap rockets to the Mad Moose as that would require a total redesign
I made a couple modifications to Bills Big Bad Beaver, gave her new paint job and took her for a rip over the top in a mostly direct line .... 7 minutes 3 seconds
Top speed 96.6 m/s ... I would say I was over 70 m/s for most of the run
So it seems that the old saying is true ... Don't go around the problem, go straight through it and run it over
(this isn't my official entry ... I'm quite confident I can get this stage under 7 minutes
)
-
Just now, Pds314 said:
Well that would seem to indicate that my route is faster since my current performance is 9:22. Then again, vehicle and driving style do definitely matter.
Possibly ... although you have a faster vehicle
I am going to take a look at a more direct route but it comes down to the average speed like you mentioned above ... a higher average speed will be required to go around the mountains
10:54 isn't that bad for Bill's Big Bad Beaver, top speed that run was 102.1 m/s using 2 Junos and weighed down with enough fuel to do the whole course ... I may just have to bring out the Mad Moose and go right over the top (although I think I need to strap some rockets to that beast ... moar boosters
)
Time to pull out and modify the Mad Moose
Spoiler -
8 minutes ago, Pds314 said:
Re: going around the mountains and past Stage 4 instead of through them:
It looks to me like it's something like 45 kilometers vs 24.5 in the "ultra-direct" route. So you need about 80% greater average speed. Is it worth it? I don't know.Well I have managed to pull a sub 11 minute run doing exactly that so it might actually be worth it
Here's the very end of the run ... Note to self - Slow down before you get to the stage gate
Methinks imma gonna have to try this again lol
-
17 minutes ago, QF9E said:
I think I can do better than what I posted, as I drove around the temple for a bit before doing that screenshot, in search of the end of stage. I'm thinking of doing the stage again using the save game method, if that gives a faster time will you update the scoreboard?
of course I'll update your times
as an aside, here's a fix for those issues with OrX
https://www.dropbox.com/s/drla4zkvv2d0wle/OrX.dll?dl=0
just overwrite the .dll in OrX/Plugin
I'll release an updated OrX shortly
-
8 minutes ago, Pds314 said:
Ugh. That final hill is brutal... I could have gotten a 9-10 minute first-stage run and I was being pretty conservative. But then I botched a landing and flipped out with reverse thrust. I started at MET 1:00.
Damn .. that is rough
I think the fastest route if you can maintain high speeds is going around via the stage 4 flag and then over to the pyramids ... much smoother ride
I managed under 12 minutes in my testing with Bill's BBB Mk3 the other day .. 102.7 m/s lol
-
@Snark would you be so kind as to move this thread to the C# Development Help and Support section ... I have a few questions regarding the targeting distance deal and would like to pick your brain a bit (as well as anyone else who would like to chime in)
In the spoiler below is the main targeting code I am using in OrX Kontinuum ... The example I posted at the beginning of the thread is only for changing the color of the distance display and preventing a stage gate from being placed if it is too far from the challenge starting coordinates (the Short Track Racing challenge creator has a maximum radius of 4km for placing gates)
Spoilerif (FlightGlobals.ActiveVessel.altitude <= _altMission)
{
_altDiff = _altMission - FlightGlobals.ActiveVessel.altitude;
}
else
{
_altDiff = FlightGlobals.ActiveVessel.altitude - _altMission;
}if (_latMission >= 0)
{
if (FlightGlobals.ActiveVessel.latitude >= _latMission)
{
_latDiff = FlightGlobals.ActiveVessel.latitude - _latMission;
}
else
{
_latDiff = _latMission - FlightGlobals.ActiveVessel.latitude;
}
}
else
{
if (FlightGlobals.ActiveVessel.latitude >= 0)
{
_latDiff = FlightGlobals.ActiveVessel.latitude - _latMission;
}
else
{
if (FlightGlobals.ActiveVessel.latitude <= _latMission)
{
_latDiff = FlightGlobals.ActiveVessel.latitude - _latMission;
}
else
{_latDiff = _latMission - FlightGlobals.ActiveVessel.latitude;
}
}
}if (_lonMission >= 0)
{
if (FlightGlobals.ActiveVessel.longitude >= _lonMission)
{
_lonDiff = FlightGlobals.ActiveVessel.longitude - _lonMission;
}
else
{
_lonDiff = _lonMission - FlightGlobals.ActiveVessel.latitude;
}
}
else
{
if (FlightGlobals.ActiveVessel.longitude >= 0)
{
_lonDiff = FlightGlobals.ActiveVessel.longitude - _lonMission;
}
else
{
if (FlightGlobals.ActiveVessel.longitude <= _lonMission)
{
_lonDiff = FlightGlobals.ActiveVessel.longitude - _lonMission;
}
else
{_lonDiff = _lonMission - FlightGlobals.ActiveVessel.longitude;
}
}
}double diffSqr = (_latDiff * _latDiff) + (_lonDiff * _lonDiff);
double _altDiffDeg = _altDiff * degPerMeter;
double altAdded = (_altDiffDeg * _altDiffDeg) + diffSqr;
double _targetDistance = Math.Sqrt(altAdded) * mPerDegree;targetDistance = _targetDistance;
OrXHoloKron.instance.targetDistance = _targetDistance;if (OrXHoloKron.instance.challengeRunning)
{
if (FlightGlobals.ActiveVessel.srfSpeed >= OrXHoloKron.instance.topSurfaceSpeed)
{
OrXHoloKron.instance.topSurfaceSpeed = FlightGlobals.ActiveVessel.srfSpeed;
}if (!FlightGlobals.ActiveVessel.LandedOrSplashed)
{
OrXHoloKron.instance.airTime += Time.fixedDeltaTime;
}
}if (_targetDistance <= 20000)
{
if (checking)
{
if (OrXHoloKron.instance.bdaChallenge)
{
if (OrXVesselLog.instance._playerCraft.Contains(FlightGlobals.ActiveVessel))
{
Vector3d stageStartCoords = OrXSpawnHoloKron.instance.WorldPositionToGeoCoords(new Vector3d(_latMission, _lonMission, _altMission), FlightGlobals.currentMainBody);OrXHoloKron.instance.checking = false;
OrXLog.instance.DebugLog("[OrX Target Distance - Goal] === TARGET Name: " + HoloKronName);
OrXLog.instance.DebugLog("[OrX Target Distance - Goal] === TARGET Distance in Meters: " + _targetDistance);
checking = false;
CheckIfHoloSpawned(HoloKronName, stageStartCoords, missionCoords, primary, Goal);
}
}
else
{
if (_continue)
{
if (_targetDistance <= 4000)
{
_continue = false;
Vector3d stageStartCoords = OrXSpawnHoloKron.instance.WorldPositionToGeoCoords(new Vector3d(_latMission, _lonMission, _altMission), FlightGlobals.currentMainBody);
OrXLog.instance.DebugLog("[OrX HoloKron Distance] === " + HoloKronName + " Distance in Meters: " + _targetDistance);
CheckIfHoloSpawned(HoloKronName, stageStartCoords, missionCoords, primary, Goal);
}
}
else
{
}
}
}
else
{
if (_targetDistance <= 50 && OrXHoloKron.instance.checking)
{
OrXHoloKron.instance.checking = false;if (!OrXHoloKron.instance.bdaChallenge)
{
OrXHoloKron.instance.OrXHCGUIEnabled = false;
OrXHoloKron.instance.MainMenu();
}
}
}
}
else
{
if (OrXHoloKron.instance.bdaChallenge && !_airsupportSpawned)
{
try
{
bool _continue = false;List<Vessel>.Enumerator _playerVessels = OrXVesselLog.instance._playerCraft.GetEnumerator();
while (_playerVessels.MoveNext())
{
if (_playerVessels.Current != null)
{
if (_targetDistance <= 60000)
{
if (_playerVessels.Current.altitude >= _playerVessels.Current.radarAltitude)
{
if (_playerVessels.Current.radarAltitude >= _targetDistance / 100)
{
_randomSpawned = true;
_continue = true;
}
}
else
{
if (_playerVessels.Current.altitude >= _targetDistance / 100)
{
_randomSpawned = true;
_continue = true;
}}
}
else
{
if (OrXSpawnHoloKron.instance._interceptorCount != 0 && !_randomSpawned)
{
if (_targetDistance <= 100000)
{
double spawnChance;if (_playerVessels.Current.altitude >= _playerVessels.Current.radarAltitude)
{
spawnChance = (((100000 - _targetDistance) / 10000) * OrXSpawnHoloKron.instance._interceptorCount) * 500;
if (_playerVessels.Current.radarAltitude <= spawnChance)
{
_continue = true;
}
}
else
{
spawnChance = (((100000 - _targetDistance) / 10000) * OrXSpawnHoloKron.instance._interceptorCount) * 500;
if (_playerVessels.Current.altitude <= spawnChance)
{
_continue = true;
}
}
}
}
}
}
}
_playerVessels.Dispose();if (_continue)
{
if (!_randomSpawned)
{
_randomSpawned = true;
OrXLog.instance.DebugLog("[OrX Target Distance - Spawn Random Air Support] === TARGET Distance in Meters: " + _targetDistance);
_wmActivateDelay = (100000 - ((float)_targetDistance)) * 2;
OrXSpawnHoloKron.instance.SpawnRandomAirSupport(_wmActivateDelay);
}
else
{
OrXLog.instance.DebugLog("[OrX Target Distance - Spawn Air Support] === TARGET Distance in Meters: " + _targetDistance);
_airsupportSpawned = true;
_wmActivateDelay = 60000 - ((float)_targetDistance);
OrXSpawnHoloKron.instance.SpawnAirSupport(false, true, HoloKronName, new Vector3d(), _wmActivateDelay);
}
}
}
catch { }
}
}So what you were saying above, just so that I understand, is I need to take the active vessel coordinates (lat, lon, alt) as well as the mission coordinates and convert them from the coordinates as reported by the vessel (FlightGlobals.ActiveVessel.latitude for example) and convert them using this (I have the altitude plus radius of the celestial body already):
double latRad1 = latDeg1 * Math.PI / 180.0; double latRad2 = latDeg2 * Math.PI / 180.0; double lonRad1 = lonDeg1 * Math.PI / 180.0; double lonRad2 = lonDeg2 * Math.PI / 180.0;
And then do this:
double cylindricalR1 = r1 * Math.cos(latRad1); double cylindricalR2 = r2 * Math.cos(latRad2); double x1 = cylindricalR1 * Math.cos(lonRad1); double x2 = cylindricalR2 * Math.cos(lonRad2); double y1 = cylindricalR1 * Math.sin(lonRad1); double y2 = cylindricalR2 * Math.sin(lonRad2); double z1 = r1 * Math.sin(latRad1); double z2 = r2 * Math.sin(latRad2);
and then I do the math I am doing in my code above ... Swapping the mission coordinates and active vessel coordinates with the converted coordinates?
-
1 hour ago, Pds314 said:
Junos should be able to get you to pretty insane speeds. I would think more than ~85 m/s. Considering that even a single Juno can make an aerodynamically optimized aircraft reach like mach 2 and a completely unoptimized one reach mach 0.7. A pickup won't have as good drag coefficient but still.
Yes, Junos can get to pretty insane speeds across the ground ... I routinely hit over 100 m/s with 2 pushing 8 tons on 8 wheels
@Pds314 I just saw your post with your time, did you have a start picture for the timing so I can put it on the scoreboard?
EDIT: disregard that, I just realized that you startedthe race as soon as you spawned ... I'll post your mission time
-
7 minutes ago, ChaoticPheonix said:
My only issue with OrX has been the craft blowing up when I try and start the race. It only happens with my big rally truck entered on page 1, and not anything smaller.
Do you have a bunch of clipped parts and is your CoM for the craft close to the ground or really high up off the ground? ... If you could, PM me a KSP.log from a session where this happens (it would help substantially)
Could very well be the repositioning of the craft during start that is going bonkers by moving your craft to the start position but due to the CoM being so high off the ground it moves the craft with some of its parts in the ground causing it to go boom
I'll have to fix that
And sorry @Triop and everyone else, I didn't want this thread to turn into a support thread for OrX K ... I will put a warning in the OP and if others here do use OrX K and have issues please post in the OrX K thread so we can keep this thread more focused on the race instead of my mistakes
-
5 hours ago, Dragon01 said:
They're flipping because physics. Someone mentioned 80m/s. None of you probably realized (courtesy of lousy ground textures) that it's 288kph (or 179mph, for the metrically challenged). This is how fast F1 racers go. Those cars have a whole array of aerodynamics designed solely to keep them on the ground, especially in corners. There's a video of one, upon leaving another car's aerodynamic wake, lifting off, flipping over a few times like a badly designed KSP airplane, and landing in the bushes. It was probably going at something around 80m/s. In aviation terms, that's 155 knots, the landing speed of a mostly unloaded F-16, or ten knots below the maximum speed a Cessna. TL;DR: Yer going too fast!
If you were to be going at highway speeds, you're looking at driving at 30-40m/s. I once charged down a mostly straight highway at 47m/s, on a very urgent business. It wasn't very legal, but I knew that highway well enough, traffic was light and it got me where I was going, (barely) on time. That's about as fast as you can drive safely in a car on that particular highway, provided you have a good engine, good brakes, good road and a good idea of what's ahead. You're all trying not only trying to do that much over grass, sand and rocks, but you're trying to turn at this speed. Without analog steering, no less. People regularly fly off the road at much lower speeds.
The problem with KSP is that driving at 10-20m/s gets you nowhere, and there's no stock way to automate the rovers. Wheels are all right, not perfect, but they do work if used as intended.
^^ This
I have a few rovers I use for racing on Kerbin and I routinely reach speeds of over 100 m/s (360 kph / 223 mph) ... the only reason they are the least bit stable and stay on the ground (for the most part) is due to the aerodynamics (and of course reaction wheels
)
-
11 hours ago, QF9E said:
@DoctorDavinci: Not sure why but the stage 1 finish flag isn't visible for me. I've driven multiple times over the approximate point where the flag should be according to other posts , but the stage does not finish. Meanwhile, the holokron icon seems to have moved over to the Stage 1 start point.
I'm using KSP 1.8.1.2694 64 bits on Windows 10 with Making History but without Breaking Ground. Contents of GameData folder (which, if I am not mistaken, gives a list of all installed mods):
The route itself is very enjoyable. Needless to say my solar racing car is not the most durable one out there and it was quite a challenge to get it to the finish in one piece. Awesome work designing the track!
The timer not stopping is odd and a detailed report of your time should appear ... I guess that is broken somehow (I have a suspicion that it has something to do with terrain detail ... different terrain detail settings will cause the Kerbin terrain altitude to change)
I didn't take the above into account although not exactly sure if that is the issue ... KSP.log would help substantially in figuring this out
As for the stage flags not appearing, you need to use the save game from the OP
8 hours ago, QF9E said:Some other bugs in OrX:
* Sometimes the Holokron does not appear after spawning on the Dessert Airfield and opening Stage 1. When this happens it seems that starting the race is impossible. Reloading, resetting OrX and trying again sometimes solves the issue but sometimes multiple reloads are necessary to get the holokron to appear.
* Sometimes my car gets destroyed when OrX places it on the starting position. It seems that in these cases OrX spawns the car beneath the surface. It also seems that some of the pieces of my car get displaced, but if this is OrX or a consequence of spawning beneath the surface isn't clear to me.
* If you are thrown out of the car the Holokron disappears. Running after my car and getting in did not return it. I haven't been able to find a way to continue the race when this happened. OrX only allows me to restart the stage but that is not what I would want in such cases.
My conclusion is that OrX is not yet mature enough to handle this Dakar challenge, at least not for me and my KSP setup. I might try again using the savegame method.
I'm suspecting the same issue as mentioned above .. regardless, something isn't right and I need to figure it out and fix it
I didn't know that the start location is at the desert airfield and I suspect that terrain height is the culprit as the holokron would be trying to spawn at the altitude it was saved at and if there is something above that altitude, the model of the airfield perhaps, then it would likely crash through the terrain and explode .. I'll have to add in some code to account for the terrain height for above as well as for any models etc.. as explained above
As for the being thrown from your car, that is how the OrX K Outlaw Racing challenge type was set up (so that the challenge would stop if the active vessel changes after the challenge had started) ... I can change that and put in a button instead to stop the challenge, although I'll likely make it a select-able option in the challenge builder so that a creator can select whether they want challengers to be able to switch vehicles (that was the original purpose ... to prevent spawning a new vessel in the middle of a challenge)
3 hours ago, klond said:Mod failed to stop timer so I'm using this photo here at a full stop
I'm thinking the same as above in regards to the terrain height ... the holokron is spawning under the ground which makes it too far away to detect that a challenger has passed through the gate ... I know the holokron spawned since it is what actually spawns the stage gate when you're 800 meters out
I think I'll do away with a holokron spawning at the finish line and just make the gate do the timing
----------------------------------------------------------------------------------------------------------------------------------------------------------------
I'll post your guys/gals/others times to the OP when I get a chance to sit down at my computer ... if you decide to continue with using OrX I would love to see the KSP.log after each stage as well as some info on your sytems and KSP settings as it will help me figure out exactly where I screwed up
(if you end up having the KSP.log it would be greatly appreciated if you could post a dropbox or other link in the ORX K thread so I can take a look at it and fix it)
-
-
-
7 minutes ago, fulgur said:
So how do you work out the error? Am I doing it wrong? Because an error of 200m every 25000m is an error of 0.008, which is more than 0.00000001 or whatever your figure was.
the error factor given is in degrees, not distance
The error in distance will depend on how many meters is in a degree at the given altitude
-
3 hours ago, fulgur said:
When did you say that?
Also the error from your own example was 0.008! (0.2km divided by 25km).I didn't say it, I assumed it was a given that those reading this thread would realize that is the case ... my bad
3 hours ago, fulgur said:As well as this there is a difference in lat/long depending on altitude, because lat/long are based on degrees and that changes depending on altitude:
Here you can see the extra distance.
There is not a difference in lat/long, it's actually a difference in how many meters are in a degree ... more specifically a difference In degrees per meter of distance at a given altitude
That is what most of the math is for, calculating how many meters are in a degree at a given altitude (I use the higher of the two)
The math isn't wrong, that I am sure of
Still waiting for proof that it is wrong ... any takers @cineboxandrew, @Hotel26?
-
1 hour ago, fulgur said:
Come up with a couple of ways of proving this:
1) If you change all values to floats, does the difference disappear?
2) If there is a difference which goes up with the distance, couldn't you test whether it has an impact on the game by asking the game for a projected Eeloo periapsis for example, and comparing it with the real value (what it says at periapsis)? Unless that's not the error.You said that there is a difference of 0.2m at 25km.
Eeloo's SoI is 1.2*10^8km. Its Pe is 6.7 * 10^10km while Kerbin's Ap is 1.3 * 10^10km. Therefore the shortest distance is 5.4 * 10^10, which is 520 000 000x bigger than 25km.
So the error of 0.2km will be multiplied to 104 000 000 km, or 1.04 * 10^8. This means that if you have a projected closest approach (periapsis) of more than about 16 000 000km, or 1.6 * 10^7, or 16Mm, this error would mean that you miss Eeloo entirely.
This does make the assumption that you have a K-Drive & go straight from Kerbin to Eeloo on the shortest possible path, while Kerbin is at Ap and Eeloo is at Pe. The error would therefore be even bigger at larger distances.
This is easily testable by mounting an Eeloo mission and seeing if there is any difference between projected Pe and actual Pe (or indeed missing the SoI altogether).
You have forgotten that there is a maximum discrepancy of 0.0000001 in the calculations ... meaning there is a maximum distance discrepancy that will limit the error factor
-
17 minutes ago, cineboxandrew said:
It doesn’t work like that, the Pythagorean theorem works on linear directions in cartesian space, not angles in spherical space. If you start at the equator and go 90° east and 90° north, you’re 90° from your starting point, not 127°
Degrees of altitude? What does that even mean? Why are you multiplying the altitude by pi?
This whole set of code will work fine for small angles (see the small angle approximation) but completely fall apart with larger distance in any axis but r, but of course you only tested it in the r axis...
if you want the real formula for distance between points in a spherical coordinate system, look at this stack exchange post
lol
So I am calculating which of the vessels have a higher altitude and using that altitude and adding it to the radius of the celestial body
I then take the latitude of each vessel and through math figure out which has a higher value and also check if the value is negative (I do this for longitude as well)
After calculating those values I have the lengths of the three sides of a right angle triangle ... math much?
Simple math gives me a distance ... where is this wrong?
You do realize that there is more than one way to skin a cat, no? ... meaning there is more than one way to calculate distance between two points in 3D space?
EDIT: Actually there is really only one way to get the hypotenuse of a right angle triangle that I know of ... do you know of other ways, I'd like to know what they are
EDIT 2: Still haven't shown where the math is wrong .... still waiting
-
15 minutes ago, cineboxandrew said:
Honestly not sure where to begin with how wrong this math is
Please, show me where I am wrong ... I beg you
If you know my math is wrong then it should be fairly simple to demonstrate ... meaning you should know where to begin
-
On 1/1/2020 at 4:07 AM, fulgur said:
Ah. So if that is happening, how can it be fixed? KSP runs on Unity.
It's already all there in OrX K ... if they can figure it out that is
Although my code is licensed GPLv3 so they can't touch it
-
1 minute ago, fulgur said:
Could you possibly tell me why my maths is wrong? I'm assuming it is but as I don't know why, perhaps you could enlighten me?
Not being sarcastic.In the case of KSP the issue arises from Unity using float values instead of doubles (which are more precise)
Basically if you have a number that has 15 to 16 decimal places (a double) and then need to convert it to a number that Unity can use (which is a float ... meaning 7 decimal places) you lose a ton of precision
KSP code uses Unity to calculate its vectors and distances which is unable to use doubles (see above)
This causes a discrepancy in the math since, from what I understand, Unity requires any doubles to be converted to floats (7 decimal places instead of 15 to 16)
What is happening, from my perspective, is a truncating effect on vector and distance calculations in the core of KSP due to its code using Unity to do its math instead of doing the math itself
-
Just now, Gargamel said:
Ok guys. The mods are watching this one, as it does bring up some interesting aspects of the game. So stick to the facts and maths, keep any personal references out it.
Thank you for saying this
... Gotta do that again but this time the objective is to not smash into the small pyramid
)
[1.8.1] OrX Kontinuum Development Thread ... Geo-Caching, Scuba Diving, W[ind/S], Challenge Creation and more ......
in KSP1 Mod Development
Posted · Edited by DoctorDavinci
Just a quick FYI in regards to the next release for those interested ... I'll be posting it in a few hours
I have fixed the HoloKron spawning under the ground (this also fixed the scoreboard not showing up at the finish line) - thanx to @QF9Efor the assistance
I also fixed the exploding vessels while placing a challenger if they have a huge craft
Fixed the distance checking .... note to self: math might be right but is it the right math (thanx @Snark)
Added a speedometer that can be toggled to show kilometers per hour or miles per hour
Added an automatic quick save deal that is created when starting a challenge so that if a challenger crashes they can just load the quick save (its named the Holokron name plus ' - START')
Also added a toggle switch to the Boost Flap module to swap the deploy on DLC turbofans - paging @FleshJeb
Couple other minor things too .... release in a few hours, after I do a bit of testing