Talk Unafraid

OK, here’s an idea I’ve really been too snowed under with real projects to play around with. If you want to implement it go ahead; you’ve got a few weeks till I clear my plate and have at it.

In EVE, there’s always been a fairly open market for secrets. Be it market info, inside information on fleets, teamspeak login details, you name it. There’s no real formality to any of this, though; it’s very cloak-and-dagger, and that brings it’s own dangers; misinformation, for example.

My idea was this: Why not have a trading system for secrets? It would allow complete anonymity between spy and spymaster, it would permit a level of security for spies and spymasters not seen before in EVE (Protection against paying for misinformation, for one thing), and it would make being a spy much easier.

In order to protect everyone: Spymasters would have to provide payment in advance to the service (they put up a request for the information they’re looking for). Spies can give a snippet of the intel to show they’re not making it up, and can then be paid by the spymaster. The spy can’t withdraw the ISK for a week after being paid, during which time the spymaster can revoke the payment if the intel proves to be useless.

This would work, because spymasters want to reward good spies, are at no risk from spies providing crap info, and the identity of the spy/spymaster is concealed, reducing the chance of the spy being revealed by their spymaster or by the app being compromised. The only person who would have to know the identifies of the spies/spymasters would be whoever ran the app; a problem for some, perhaps, but if it were run by someone entirely unquestionably reliable and reputable (or simply someone with nothing to gain) it’d be fine.

Many may argue that spies already have it too easy. I’d agree. This still seems like a pretty nifty app idea, though, so I’m throwing it out there for some critique and discussion, and maybe even as an app for developers looking for something to do in the world of  EVE.

Blimey. Twitter has distracted me from actually keeping this blog up to date. Still, better late than never, eh?

Since my last post a lot has happened. Temperatures have risen to record highs, reducing productivity as I persevered to build my own air conditioning on the cheap (which looks like a probable failure, pending a cheap pump). Charactr has managed to produce all sorts of interesting bugs in my inbox, delayed_job has broken in some new and interesting ways, and EVE Metrics 2 development has steamed ahead.

Let’s look at the last one quickly.

So far we’ve gotten most of the basic backend for EM2 done in such a way as to avoid scalability issues as much as possible. We’re using PostgreSQL instead of MySQL, we’re using table partitioning, we’re using an upload processor that does most of the log parsing work with a custom C extension we’ve put together (0.06 seconds as opposed to nearly 2 doing it in Ruby natively), and we’ve added more features and tools for statistics like inferred trade tracking and per-upload statistics.

So, a few things we’re pretty sure will be in EM2 at release:

• Inferred trade statistics and display – We can basically make guesses based on what we see about how much of an item is being bought at what price by observing changing or vanishing orders. It’s not perfect but mostly accurate.
• Performance. Pages will load quickly.
• Better APIs for developers – Including movement, historic price data (same stuff as you can see ingame on the graph tab) and other oft-requested APIs.
• Trade Finder. If you’ve got a hauler, some time, and want to make some ISK, this will tell you the optimal way to do so.
• API integration. You’ll be able to put in your API key to have your market orders autoupdated on the site, optionally fed into the main market display for more accurate data overall, and so on.

Stuff we’re looking to implement but we’re not sure if we’ll have it out in the first version includes Science and Industry integration, Location-based filtering, and so on. We’re also looking at a way to reward uploaders; after all, the site is made accurate by accurate and regularly updated data, and while uploading with EMU isn’t much of a chore we’d like to reward those uploaders who go and upload whole swathes of the market or bits that aren’t so regularly covered, and so on.

The team working on EM2 is more or less at it every day and with Makurid’s determination to make stuff fast, we’re getting scarily close to having a really, really nice framework on which to build some exceedingly powerful tools. So now we’re at the phase where we’re now working out the final feature list, and implementing them. Hopefully we’ll be looking at a release in a few weeks time, assuming nothing goes horribly wrong; watch this space!

Edit: This post was originally titled ‘Too long, new ideas’. Kinda drifted off from my original post and renamed it. Ho hum. New ideas can get talked about later.

For the EVE people reading my blog, probably best to skip this one. If you’re one of my Rails readers, however, then this may interest you.

Charactr has been doing quite well. We originally released it deployed on Apache with Passenger (also known as mod_rails). While the performance was tolerable it wasn’t the snappiest thing in the world, and on a memory-limited VPS even with Ruby Enterprise Edition we were often running into memory limits. Right now however we’re on nginx and thin, the first production environment I’ve used this combination for.

Performance-wise, I’m impressed. Not only is the static asset hosting snappy as anything, but thin handles remarkably well and does it without chewing up much RAM. I’m pretty sure Passenger/REE would win on a box with a few gigs of RAM, but on something this small (540 megs, including the db server on the same box) the extra overhead from Passenger’s spawner was too much.

Configuration is where nginx really wins out, however…

read more…

Well, time to unveil the application that myself, Makurid, flexd and Lilima Zennen have been working on for the past month.

The app is Charactr, a web based skill training monitor and planner with both email and SMS notifications. Go check it out!

The team (MMMetrics) is the same team who will be attacking the problem of EVE Metrics 2. A quick rundown of the features of Charactr:

• Support for as many API keys as you want
• Flexible notification framework
  • Send notifications via text message or email
  • Get notifications on specific characters, accounts, or everything
  • Receive daily summaries, messages before or on completion
• Powerful skill planner
  • ‘New Character’ training speed bonus support
  • Learning skill suggestions
  • Reorder, add and delete skills
  • Training for item/ship
• Secure and fast access anywhere in the world
• SMS messaging to over 750 networks in over 200 countries

Enjoy!

For a project which will be released to the public next weekend and should start appearing on blogs in the next week (and which could be _huge_), we needed the Clickatell gem from Luke Redpath to pass some other parameters to Clickatell to handle our custom sender ID and callback options. I’m not quite sure why, but the original gem filters out all but two of the configuration options you can pass it.

Fortunately, thanks to Ruby we could work around it with a nasty monkeypatch- namely, overriding the method in it’s entirety in environment.rb:

1
2
3
4
5
6
7
8
9
10
11

# Monkeypatch for Clickatell gem to allow callback param
module Clickatell
  class API
    def send_message(recipient, message_text, opts={})
      response = execute_command('sendmsg', 'http',
        {:to => recipient, :text => message_text}.merge(opts)
      )
      parse_response(response)['ID']
    end
  end
end

Not pretty, but it does the job. You can now pass in all the options you need:

1

api.send_message(mobile_number, content, :from => 'SenderID', :callback => 3)

Again, entirely confused as to why the gem filters all options out. I’ll prod Luke Redpath and see if there’s some reason to it, and if there’s not perhaps this can get fixed to avoid the monkeypatching.

There’s a new meme running wild right now that I think is kinda neat.
Basically- where have you been in EVE? Well, here’s my contribution, in slightly-color-adjusted format. Darker color means more visits, or just click on the image for a larger original-color image.

So where do I start with this? Well, how about the beginning. Started down in Khanid, despite being Caldari. Went back up to the area around Verge Vendor/Essence, and about then got involved in 0.0. Before I know it, I’m all the way over in what is now Malpais with my new corpmates in Vanguard Frontiers, and the Invictus alliance. After a while we merged to form IRON, and shortly after that we decided that since TRI weren’t doing much with Deklein we’d have that. Over we go once more, followed by the BoB MAX campaign. That didn’t go too well for us in the long run, and IRON more or less disbanded. We went over to Cloud Ring after that, then moved down to our new home in Wicked Creek where I still live. Where I’ll go from there is anyone’s guess, but I hope that’s in the fairly distant future.

Welcome to the eighth installment of the EVE Blog Banter , the monthly EVE Online blogging extravaganza created by CrazyKinux. The EVE Blog Banter involves an enthusiastic group of gaming bloggers, a common topic within the realm of EVE Online, and a week to post articles pertaining to the said topic. The resulting articles can either be short or quite extensive, either funny or dead serious, but are always a great fun to read! Any questions about the EVE Blog Banter should be directed here . Check out other EVE Blog Banter articles at the bottom of this post!

This month’s topic comes to us from me, Ga’len at The Wandering Druid of Tranquility. He asks: “What new game mechanic or mechanics would you like to see created and brought into the EVE Online universe and how would this be incorporated into the current game universe? Be specific and give details, this is not meant to be a ‘nerf this, boost my game play’ post like we see on the EVE forums.”

I do plenty of spying, intelligence wargames and so on in EVE. It’s more or less impossible not to be involved with this when you’re embroiled in alliance politics and warfare. Yet it more or less all has to happen out of game or requires a certain amount of metagaming to achieve.

What I’d love to see in EVE would be physical manifestation of communications.

Let’s face it, EVE’s communications are something of a mystery when it comes down to the actual implementation in the universe. Let’s say we add some new objects to the world: relay stations. Systems could have a few relay stations each that connected them to the outside world- think of them as stargates for your evemails and conversations. The number of relay stations and the defensive capability of the stations could vary depending on the system. Highsec systems could be CONCORD-protected, multi-honed systems. Lowsec would be poorly defended and have 1-3 relays. Nullsec could have 0-n relays, where the number depends on how many are deployed by the system’s owners. NPC nullsec and so on could have poorly defended relays preplaced- anywhere should have relays except player-controlled space.

And of course to make life a little easier for the next bit of my grand plan, let’s say if you have more than one relay you also need a router to link the relays together.

So now let’s review the use cases: I’m a spy who wants to listen in on an enemy fleet’s chatter. I fly up to a relay cloaked, use a module on the relay, and am rewarded with a realtime display of their fleet chat. Or alliance chat, or more or less any other chat that is taking place on that relay. If a person talking in a chat is in that system using that relay, then I could potentially listen in on that chat. Upgrades could permit chats to be secured but not to the extent where it is impossible to view them. Perhaps garble some of the text or require a decryption delay. Routers would be harder to tap and better defended but would provide an entry point into an entire system’s chatter.

What would this mean for the average pilot? Very little. Local chat would remain public through ship-to-ship broadcasts, but if you’re in a system with no relay operational (We’ll assume relays could be destroyed or disabled through some means, but not easily) then your other chats become unusable- you’re off the network. EVEmail would stop updating and you wouldn’t be able to send anything. And, of course, fleet chat would only work within one system.

Right now spies use out of game techniques to achieve this same level of network penetration, be it a spy in fleet running a program to monitor and upload chat logs in realtime, or simply relaying back chat that matters. Of course, Teamspeak/Ventrilo security can’t be tackled in this manner (ingame) but by providing people with tools to do their spying ingame without entirely breaking immersion, CCP could perhaps ground the practice of spying a little better in the ingame world.

It’d take a lot of work to implement something like this but the reward would be tangible and really change the world of EVE for the better imo. Removing the idea of untappable and reliable communications and replacing it with something no more reliable than an O2 mobile near my house would make the whole world experience a little more on-edge and a little less comfortable. And in EVE, that’s how we like it.

I spent a few hours yesterday and today poking around Battleclinic’s killboard. Say ‘Battleclinic’ or ‘Griefwatch’ to anyone considering themselves a web developer or EVE third-party dev and you’ll probably receive a derisive snort or a simple laugh; it may have a lot of data, but the interface is pretty horrific. And I mean horrific. In the course of my prodding, I noticed that the kill detail page- the page that shows a single kill related to a character- doesn’t actually list a date or time for the kill.

Now, that’s pretty important information. If I’m looking through BC to see someone’s kills, I’d like to see when those kills were. Say I’m crawling it for a corporate applicant’s kills- if the kills were a few years ago I don’t care about them as much as if they were last week. So, me being me, I looked around to work out how to file a bug report. Their forums looked like the place, so I registered with a non-me username and a mailinator address. I’m not a huge fan of spam so I try and keep my real email restricted to people rather than automatons.

All going well so far. I browsed to the ‘Bugs’ forum and made a new thread, then went to get a mug of tea. Then it got interesting. read more…

Woo, time for a purely Ruby/Rails post. I’ve not done one in a while, so here goes.

In EVE Metrics 2.0 I’ve been looking to replace the previous delayed_job system with a more robust and fault-tolerant system. A while ago I attended the Ruby Manor conference, and saw an excellent talk on Nanite by George Palmer. It’s a very neat way of doing background processing- it depends on a mapper, agents and actors. Agents have many actors and announce their presence to the mapper regularly along with (by default) system load info, and the mapper then sends jobs to the least loaded agent which supports a given actor. It also works on AMPQ, and by default the RabbitMQ server, a very high performance queue server written in Erlang. It’s fast enough that you can stream video over it quite well, apparently, and it scales well with large queues, so should fit the bill nicely for EVE Metrics.

Getting started, however, can be kinda tricky. So here’s the simple ‘getting started’ that is sadly absent from the Nanite documentation.

read more…

I’m going to get this survey out so people can start posting away as soon as possible – if you use EVE Metrics or would do if it supported a dream feature or did something better, now’s the time to help improve it.

read more…