Chipping away at it in my downtime! I have managed to separate the code from one big script into a bunch of smaller scripts to allow for some code isolation – this will let bits and pieces be worked on without impacting the whole (hopefully!). I’ve also managed to put together a preliminary basic example of how some of this might be used and at the same time finding a bug in the bearing calculator – which I’m positive I’d already fixed once before, but in a different project (hence why it’s important to put reusable code in a library). Let’s take a look at one of the functions, and, the example code.
CBD – Coordinates from Bearing and Distance
This is one of my favourites as it let’s you calculate the position of another point (or object) provided you know the start coordinates, and a bearing and distance to the new point.
Above is the entire code for calculating these coordinates. As you can see it does rely on two other functions from the .commonCalculations script, which is really the guts of the module, containing the reusable code that powers these smaller functions. Ie; using the bearing and distance to calculate the differences in Easting, Northings, and Elevation and then using these coordinates to produce new coordinates.
Simple Artillery game, place guns at two random sets of coordinates. player1 enters a bearing and distance to fire at player2 coordinates from bearing and distance are used to calculate where the round falls. bearing and distance from coordinates are used to plot how far away the round has fallen from player two. if the round is within [x] metres, it’s a kill. otherwise some approximate corrections are sent to player1 to aid in adjusting for the next round (if they’re still alive!)
I won’t break the demo code down, it’s already commented throughout so there i no point.
When I originally created my coordinates script, it was never intended to be used more than once let alone turned into a library – there is some tidy up work that needs to be done to make the code consistent which I’m addressing along the way. The biggest inconsistency however, is the one I introduced yesterday 😛 To begin with, the returns were all arrays with not a lot of information other than the expected order they were returned
In the above code block, you can see how this would not have been very helpful at all. Wanting to be able to program this for Python, and have outputs that could be exported as JSON and then utilized in other languages / platforms, I have started to switch the returned output to Python Dictionaries. Of course playing around now with what is best, what is consistent, what would the user expect, then conducting the refactor – has been a bit fiddly. I have settled on the below, with the dictionary keys being held in a config file so should I need to change these later, it won’t be a problem (hopefully!)
The next job to tackle shouldn’t take too long, I’ll be finding and fixing the bug in the BFD – bearings from deltas code. I think the last time I did this it was jsut a complete re-write (see if you can beat me to it!). And I’ll be doing some more work on the overall structure of the module in preparation for uploading Rev01.