14OCT14 – Prestige Scrolls

PRESTIGE SCROLLS

For a long time, transfers of Prestige between accounts have either had to go via the Alliance prestige pool or using sitting rights. With sitting rights, one player would give rights to an account, and the sitter would then buy the Prestige and step out of the account. This has led to some players reportedly being scammed (“I didn’t receive the gold they promised!”) or – illegal according to the TOS – players swapping sign-in and password information.
Now prestige scan be transferred directly to anyone or sold on the open market at a trade hub, by using prestige scrolls. Let’s say that player A wants to give the new player B some prestige to help them along.
All player A needs to do is go into their Library’s new Resource Production area, make sure to have the correct amount of Prestige, books, mana, research and reagents and click Make – player A now instantly has a Prestige scroll that can be given or sold to player B. Player B then redeems the scroll in their Reading Room.
Be aware that items in transit, including prestige scrolls, are vulnerable to blockade, so be careful when shipping these valuable new items.
The Prestige Scroll recipes are as follows:
  • Prestige Scrap: 75 Prestige, 75 Mana, 75 Research, 1 Giant Rat Heart, 1 Pyrestone, 1 Sharproot
  • Prestige Parchment: 200 Prestige, 200 Mana, 200 Research, 1 Wild Dog Heart, 1 Claristrine, 1 Silverthorn
  • Prestige Page: 500 Prestige, 500 Mana, 500 Research, 1 Wolf Heart, 1 Deepsilver, 1 Furzion Seedpod
  • Prestige Scroll: 850 Prestige, 850 Mana, 850 Research, 1 Brown Bear Heart, 1 Rainbowstone, 1 Brownback Moss
  • Prestige Codex: 1200 Prestige, 1200 Mana, 1200 Research, 1 Giant Scuttler Heart, 1 Trove, 1 Suntree Haft
  • Prestige Book: 1850 Prestige, 1850 Mana, 1850 Research, 1 Scritcher Heart, 1 Svelaugh Sand, 1 Vistrok Flower
  • Prestige Tome: 3250 Prestige, 3250 Mana, 3250 Research, 1 Scaled Charger Heart, 1 Earthblood, 1 Ironstem Root
Prestige scrolls are regular items and will show in your towns’ and hub inventories. They can be placed in hub buy and sell orders as regular craftable items, and appear in the “Exotic” category.
Prestige scrolls can only be created from personal prestige, not from alliance prestige.
The creation and use of prestige scrolls is recorded and is shown on your prestige history page.
 
SERVER-SIDE MONITORING & DIAGNOSTICS
We have improved our server-side monitoring and diagnostics so we can be aware of a problem and try to fix it before you are aware. It also provides rich information and extra detail around issues to allow us to more quickly diagnose potential issues. We have already resolved a number of long term issues this way.
 
Sharing some insights, below is a graph around the time the Heart of Corruption began beating. The early response time peak is a deployment for improved Windows 8.1 support (do feel free to vote for us in the store!) which required a full server code refresh and so a brief response time hit as the dlls were jit compiled:
 

 

You can also see the server’s daily heart beat or ebb and flow of player demands (this is over a week). The later half of the graph increases in requests per second as you (the players) activate the Heart of Corruption and then in response start sending thousands upon thousands of missions to it and the corrupted temples.
 

CHANGES TO IMAGE, CSS & SCRIPT HOSTING

We have moved where and how we host our images, css and javascript files. Hopefully, this has been transparent to you, the players, as mostly the files are cached in your browser and they aren’t requested that much, per player. However, players occasional requests as a group and new players’ requests do add up as can be seen on the graphs below:
The graph on the left shows when we swapped over the DNS to point at the new resource, and you can actually see the dns update propagating over the internet as the new resource slowly ramped up in requests thoughout the day. The second graph shows the now current day to day activity; do bear in mind these files should be cached for a long time for returning players so those requests shouldn’t show up here, however this does include images on our out of game site (like www).
 
HTTPS SECURE ACCESS
As part of the reason for the change above, we are now more consistent on when we can serve secure image files, so you can now use Illyriad over https if you so desire:
 

 
 

MAIL NEXT & PREVIOUS ITEMS
Mail items now have next and previous buttons inside individual mails to move you through the mail without having to return to the full mail list:
 

 

The next and previous buttons are category aware, so if you are in a subcategory e.g. sent or trade they will just navigate you through available mails in that subcategory.
 
COMBAT XML API
We’ve reinstated the Combat XML API system, so that you can can individually, as players, choose to share your combat reports with third parties.  You’ve always been able to do this on an individual report basis, by using the “XML” button at the bottom of each combat report in-game mail.
 
However, you can now generate an API key in the Account & Preferences area of the User Interface.  If you generate and give this API key to other players, they can then access a listing of all your combat reports since you issued your first key, and then drill down into each individual combat report just as if you’d sent them each report via in-game mail.
 
We can see this being useful for any builder of third party tools, an alliance that wants to track their collective members’ military actions and/or any player who wants to make a killboard for (eg) the purposes of player-run tournaments.
 
The API key is something that an individual player can generate, and revoke (or rather, generate a new key) from their Account & Preferences page in the “API Keys” submenu.It differs from the individual combat report XML in that it is a generic key which essentially says “I hereby grant the holder of this key the right to access all my non-covert combat event logs in XML format until such time as I revoke the key by changing it“.A player who issues a Combat API Key can then use this unique, individual key to query a page that will produce a list of combat events that can then be queried via the individual report identifier, and they can share this key with anyone they choose.

Players can pass their Combat API key to third parties (such as alliance techies, or killboard website operators) and these third parties can then query this page on behalf of the player, and retrieve the individual combat reports for every combat this player has been involved in.

ISSUING & REVOKING YOUR COMBAT API KEY

Go to your Account & Preferences page and click on the API submenu:

You will have a list of keys here – or, on your first visit, the option to issue a Combat Reports API Key for the first time.To create a Combat Reports API Key, press the “Generate” button.If you already have a key, pressing “Generate” will instantly disable your current key and generate a new one for you; thereby preventing access to your combat reports by anyone who knows your old key.

Account sitters can generate and/or revoke API keys.

SUPPRESSING INDIVIDUAL COMBATS FROM DISPLAYING TO KEY HOLDERS
For whatever reason (doubtless nefarious!) you might not want a specific, particular combat to appear in the Combat Report list you’ve made available to anyone with your API Key.
You can suppress individual combat reports from appearing on the list if you check the Is Covertoption checkbox on the “Send Army” page before you dispatch the army outbound.  You will need to have researched Covert Operations in the Military research tree to see this option.

USING THE API KEY TO GET AN XML LIST OF AVAILABLE COMBAT REPORTS – A PROGRAMMERS’ GUIDE
If you’re not a programmer, then the following is probably not relevant, and you can skip over the next couple of sections!
The API Key is in the format:

[Server Name][KeyType][Key]

This helps you identify which server to query (we currently only have elgea) and what page to query with the key.

A sample full combat API key for elgea might look like this:

elgea-COMRP-AQAAABoolkA8l0qQ7kL5Vpxmk-LwCjrv0qh5f9uB6M10saMBnAi01_0IiV4a-pnxWDUF5UcAhtw1SNQ2n0XGbgvb6gw=

This identifies this key as being good for pulling data from Server [elgea] for Combat Reports [COMRP], and the remainder of the key is an encrypted piece of data that identifies the player to us (twinned with the rights he has given to this key).

To query a key for the first time, call the following page:

https://elgea.illyriad.co.uk/external/combatreportsapi/[insert player’s full Combat API Key including the server and keytype here]

and so, using the example above, your query would be:

https://elgea.illyriad.co.uk/external/combatreportsapi/elgea-COMRP-AQAAABoolkA8l0qQ7kL5Vpxmk-LwCjrv0qh5f9uB6M10saMBnAi01_0IiV4a-pnxWDUF5UcAhtw1SNQ2n0XGbgvb6gw=


WHAT DOES THE PAGE RETURN?

Sample (will not work in reality)
<combateventsapi>
<server>

<name>UK1</name>
<servercountrycode>gb</servercountrycode>
<serverlanguagecode>en</serverlanguagecode>
<serverlivedate>2010-02-21T21:53:01.190</serverlivedate>
<datagenerationdatetime>2014-10-13T16:30:43.040</datagenerationdatetime>

</server>

<player id="1"/><playerapikey id="elgea-COMRP-AQAAABoolkA8l0qQ7kL5Vpxmk-LwCjrv0qh5f9uB6M10saMBnAi01_
0IiV4a-pnxWDUF5UcAhtw1SNQ2n0XGbgvb6gw="/>

<combatevents>

<uniquecombatidentifier>

<server id=”UK1″/>
<combatguid id=”F94B7AC1-CFB8-4DE8-A211-044D1A4DAC18″/>
<troopmovementevent id=”507040″/>
<datacomplete id=”1″/>
<personalcombatkey id=”AQAAACTYblel0LzEsSb7kiZcZg0hQJZCDmbi_sgo82Ej6iKr”/>
<combatoccurrencedate>2014-10-06T03:09:10.523</combatoccurrencedate>

</uniquecombatidentifier>

<uniquecombatidentifier>

<server id=”UK1″/>
<combatguid id=”4D389937-545A-4CC0-A7E8-4EA27487DAAE”/>
<troopmovementevent id=”509341″/>
<datacomplete id=”1″/>
<personalcombatkey id=”AQAAAFICvEs1DXLWCN2fesfs61oCyonjDBukVnB0TxJJg2t3″/>
<combatoccurrencedate>2010-08-06T16:39:30.907</combatoccurrencedate>

</uniquecombatidentifier>

</combatevents>

Breaking it down, you have:

  • The standard Server Identification snippet, followed by
  • The PlayerID who this Key belongs to, and the exact key you just used
  • A list of combat events that this player has been involved in, along with the <personalcombatkey> identifier so you can then go off and query the specific event for the full details, using:
    https://elgea.illyriad.co.uk/external/combatreport/[insert <personalcombatkey> here]
You do not need to be logged in to access the Combat API listing or any individual Combat API report, so long as you have the key!


HOW TO CHOOSE WHAT EVENTS YOU NEED TO QUERY

1. You may already have the report from another player
Within:

<uniquecombatidentifier>

<server id=”UK1″/>
<combatguid id=”4D389937-545A-4CC0-A7E8-4EA27487DAAE”/>
<troopmovementevent id=”509341″/>
<datacomplete id=”1″/>
<personalcombatkey id=”AQAAAFICvEs1DXLWCN2fesfs61oCyonjDBukVnB0TxJJg2t3″/
<combatoccurrencedate>2010-08-06T16:39:30.907</combatoccurrencedate>

</uniquecombatidentifier>

IF

  • You already have a combat report with this <server id> and
  • You already have a combat report with this <combatguid id> and
  • You already have a combat report with this <troopmovementevent id>

THEN

IF

  • This new report has a less than or equal to ( <= ) <datacomplete id> than the one you currently have:

WHEN TRUE (YES, YOU HAVE THIS “NEW” REPORT ALREADY AND THE VERSION YOU HAVE IS AS GOOD AS, OR BETTER THAN, THE NEW REPORT) THEN

  • Don’t query this report – you already have everything you need

WHEN FALSE (NO, THIS “NEW” REPORT HAS MORE ACCURATE DATA THAN THE REPORT YOU CURRENTLY HAVE) THEN

  • Query this report using the <personalcombatkey id> and replace your existing report with this one

ELSE

  • This is a new report and you should import it

The reason we have the datacomplete flag is because different players can get slightly different versions of the same combat report (eg “Your army was completely destroyed and you heard nothing of its’ fate” vs “You completely whupped that guy, here’s the report”).

2. You don’t need to query the complete player history every time, to decide what’s new

Obviously we don’t want you to be querying a complete player history every time you pull the API key.

So there is an additional parameter we’d like you to use when you subsequently query view_combat_reports_api.asp – this parameter is called [since].  [since] is based on the actual combat occurrence date, not the date that the army was originally sent, so it should be a historic record.

This should be set to the most recent <combatoccurrencedate> for the <player ID> whose key you are using.

If you don’t have any data for this player so far, then please do not provide the [since] parameter.

Because there is a chance that you might have two combat events from the same player occurring at the same second, we will return the event(s) you already have at that datetime stamp, so please be prepared to ignore the first couple of events returned – as you may already have them (see above for how to decide).

The [since] parameter is in the same format it was provided in originally in the <combatoccurrencedate>field of the last report you have from this player, such as: 2014-08-06T03:09:10

The Date Time format is YYYY-MM-DDTHH:MM:SS

So, a first API Key query might look like this:

https://elgea.illyriad.co.uk/external/combatreportsapi/elgea-COMRP-AQAAAI0WUkqicWZIAoiQOP2bObRf5c2Vxr0CoiEQ3PPQNfCAXtq_ftlyXzYsNQ_dGhCAkRf_b2_C6VVn

… and a subsequent one might look like this:

https://elgea.illyriad.co.uk/external/combatreportsapi/elgea-COMRP-AQAAAI0WUkqicWZIAoiQOP2bObRf5c2Vxr0CoiEQ3PPQNfCAXtq_ftlyXzYsNQ_dGhCAkRf_b2_C6VVn?since=2014-10-14T13:36:38

… which will only return those combat events related to the player since (and including) the event that occurred on the [since] timestamp.


HOW OFTEN CAN I QUERY A PLAYER’S API KEY?

For the purposes of development, we haven’t yet set a limit.

However, we will probably impose a limit for a particular key query (from the same querying source) at some point in the future, simply to preserve server resources and bandwidth.  It all rather depends on how you player-programmers choose to use the API key system!

WHAT DATA IS AVAILABLE
Combat report data is only available from the moment that any API key is generated by a player.  You cannot access historic records from before the first API key was generated, except via the direct link provided at the bottom of your ingame mail combat report.
 
MOVING TROOPS
 
Things got a little wild around the Heart of Corruption as huge numbers of missions piled into it. Unfortunately this caused some noticable slow-downs in the browser pages getting updates to their movements when the map was focused on the HoC. 
 
To resolve this we throttled what was sent to the map to display a maximum of 1 mission icon (per type) per quarter square – and a maximum of 75 missions on the visible map (per type) at any time, focused around the map center. 
 
 
 
We hope you enjoy these enhancements to the game environment.
 
GM Rikoo