Working on unbitrotting the rest of the guild endpoints for dumping the event log (which contains info to track treasury donations) and stash contents, as well as adding stuff to track the current treasury status.
A lot of my members have the join date as null. I’m guessing that’s because this was only tracked after a certain date and those people joined before that date.
What is that date?
“I’m not a PvE, WvW, or PvP player – I am a Guild Wars 2 player”
Tarnished Coast – Dissentient [DIS]
All classes
A lot of my members have the join date as null. I’m guessing that’s because this was only tracked after a certain date and those people joined before that date.
What is that date?
Looks like the change that added join time tracking was integrated into the live branch on March 19, 2013. Usually once something’s on the live branch it’s live in a matter of days, but I’m not sure where the deploy logs live (or how to query them) so I’m not sure I can get more accurate than that.
Is there any chance we’ll be able to see the online/offline status of guild members on the roster through the API? I’d love to create a graph to see peak activity times.
Is there any chance we’ll be able to see the online/offline status of guild members on the roster through the API? I’d love to create a graph to see peak activity times.
Seems reasonable. Created a github issue for this.
Going out on a limb and think he is referring to it not being localized into, say German.
Not sure if its normal to localize these though, seeing as they look like property strings and not actual text strings.
On an unrelated note, how goes the unbitrotting of the rest of the guild API? Any ETA?
Eh, ran into some minor technical issues with exposing the event log but everything else is coming along. Not planning on releasing anything else this year (this is the last week before our holiday break), but I’m hoping to turn on the treasury and stash bits sometime in January.
> Any chance we can get Last Login added to the members list?
Ideally also if they are repping the guild or not, so perhaps three states: Repping, NotRepping and Offline. If that isn’t possible maybe a Last Rep date on top of the last log in?
So, already put a bit of a thing together authenticating Slack signups based on the members API (I’m very very lucky to have Liss in my guild ). Please tell me if you are able to break this so I can fix it: http://gw2mathhammer.com/slack.html
I almost feel guilty asking for a feature request cause everything’s so awesome but…
Is there any chance we could have the upgrades list the vendors they come from? I’ve got guild-aggregated list from a few people (http://gw2mathhammer.com/js/aetherium/upgradedata.js), but I would love to be able to pull from the API instead of crowd-sourcing guildies. Categories/vendors make it a bit unmanageable though.
Any chance we can get Last Login added to the members list?
Ideally also if they are repping the guild or not, so perhaps three states: Repping, NotRepping and Offline. If that isn’t possible maybe a Last Rep date on top of the last log in?
Can definitely look into it. If the rep status is on there, it’ll definitely be separate from the online/offline field — the tristate doesn’t support the “offline but repping” pair. I’m pretty sure last rep date isn’t tracked on the backend though, so that likely won’t be in there (might be wrong).
Is there any chance we could have the upgrades list the vendors they come from? I’ve got guild-aggregated list from a few people (http://gw2mathhammer.com/js/aetherium/upgradedata.js), but I would love to be able to pull from the API instead of crowd-sourcing guildies. Categories/vendors make it a bit unmanageable though.
IIRC when I looked into exposing vendor data in general awhile back it was totally infeasible — the way it works is that there’s a generic “open vendor $id” script command so to only show accessible vendors the backend would have to figure out which scripts it was possible for a player to trigger. A lot of them are pretty easy to figure out since they’re usually tied to dialog options, but there’s a both a handful of debug-only dialogs that you’ll never see as a player, and a handful of vendors that aren’t accessible via dialogs (e.g., the ecto gambling one that you open with an item).
Anyway, the implementation on both our sides would be the same — a hardcoded list. In cases like that I think it’s better to keep it on the application side since you guys can move faster if/when the hardcoded list changes/breaks.
It must not be hardcoded. We are able to check the prerequisites of each upgrade and compare them with the IDs of the “vendor upgrades”. For example the “Guild Armorer 1” (ID 38) has 350 as prerequisite. 350 is the “Market Restoration 1”, so we know the Guild Armorer is part of the Market. Sometimes we must check the prerequisite of the prerequisite to get the “vendor upgrade”, but this technique totally worked for me. The only exception is the “Further Exploration” (ID 641) which has the Tavern as prerequisite but a special vendor. The only hardcoded part are the IDs of the “vendor upgrades” but all other upgrades are modifiable.
It must not be hardcoded. We are able to check the prerequisites of each upgrade and compare them with the IDs of the “vendor upgrades”.
Right, but determining which upgrade vendors are player-accessible is an exceptionally difficult problem — without pulling in a whole bunch of dependencies (e.g., large parts of the game logic) the implementation would just be a whitelist of “these vendors are player-accessible, look at their upgrade lists to determine which vendor sells which upgrades”.
Following up on the “vendorlist” that Holox asked for, are there any upgrades in any of the branches that requires an upgrade from another one, and later on in the tree its the other way around? Kind of hard to explain, but going to try:
Say you have two branches, the tavern and the workshop.
Say an upgrade in the workshop branch requires Tavern 1. You create Tavern 1 and subsequently the workshop upgrade. Then later on when you want to unlock an upgrade in the tavern branch, you see that it requires Workshop 2.
This leaves the two branches with quite high coupling. Are there any upgrades like that or any plans to add this?
On another note though, are there any way to traverse the tree downwards, or do I have to find the first upgrade, then loop through every upgrade and see if the one I found is a requirement? Otherwise just keeping an internal list and adding to that every time a new upgrade is available?
This leaves the two branches with quite high coupling. Are there any upgrades like that or any plans to add this?
So, I just tossed together an upgrade tree visualization thing with vis.js: warning may crash browser (source). Probably want to open it with Chrome because Firefox is choking on it a bit for me.
The per-vendor trees basically start at each of the “Restoration 1” upgrades; from the visualization it doesn’t seem like there’s any coupling at all between the trees. They’re all currently self-contained, though it’s technologically possible for a new upgrade to have cross-tree prerequisites. I don’t work on the game so I have no idea what our future plans are, this is just idle speculation.
Anyway, I’m not very knowledgeable about the upgrade tree; you’re better off having a gander at the data yourself.
On another note though, are there any way to traverse the tree downwards, or do I have to find the first upgrade, then loop through every upgrade and see if the one I found is a requirement? Otherwise just keeping an internal list and adding to that every time a new upgrade is available?
IMO the easiest way is to just fetch all upgrades with the first request (via ?ids=all), then delinearize the objects into either a tree or an edge table. vis.js wants an edge table, so that’s what I’ve done in the example. But yeah, you basically have to do it yourself (sorry).
Also as an aside, vis.js is much more awesome than I expected it’d be.
This leaves the two branches with quite high coupling. Are there any upgrades like that or any plans to add this?
So, I just tossed together an upgrade tree visualization thing with vis.js: warning may crash browser (source). Probably want to open it with Chrome because Firefox is choking on it a bit for me.
The per-vendor trees basically start at each of the “Restoration 1” upgrades; from the visualization it doesn’t seem like there’s any coupling at all between the trees. They’re all currently self-contained, though it’s technologically possible for a new upgrade to have cross-tree prerequisites. I don’t work on the game so I have no idea what our future plans are, this is just idle speculation.
Anyway, I’m not very knowledgeable about the upgrade tree; you’re better off having a gander at the data yourself.
Ah, thanks. The reason I was wondering if there were any cross-vendor upgrades, was that otherwise you could use each “restoration” as a marker for which vendor it comes from. If there were any cross-vendor upgrades, it would mess up that idea.
Seeing as at the moment there are not any cross-vendor upgrades, you just need to create a link between the vendors and each restoration, and from there just add everything that depends on the restoration.
On another note though, are there any way to traverse the tree downwards, or do I have to find the first upgrade, then loop through every upgrade and see if the one I found is a requirement? Otherwise just keeping an internal list and adding to that every time a new upgrade is available?
IMO the easiest way is to just fetch all upgrades with the first request (via ?ids=all), then delinearize the objects into either a tree or an edge table. vis.js wants an edge table, so that’s what I’ve done in the example. But yeah, you basically have to do it yourself (sorry).
Also as an aside, vis.js is much more awesome than I expected it’d be.
Aye, seems the only way to really do it, is to parse the whole thing and create a tree like you did with vis.js (Gotta check out that.. The tree looked beautiful in presentation, with a few ugly “paths”)
> Any chance we can get Last Login added to the members list?
Ideally also if they are repping the guild or not, so perhaps three states: Repping, NotRepping and Offline. If that isn’t possible maybe a Last Rep date on top of the last log in?
I would LOVE this endpoint if it could, as others have suggested, show if guild members are currently online. I would like to expand on that idea and ask if it’s possible to view the current map the member is on, along with the map IP address. This would make thing based around attendance tracking VERY easy for guild leaders.
Some potential issue with the ’are they online’ and ’are they repping us’ is when they log in and not auto play, or sit at the char screen, then I’ve noticed that can show them as online and repping just with a location of ’unknown’. So either we need their location too (I guess your map suggestion does that!) or some clearer definition of online.