zcamp

skills used:

• python
• javascript
• svelte
• webhooks
• sql

Project code (original python tool)

Project code for Zcamp

Zcamp for Eve Online

The zCamp project started as a way to create an alarm to locate officer NPCs that killed players. An officer NPC in EVE Online is the rarest enemy, and their item drops can be some of the most valuable items in the game universe. The goal was to hopefully reach these unsuspecting players before they had realized what had happened. They are also quite difficult to defeat, so it was not unreasonable to assume that they may still be at the location long after the player had died.

Firstly, I took the available websocket provided by the player run service zkillboard.com. Then I created my own filter rules with Python and a Tkinter GUI, allowing for more fine grained control like item type and ship grouping for the live feed. Zkillboard allows you to filter on past results, but the live feed of results was not able to be filtered on, furthmore there was no way to set a notification if a new player loss appeared. My tool achieved both these aims, and I was shocked to find not one, but two officer NPC losses the next morning.

After several days of analysis and multiple officer NPCs destroying players, I realized that there was a connection. The ships were all the same, and the their loadouts were nearly identical. They were drone boats, which are one of the few weapon systems in the game that will automatically attack targets without cheating. I realized that there was a large, organized effort to farm the rarest NPCs in the game, which up until that point I’d thought were purely random.

Coincidentally, around the same time, a Russian youtuber began posting videos about farming officer NPCs in EVE Online. He found that the probability for an officer to spawn was exactly 0.001% and not based on random factors. This means that if a player destroys 1000 waves of NPCs (which respawn every 30 minutes), there is a guarantee that an officer NPC will spawn. This took away a bit of the mystery for me surrounding officer NPCs in general, and led to be seeing what other usescases I could create using the killmail data from zKillboard.

---

I noticed that every killmail has an exact coordinate point in the system that determines the nearby celestials. After doing some digging I was able to find a file that CCP games provides to the community that has the exact coordinate points of every celestial and object in the game. This got me excited, as I realized then that I could completely rebuild the universe’s game map in my application, which has a lot of implications!

• I can track paths for groups of players as they transition from system to system
• I can warn players when systems that are about to travel into have specific hostile activity, essentially creating a tool that allows you to travel through the game without worrying about gate camps (blockades set up by other players to kill players when they enter a new region).
• I can make a sick visualization that shows live activity through the game
• I can calculate routes and display them in my version of the game map, and use the CCP Games API to set that destination in the game for player, along with waypoints. This way the player can create a risk-free route ingame through my application, avoiding all active gate camps.

I mentioned what I could do to the creator of zKillboard, and was a bit surprised by the lack of interest. In particular, the ability track gangs as they traveling and the route warning tool seemed particularily valuable. He did give me a useful bit of advice regarding the application itself. He said that players don’t trust software that you have to download, so it would be best if I turned it into a web application. That’s exactly what I did next.

Not having a solid grasp of typescript yet, I decided to keep this as simple as possibly and just use JavaScript, which I was most familiar with. For the frontend, I’d heard a lot of good things about Svelte recently, so I decided to use that.

I tested a couple of different hosting providers, but I was doing a ton of pulling and pushing, so I burned right through the trial period of Railway, which was a great app and dev service, just way too expensive! I ended up picking Hetnzer for the cloud hosting because of its excellent pricing (better than AWS, Azure, all these other ones), it was also located nearby in Germany and had a discount with the trial for the service I was setting up, Coolify. Coolify made it effortless to constantly fetch and deploy my docker containers and allowed me host multiple web services and databases on a single shared instance for only $10 per month. On top of that all, Coolify was free and open source. I highly recommend it for quick prototyping as an alternative to tools like Firebase that require vendor lock in and high prices. As far as I know, there is no better budget option.

After several months of development work, I had several new features working in my tool

1. A minigame called “campcrushers” to get rewards for attempting to or succeeding in the destruction of gatecamps

• Players earn points for having their kill id appear on the killmail of the gatecampers
• Points are permanently recorded in the Postgresl database and used to generate a leaderboard
• Users can share their points counter in their eve profile using a unique profile page in zCamp created with an autogenerated, permanent url.

1. A live feed of the parsed killmails that allow the user to filter in real time against all the killmails in the last 24 hours as the feed continues to update.

• Users can set alerts for audio notifications when a kill makes it past their filters
• Users can set a discord webhook, if a kill makes it past their filters it will notify them in discord.
• Users can create and save permanent profiles of their settings to quickly load them next time they log in.

1. A bubble map where bubbles appear to inflate based on kills in the last 5 minutes, showing all active battles as they happen and die out in the game. The bubbles change color based on whether they are about to pop.

1. Salvage fields. Filters are applied to show the user where kills have occurred in the last two hours (before a wreck expires) with ships that are tech level 2, meaning they drop extra loot when salvaged, where T1 drop next to nothing.

1. An officers, belt commanders, and mordus legion detector that notifies the user if a player dies to these unique, rare npcs.

1. The solar system map that allows the user to see the point of the kill in relation to all the celestials in the star system, rendered in beautiful 3D with their orbit paths using ThreeJS.

2. Triangulator minigame: A way to find the player wrecks without a bookmark.

   • Using several mathematical calculations we determine whether the point of a killmark exists within four celestial bodies. If the point exists, then we enrich the killmail data with the coordinate points of the closest celestials it exists between. Based on this information, the user can warp between the four points placing bookmarks at closer and closer intervals until eventually they reach the wreck itself and can loot or salvage it. My friends and I had a lot of fun doing this and made several billion isk pretty quickly. If you message the person in advance, a lot of times they will tell you if they can’t reach the wreck.
   • Players often don’t expect someone to be able to reach the wreck at all, so if you are quick you could also steal it from them while the site is still active.

1. The real time global activity map showing live fights, active roam paths, and a lot more! The map is rendered in full 3D using ThreeJs, then flattened into regions for easier viewing. It was a bit difficult to tell where things were happening otherwise.
   • The user can set the destination in the map and add waypoints
   • If there is hostile activity along the route, it will notify them.

1. Live tracking of the user as they traverse though the game world.
   • For each system change, we can ping the EVE Online API to retrieve the user’s live location in the game world. We can compare the user’s current system against our rendered map to determine all possible gates they could be jumping into and warn them if there is an enemy on the other side.

1. Naturally, for these features to work we had to find a way to bind it all to the player Oauth login with EVE Online
   • Each login is paired with a unique code that is used for API calls and to keep track of the player account in our local database.
   • Features like minigames and profiles only start working after you’ve logged in.

To reduce the potential of bot spam I added a cloudflare check screen that appears when you first visit the application. I intend to remove this because it adds too much of a wait when users first try to visit the application.

[wip]