Topic: Rating system

Tabs can be imitated by different pages , or loading on user demand. Frontend and API for that can be done in the future. No worries.

Hope your branch will be soon available on widelands alpha site (@kapputnik, is it possible to test it there? Can you remember link to that page?)

But I have a question: how input is sent to the ranking engine? Do you have proper page or so?

EDIT: by imitating tabs, go to your profile page here, in Widelands: https://www.widelands.org/profile/ . You will see tabs, but all of them are just different pages, reloaded on user needs. So they are not "real" tabs. That is the easiest solution for making tabs.

einstein13
calculations & maps packages: http://wuatek.no-ip.org/~rak/widelands/
backup website files: http://kartezjusz.ddns.net/upload/widelands/

Top

Quote

Hope your branch will be soon available on widelands alpha site (@kapputnik, is it possible to test it there? Can you remember link to that page?)

Huh, that would be cool, although maybe complicated because you need to be admin in order to add games.

But I have a question: how input is sent to the ranking engine? Do you have proper page or so? face-smile.png

Proper? What does that mean? I take the request and create from there. Something like:

# data html handling
def process_data_from_html(r):
    results_list = clean_list(r['result'].split(','))
    tribes_list = clean_list(r['tribes'].split(','))
    players_list = clean_list(r['players'].split(','))
    data = {}
    data['participations'] = []

    for num, player in enumerate(players_list):
        print (player, num, tribes_list[num], results_list[0])
        participation = {}
        participation['user'] = player
        participation['team'] = num #to change for bigger team than 1vs1
        participation['submitter'] = False
        participation['tribe'] = type_to_int(tribes_list[num])
        data['participations'].append(participation)

    data['win_team'] = results_list[1] #to change for bigger team than 1vs1
    return data

But I don't use the form directly. I see you guys did that on other modules. Like here:

class ArticleForm(forms.ModelForm):

    summary = forms.CharField(widget=forms.Textarea)

    comment = forms.CharField(required=False)

    content_type = forms.ModelChoiceField(
        queryset=ContentType.objects.all(),
        required=False,
        widget=forms.HiddenInput)
    object_id = forms.IntegerField(required=False,
                                   widget=forms.HiddenInput)

    action = forms.CharField(widget=forms.HiddenInput)

    class Meta:
        model = Article
        exclude = ('creator', 'group', 'created_at', 'last_update')
.......

I guess that's the clean way to do it. I would need to study how that works a bit before implementing. But yes, ultimately, at the very least for code consistency, that's what I should do.

EDIT: by imitating tabs, go to your profile page here, in Widelands: https://www.widelands.org/profile/ . You will see tabs, but all of them are just different pages, reloaded on user needs. So they are not "real" tabs. That is the easiest solution for making tabs. face-wink.png

Yes yes, I see what you mean. You're right, but maybe there is another UI solution?

The tables for 'Ratio Score' and 'Glicko Score' can be side by side i think.

That might be the easiest solution, but I'm afraid people will get confused as to which score is the official one. If we separate the pages, we would redirect the user to the 'glicko rank directly.

Another option could be to merge the two and just put the winrate in the same table. We don't really need a ranking using winrate maybe?

But i am a bit confused about why we need two different calculations here.

At first it was for tests yes.

But, I also see a place for it in the future. Afterall we need to find a place where the winrate is close to 50% for most people. So showing the winrate of most players would be a good indicator if we get closer to our goal or not.

Top

Quote

huh. So now I wonder. Should I rather remove the current page I made for adding games? Knowing I already added some more buttons to calculate score etc.

Maybe we could have both, but I'm afraid that would be much more confusing

Top

Quote

kaputtnik wrote:

Calculating the score should be done in the save() method of the model, imho.

For the beggining - yes, but since we want to have more possibilities (examples!):

• adding new rank system (seasonal, secondaries for any needs, maybe tournaments too)
• handling / using multiple rank systems at once
• recalculating any of them on need (button?)

Putting all calculations on save() method would be enough for now, but in the future it would cost us. BUT we don't have to do everything .
The best solution is to create an asynchronous calculations, but it will be quite hard for maintenance (I used celery for that purposes, but I haven't done it on pure server, just on localhost).

Maybe we could have both, but I'm afraid that would be much more confusing

We can have both

I agree - let's make both ways and decide which one will be better . Finally we can stay with the simplest version .

I would suggest to add the admin page and then you can play around with it. But honestly i think using the admin page directly is much easier than adding another view

I agree in 80% of cases. And this is one of them.

einstein13
calculations & maps packages: http://wuatek.no-ip.org/~rak/widelands/
backup website files: http://kartezjusz.ddns.net/upload/widelands/

Top

Quote

Don't forget to merge the latest changes in your branch

Top

Quote