These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

EVE Technology Lab

 
  • Topic is locked indefinitely.
 

Slack-Eve-Killmail

First post
Author
Previous Topic Next Topic
dimurgos
Laststar Industries Inc.
#1 - 2015-10-23 22:00:09 UTC  |  Edited by: dimurgos
Pride, honour, death, part of any corp or alliance. but how do you let every one see just how great you really are? If you, your corporation, your alliance or your coalition uses slack, the answer may be here. Slack-Eve-Killmail posts your glorious kills and your epic deaths in your corp/alliance/coalition slack channel, alerting, warning, or showing off.

Feel free to use, share, fork, improve, comment, anything, just show off your kills.

Slack-Eve-Killmail
Mr Twinkie
Republic Military School
Minmatar Republic
#2 - 2015-10-25 10:56:40 UTC
Need to find one of these for jabber. Been lazy on teaching myself how to make.one

MAMBA/The-Culture Head of IT

Dramiel - An EVE Bot for Discord

!!Hosted Dramiel Service!!
Romulous Winter
Dark Shadow Syndicate
Blood Drive
#3 - 2015-10-26 23:35:08 UTC
You go Lilith! This has been the coolest thing of our slack channel!!! Thank you!
CCP FoxFour
C C P
C C P Alliance
#4 - 2015-10-29 11:37:54 UTC
That is really awesome! Already seeing a few people use it which is very cool! Something I noticed is that you require the SDE, or part of it anyways. Something to maybe consider is using public CREST for that data. Two options for that:


  1. If you always want to make sure you have all of the data up-to-date then when the application starts it could crawl public CREST. Fetch all the regions, then the constellations, then the solar systems. That way you have it all locally and in whatever format you want really. Then periodically check the version number in the root of CREST. If the version number is different than what you have you can nuke the data and re-fetch it.
  2. Just fetch the data as you need it. This would require a few fetches however since you would need to get the solar system, then constellation, then region. You could cache it locally for a while though.


Option one has the disadvantage of whenever we deploy a new version of EVE, even if the universe data didn't change, you will fetch it all again.

Just something to consider. It would make the installation and maintenance of the application simpler for admins or developers running it.

@CCP_FoxFour // Technical Designer // Team Tech Co

Third-party developer? Check out the official developers site for dev blogs, resources, and more.
CCP FoxFour
C C P
C C P Alliance
#5 - 2015-10-29 11:40:51 UTC  |  Edited by: CCP FoxFour
Oh also you use the XML API for getting the type name of items. I would consider using public CREST again. For example: https://public-crest.eveonline.com/types/458/

JSON just tends to be easier to parse in python than XML and if you make the other change would be more consistent and fewer different APIs being used.

The other advantage with this is you can again check periodically if the version number has changed in the root of CREST. If it has nuke the local cache. Always a chance we rename things over a down time and the application is still running but now with the old name of a type. Rare... but a possibility.

@CCP_FoxFour // Technical Designer // Team Tech Co

Third-party developer? Check out the official developers site for dev blogs, resources, and more.
dimurgos
Laststar Industries Inc.
#6 - 2015-10-29 17:50:17 UTC
Thank you so much for the feedback. To be honest I completely overlooked the public CREST. Couldn't find the system information using the XML api and did find it in the SDE. Changed the code based on your advice. Pulls the region information when required, and caches it afterwards. Will add some code soon to check the CREST version.

Again, thanks! So much neater/easier this way :)
CCP FoxFour
C C P
C C P Alliance
#7 - 2015-10-30 12:22:13 UTC
dimurgos wrote:
Thank you so much for the feedback. To be honest I completely overlooked the public CREST. Couldn't find the system information using the XML api and did find it in the SDE. Changed the code based on your advice. Pulls the region information when required, and caches it afterwards. Will add some code soon to check the CREST version.

Again, thanks! So much neater/easier this way :)


:D Yay! Glad you were able to get it implemented and find it easy to work with. I would really recommend watching this video: https://www.youtube.com/watch?v=QMQOjUjrZIo

Most importantly from it is how versions for CREST work. I noticed you are not sending an accept header. If you don't do that and we release a new version of the resource you will get the new version and since we bump versions because of backwards incompatible changes... bad things could happen. :)

@CCP_FoxFour // Technical Designer // Team Tech Co

Third-party developer? Check out the official developers site for dev blogs, resources, and more.
dimurgos
Laststar Industries Inc.
#8 - 2015-10-30 13:58:12 UTC
Added the accept header. The other recommended items in that video I will have to look at later (and decide how to use it). Going to have to rework parts anyways to make it behave better/cleaner. Thanks :)
CCP FoxFour
C C P
C C P Alliance
#9 - 2015-10-30 14:39:56 UTC
dimurgos wrote:
Added the accept header. The other recommended items in that video I will have to look at later (and decide how to use it). Going to have to rework parts anyways to make it behave better/cleaner. Thanks :)


Hey, it seems you're sending the same accept header for all resource. application/vnd.ccp.eve.Api-v3+json is only for the root of the API. If you check the headers when you request a resource you will see the content type we are actually getting back.

We have some documentation here: https://eveonline-third-party-documentation.readthedocs.org/en/latest/crest/versioning/

For requesting the systems resource you would want to send: application/vnd.ccp.eve.System-v1+json

@CCP_FoxFour // Technical Designer // Team Tech Co

Third-party developer? Check out the official developers site for dev blogs, resources, and more.
dimurgos
Laststar Industries Inc.
#10 - 2015-10-30 15:19:54 UTC  |  Edited by: dimurgos
Lol ok I imagined that you would have one version overall. Just tested it on the root (didn't fully do a test run on every resource). Kinda a challenge to make this work properly I think. Not sure if I am a fan of changing headers per request, you would basically have to know the resource type/version for every path you navigate to (https://public-crest.eveonline.com/solarsystems/31000007/ has for example application/vnd.ccp.eve.System-v1+json; so before navigating to that resource, you have to know its of type System v1). But ok, I will fix it to spec.
XTheGame
Seventeenth Battalion
Honorable Third Party
#11 - 2015-11-03 21:05:50 UTC
First off great app i cant wait to get it working.

I seem to be stuck at attempting to run the payload.

I am getting a Exception in processing record class 'locale . Error'
dimurgos
Laststar Industries Inc.
#12 - 2015-11-03 21:17:11 UTC
I imagine thats related to me using LC_ALL 'en_US' locale for showing the ISK values. So I guess you don't have that installed. Two options would be to actually install en_US locale or, change the line with locale.setlocale(locale.LC_ALL,'en_US') to a locale you actually have.
XTheGame
Seventeenth Battalion
Honorable Third Party
#13 - 2015-11-03 21:23:50 UTC
dimurgos wrote:
I imagine thats related to me using LC_ALL 'en_US' locale for showing the ISK values. So I guess you don't have that installed. Two options would be to actually install en_US locale or, change the line with locale.setlocale(locale.LC_ALL,'en_US') to a locale you actually have.



Wow thanks for replying so fast =D. Now when you mean install en_US locale can you explain that to me. I am using a windows server 2012 VM. I checked both of my language and region locales they are set to English (US)
dimurgos
Laststar Industries Inc.
#14 - 2015-11-03 21:34:11 UTC
Never actually worked with python on windows, apparently they use different locale names. From what I can tell eng_US should work, but, maybe easier would be to change the line I previously mentioned to '' instead of any value. It should take your default locale.
XTheGame
Seventeenth Battalion
Honorable Third Party
#15 - 2015-11-03 21:38:42 UTC
dimurgos wrote:
Never actually worked with python on windows, apparently they use different locale names. From what I can tell eng_US should work, but, maybe easier would be to change the line I previously mentioned to '' instead of any value. It should take your default locale.



I changed the locale to eng_US now its giving me a exceptions.IOError

Im guessing i should just load up a ubuntu VM and install it there, might just be easier.
XTheGame
Seventeenth Battalion
Honorable Third Party
#16 - 2015-11-03 21:47:35 UTC
dimurgos wrote:
Never actually worked with python on windows, apparently they use different locale names. From what I can tell eng_US should work, but, maybe easier would be to change the line I previously mentioned to '' instead of any value. It should take your default locale.


Just to update tried in a ubuntu 14.04 server i am now getting a exceptions.IOError
dimurgos
Laststar Industries Inc.
#17 - 2015-11-03 21:54:49 UTC  |  Edited by: dimurgos
And I just realised it requires the following file in the directory: 'handled_kills.dat' *pushing a change as I post this*.

Just an empty file with that name (that is writable) is enough.
XTheGame
Seventeenth Battalion
Honorable Third Party
#18 - 2015-11-04 13:29:39 UTC
dimurgos wrote:
And I just realised it requires the following file in the directory: 'handled_kills.dat' *pushing a change as I post this*.

Just an empty file with that name (that is writable) is enough.



Thanks for your hard work everything is working great.