Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add possibility to count strongholds to the system (payout currently affected) #38

Open
enbewu opened this issue Oct 15, 2014 · 17 comments

Comments

@enbewu
Copy link

enbewu commented Oct 15, 2014

I propose to add strongholds to the system which currently would affect only payouts. For the time being it would be great to input the amount of earned points in the given time interval and add an option to add a point value to each point. Most probably this would be some fraction number, i.e. resources/inputed value

PS. I finally got more time and got the system running on my local machine, I'll try to add next tickets with real-life previews. Hope this helps mate.

@ceari
Copy link
Owner

ceari commented Oct 18, 2014

I'll look into it tomorrow but I'm not sure I understand your explanation of the points distribution. Can you rephrase that please?

Any help is appreciated of course.

@enbewu
Copy link
Author

enbewu commented Oct 19, 2014

Because I'm not quite sure, where I'd put this functionality in and what is possible and what's not.

Basically my whole idea resolves around the "resources" gathered in strongholds which would be the base to know which players are active in strongholds and which are not when it comes to paying out gold.

I'm thinking currently of an implementation in the Payout screen where users with addequate role types could provide info on how many resources each player got, provide info on how much do we value those points (exactly the same implementation as for the payout modifier for recruits I asked about recently) and click the Payout - the system would use this data to add points and give info on how much gold each player should receive.

For example: a player earned 1000 resources in strongholds, we decide that each resource is worth 0.01 regular point in CW which means that the user earned additional 10 points for the Payout calculations.

Is it more clear now?

@ceari
Copy link
Owner

ceari commented Nov 8, 2014

Apparently the replay files contain the resources earned by players so ideally the tracker would get all the information from that. The problem with also tracking stronghold battles is that this will interfer with the activity calculations for normal clan wars and the concept of reserve doesn't make much sense. Separating stronghold battles from clan wars will require quite some coding work though.

Your suggestion would be more simple to implement but I'm not really playing the game at the moment so my motivation to work on the tracker isn't the highest, sorry! Can you use an Excel sheet to post-process the payout calculations and factor in resources for now?

@enbewu
Copy link
Author

enbewu commented Nov 8, 2014

Personally I think that reserves don't make sense either way - even without counting the stronkholds. From what I see in the clans (not only the ones I'm in like PSQD and PTS), stronkholds are currently as important or even more important for CL's than CW.

But the biggest flaw of the current implementation of reserve are the players who rarelly use this functionality or assign themselves to each battle. Better implementation would involve a Windows app/widget that would have to be run in the background - there was one such implementation couple of years ago.

So from my perspective if the reserves are the biggest obstacle, I'd say to scrape them and implement stronkholds.

I wouldn't like to see the project going down, especially that a lot of clans are using it. Let me know if there would be anything to help your motivation (really). Or maybe join PSQD or PTS? ;)

ceari added a commit that referenced this issue Nov 8, 2014
Resources earned by players are determined from the replay file and stored
in the database. In the payout form the number of points to give for each resource
earned can be entered and is factored into the gold share calculation.

Feature request from #38
@ceari
Copy link
Owner

ceari commented Nov 8, 2014

Oh well, I started working on it ... still needs work with the reserve system etc. but if you have a local installation of the tracker working please try it with some stronghold replays: https://github.com/ceari/whyattend/archive/feature/strongholds.zip
It requires a database upgrade again (alembic upgrade head).

I forgot how to play the game by now so I would be useless for PSQD or PTS but thanks for the offer :-)

@enbewu
Copy link
Author

enbewu commented Nov 9, 2014

Super unicum will always be unicum :)

Thank you that you did find some motivation tho, I'm just backing up my setup and will try this.

@enbewu
Copy link
Author

enbewu commented Nov 10, 2014

On new setup, the feature works for strongholds but doesn't allow to upload CW battles.

127.0.0.1 - - [10/Nov/2014 17:14:53] "POST /battles/create HTTP/1.0" 500 -

That's the whole output I'm currently getting.

@uetam
Copy link

uetam commented Nov 10, 2014

I have the same error.

ceari added a commit that referenced this issue Nov 10, 2014
@ceari
Copy link
Owner

ceari commented Jan 26, 2015

Merged into master. Needs a database upgrade (alembic upgrade head) if not done yet.

Have any of you used this feature after my bugfix in November or did it not work?

@enbewu
Copy link
Author

enbewu commented Jan 26, 2015

Checking this right now, but I also were afb for a long time, so give me a while :)

@enbewu
Copy link
Author

enbewu commented Jan 26, 2015

ATM all seems to be working, the only thing that would be good to have is a distinction on the list that it's not a regular CW battle

@ceari
Copy link
Owner

ceari commented Jan 26, 2015

It should say "Stronghold" in the Type column of the battles list.

@enbewu
Copy link
Author

enbewu commented Jan 26, 2015

Nope, it doesn't. Either I'm blind, did something wrong or it doesn't :)

@ceari
Copy link
Owner

ceari commented Jan 26, 2015

Hm strange, it seems the "battleType" in the replay changed from 10 to 11 for Strongholds since November or I somehow did not test with the code I committed back then .. Oh well, it should work now.

Quite annoying to test without replays from my own clan by the way, I have to disable all validation for the clan, players etc. :(

@ceari
Copy link
Owner

ceari commented Jan 26, 2015

Actually, there are "skirmishes" = 10 and "battles for stronghold" = 11 and only the skirmish replays contain an amount of resources earned. Back when I played there was no "battle for stronghold". Does it make sense to track stronghold battles when we can only get the resources for skirmishes?

@enbewu
Copy link
Author

enbewu commented Jan 28, 2015

That's interesting. Battle for stronghold is actually the more important one as the clan gets the most of it (resources)

I understand that you refrain from playing currently (can't blame you :) so - the battle for stronghold looks like a ladder for a landing province. Clans fight for each building that is on their path, sometimes fighting couple of times for the same building - it depends on their success rate. A typicall good clan has at most 3-4 battles for stronghold. Therefore it makes sense that there are no resources in the replay as it's calculated after the whole battle ends.

From here I see two options, with one common issue: detect both types of battles, add description 10 = "Skirmish", 11 = "Stronghold"

  1. Scenario - try to sum the resources from the skirmishes, and option to update earned resources per player in the Payout screen
  2. Ditch the resources completely and just add strongold+skirmish battles to player activity.

In fact, I just came up with the idea, that in the second option we might just split the activities: one for CW and other for Strongholds and duplicate the system of points for being in the battle like in CW.

@ceari
Copy link
Owner

ceari commented Feb 6, 2015

Both options are possible, I think the second one requires quite some changes overall though.

Unfortunately I can't promise when I start to work on this - I'm really busy with work again and not in the mood to work on side projects, sorry. Next weekend might be better.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants