Print Page | Close Window

Combat API and its use in a Player Run Tourney

Printed From: Illyriad
Category: The World
Forum Name: Elgea
Forum Description: For everything related to the Elgea Continent
URL: http://forum.illyriad.co.uk/forum_posts.asp?TID=6867
Printed Date: 19 Mar 2024 at 11:48
Software Version: Web Wiz Forums 12.03 - http://www.webwizforums.com


Topic: Combat API and its use in a Player Run Tourney
Posted By: Cilcain
Subject: Combat API and its use in a Player Run Tourney
Date Posted: 11 Apr 2016 at 16:02
In a previous thread regarding the activation of Tournament Squares ( http://forum.illyriad.co.uk/tournament-square-update_topic6846_page1.html" rel="nofollow - http://forum.illyriad.co.uk/tournament-square-update_topic6846_page1.html ) some concerns regarding the use of the Combat API for this tournament were raised.  Based on some replies in that thread, and on some messages I have received, I don’t believe there is a wide understanding in the player base of what this API is, and what the concerns are.  So, I thought I would document my understanding of the API, how it works, and things players sharing their API key should be aware of (IMHO).

I think it’s great that the Devs have provided this, and the other APIs, but believe that the running of a server wide player run tourney is a specific scenario that the current API is not suitable for.

 

What is the Combat API?

Without getting too technical, the Combat API is one of a set of computer programs that the Devs have made available to players.  Its job is to return a set of data based upon a ‘key’ that is passed in a request.  The ‘key’ is a big line of characters that is specific to you as a player – you generate this in your Account screen.

How is the Combat API used?

Again, without getting too technical – you (or someone else), can use the API either in a computer program you (or someone else) have written, or even just in a web browser - the API call is essentially just a URL/web address.  The call to the API will require a valid ‘key’ as part of the address.  The API will then return a set of data to the caller containing all of the data corresponding to the ‘key’ provided.

Can I have a go?

Yes.  Generate yourself a Combat API key in the relevant page under your Player Account.  It will begin with “elgea-COMRP-“, and then a long list of random characters.

Next, in a browser’s address bar, enter http://elgea.illyriad.co.uk/external/combatreportsapi/" rel="nofollow - http://elgea.illyriad.co.uk/external/combatreportsapi/ - and then paste in your API key after the last /.  Press enter, wait a second or two, and you will see the response.  This response is in XML format, but it’s quite easy to read.  It just lists all combats you have been involved in since you generated your API key (so you might want to go and kill some rats, and then try this again).

Each combat is identified with a ‘personalcombatkey id’ – this is another string of random characters contained within quotes.  Next, you need to copy one of these, and paste it onto the end of http://elgea.illyriad.co.uk/external/combatreport/" rel="nofollow - http://elgea.illyriad.co.uk/external/combatreport/ in your browser address bar, and press enter.  This will now return another set of data with specific details of the combat event you selected.

This is the manual way of using the API, but if you are a reasonable coder, then you can do all this automatically for a large number of players’ APIs (as long as they have provided the keys to you).  The returned XML data can then be automatically split out and stored in a database.

What data is provided by the Combat API?

If you follow the steps above, and read the XML, then you will see what is available – if not, then in summary;

·         Location of combat,

·         Date/Time of combat,

·         Terrain details,

·         Date/Time that your army began moving to the combat square,

·         Length of any occupation following the combat,

·         Defending Player(s),

·         Cities that defending armies come from,

·         Defending alliances,

·         Defending army names,

·         Defending commanders and health,

·         Defending troop types,

·         Defending troop quantities,

·         Attacking Player,

·         City that attacking army came from,

·         Attacking alliance,

·         Attacking army name,

·         Attacking commander and health,

·         Attacking troop types,

·         Attacking troop quantities.

 

If I don’t share my API Key can my data still be accessed?

Yes, in some circumstances.

If you are attacked by someone who has shared their API key, then your data will be returned via their API key (if the attacker is comprehensively crushed, then your data will be limited, as it is in the in-game battle report).

Also, if an Ally, Confed or NAP player reinforces a square or city you occupy, then their API key will return data on ALL the armies (including troop type and quantities) for ALL other players on that square/city.

What happens if I share my API Key for a Player Run Tournament?

If you want to take part in a player run ‘King of the Hill’ style tournament, then there is currently no alternative to you supplying the organiser with your Combat API key.

However, there are some considerations you should be aware of;

1.       Do you know exactly who will have access to this data?  It is unlikely to be just one person, as putting together a tournament is a lot of work,

2.       To run a KotH tournament, only a small subset of the data returned by the Combat API is actually needed – are you happy that the organisers will have access to all the other data too?

3.       The data returned by the Combat API is not restricted to tournament squares – therefore, data from any other combat engagement you are involved in outside of the tournament will be available to the organisers too,

4.       If we have multiple player run tournaments over time, then the group of players with access to your data (either static historic data, or live up to date data) will grow.

 

What protection is there against my data being available to others?

Number one is – don’t generate and share you API key.  However, as stated above, currently if you want to take part in a KotH tournament, this isn’t an option.

You can set your military activity to be ‘covert’ by ticking the relevant box before sending each army out – this keeps the resulting data out of your API.  But if you do this for tournament related activity, then it will compromise your involvement in the tournament.

You can also regenerate your Combat API key.  This will immediately render any previously shared key as invalid – again, if you do this during a tournament, it will compromise your involvement.  Also, regenerating your API key does not make existing ‘personalcombatkey id’ values mentioned above invalid – so people could still access your historical combat data – they just wouldn’t get any new ‘personalcombatkey id’ values after you regenerate your key.

If you get attacked/reinforced by someone who has shared their key, then there’s not much you can do to protect your data.

 

What could be done with all this data?

The organisers of the forthcoming tournament have stated that they are only interested in data required to run the tournament – and I have no reason to doubt this.  I expect that future tournament organisers will also say the same thing.

But let’s just imagine that somehow, at some point in the future, a database containing data from hundreds/thousands of players’ Combat APIs falls into the hands of someone who wishes to act against you in the game.

If the database contains data about you and your alliance, then the person with the database would quite easily be able to form a picture of which cities specialise in what troop types, and also the approximate capacity of troops each city can support.  Even if you regenerated your API Key after a tournament ends, then the static data residing in the database will probably still be valid – after all, how often do you change a city’s troop specialisation?

Also, if you and your alliance are defending a square for whatever reason, then it will only need one defender on the stack to have a shared and active API Key for someone with that key to see exactly what troops are on that square.

 

Trust?

In the other thread where this topic was discussed, a number of posters said something along the lines of “what’s the problem as long as you trust the tournament organiser?”

I believe that trust in the tournament organiser is irrelevant – and when I say “tournament organiser”, I mean current and future organisers (including me, if I ever take on the task of arranging a tournament).

The best way of demonstrating that someone has not leaked data (accidentally or otherwise), is to prove that they did not have access to that data in the first place – if you can do that, then it’s instantly ‘case dismissed’.  By using the current Combat API, then this proof is not possible – in fact, it would prove the opposite.

Next, if someone does need access to data, then that person(s) needs to be clearly identified and the number of people kept to a minimum.  Even with the forthcoming tournament, I don’t know exactly who will have access to the API Keys – I know of two names, but I’m sure there must be more.  Even if I was given a list of names and all their alts, there is no way to restrict the use of my key to the people on that list.  And as we get to a second, third, fourth player run tournament, then the picture just gets even more blurred.

Also, trust is transient.  Can anyone guarantee to me, that someone I trust with this data now (or in future tourneys), will not at some point in the future be in an alliance that wants to declare war on me?

 

Can the above concerns be resolved?

Yes.  And hopefully, GM Storm Crow is already on the case, as per his previous post in the forum (in the thread linked above).  If the Devs were to introduce a new API type – let’s call it ‘Tourney API’, then this API could be built such that;

·         It only returned data from combat occurring on the defined tournament squares,

·         It only returned the data required to run a KotH type tournament (which I believe to be Player Name, Alliance Name, Occupation Time, Combat Date/Time, Number of Casualties).

This would then address all of the concerns above whilst supporting the running of much needed tournaments.

 



-------------
http://elgea.illyriad.co.uk/a/p/77750" rel="nofollow">



Replies:
Posted By: Rill
Date Posted: 11 Apr 2016 at 17:13
Thank you for posting this, Cilcain.

I also really hope that the developers will develop this new key in time for the tournament.  I also hope they think about the possibility of generating time-limited API keys in the future.  

One of the things I didn't realize when API keys were introduced was that any new generated API will still pull ALL historical data since the date ANY API key was first generated.  This is not a problem for me personally since my combat participation is trivial, but I can imagine in the long run that people will not wish to share EVERY combat they have ever been present at (perhaps since first generating an API key years before) merely for the opportunity to participate in a current event.

I urge the developers to consider alternatives to limit the information accessible by creating keys that would restrict date ranges, for example.  These would not have to be customizable; even something that only pulled for data after January 1 of the current year or something similar would be desirable.

That said, developing a tourney-specific API key as Cilcain described that only pulls data for tournament squares would address this concern for the current tournament and should be a top priority.

Thank you!


Posted By: Mahaut
Date Posted: 11 Apr 2016 at 20:56
Dear lord this API thing is a mess.

So if I am reading this correctly........

Even without player run tourneys

If a player has used an API and that persons troops are used for any operation whatsoever then you are running a massive risk that all the above data will be available outside the alliance, due to confed or naps it could be anyone from outside the alliance as well or whoever is doing the attacking.

No point in scouts, just have a troop with an API on a tile from a spy account, an alliance tourist or even just a nap or confed that might not even know the API is running in one of their players accounts. Alt accounts not in the same alliance - forget it. 

Just made spy accounts even more important, scouts pointless, naps and confeds something to be viewed with great suspicion whenever anything goes awry. In fact made even HAVING naps and confeds something to really be looked at very very carefully.

Jeez

Why don't we all just publish our troop numbers and what we make where on the forums and save everyone the bother of looking it up. Then we can all go play farmville
 - after all we aren't playing a strategy game anymore, we're playing a "who has good coders in their alliance" game instead. 

What on earth were the devs thinking when they released this?


-------------


Posted By: Excession
Date Posted: 11 Apr 2016 at 22:12
Truth is that player led Tourneys are a great addition to the tradition of Tourneys of the traditional form but should not be a way for the game escaping the effort of running them for the players. As a long term player that thrived on Tournaments I've found myself increasingly disappointed by the lack of them. It would be true to say I was lured to this game by them, a kinda end game but without having to start again. So I have this to say to the game's custodians. "Sort the API for player led tourneys to work properly and securely and get you fingers out and run one for the players yourselves". ATM this is getting like a restaurant where the customer is expected to cook for themselves and then clear up afterwards.


Posted By: GM Stormcrow
Date Posted: 11 Apr 2016 at 23:52
Originally posted by Mahaut Mahaut wrote:

What on earth were the devs thinking when they released this?

We were thinking that, for example, an alliance might find it useful to keep track of the progress of a war., with realtime combat reports from the members of the alliance who shared the key with their leadership  

The API key system has been out there - and used by many highly successful alliances - for many years - since well before the player-run tournaments idea.

The 'key' thing, which I think you might be missing, is that *you can choose to whom you give your API key*.  If you don't want someone finding out your super-sekret battle reports, don't give them your API key.  Plus you can revoke it at any time of your choosing.  If you don't like the idea of the API key, then don't share yours with anyone.  Problem solved.

Originally posted by Mahaut Mahaut wrote:

Dear lord this API thing is a mess.
The API key system is a hugely useful and massively extensible system.  It is not a "mess".  Your understanding of it and it's possible uses and purposes, however, most definitely is.

Regards,

SC




Posted By: Mahaut
Date Posted: 12 Apr 2016 at 00:28
I can choose to whom I give my API key. I however have no control over who else hands out theirs in a war or a tourney (player run ones I can't even enter if not sharing) and is on the same tile.

and as for not sharing my super-sekret[sic] battle reports...well why would I? How many games have you played that dish out that information to all and sundry?

"The API key system has been out there - and used by many highly successful alliances - for many years - since well before the player-run tournaments idea."  Really? The existing one was released Feb 2015, the previous one didn't have the same amount of data and wasn't so accessible


-------------


Posted By: Excession
Date Posted: 12 Apr 2016 at 00:48
SC I note you made no response to my post.


Posted By: Excession
Date Posted: 12 Apr 2016 at 00:52
I'd say the key thing is if I can be bothered to play a deeply flawed game!


Posted By: Dungshoveleux
Date Posted: 12 Apr 2016 at 01:07
I would suggest all involved to take a deep breath, step back, and wait for the revised api key which limits the information shared to acceptable levels for most people.  Give the devs space to fix this which I am sure, having got their attention, they will.


Posted By: GM Stormcrow
Date Posted: 12 Apr 2016 at 01:18
Originally posted by Mahaut Mahaut wrote:

How many games have you played that dish out that information to all and sundry?

Eve Online is a great example of a combat API key in use.

And it's not 'to all and sundry': it's to those whom you choose to share your API key with - just like it's to those whom you choose to forward on your combat reports to.  

It's your choice.  

No one is forcing you to share your API key.  

No one is forcing you to forward your combat report emails. 

Regards,

SC


Posted By: GM Stormcrow
Date Posted: 12 Apr 2016 at 01:25
Originally posted by Dungshoveleux Dungshoveleux wrote:

I would suggest all involved to take a deep breath, step back, and wait for the revised api key which limits the information shared to acceptable levels for most people.  Give the devs space to fix this which I am sure, having got their attention, they will.

To be clear:

The only fix we're putting in place is for a tournament-square-specific API key that will share all the information currently in the current combat report ingame mail - just as the current combat API key does - but only for combats that occur on tournament squares.  

We're not limiting any other information; the tournament API key will be the exact current combat report, just restricted to combats that occurred on the tournament square.

We've had requests, for example, to restrict troop numbers and casualty information in the combat report.  However, the last tournament made these numbers (broken down combat by combat) publicly available on a battle-by-battle basis - and no one complained then; so I find these requests for even more slimmed-down datasets somewhat perplexing.

If this is not to anyone's liking, then I suggest they don't share their API key/participate in the player-run tournament - and the problem is entirely solved.

Regards,

SC


Posted By: GM Stormcrow
Date Posted: 12 Apr 2016 at 01:27
Originally posted by Mahaut Mahaut wrote:

"The API key system has been out there - and used by many highly successful alliances - for many years - since well before the player-run tournaments idea."  Really? It was released Feb 2015 so just over a year, who had it before that?

D minus - must try harder. 2010 is - by my reckoning - many years.

http://forum.illyriad.co.uk/combat-api-keys_topic906.html

Regards,

SC


Posted By: Rill
Date Posted: 12 Apr 2016 at 01:43
GM Stormcrow, I am glad you are working on a tourney-specific API key.  This is excellent news and will be very useful for the upcoming tourney.  I appreciate your responsiveness in this regard.

I would be interested in your comment on whether it is possible to create a key that is time-limited (rather than geographically limited), for use for example in hunting tournaments or other events that do not use the tournament squares and which therefore must use a broader API key that is not limited to those squares.

Do you understand what I am saying about players not wishing to share ALL their historical information each time they wish to participate in an event?  Illy is a perpetual world, and as such political feelings can simmer for a long time -- a strength of the game.  It would be good to have a tool that is robust enough to take this into account by limiting the period of time someone given an API key can "look back" on historical data. 

 As someone who is not a coder, I do not know how practical this is, and I am interested in your response.  I'm not suggesting that this be something the player can select upon creation of the key (although that idea has merit, I anticipate it would be too difficult), but rather that there be keys that are limited to a timeframe such as the current year.

Thanks!


Posted By: Mahaut
Date Posted: 12 Apr 2016 at 01:46
Originally posted by GM Stormcrow GM Stormcrow wrote:

Originally posted by Mahaut Mahaut wrote:

"The API key system has been out there - and used by many highly successful alliances - for many years - since well before the player-run tournaments idea."  Really? It was released Feb 2015 so just over a year, who had it before that?

D minus - must try harder. 2010 is - by my reckoning - many years.

http://forum.illyriad.co.uk/combat-api-keys_topic906.html

Regards,

SC

Lol yes indeed I found the previous release date just after my posting. Ya got me good with that one hehe


-------------


Posted By: GM Stormcrow
Date Posted: 12 Apr 2016 at 01:57
Originally posted by Rill Rill wrote:

GM Stormcrow, I am glad you are working on a tourney-specific API key.  This is excellent news and will be very useful for the upcoming tourney.  I appreciate your responsiveness in this regard.

I would be interested in your comment on whether it is possible to create a key that is also time-limited, for use for example in hunting tournaments or other events that do not use the tournament squares and which therefore must use a broader API key that is not limited to those squares.

Do you understand what I am saying about players not wishing to share ALL their historical information each time they wish to participate in an event?  Illy is a perpetual world, and as such political feelings can simmer for a long time -- a strength of the game.  It would be good to have a tool that is robust enough to take this into account by limiting the period of time someone given an API key can "look back" on historical data. 

 As someone who is not a coder, I do not know how practical this is, and I am interested in your response.  I'm not suggesting that this be something the player can select upon creation of the key (although that idea has merit, I anticipate it would be too difficult), but rather that there be keys that are limited to a timeframe such as the current year.

Thanks!

As far as I am aware, this is already the case.

a) Issue and provide your key at a certain time of your choosing - presumably when the tournament starts

b) The key is only valid for combat data from the moment the (new) key is issued, onwards (as far as I am aware)

c) When the tournament is over, change your key with one click (and the old one becomes invalid)

If it doesn't work like this (ie a newly-issued key gives access to combat data issued prior to the timestamp on the key), please do let me know.

Regards,

SC


Posted By: kodabear
Date Posted: 12 Apr 2016 at 02:02
The combat key does have data from all combat from the time you first created the key even when you create a new key


Posted By: GM Stormcrow
Date Posted: 12 Apr 2016 at 02:05
Originally posted by kodabear kodabear wrote:

The combat key does have data from all combat from the time you first created the key even when you create a new key

Ah kk.  That can be easily fixed (and should be how it always worked - funny how, 6 years on, these things come to light XD).  

All those in favour say 'aye'? 

Regards,

SC


Posted By: GM Stormcrow
Date Posted: 12 Apr 2016 at 02:11
Oh, one further question.  

Should key issue date (which combats to report in the API key list of available combats from the datetime of the key issuance) be based on:
a) troop movement sent timestamp, or 
b) combat occurrence timestamp?

Edt: my thinking is combat occurrence, but willing to hear alternative views.

Regards,

SC




Posted By: Solanar
Date Posted: 12 Apr 2016 at 02:17
I vote combat occurance 


Posted By: Rill
Date Posted: 12 Apr 2016 at 02:19
I definitely vote only combats from when you newly create a key should be available, that was my initial impression and I only learned differently recently.  So if that is changed so that only combats from when the key was generated are available, that would be awesome.

Also, I think it should be the date and time of combat occurrence, not when the mission was sent.


Posted By: Count Rupert
Date Posted: 12 Apr 2016 at 02:35
Definitely combat occurrence.  All the tournaments I know of are based on when the combat occurs, not when the troops were sent.


Posted By: Digioso
Date Posted: 12 Apr 2016 at 10:26
[x] combat occurrence timestamp

-------------
http://www.digioso.org" rel="nofollow">


Posted By: Diva
Date Posted: 12 Apr 2016 at 14:44
Though I know nothing how it's done... but keeping it a restricted API key to the combat report on the square alone will probably bring in more alliances, as the sekret info wants to stay sekret. 

Man, many must be holding (I know some do) over 1 million+  troops PER player for years!! LOL.

restricted API key to the combat report on the square alone  is my vote :)  [x]


-------------
"Um diva.... you are sort of acting like a .... diva...." - PhoenixFire


Posted By: Cilcain
Date Posted: 12 Apr 2016 at 16:32
Originally posted by GM Stormcrow GM Stormcrow wrote:



To be clear:

The only fix we're putting in place is for a tournament-square-specific API key that will share all the information currently in the current combat report ingame mail - just as the current combat API key does - but only for combats that occur on tournament squares.  

We're not limiting any other information; the tournament API key will be the exact current combat report, just restricted to combats that occurred on the tournament square.

We've had requests, for example, to restrict troop numbers and casualty information in the combat report.  However, the last tournament made these numbers (broken down combat by combat) publicly available on a battle-by-battle basis - and no one complained then; so I find these requests for even more slimmed-down datasets somewhat perplexing.

If this is not to anyone's liking, then I suggest they don't share their API key/participate in the player-run tournament - and the problem is entirely solved.

Regards,

SC


SC, what's the difficulty/objection to stripping out a few data elements? As far as I know, KotH does not need to know troop type or quantities, city name/identifier, time travelled. If we were asking for new data, I could understand.

Is Koda able to comment on what data is essential for the forthcoming tourney?

Number of casualties is fine, and from memory, is what has been reported in previous tournaments.

C

-------------
http://elgea.illyriad.co.uk/a/p/77750" rel="nofollow">


Posted By: Digioso
Date Posted: 12 Apr 2016 at 16:55
For Kodas tournament we basically only need to know the occupation time and which armies are still there after the battle.


-------------
http://www.digioso.org" rel="nofollow">


Posted By: GM Stormcrow
Date Posted: 12 Apr 2016 at 17:11
Originally posted by Cilcain Cilcain wrote:

 
SC, what's the difficulty/objection to stripping out a few data elements? As far as I know, KotH does not need to know troop type or quantities, city name/identifier, time travelled. If we were asking for new data, I could understand.
C
Hi Cilcain,

Fundamentally, because we're keeping the data in the combat report XML identical to the data that's in the combat report ingame mail, and see no reason to branch the XML output  - especially as this may hinder possible future player-run tournaments that might need/want these fields for the express purposes of administering their tournament and/or prizes.  

Off the top of my head, I can think of many circumstances in which these data fields could be specifically relevant to a tournament competition, eg:
  • a cavalry-only tournament, or 
  • awarding prizes for the highest K/D ratio, or 
  • a tournament to see who has the best military from a single city, or
  • a tournament that is only open to cities in a named region
Regards,

SC



Posted By: Dungshoveleux
Date Posted: 12 Apr 2016 at 20:47
Having read through the thread again, I am a little disappointed that the concern from individuals about the data hasn't been addressed.  On the plus, side, a combat report bug HAS been fixed so that troops and commanders now sort properly, but this also seems important - more so in fact.


Posted By: GM Stormcrow
Date Posted: 12 Apr 2016 at 21:06
Any tournament organiser can choose not to display any of the data you wish to be suppressed, if they wish.  

But at the end of the day, you have to trust the tournament organiser with the data the API key provides for those combats that occur on the tournament square whilst the key is still valid.

Regards,

SC


Posted By: Luffster
Date Posted: 12 Apr 2016 at 22:54
So let me get this right...

The Devs/Admin don't run any tournaments any more (straining to remember the last one!), we are now reliant on the players to run any form of tournament.  Should you wish to take part in one, any player run tournament you will have to give the API key thing to your opponent/opposition/anybody..... and that is totally fine?  Actually not entirely sure, but even if I don't if somebody (Ally/NAP etc) does then my details are out there for anybody to see??

We hoped that the key was going to amended to restrict details but it seems to be too tough/too much time for the Devs/Admin to spend on - because they are so busy answering all of our petitions - this must be the case because I have 2 from 2012 that were never answered....   

Wait one minute, have I arrived in my deLorean 4 years into the future?

Regards

Luffy 


Posted By: GM Rikoo
Date Posted: 12 Apr 2016 at 23:14
Luffy;

We have already addressed these concerns and why leaving out any information would not work.

If you have any other specific questions about the topic, let us know!

If you have a specific petition from years ago, feel free to send it to community@illyriad.co.uk and I can look into it. 


Thanks!


Rikoo




-------------
Illyriad Community Manager / Public Relations / community@illyriad.co.uk


Posted By: TheBillPN
Date Posted: 12 Apr 2016 at 23:39
I have a question Rikoo:

Given player concern about privacy issues and the effort of coming up with a player run tournament, wouldn't it have just been easier to use pre-existing code to automatically and with very little effort have a quarterly/big-annually/annually dev tourney? And surely you can very easily swap round the stlye of tourney for variation.
I know you want players doing their own thing, and hats off to koda / digioso, but I'm sure this would have been far easier and made far more people happier.

Given that you have already run tourneys, is it not just a matter of copy and paste?
Sorry if this has been answered before, but I havent seen jt if it has.


Posted By: Cilcain
Date Posted: 12 Apr 2016 at 23:44
Originally posted by GM Rikoo GM Rikoo wrote:

Luffy;

We have already addressed these concerns and why leaving out any information would not work.

If you have any other specific questions about the topic, let us know!

If you have a specific petition from years ago, feel free to send it to community@illyriad.co.uk and I can look into it. 


Thanks!


Rikoo




With respect Rikoo, you haven't stated why removing certain data elements wouldn't work, you have just stated that you don't want to do it (i.e. It's not just a co-ords filter).

I still firmly believe that a new Tourney API (with limited data elements, and restricted to Tourney squares) can co-exist with the existing Combat API. Tourney organisers can then choose which API they require to run their tourney.

In the case of the forthcoming KotH tourney, for example, the Tourney API would be sufficient (as already confirmed by Digi). In the case of a more complex tourney mechanic (as per SC's earlier post), the current Combat API would be required. Players would then have a choice.

I would expect most player run tourneys will be KotH types.

C

-------------
http://elgea.illyriad.co.uk/a/p/77750" rel="nofollow">


Posted By: GM Rikoo
Date Posted: 13 Apr 2016 at 01:12
Luffy,

You are correct and I am wrong; I meant to say that we have already posted why we will not be removing certain data elements, not why it would not work.

I think that's a quadbilion negative, but you get my point! :)


Rikoo


-------------
Illyriad Community Manager / Public Relations / community@illyriad.co.uk


Posted By: GM Stormcrow
Date Posted: 13 Apr 2016 at 02:30
Originally posted by Cilcain Cilcain wrote:

 
With respect Rikoo, you haven't stated why removing certain data elements wouldn't work, you have just stated that you don't want to do it (i.e. It's not just a co-ords filter).

I still firmly believe that a new Tourney API (with limited data elements, and restricted to Tourney squares) can co-exist with the existing Combat API. Tourney organisers can then choose which API they require to run their tourney.

In the case of the forthcoming KotH tourney, for example, the Tourney API would be sufficient (as already confirmed by Digi). In the case of a more complex tourney mechanic (as per SC's earlier post), the current Combat API would be required. Players would then have a choice.

I would expect most player run tourneys will be KotH types.

C

If you fight someone in any historic tournament (or indeed in any circumstance where combat occurs between 2 or more players), when your troops arrive and attack/destroy the player/alliance who was holding the square, everyone involved currently receives an ingame mail (with all the XML in it) that currently contains the details you now wish to have suppressed, including troop types, casualties, etc.

Are you similarly requesting that we remove troop types, city sent from, casualties etc from the combat reports that are sent via ingame mail to the attackers and defenders?  And if not, why not?

Regards,

SC


Posted By: GM Stormcrow
Date Posted: 13 Apr 2016 at 02:42
Sorry if I'm being obtuse:  I genuinely want to understand the objection to the API and the XML, as it currently stands.

SC


Posted By: Diva
Date Posted: 13 Apr 2016 at 03:46
Correct me if I'm wrong... anyone in objection.. is it that OTHER "players" (the organisers) have access to this info and NOT the devs? 

Do you feel that it is not trustworthy enough that it stays where it belongs and that all other Organizers of thine enemy and non-friends and friends, that run a tourney in this fashion will have it as well? If that is what it is.. say so.

SPILL THE T!!

But if the API is restricted to the square only .. and combat for the square,  does it not just show the square data only? (This is what I'm thinking it only does). 

And does not lead back to "what each player has in each of their cities"? 



-------------
"Um diva.... you are sort of acting like a .... diva...." - PhoenixFire


Posted By: GM Stormcrow
Date Posted: 13 Apr 2016 at 11:47
Originally posted by Luffster Luffster wrote:

Should you wish to take part in one, any player run tournament you will have to give the API key thing to your opponent/opposition/anybody..... and that is totally fine?  Actually not entirely sure, but even if I don't if somebody (Ally/NAP etc) does then my details are out there for anybody to see??
I missed this one earlier.

Luffster - this is the way it has always worked, for all combats (tournament or otherwise), since 2010...

For the avoidance of doubt, let me outline what happens in combat:

1) A defender (or defenders) are on a square
2) An attacker arrives at the square
3) Combat happens
4) All the participants in the combat get an ingame mail, which details all of the data fields listed (such as the troop types involved, the town the attackers came from, etc), which some of you are now asking to have repressed from the data as applied to tournament squares
5) This data is also supplied as an individual combat XML file linked at the bottom of the ingame combat report that all participants in the combat get.

So, everyone involved in the combat gets this data, and anyone can also choose to share it by forwarding on the combat email to anyone they so choose.

What the API key adds is to ask one (or all) of the participants in the combat to, essentially, automatically forward-on their ingame combat emails that happened on the tournament squares during the tournament duration... to forward on these to the tournament administrator, so they can administer the rules and prizes.  The data always was shared amongst all participants in the combat; and any one of the players involved in the combat could always centralise the full dataset, wherever they wished to.

Regards,

SC



Posted By: Mr Damage
Date Posted: 13 Apr 2016 at 11:57
Question, if I dont give my API key I can still hit the tournament squares and the only consequence is that I won't be recorded in the stats for the tournament?


Posted By: GM Stormcrow
Date Posted: 13 Apr 2016 at 12:12
Originally posted by Mr Damage Mr Damage wrote:

Question, if I dont give my API key I can still hit the tournament squares and the only consequence is that I won't be recorded in the stats for the tournament?
I have no idea. Mr D: that'd be up to the tournament organiser.  

They may be fine with it, or they (and the other participants) may take a dim view to people turning up and fighting without providing the API key.

SC


Posted By: Digioso
Date Posted: 13 Apr 2016 at 14:48
Originally posted by GM Stormcrow GM Stormcrow wrote:

Originally posted by Mr Damage Mr Damage wrote:

Question, if I dont give my API key I can still hit the tournament squares and the only consequence is that I won't be recorded in the stats for the tournament?
I have no idea. Mr D: that'd be up to the tournament organiser.  

They may be fine with it, or they (and the other participants) may take a dim view to people turning up and fighting without providing the API key.

SC


Your attack will be recorded and taken into account. The script will produce a warning message that a player took part in the tournament that hasn't shared his key.
So as long as your attack is recorded by another player it will be taken into account. If there is no record from another player of your attack it won't be considered simply because the script doesn't know about it.

Koda has to decide whether he politely asks you to give him your key or whether he'll issue a warning to you and your alliance. 2nd warning = your alliance is out of the tournament.
@Koda: Please correct me if I'm wrong about these plans.


-------------
http://www.digioso.org" rel="nofollow">


Posted By: Gragnog
Date Posted: 13 Apr 2016 at 16:49
You only need one player in an alliance to be occypying the square with api key for the alliance to get the occupy time. All other players can just attack and reinforce said player. Trying to punish players and alliances is just going to result in people hitting tournament squares to mess with the tournament. I for one will not be giving my api but will be reinforcing the square my alliance goes for. If that gets my alliance penalized you can be assured I will start to hit other squares just for fun then.

-------------
Kaggen is my human half


Posted By: Rill
Date Posted: 13 Apr 2016 at 17:40
When this was discussed in gc, kodabear said he didn't see a problem with people not officially participating in the tournament trying to occupy the squares.  They won't get the prizes if they win, of course.

In terms of people who haven't given APIs trying to act as "spoilers" for the tournament, I don't see how that could be a thing, given that in the past everyone could try to occupy tournament square, and in this tournament, the same thing, everyone can try to occupy tournament squares.

In the past there have been folks who have tried to act as "spoilers" by camping on squares for reasons that did not appear to have tactical or strategic value.  There have also been people who seemed to think their actions had tactical or strategic value when they probably didn't.

Who are we to judge?


Posted By: Mr Damage
Date Posted: 13 Apr 2016 at 20:24
Thanks for the replies. Not trying to spoil anyone's fun just looking to have some of our own. I am happy not to be a chance of winning anything but would like to hit the squares regardless. There is no chance that Grey can win anything to start with.


Posted By: kodabear
Date Posted: 13 Apr 2016 at 20:40
Originally posted by Digioso Digioso wrote:

Originally posted by GM Stormcrow GM Stormcrow wrote:

Originally posted by Mr Damage Mr Damage wrote:

Question, if I dont give my API key I can still hit the tournament squares and the only consequence is that I won't be recorded in the stats for the tournament?
I have no idea. Mr D: that'd be up to the tournament organiser.  

They may be fine with it, or they (and the other participants) may take a dim view to people turning up and fighting without providing the API key.

SC


Your attack will be recorded and taken into account. The script will produce a warning message that a player took part in the tournament that hasn't shared his key.
So as long as your attack is recorded by another player it will be taken into account. If there is no record from another player of your attack it won't be considered simply because the script doesn't know about it.

Koda has to decide whether he politely asks you to give him your key or whether he'll issue a warning to you and your alliance. 2nd warning = your alliance is out of the tournament.
@Koda: Please correct me if I'm wrong about these plans.


I will ask players nicely for there API key. They wont have to give it to me but they wont get any prizes though.


Posted By: Lagavulin
Date Posted: 13 Apr 2016 at 20:55
sounds more than fair to me


Posted By: kodabear
Date Posted: 13 Apr 2016 at 22:11
Originally posted by Gragnog Gragnog wrote:

You only need one player in an alliance to be occypying the square with api key for the alliance to get the occupy time. All other players can just attack and reinforce said player. Trying to punish players and alliances is just going to result in people hitting tournament squares to mess with the tournament. I for one will not be giving my api but will be reinforcing the square my alliance goes for. If that gets my alliance penalized you can be assured I will start to hit other squares just for fun then.

Just to be clear the only way for a whole alliance to be disqualified is by cheating (having more then one alliance hold a Tournament Squares). Now if no one from an alliance end up giving me a Tournament  API key and wins a sq they will still  prizes for the sq but if they won 1st place in the whole Tournament they wont get any medals (because i will be giving medals based on API key given to me). 


Posted By: Digioso
Date Posted: 14 Apr 2016 at 09:34
Originally posted by Gragnog Gragnog wrote:

You only need one player in an alliance to be occypying the square with api key for the alliance to get the occupy time. All other players can just attack and reinforce said player. Trying to punish players and alliances is just going to result in people hitting tournament squares to mess with the tournament. I for one will not be giving my api but will be reinforcing the square my alliance goes for. If that gets my alliance penalized you can be assured I will start to hit other squares just for fun then.


As long as the script can get the information it doesn't matter how many players are involved that shared the combat key.
If none of the players who participated in the combat shared their API keys the combat cannot be tracked.
If only one player per alliance shares their key this would mean that this player has to participate in ALL combats and he also has to be the first player to occupy any square.
Because if another player that didn't share the key is the first player on a square it cannot be tracked.


-------------
http://www.digioso.org" rel="nofollow">


Posted By: Cilcain
Date Posted: 14 Apr 2016 at 12:09
Originally posted by GM Stormcrow GM Stormcrow wrote:

Sorry if I'm being obtuse:  I genuinely want to understand the objection to the API and the XML, as it currently stands.

SC

SC,

 

Sorry for the delayed response to your post – but I’ve been attempting to be on holiday for the last few days J

All you say regarding in-game battle reports is, of course, true.  A participant in a battle gets a report (either complete or partial), and is able to share this with whomever they like by forwarding the report.

This is fine, and it translates into the ‘fantasy Illyriad universe’ quite well as “word of the battle spread far and wide” type stories.

The use of the current API in my mind changes this somewhat.

Firstly, it enables intelligence gathering to be done automatically, and at volume – this is easily then extended into automation that populates a large database of intelligence outside of the perimeters of Illyriad.  The action of sharing information then becomes less of a ‘role play’ thing – which essentially the game is – to a coding thing.  The owner of data also loses the ability to cherry pick which data to forward on to others, as the API gives access to all data.

Secondly, the use of the current Combat API for a player run tourney means that players must share this data with players outside of their alliance with whom they have probably had no previous dealings.  Your example of forwarding battle reports is generally done within the confines of an alliance – or more specifically, shared with specific leadership accounts within an alliance.  On the fewer occasions when reports are shared outside of an alliance, they tend to be on a battle by battle basis (see the first point above).

Thirdly, the current Combat API provides more information (or rather, the same information in more scenarios) than in-game battle reports do.  Currently, if I reinforce a square occupied by my Allies, Confeds or NAPs, I just get a report stating that my army has arrived, and the name of the player with the earliest occupying army.  However, using the API, I get an XML that details all of the armies on the square (including troop types and quantities) – i.e. you can scout without Scouts, even when the occupying armies have huge contingents of defending scouts themselves.  The same applies for reinforcing a city.

 

I am not saying that the current Combat API should be retired – I think there are a great many good uses for it.  What I am saying, is that for the specific use case of a player run tourney, the current Combat API is not suitable, and that we need an API specific to this use case.  This tourney API should not only be tourney square specific, but should also filter out some data elements so that it doesn’t become a tool for intelligence gathering via the coder’s back door.  It wouldn’t require a new XML schema – just an API policy or data masking rule on the existing schema.

 

C



-------------
http://elgea.illyriad.co.uk/a/p/77750" rel="nofollow">


Posted By: Tacardi
Date Posted: 14 Apr 2016 at 18:41
I would like to know "IF or WHEN" the coding will be changed? and if so will there be like another button to generate the tourney API code?

I'm a co-lead in TCOL and we are starting to get our members coordinated and providing the needed API code

Thanks
Tacardi 


Posted By: GM Stormcrow
Date Posted: 14 Apr 2016 at 19:40

Hi Cilcain,

Thanks for getting back to me.  

Originally posted by Cilcain Cilcain wrote:

Firstly, it enables intelligence gathering to be done automatically, and at volume – this is easily then extended into automation that populates a large database of intelligence outside of the perimeters of Illyriad.  The action of sharing information then becomes less of a ‘role play’ thing – which essentially the game is – to a coding thing.  The owner of data also loses the ability to cherry pick which data to forward on to others, as the API gives access to all data.

Many alliances have used the Full API key and automated parsers, for many years - precisely for the purpose of collating alliance-wide (and even confed-wide) intelligence purposes.  It saves all the members the hassle of copying and pasting every combat email into a text parser, which would achieve the same effect - but with more hassle.
Originally posted by Cilcain Cilcain wrote:

All you say regarding in-game battle reports is, of course, true.  A participant in a battle gets a report (either complete or partial), and is able to share this with whomever they like by forwarding the report.

This is fine, and it translates into the ‘fantasy Illyriad universe’ quite well as “word of the battle spread far and wide” type stories.

So... you're absolutely *fine* with the 'secret' data being shared with - or aggregated by - anyone in the game, entirely out of your control... but only so long as it's done manually via igms or via copy'n'pasting each individual xml file attached to each email into an xml aggregation system.

I guess this is where I believe your argument for a reduced API dataset loses traction; especially now as you're specifically making it an imposition on all the other players in this tournament as well - ie there's no point in your alliance using a restricted dataset API key unless all the tournament participants do... so we, the developers, must force all the tournament participants to abandon use of the Full API key for combats on tournament squares in order to satisfy your requirements to participate.

Your argument is, fundamentally, "it's not the data we object to, it's that the system is too automated - and we'd be fine if it was made more manual"... and I'm afraid to say that's not an argument that really holds much water.

Regards,

SC



Posted By: GM Stormcrow
Date Posted: 14 Apr 2016 at 19:46
Originally posted by Tacardi Tacardi wrote:

I would like to know "IF or WHEN" the coding will be changed? and if so will there be like another button to generate the tourney API code?

I'm a co-lead in TCOL and we are starting to get our members coordinated and providing the needed API code

Thanks
Tacardi 
Within the next week, Tacardi.  afaik there is at least a month before the tournament begins, so there's still good time.

Regards,

SC


Posted By: Tacardi
Date Posted: 14 Apr 2016 at 20:24
Thank you GM Stormcrow Star


Posted By: Mahaut
Date Posted: 14 Apr 2016 at 23:00

Originally posted by GM Stormcrow GM Stormcrow wrote:

So... you're absolutely *fine* with the 'secret' data being shared with - or aggregated by - anyone in the game, entirely out of your control... but only so long as it's done manually via igms or via copy'n'pasting each individual xml file attached to each email into an xml aggregation system.

Please stop with the emotive and sarcastic "secret" data digs. Most alliances especially military ones have thinsg they would prefer to not be widely known, nothing new there.

Originally posted by GM Stormcrow GM Stormcrow wrote:

I guess this is where I believe your argument for a reduced API dataset loses traction; especially now as you're specifically making it an imposition on all the other players in this tournament as well - ie there's no point in your alliance using a restricted dataset API key unless all the tournament participants do... so we, the developers, must force all the tournament participants to abandon use of the Full API key for combats on tournament squares in order to satisfy your requirements to participate.

And what you are saying is our members concerns are to be ignored. Whereas a reduced subset will make no difference to anyone else whatsoever.

Originally posted by GM Stormcrow GM Stormcrow wrote:

Your argument is, fundamentally, "it's not the data we object to, it's that the system is too automated - and we'd be fine if it was made more manual"... and I'm afraid to say that's not an argument that really holds much water.

Incorrect, our concerns are simply that there is too much data, most of it completely unnecessary to the effective operation of a KoTHT. As Cilcain himself explained if a player makes a personal decision to share data by whatever means - it is his choice - if he chooses to copy paste he can delete data he doesn't want the recipient to see.



-------------


Posted By: GM Stormcrow
Date Posted: 14 Apr 2016 at 23:07
I've had a request to explain what this is about as simply as I can, and why we can't just "do what is being asked"; so here goes...

I believe the people arguing for a 'reduced' dataset are coming from the erroneous position that they somehow 'own' the data from a combat that involved them, and that they can choose what happens to it.

In any combat at least two participants get the data - and maybe more, depending on how many defenders are on the square.  

If any one of those participants chooses to share the data further with other people - by forwarding the combat report email - they may do so.  There's nothing to stop them.

Combat data by definition cannot be "owned" by a single player, and a single player cannot decide what happens to that data.

The system that Cilcain is requesting we implement is, I'm afraid to say, entirely pointless - and let me explain why.

The system we're being asked to implement is that players have a restricted API key that allows players (through checkboxes) to choose what data is returned by their API key.

This data might consist of things like the town that the troops are from, the casualties taken, the troop types, the commanders names, the troops remaining etc.  For the purposes of a hypothetical, let's say there are these 5 pieces of data only, labelled Data1 through Data5.

And let's say we implement the system that Cilcain is requesting.

The scenario: 
  • An attacker (Player1) arrives at a square, where there are 4 defenders (Player2, Player3, Player4 & Player5) on it.

  • Player1 has set up his API key, using the checkboxes, to only reveal Data1 & Data2
  • Player2 has set up his API key, using the checkboxes, to only reveal Data2, Data3 & Data4
  • Player3 has set up his API key, using the checkboxes, to only reveal Data5
  • Player4 doesn't care, and is sharing his full combat API key to reveal all pieces of Data1 thru Data5
  • Player5 doesn't want anyone to know what happened in the combat, and has chosen not to share any data or APIkeys at all
It should be clear, at this point, that it fundamentally doesn't matter who wanted what.  

All the data has been shared, on the wishes of - or against - all of the players involved in the combat. 

Even if Player4 wasn't on the square... all the data would have been shared anyway!

I hope this outlines why the argument for restricting data is logically incoherent: there is no 'ownership' of the data.  Any player involved in any combat (tournament or otherwise) can do whatever they want with the data from the combat report, and can share it all with whomsoever they like - and have been able to since the game began.

Regards,

SC


Posted By: The Reaper
Date Posted: 14 Apr 2016 at 23:12
That actually makes a hell of a lot more sense. Thanks.


Posted By: GM Stormcrow
Date Posted: 14 Apr 2016 at 23:16
Originally posted by Luffster Luffster wrote:

Cil - Thank you for taking your time on your holiday to look into the forum and put forward your points, I note that SC has not deigned to respond or to include the second and third points you put forward, but cherry pick your post to give his argument traction.

Then let me do so.

Originally posted by Cilcain Cilcain wrote:

Secondly, the use of the current Combat API for a player run tourney means that players must share this data with players outside of their alliance with whom they have probably had no previous dealings.  Your example of forwarding battle reports is generally done within the confines of an alliance – or more specifically, shared with specific leadership accounts within an alliance.  On the fewer occasions when reports are shared outside of an alliance, they tend to be on a battle by battle basis (see the first point above).

It seems fairly self-evident that in order to participate in a player-run tournament, you are going to have to share your data with the player who runs the tournament, with whom you may or may not have had previous dealings.  I'm not sure I understand what point is being made here.

Originally posted by Cilcain Cilcain wrote:

Thirdly, the current Combat API provides more information (or rather, the same information in more scenarios) than in-game battle reports do.  Currently, if I reinforce a square occupied by my Allies, Confeds or NAPs, I just get a report stating that my army has arrived, and the name of the player with the earliest occupying army.  However, using the API, I get an XML that details all of the armies on the square (including troop types and quantities) – i.e. you can scout without Scouts, even when the occupying armies have huge contingents of defending scouts themselves.  The same applies for reinforcing a city.
But when combat occurs on the square, you do get to know all the details of who was on the square with you.... they're your co-defenders in the combat report...

It makes total sense to me that when you are reinforcing with friendlies, you should know which friendly reinforcements are occupying the same square as you, as you're all fighting together.  In fact, and as has always been the case, when a fight *does* occur... you'd see all this data in the combat report (who you were fighting alongside) anyway.  It makes both logical and roleplay sense.

If there's anything in point 3 that isn't right, it's the initial email not telling you everyone who is on the square with you when you arrive; and maybe it should!

Regards,

SC


Posted By: GM Stormcrow
Date Posted: 14 Apr 2016 at 23:26
Originally posted by Mahaut Mahaut wrote:

Please stop with the emotive and sarcastic "secret" data digs. Most alliances especially military ones have thinsg they would prefer to not be widely known, nothing new there.
I'm sure alliances do have secret data.  But combat data is not secret and never has been... that's the point.  

The counterparty or counterparties to the combat (ie the people you are fighting with who are not you) have always had this information.  This is why I'm putting the word 'secret' in inverted commas.  It's not because I'm being sarcastic - it's because this data is not secret, and it never has been.

Originally posted by Mahaut Mahaut wrote:

And what you are saying is our members concerns are to be ignored. Whereas a reduced subset will make no difference to anyone else whatsoever.

I think my efforts to explain my position show that I'm not ignoring your concerns, and am actually going out of my way to allay them.  A reduced subset will make a difference - for all these reasons I'm attempting (clearly poorly) to explain.

Originally posted by GM Stormcrow GM Stormcrow wrote:

Incorrect, our concerns are simply that there is too much data, most of it completely unnecessary to the effective operation of a KoTHT. As Cilcain himself explained if a player makes a personal decision to share data by whatever means - it is his choice - if he chooses to copy paste he can delete data he doesn't want the recipient to see.
Sorry to come back to this, but a player cannot make a personal decision as to which data he or she wishes to share.  That decision is not his or hers to make as the data is, by default, out of that player's control, regardless of his or her wishes.

Regards,

SC


Posted By: Xmco
Date Posted: 14 Apr 2016 at 23:32
Originally posted by GM Stormcrow GM Stormcrow wrote:


The system that Cilcain is requesting we implement is, I'm afraid to say, entirely pointless - and let me explain why.

The system we're being asked to implement is that players have a restricted API key that allows players (through checkboxes) to choose what data is returned by their API key.


Regards,

SC


You are misrepresenting what has been requested, or maybe simply misunderstanding.

We have never asked for an API key that allows players (through checkboxes) to choose what data is returned by the API key. 

We have asked, politely and patiently, that an API key is provided by the DEVS that returns ONLY the information that is required to run a KOTH tournament.  (The Checkbox option was suggested to THE DEVS to allow them to quickly and easily produce API keys that would return appropriate information for future Tourneys). 

Is there any possibility of answering, without misunderstanding, why an API key that returns ONLY the relevant information to run Koda's tournament cannot be provided? 


Posted By: GM Stormcrow
Date Posted: 14 Apr 2016 at 23:35
Originally posted by Xmco Xmco wrote:


We have never asked for an API key that allows players (through checkboxes) to choose what data is returned by the API key. 

I'm not sharing private correspondences I may have had with any player, but you might want to check that assertion directly with Cilcain, Xmco.  

Regards,

SC


Posted By: Luffster
Date Posted: 14 Apr 2016 at 23:45
Originally posted by Xmco Xmco wrote:


Is there any possibility of answering, without misunderstanding, why an API key that returns ONLY the relevant information to run Koda's tournament cannot be provided? 

Regards

Luffy


Posted By: GM Stormcrow
Date Posted: 14 Apr 2016 at 23:47
Originally posted by Xmco Xmco wrote:



We have asked, politely and patiently, that an API key is provided by the DEVS that returns ONLY the information that is required to run a KOTH tournament.  (The Checkbox option was suggested to THE DEVS to allow them to quickly and easily produce API keys that would return appropriate information for future Tourneys). 
To answer the second part, though - the only way that this could work is if we *also* suppressed any data coming back from the FULL Combat API XML key for *all* other players related to combats on those squares - which might well pick up backlash from those players who want their API keys to work for all the combats that they participate in.

Subsequently, we would then have to tailor-make different API keys for every different non-KotH tournament; which would be subject to all the players who wish to participate coming to a common consensus of agreement as to what is the minimum data needed for that specific tournament to run properly.

That doesn't sound like a workable solution to me.

Regards,

SC



Posted By: GM Stormcrow
Date Posted: 14 Apr 2016 at 23:51
Originally posted by Luffster Luffster wrote:

Originally posted by Xmco Xmco wrote:


Is there any possibility of answering, without misunderstanding, why an API key that returns ONLY the relevant information to run Koda's tournament cannot be provided? 

Regards

Luffy
See above.


Posted By: Hyrdmoth
Date Posted: 14 Apr 2016 at 23:53
Originally posted by Luffster Luffster wrote:

Originally posted by Xmco Xmco wrote:


Is there any possibility of answering, without misunderstanding, why an API key that returns ONLY the relevant information to run Koda's tournament cannot be provided? 

Regards

Luffy
If I understand it correctly it is because such an API key would be pointless, because it only requires one participant in the combat to have shared their full API key - or to forward the IGM of the combat report - and all the data you wish to hide is no longer hidden.


Posted By: mjc2
Date Posted: 14 Apr 2016 at 23:56
Originally posted by Xmco Xmco wrote:


You are misrepresenting what has been requested, or maybe simply misunderstanding.

We have never asked for an API key that allows players (through checkboxes) to choose what data is returned by the API key. 

We have asked, politely and patiently, that an API key is provided by the DEVS that returns ONLY the information that is required to run a KOTH tournament.  (The Checkbox option was suggested to THE DEVS to allow them to quickly and easily produce API keys that would return appropriate information for future Tourneys). 

Is there any possibility of answering, without misunderstanding, why an API key that returns ONLY the relevant information to run Koda's tournament cannot be provided? 

as an aside since SC has already answered this.  lets assume the devs do make a specific API for a KotH  tourney, once they do that they are now putting themselves at the mercy of any other player that requests a specific type of API for any tourney they can come up with.  the only reasonable way they could do this without constantly being diverted from development to make these API keys is to use a checkbox system, and honestly i would rather have the developers working on other features to this game instead of creating lots of different types of API keys for individual situations.


Posted By: GM Stormcrow
Date Posted: 14 Apr 2016 at 23:56
Originally posted by Hyrdmoth Hyrdmoth wrote:

Originally posted by Luffster Luffster wrote:

Originally posted by Xmco Xmco wrote:


Is there any possibility of answering, without misunderstanding, why an API key that returns ONLY the relevant information to run Koda's tournament cannot be provided? 

Regards

Luffy
If I understand it correctly it is because such an API key would be pointless, because it only requires one participant in the combat to have shared their full API key - or to forward the IGM of the combat report - and all the data you wish to hide is no longer hidden.

^^ qft. Bingo.  Someone gets it!

Regards,

SC


Posted By: Rill
Date Posted: 15 Apr 2016 at 00:01
I think we are finally getting to the crux of the matter in Stormcrow's post above.

As I understand it, the reason the developers do not want to provide these more limited API keys is that they believe that producing API keys specific to players' desires to share information for a particular purpose would be a great deal of work and not widely used enough to make the process worth it.

The developers have shown themselves willing to make a more specific API key (the tournament squares key) for a purpose they perceive will see wide and repeated use.

I suggest that those who want some other specific type of API key develop a more cogent proposal, including examples in which the API key will be used in which existing tools would inadequate or undesirable, develop a broad consensus as to the need for such a tool, and present the proposal to the developers.


Posted By: GM Stormcrow
Date Posted: 15 Apr 2016 at 00:04
Originally posted by Rill Rill wrote:

As I understand it, the reason the developers do not want to provide these more limited API keys is that they believe that producing API keys specific to players' desires to share information for a particular purpose would be a great deal of work and not widely used enough to make the process worth it.

Nonononono...

It's that we cannot produce API keys specific to players' desires without also shutting off the Full Combat Report XML API that has been in place since 2010 for combats that occur on those squares otherwise it renders the limited key system either partially or wholly pointless.

Please, please.... let's not further muddy the waters :)

Regards,

SC


Posted By: GM Stormcrow
Date Posted: 15 Apr 2016 at 00:47
I should point out, because someone has asked for clarification.

It doesn't matter whether it's an individual checkbox system, or whether it's a pre-baked limited key system of agreed data for the tournament API key.  Think of the limited key pre-baked system as two checkboxes instead, one reading 'limited', the other reading 'full'.

So long as the *full* API key is also available to *any* of the combat participants, any limited keys are rendered wholly pointless for any combat that any participant was involved in, regardless of their 'limited'-key-only wishes *unless* the full key is simultaneously suppressed for everyone involved.

Regards,

SC


Posted By: Xmco
Date Posted: 15 Apr 2016 at 00:53
Originally posted by GM Stormcrow GM Stormcrow wrote:

Originally posted by Xmco Xmco wrote:



We have asked, politely and patiently, that an API key is provided by the DEVS that returns ONLY the information that is required to run a KOTH tournament.  (The Checkbox option was suggested to THE DEVS to allow them to quickly and easily produce API keys that would return appropriate information for future Tourneys). 
To answer the second part, though - the only way that this could work is if we *also* suppressed any data coming back from the FULL Combat API XML key for *all* other players related to combats on those squares - which might well pick up backlash from those players who want their API keys to work for all the combats that they participate in.


Thanks for the answers SC.

I understood that it was already established that the API key would only provide information on the Tourney tiles, rather than combats across the whole server.  Is that the case?  How will this affect players that want to use their API key for all combats they are participating in?

Edit: Ah - I see you already partly answered this above.  So if I understand correctly, the full API key will continue to run, alongside the key that only reports on tournament squares?

Originally posted by GM Stormcrow GM Stormcrow wrote:



Subsequently, we would then have to tailor-make different API keys for every different non-KotH tournament; which would be subject to all the players who wish to participate coming to a common consensus of agreement as to what is the minimum data needed for that specific tournament to run properly.



Rather than having to get a consensus of agreement on each subsequent tournament, it would be for the tournament organisers to give information to the developers about the minimum data that was required for their tournament.  It's to Koda and Digi's credit that they have been very clear about the minimum information that they would need to run their tournament, and it has shown them to be reliable tournament organisers. 

I'm sure the game would benefit from more players of similar credibility stepping up, taking responsibility for sensible data collating, and showing themselves to be honorable players. 




Posted By: Rill
Date Posted: 15 Apr 2016 at 01:00
I don't see how it is pointless.  It is only pointless IF someone chooses to share different information (the more full information).  You are assuming someone will.  I would suggest that is a risk people would knowingly take, that maybe someone will or maybe someone won't.

Unless you mean that sharing the more limited information would prevent someone else from sharing additional information?  I am completely open to believing that my understanding of API keys is incorrect, but here's how I understand it would work.

Player X announces a tournament.  He specifies that all people who are participating in the tournament will be asked to share a specific API key with limited information.  All the people involved in the tournament share that API key and only that API key with him.  Player X then only has access to the specific data people have shared.

Even if only MOST people involved only shared the more limited data, anyone wanting data for nefarious purposes would likely only be privy to a subset of data desired for nefarious purposes.

Now, if someone also shared another API key with player X, he would have access to different data for combats that someone participated in, including those of people who shared the more limited data.

But assuming say Player X ONLY was willing to take the more limited API keys, he ONLY could access the more limited data, right?

Trust is still involved in these situations, of course.  You have to trust that other players will provide the more limited key and that player X will only accept that key.  But it is likely in the self interest of all players involved to do so.  This makes it harder for one or two bad actors to subvert a whole bunch of data and makes everyone less dependent on trusting a single player.

Basically, it reduces the temptation to attempt to use player-run tournaments to try to gain a whole bunch of data that you then want to use in another way.  (Such as re-selling it for oodles of gold.)  One would like to think that this would never happen, but of course it would.  But if it is well known that the dataset is incomplete because a large portion of players did not share their full data, then this becomes less likely.

Basically it works off the principle that most people are trustworthy and a few people will be asses if it is to their advantage -- so it is best to limit the benefits of being an ass, in the interest of making things more fun for everyone.

Edited:  It also greatly reduces the pressure on people who want to run these tournaments, making it harder to accuse them of using data for nefarious purposes, and potentially making people more likely to want to take on that responsibility.  Thus it makes more events and a greater variety of events more likely.

In my mind, that is not pointless at all.


Posted By: Brandmeister
Date Posted: 15 Apr 2016 at 03:33
I know that people on this thread have good intentions, but I just find myself shaking my head.

An API is just a messaging interface between two architectural layers, with the added wrinkle that the programmatic interface has been made public. The developers are just allowing people a direct web access to their own complete battle report XML files. The addition of the encryption key is what allows players to identify they are a particular account owner to the system. By extension, this allows them to grant others access to their complete battle report XML files stored on the Illyriad servers.

Any request at a filtered API is a lot of additional extra work. What some of you are requesting is a user-configurable filter layer between the internal system battle report XML interface (which delivers a mail to your inbox) and the external API interface. That is not a trivial request. Right now the devs just give you the same basic data as your battle report. That's simple and maintainable.

The filtering request is also pointless. There are two points of potential spying: the person running the tournament, and your fellow alliance mates. Frankly, if you can't trust the person running the tournament, then why are you even participating? As for spies among your alliance mates sharing battle report information, they don't need an automated battle report API to accomplish that. Web-based collection makes it easier, but accumulating the information is trivial regardless. Again, if you can't trust your own allies to not publish alliance troop numbers, maybe you should reconsider your choice of allies.


Posted By: Gragnog
Date Posted: 15 Apr 2016 at 05:58
The easiest solution to this whole issue is the devs start to introduce tournaments again and stop trying to rely on a few really passionate players to keep their game alive. With all the data issues involved I am surprised that those players even bother. Thumbs up for Koda and his team and thumbs down for the devs in letting it get to this situation. Regular tournaments would have never let this moaning session arrise.

-------------
Kaggen is my human half


Posted By: Luffster
Date Posted: 15 Apr 2016 at 08:35
Originally posted by Gragnog Gragnog wrote:

The easiest solution to this whole issue is the devs start to introduce tournaments again and stop trying to rely on a few really passionate players to keep their game alive. With all the data issues involved I am surprised that those players even bother. Thumbs up for Koda and his team and thumbs down for the devs in letting it get to this situation. Regular tournaments would have never let this moaning session arrise.

Gragnog I totally agree!

Cheers

Luffy


Posted By: TheBillPN
Date Posted: 15 Apr 2016 at 12:35
My post 4 pages ago:

Originally posted by TheBillPN TheBillPN wrote:

I have a question Rikoo:

Given player concern about privacy issues and the effort of coming up with a player run tournament, wouldn't it have just been easier to use pre-existing code to automatically and with very little effort have a quarterly/big-annually/annually dev tourney? And surely you can very easily swap round the stlye of tourney for variation. 
I know you want players doing their own thing, and hats off to koda / digioso, but I'm sure this would have been far easier and made far more people happier. 

Given that you have already run tourneys, is it not just a matter of copy and paste? 
Sorry if this has been answered before, but I havent seen jt if it has.

Another post:

Originally posted by Luffster Luffster wrote:

Originally posted by Gragnog Gragnog wrote:

The easiest solution to this whole issue is the devs start to introduce tournaments again and stop trying to rely on a few really passionate players to keep their game alive. With all the data issues involved I am surprised that those players even bother. Thumbs up for Koda and his team and thumbs down for the devs in letting it get to this situation. Regular tournaments would have never let this moaning session arrise.

Gragnog I totally agree!

Cheers

Luffy


Totally agreed as well.


Posted By: Digioso
Date Posted: 15 Apr 2016 at 14:33
To add a bit on this.
Especially Rills last posting.

@SC:
My tournament script can only look at one type of key for each tournament.
So let's say there's a new tournament API that only has a limited amount of info.
We decide that we want to use this. That means we'll only get API keys for this.
So in that case we don't know any of the FULL-Combat-API-Keys and cannot query them.
Whether a participant shares his FULL combat key with someone else or not is of no concern for the tournament in this case.

This would fix the issue that the tournament administrator knows information that he does not need to run the tournament. In our case:
Attacker, Defenders, Occupation Time in secs, Fake Attack yes/no, Combat occurance date and who is the winner of the battle. The latter could be a simple boolean: Attacker has units left yes/no - Defenders have units left yes/no. My script does nothing else to determine the winner of the battle.
0 = Defender lost everything
1 = Attacker lost everything
2= Both have units left (EG when the attack is a raid)
Yeah I have three values so it's not a boolean, but... blah. :P

This would address the trust concerns that data about army sizes gets leaked by the tournament administrator or may be used by the tournament administrator in the future in case his alliance engages against another. Because the admin only knows who attacked and who won.


-------------
http://www.digioso.org" rel="nofollow">


Posted By: Cilcain
Date Posted: 15 Apr 2016 at 15:36
SC,

You have mentioned a couple of times that the current Combat API has been in use since 2010, and infer “what’s the fuss about?”

Well, the fuss is due to the fact, that all players on the server are now being asked to provide their API key to a peer – this as far as I know is unprecedented.  Yes, Alliances (and possibly Confeds) have shared keys in the past, but that was for completely different reasons – for which the existing API is suitable.

All players now face the option of sharing all their data (automatically and without discretion) with a peer, or to continue in the drought of “regular Tournaments”  [ http://www.illyriad.co.uk/GameInformation/Military" rel="nofollow - http://www.illyriad.co.uk/GameInformation/Military ], which until now (and I use the word “now” loosely) have been run by Devs and not players.

I have always maintained that a Tourney API could co-exist with the current Combat API – I have never suggested retiring it – and therefore, I am not wishing to impose anything on anyone.

A tourney organiser could quite happily say that they will accept either API key to run a tourney – as both would have the required data (it’s just one would have additional data unnecessary to the tournament).  But I bet, if players were given this option, most would go for the Tourney API.

Yes, there would always be some cases where the effects of the Tourney API in a battle are overridden by the presence of the Combat API in the same battle – but if most people in the tourney are using the Tourney API, then the volume and completeness of data from the Combat API will reduce such that it becomes less viable to use for unintended purposes.

Also, in one of your posts, you may have inadvertently given the impression that throughout this thread, I have been arguing for the ‘checkbox API’ option – it should be clear to anyone reading this thread that I have not.  It was, I agree, one of a number of initial ideas you and I discussed, but was quickly shelved.  I am happy to quote from our convo if necessary and with your permission.

I must go now, as I have an update meeting with my development team for them to demo the suite of B2B APIs they have developed this week.

Regards,

C



-------------
http://elgea.illyriad.co.uk/a/p/77750" rel="nofollow">


Posted By: BARQ
Date Posted: 15 Apr 2016 at 16:14
stop shouting on API thing and ask devs for regular dev run tourneis . u'll enjoy tournaments without giving anyone ur API key prob solved

-------------
I m the most scarring dream of your life


Posted By: Mahaut
Date Posted: 15 Apr 2016 at 16:30
Strangely Barq, thats been tried. In spite of their own blurb saying "regular tournaments" (screenshotted by the way) apparently "regular" means once every two to three years if we're lucky.

In general I think a lot of players would like to see the devs returning to the game to run tournies like they used to. I know I would.

We're currently fighting a rear guard action here to try to get player run tournies as secure as possible.



-------------


Posted By: GM Stormcrow
Date Posted: 15 Apr 2016 at 22:17
Hi everyone,

I suggest people read all the way through before hitting reply!

Originally posted by Cilcain Cilcain wrote:

I have always maintained that a Tourney API could co-exist with the current Combat API – I have never suggested retiring it – and therefore, I am not wishing to impose anything on anyone.

A tourney organiser could quite happily say that they will accept either API key to run a tourney – as both would have the required data (it’s just one would have additional data unnecessary to the tournament).  But I bet, if players were given this option, most would go for the Tourney API.
I think I've made it clear that I believe this position is illogical enough times not to have to do it again :)

Originally posted by Cilcain Cilcain wrote:

Also, in one of your posts, you may have inadvertently given the impression that throughout this thread, I have been arguing for the ‘checkbox API’ option – it should be clear to anyone reading this thread that I have not.  It was, I agree, one of a number of initial ideas you and I discussed, but was quickly shelved.  I am happy to quote from our convo if necessary and with your permission.
Sadly we don't permit the publication of conversations with the dev team.  I certainly acknowledge you requested this feature, we discussed it and shelved it.  However, I do hope you will agree that the system you *are* requesting (a limited dataset to coexist with a full dataset) is functionally and logically the same as a checkbox system.

At most, the minor semantic difference between the two is that the fixed-dataset limited key system is a radio button (coexisting with the full dataset) rather than a flexible-dataset checkbox system (also coexisting with the full dataset).  The point is that the issues associated with implementing it are the same: different players choosing to share different sets of data, with the more-open players' wish to share data inevitably trumping the less-open players' wish to suppress data.

-----

@TheBillPN, @Luffster, @Gragnog
You guys have asked why we (the dev team) don't just run a tournament ourselves.

One of the (only six!) founding principles of the company, which http://www.illyriad.co.uk/GameInformation/Principles" rel="nofollow - we published way back in 2009  when the game first started, is that "There’s no in-game content that’s as compelling to players as player-created content."  We still believe this passionately.

Player-run tournaments are an attempt to further that part of the Illy sandbox, and we are keen to get player-run tournaments off the ground and see how they go.  

For example, I think it's awesome that part of this tournament's objectives is to highlight Neurofibromatosis - and that wouldn't have happened if we'd put a tournament together.

-----

Partly because I've run out of energy to further discuss what seems self-evident to me, but mostly because we actually want to see a player-driven tournament succeed, and especially given that the tournament organisers themselves have requested this limited data API key - I agree: we'll implement the limited tournament data key.

Some caveats/notes:
1. Full combat API key
It'll be up to digi and Koda if they also accept the full API key as well.  Cilcain has said he's fine with them running in parallel (so there's no issue there).  But it's your call.

2. Limited key specification
Digioso, I know you made a brief specification a couple of posts above, but I think it needs some clarification and refinement.

Amongst many data fields I believe you would want, your specification is missing some key ones, such as <combatoverview><location>.  I imagine it'd be hard to hand out your Regional Winner prizes if you don't know which square any of the participants arrived at Big smile

And I specifically need to know what data you want in the <participant> fields, as I believe Cilcain wants (eg) player town repressed from these fields.

As you guys (the tournament organisers *and* the limited-data-crew collectively) are defining what the limited dataset should actually consist of, I will need you to produce a collectively-agreed sample xml file that contains only the data fields you want shared; and I will code to that sample file.

I will add, from some prior experience, that you should carefully consider what makes a tournament exciting to not only participate in, but also to watch - and I'd caution against kneecapping "fun" in the name of limiting data.  For example, a tournament without a visible casualty count (and only with the proposed win/lose/draw) is not that much more than a ranked list of alliances, and I believe would lose the 'epic'.  

But this is, as I hope is now crystal clear, entirely your call.

3. Square and key timestamp limits
As I mentioned earlier in this thread, I'll be fixing the key time bug (for both the tournament and the full API key) where a reissued key produces data that precedes the new key issuance datetime back to the original key issue datetime.

I'll also be ensuring that the tournament API key only returns data from the specifically designated tournament squares.

4. Development schedule
I don't currently have any time in the development schedule for this work, and - depending on how long it takes you to get a mutually acceptable (between the tournament organisers and the limited-data-crew) sample xml file put together - I can then see when we can slot some development time in to make this change.  We may not make May 17th, but I will keep you posted.

-----

tldr;

Fundamentally, I want player-run tournaments to work, and although I wholeheartedly disagree with this limited-data tournament key... if it's the only thing that'll make this tournament fly - and if it's what the organisers of the first player tournament also want - then "what the hey, let's give it a whirl and see where we end up".

Regards,

SC


Posted By: Digioso
Date Posted: 15 Apr 2016 at 22:23
Thanks SC. :)
I'll work out a sample XML that would suffice for this tournament.


-------------
http://www.digioso.org" rel="nofollow">


Posted By: kodabear
Date Posted: 15 Apr 2016 at 22:34
I personally don't like the idea of limited-data tournament key. Yes they will work with King of the Hill Tournament but other type of Tournament they will be force to use the combat API key or the devs make new API key for everytime of Tournament. Having said that as long Digioso is fine with it and is willing to be in the work I am ok with it


Posted By: Cilcain
Date Posted: 15 Apr 2016 at 23:45
SC,

I appreciate that even in the absence of us agreeing on many points, you are willing to go ahead with the Tourney Key, so thank you.

Digioso - I'll be happy to work through the xml with you, I will message you separately.

Koda, I'm sure we will come up with something to address your concerns.

C

-------------
http://elgea.illyriad.co.uk/a/p/77750" rel="nofollow">


Posted By: kodabear
Date Posted: 15 Apr 2016 at 23:53
the limited-data tournament key must include casualties doesn't matter if say what type of units but i do want the casualties as part of the Tournament 


Posted By: Cilcain
Date Posted: 16 Apr 2016 at 00:09
Originally posted by kodabear kodabear wrote:

<span style="line-height: 16.8px;">the limited-data tournament key must include casualties doesn't matter if say what type of units but i do want the casualties as part of the Tournament </span>


Agreed. It's the troop count we object to, not the casualties.

C

-------------
http://elgea.illyriad.co.uk/a/p/77750" rel="nofollow">


Posted By: Rill
Date Posted: 16 Apr 2016 at 00:28
GM Stormcrow, thank you for taking the time to listen to and interact with players.  To me, that is the most important thing that has happened here, and an example of what makes Illy such a great place to play.  Hard to find this level of engagement and frank exchange (from both sides) almost anywhere in the gaming world.

You rock!


Posted By: palmz
Date Posted: 16 Apr 2016 at 00:42
I agree the the data should not be so limited that the key will only work for this type of tournament. 

If it is done right the first time it may add a huge amount to the game, depending on how we (the players) use it. And that is my two cents added. Big smile


Posted By: Tensmoor
Date Posted: 16 Apr 2016 at 11:56
Originally posted by Rill Rill wrote:

GM Stormcrow, thank you for taking the time to listen to and interact with players.  To me, that is the most important thing that has happened here, and an example of what makes Illy such a great place to play.  Hard to find this level of engagement and frank exchange (from both sides) almost anywhere in the gaming world.

You rock!


I have to agree wholeheartedly with Rill on this.


Posted By: Dungshoveleux
Date Posted: 16 Apr 2016 at 12:46
The meaningful frank exchange of views gives me hope that an acceptable solution will be taken care of.  Hopefully this will herald an increasingly broader concept of "community" with the user base becoming increasingly involved in direction and development.  I think that, at present, the Illyriad gaming model requires changes to increase its stability, and these events give me hope that they will be addressed.  It is ultimately all about keeping customers happy and loyal by communicating with them and involving them.  Fingers crossed Eh? 


Posted By: GM Stormcrow
Date Posted: 16 Apr 2016 at 15:37
Originally posted by Cilcain Cilcain wrote:

Originally posted by kodabear kodabear wrote:

<span style="line-height: 16.8px;">the limited-data tournament key must include casualties doesn't matter if say what type of units but i do want the casualties as part of the Tournament </span>


Agreed. It's the troop count we object to, not the casualties.

C

I think the best approach would be "What are the minimum data fields that need to be suppressed?" rather than "What are the minimum data fields that need to be there?" - as then the final key might have further applications outside a purely-KotH tournament.

Regards,

SC


Posted By: Digioso
Date Posted: 17 Apr 2016 at 08:51
My suggestion would be this:

For the combat report overview (API-Key):
<combateventsapi>
    <server>
        <datagenerationdatetime></datagenerationdatetime>
    </server>
    <player id=""/>
    <playerapikey id=""/>
    <combatevents>
        <uniquecombatidentifier>
            <server id=""/>
            <combatguid id=""/>
            <troopmovementevent id=""/>
            <datacomplete id=""/>
            <personalcombatkey id=""/>
            <combatoccurrencedate></combatoccurrencedate>
        </uniquecombatidentifier>
    </combatevents>
</combateventsapi>

Here it would also be nice if you could include the X/Y coordinates as well. Not only for the tournament API but for the normal API as well.
If a tournament only happens on specific squares we can skip reading unneccessary reports.
For the tournament API this doesn't really matter because it'll only provide reports for tournament squares. But it would be nice to have for the normal API.

Fot the specific combat report:
<combatevent>
    <server>
        <datagenerationdatetime></datagenerationdatetime>
    </server>
    <personalcombatkey id=""/>
    <uniquecombatidentifier>
        <server id=""/>
        <combatguid id=""/>
        <troopmovementevent id="" occurrence_datetime=""/
        <datacomplete id=""/>
    </uniquecombatidentifier>
    <combatoverview>
        <location>
        <X></X>
        <Y></Y>
        <terrainspecifictype id=""></terrainspecifictype>
        <terraincombattype id=""></terraincombattype>
    </location>
    <datetime>
        <combatoccurrencedate></combatoccurrencedate>
        <occupationlengthsecs></occupationlengthsecs>
    </datetime>
    <stratagem>
        <armyaction id=""></armyaction>
        <feint>Yes/No</feint>
    </stratagem>
    <participants>
        <participant>
            <role></role>
            <player>
                <playername id=""></playername>
                <alliance id="">
                    <allianceticker></allianceticker>
                    <alliancename></alliancename>
                </alliance>
            </player>
        </participant>
    </participants>
</combatevent>
   
Either: total casualties for the whole battle or casualties per side:
EG Defender(s) lost x troops and Attackers lost x troops

And we need to have an identifier which side is left standing after the battle.
<winner></winner>
EG:
0 = Attacker
1 = Defender(s)
2 = Both are left (EG after a raid)


-------------
http://www.digioso.org" rel="nofollow">


Posted By: GM Stormcrow
Date Posted: 17 Apr 2016 at 18:35
Awesome.  Is this a list that everyone's agreed on?  Speak now, or forever hold your peace!

I'm assuming you want me to supply <winner id="2"> if combat does not occur?

SC


Posted By: Digioso
Date Posted: 17 Apr 2016 at 18:56
So far that's the list I need. :D

Hmm... that's a good question.

Can you put a 0 (attacker wins) in there if there is no defense (= square was onuccupied)?
And a 2 (no winner) if the new army is sent as a reinforcement?

Then I can do:
If winner == 2
    if casualties == 0
            army must be a reinforcement
    else
            a battle took part but both sides survived. In our case that means that the defender is still holding the square.


-------------
http://www.digioso.org" rel="nofollow">


Posted By: GM Stormcrow
Date Posted: 17 Apr 2016 at 19:59
Originally posted by Digioso Digioso wrote:


If winner == 2
    if casualties == 0
            army must be a reinforcement OR A FEINT
    else 
            a battle took part but both sides survived. In our case that means that the defender is still holding the square.
Added at least one other circumstance above; there may be other scenarios you need to consider for your win/loss/draw calculation.

Regards,

SC





Posted By: Cilcain
Date Posted: 18 Apr 2016 at 10:04
Digioso/SC,

 

That XML looks fine.

I would suggest that battle casualties are per side rather than for the battle as a whole – this would make reporting on the tournament more meaningful.

One observation though, the <personalcombatkey id> will need to have a different value to that returned from the current ‘combatreportsapi’ API, otherwise it would be possible to obtain the <personalcombatkey id> via the new tournament version of ‘combatreportsapi’ and then feed it into the existing ‘combatreport’ API and get the full data set.

(X,Y) co-ords from the first API is a good idea, as it will mean you do not have to execute the detailed process for squares you are not interested in (e.g. if someone in the future just wants to run a BL tourney)

 

C



-------------
http://elgea.illyriad.co.uk/a/p/77750" rel="nofollow">


Posted By: kodabear
Date Posted: 18 Apr 2016 at 10:22
What will this  limited data Tournament api key show if one of the Faction attack one of the Tournament Squares?


Posted By: kodabear
Date Posted: 18 Apr 2016 at 21:28
Something that would be great, if you guys added when Messenger recall an army to the Tournament API.


Posted By: GM Stormcrow
Date Posted: 18 Apr 2016 at 22:51
Originally posted by Cilcain Cilcain wrote:

I would suggest that battle casualties are per side rather than for the battle as a whole – this would make reporting on the tournament more meaningful.

Sure, can do.

Originally posted by Cilcain Cilcain wrote:

One observation though, the <personalcombatkey id> will need to have a different value to that returned from the current ‘combatreportsapi’ API, otherwise it would be possible to obtain the <personalcombatkey id> via the new tournament version of ‘combatreportsapi’ and then feed it into the existing ‘combatreport’ API and get the full data set.
Well, any player involved could of course have just supplied their full API key instead, but yup, can do.  

I just don't want any player thinking that because they have supplied a tournament-only API key, they have an expectation that the only data getting shared is what they wanted shared - because that's not necessarily the case.  If I ever hear "But I only supplied my tournament API key... why is all my secret combat info plastered across this tournament summary?", I shall refer said player to you guys to explain the logic behind it Big smile

Originally posted by Cilcain Cilcain wrote:

(X,Y) co-ords from the first API is a good idea, as it will mean you do not have to execute the detailed process for squares you are not interested in (e.g. if someone in the future just wants to run a BL tourney)

 

As it's not needed for this tournament, I won't implement now - esp as the next one may have other requests/refinements.  But I agree that this would be useful.

Originally posted by kodabear kodabear wrote:

What will this  limited data Tournament api key show if one of the Faction attack one of the Tournament Squares?

No idea, I'm afraid, but it'd be the same as whatever currently appears in the XML for an attack by a faction (at the listing level) and the same, but slimmed data fields as specified, at the individual report level.

Does anyone have a combat report individual XML link from when they were attacked by a faction that they wouldn't mind sharing publicly?

Originally posted by kodabear kodabear wrote:

Something that would be great, if you guys added when Messenger recall an army to the Tournament API.

That's not going to happen in the Tournament API as it's an entirely different dataset, format, and functional bucket to combat.

We are looking into producing a diplo key API for all diplomatic unit events including messengers, but that's a way away.  And then we can have a discussion about producing a limited version of it too, as well Smile 

Regards,

SC



Posted By: kodabear
Date Posted: 18 Apr 2016 at 22:57
<participants>
<participant>
<role>Attacker</role>
<player>
<playername id="-1"/>
<troopsfromtown id="-1"/>
<alliance id="0">
<allianceticker/>
<alliancename/>
</alliance>
</player>
<armies>
<army>
<armyname id="0"/>
<divisions>
<division>
<divisionname id="0"/>
<units>
<unit>
<unitname id="726">Warrior Chiefs</unitname>
<unitquantity>82</unitquantity>
<unitcasualties>82</unitcasualties>
</unit>
</units>
</division>
</divisions>
</army>
</armies>
</participant>
<participant>


Posted By: kodabear
Date Posted: 18 Apr 2016 at 23:05
Originally posted by GM Stormcrow GM Stormcrow wrote:

Originally posted by kodabear kodabear wrote:

Something that would be great, if you guys added when Messenger recall an army to the Tournament API.

That's not going to happen in the Tournament API as it's an entirely different dataset, format, and functional bucket to combat.

We are looking into producing a diplo key API for all diplomatic unit events including messengers, but that's a way away.  And then we can have a discussion about producing a limited version of it too, as well Smile 

Regards,

SC


I had guess as much it wouldn't be able to add to the Tournament API


Posted By: GM Stormcrow
Date Posted: 18 Apr 2016 at 23:59
Originally posted by kodabear kodabear wrote:

<participants>

<XML> snipped



Hi Koda,

Not sure what that xml snippet was related to, but as far as I know that's absolutely *not* what people want in this limited key, including (as it does) total troop counts, town names, army names, division names, unit types etc.

Regards,

SC
 
EDIT:  Oh wait... is that the faction attack return?



Print Page | Close Window

Forum Software by Web Wiz Forums® version 12.03 - http://www.webwizforums.com
Copyright ©2001-2019 Web Wiz Ltd. - https://www.webwiz.net