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

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

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

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) 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

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 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 ) ^^ 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 )

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

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

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

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) 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?

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

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

^^ 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 )

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 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) 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)

@Snarkthat actually clarifies a fair bit ... math is right but as @Kerbartmentioned, is it the right math I missed a step Your response is much appreciated ... thanx

http://pi.math.cornell.edu/~mec/Summer2008/Jones/sphere.htm

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

I didn't say it, I assumed it was a given that those reading this thread would realize that is the case ... my bad 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?

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

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

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

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

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

Thank you for saying this