Please upgrade here. These earlier versions are no longer being updated and have security issues.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

Having Trouble Getting Consistency in Karma Rewards

kirkpa31kirkpa31 ✭✭
edited April 2013 in Vanilla 2.0 - 2.8

Ok - Here's my situation. I've used all three of the operations - Equals, Every, and DiffEquals. For each one I come up with different things that get screwed up in tests.

When using DiffEquals: This is where I have gotten the closest to being completely accurate. I've deleted all the GDN_Karma tables through phpMyAdmin, deleted the plugin and reinstalled it. I've changed the code following x00's recommendation. What happens is that all of the user's prior information gets perfectly translated into Karma rewards (i.e. previous accepted answers get totaled perfectly and the points translate perfectly as well). What screws up is when new information is added. Sometimes negative values appear for a user when they log on after getting two or three thanks (after adding the Thankful People integration). Sometimes the Karma balance isn't increased after a user has an answer accepted, and then after getting two or three more accepted answers their balance gets negatively affected.

Does anyone know why negative values sometimes appear and why sometimes QnACountAcceptance values don't get counted?




using Vanilla 2.0.18.8

Comments

  • Basically I guess what I'm asking is:

    When is the correct time to use DiffEquals, Every, or Equals.

    From my trial and error I have set my webpage to use DiffEquals for QnACountAcceptance and ReceivedThankCount - the two that happen to a user while they are not logged into the forum.

    I have set the operation to Every for CountComments and CountDiscussions - the two that happen while the user is already logged in.

    This appears to be the best possible solution, but in testing I still occasionally get negative values for QnACountAcceptance after a user logs in and their ? has been accepted.

  • I would just use Every on everything that should just accumulate such as QnACountAcceptance.

    grep is your friend.

  • kirkpa31kirkpa31 ✭✭
    edited April 2013

    I would just use Every on everything that should just accumulate such as QnACountAcceptance.

    Using Every results in an issue where if two or more of a user's answers are accepted before they log back in, they only receive credit for one. DiffEquals using that fix you've recommended changing:

    return abs($Difference)!= $Difference? -1:1;

    to

    return $Difference;

    is this only way I can get any of the operations to accumulate properly and give credit. Just occasionally get negative values. I will continue to play around with various tests though. Thank you!

  • per this discussion: http://vanillaforums.org/discussion/comment/159464/#Comment_159464

    I have forgotten to delete the Karma Cache folders before changing each of the rules - I think this solves the issue.

  • kirkpa31kirkpa31 ✭✭
    edited April 2013

    Ok ^^^^ that didn't work - I've even created a brand new test site, brand new database - loaded only the QnA plugin and Karma Bank - set

    Meta QnACountAcceptance DiffEquals 1.00 Make transaction of 5.00 Karma

    and I immediately got a -10.00 value for one accepted answer. I am going to look into modifying either the "Equals" or "Every" meta to work with accumulated totals (i.e. what I've referenced above - accumulate QnACountAcceptance when user is not logged in) like DiffEquals sometimes does - by making either one of them retrospective, by modifying this code:

    public static function OperationEquals($MetaValue,$Target,$Condition,$User,$LastTrans,$Option){
        return $MetaValue == $Target;
    }
    
        public static function OperationEvery($MetaValue,$Target,$Condition,$User,$LastTrans,$Option){
            return $MetaValue % $Target == 0;
        }
    

    with the DiffEquals code:

        public static function OperationDiffEquals($MetaValue,$Target,$Condition,$User,$LastTrans,$Option){
            $Difference=$MetaValue-($LastTrans ? $LastTrans->LastTally : 0);
            if($Difference && abs($Difference)%$Target!==0)
                return FALSE;
            return $Difference;
        }
    

    If there would be a way - for example - to reward QnACountAcceptance points based on changes in the QnACountAcceptance value in the GDN_User table since the last time they logged in - that would fix it. Only I do not know how yet.

  • x00x00 MVP
    edited April 2013

    you are no likely get what you want by modify these operations. They are very straight forward.

    The problem most likely lies in the comparison.

    $LastTrans->LastTally and $MetaValue it could a collision issue, or some other problem.

    You could debug by logging these values over time see how it goes.

    grep is your friend.

  • $Marketplace ?

    I am not using that plugin - nor have been through these issues.

  • x00x00 MVP
    edited April 2013

    @kirkpa31 said:
    $Marketplace ?

    I am not using that plugin - nor have been through these issues.

    $MetaValue sorry

    grep is your friend.

  • kirkpa31kirkpa31 ✭✭
    edited April 2013

    EDIT

    in what seems like a million tests - both the QnACountAcceptance and ReceivedThankCount metas do not consistently reward users w/ points through DiffEquals. I have unfortunately not a clue so far as to why sometimes it works and why sometimes is doesn't.

    Removing this string:

    return abs($Difference)!= $Difference? -1:1;

    and replacing it w/ this string:

    return $Difference;

    In DiffEquals allows it to accumulate more than one 'Thanks' or more than one 'Acceptance' at a time. Is there no simple way to do the same with the "Every" Operation?

  • kirkpa31kirkpa31 ✭✭
    edited April 2013

    If someone could provide an example of why negative values would be rewarded in a situation, or just what exactly DiffEquals is trying to calculate, I cannot understand from the DiffEquals explanation alone:

    'DiffEquals'=>'Recomended over Every. Works out the relative difference between last transaction on that rule, checks if equals and returns a negative/positive based on down or up'

  • x00x00 MVP
    edited April 2013

    can you use @businessdad 's logger plugin

    http://vanillaforums.org/addon/logger-plugin

    public static function OperationDiffEquals($MetaValue,$Target,$Condition,$User,$LastTrans,$Option){
    $Difference=$MetaValue-($LastTrans ? $LastTrans->LastTally : 0);
    $Logger = LoggerPlugin::GetLogger();
    $Logger->info('MetaValue: '.var_export($MetaValue,TRUE).', LastTally: '.var_export($LastTrans->LastTally,TRUE));
    
    if($Difference && abs($Difference)%$Target!==0)
    return FALSE;
    
    $Logger->info('Target Hit!, Difference: '.$Difference,TRUE));
    
    return $Difference;
    }
    

    You should see record start to be logged in LoggerSysLog table.

    grep is your friend.

  • Is there no simple way to do the same with the "Every" Operation?

    Every is a modulus calculation. It doesn't care for the previous result.

    Think of like "does the count divide equally by n?" if is doesn't have a chance to check it could miss, becuase it is only concerned if it is exactly hit, not passed. Therefore this only suitable for things that up one by one like posts.

    For each "is the count equal n?" that absolute not relative to the last result. This is one time only.

    Only DiffEquals take a look at what the previous tally.

    If the previous time was 5 and the count when up by 5 then down by 1 before it is checked then you would be rewarded +1xAmount.

    If it went up by 5 and checked you should +5xAmount but if when down after you would have -nxAmount it all depends when it is checked. There is a possibility of race conditions, and issues.

    I will be refining these over time to make them more accurate. They are not super accurate atm, granted it will take some time.

    Every and Each don't currently make check of if a target has been previously hit, they don't check if the target has been exceeded, only a direct hit. There is no recursive check.

    grep is your friend.

  • That was a perfect explanation - thank you @x00

    I will be refining these over time to make them more accurate. They are not super accurate atm, granted it will take some time.

    And I can use this explanation to try and see if I can possibly fix this issue as well, now that I know more about the functionality of it all.

Sign In or Register to comment.