Development Log Week 114

While Martin's current workload doesn't allow for much PU development, Michi keeps on improving the flight model of spaceships in the game - despite some roadblocks!

Martin

Sorry, this is going to be super short: While I was hoping to have more time for PU this week, critical customer work just keeps on pouring in. I got started on a little bit of prep-work for the upcoming notification feature (which Michi has already talked about on the forums a while back) but that's about it.

Michi

Last week I wrote about how and why we are changing how the faster than light travel works in Prosperous Universe. This week I can report that I managed to get at least one major part of it done: the departure segment!

To visualize the departure segment I created a new marker on the map which reflects the jump point. The route to this jump point is highlighted like any system route:

I didn't do too much to visualize the route and jump point since the maps are due to a major graphical overhaul anyways and it felt like I would be doing things we change later on anyways. The important part of this segment was the calculation of the route to the jump point.

I also want to share a little programming anecdote. When I implemented the calculation of the jump point location and route I noticed that some routes where perfectly fine, others where off for several million kilometers and some wouldn't calculate at all. I spent almost a whole day trying to figure out what was wrong. It had to be something I was working on currently since route calculation did work before.

So I dug deeper and deeper and at some point I extracted the data to write some unit tests with it to be able to track down the error faster but to no avail. In a desperate attempt I took the data of a route that was failing and wrote a unit test on the server, which also does the route calculation to verify the data coming from the client. To my big surprise the route calculation was successful on the server. After stepping through the code line for line on the client and server I discover that this line

let alpha = f1f2.angleTo(this._xAxis);

resulted in different values on the client and server. On the server we use a different math package than on the client and it seems like the two have different understanding on what "angle to" means. After a quick look into the libraries I found out that the client side library was doing it wrong. Instead of going in a counterclockwise direction and measuring the angle it just returns the shortest angle between the two which results in errors in the route calculation.

I replaced the angleTo function on the client with my own implementation and voilá: everything worked as it should. Hunting these kinds of bugs can be so frustrating but now I am happy that I can continue my work on this feature!

As always: we'd love to hear what you think: join us on the forums!

Happy trading!