Skills that can't have their trained level set.

[Envisage]

Basically I found a workaround for a problem I was having with skills not being able to be set to certain level no matter what you change the skill_caps table to. Only problem is it doesn't display at the trainer until that level.

What I'm wondering is, is there a way to set it so the trainer will actually show the level the skill can be trained via the skill_caps table or even a hard coded way server side. As this is a problem with 4 skills I have found so far. The problem isn't that its not taking the correct info from the skill_caps table, its that its still allowing the client to train said skill at level 10 for pick lock for example on bards. When I had it set to 40. The below code prevents that but also doesn't permit it to be seen by the client until 40.

Just hoping someone has a workaround that will actually show it and display it correctly.

I added this to client_process.cpp in OPGMTraining.

		if( sk == PICK_LOCK && GetClass() == BARD && GetLevel() < 40 ){
			gmtrain->skills[sk] = 0;
		}
		else if ( sk == PICK_LOCK && GetClass() == BARD && GetLevel() >= 40 ){
			gmtrain->skills[sk] = GetMaxSkillAfterSpecializationRules(sk, MaxSkill(sk, GetClass(), RuleI(Character, MaxLevel)));
		}

[lerxst2112]

You could put a breakpoint where that array is filled in and find out how the skill is getting added at level 10. That might tell you what data needed to change to make it level 40 instead.

[Envisage]

Actually after doing some further research on the skill system, I've found and I'm almost ready to call it a bug. I'm going to put something in that logs so I can actually see the data thats being sent, and whats actually being loaded.

The reason it appears to be a bug. Logged in with different clients each producing different results for instance brass instruments and other skills I set in the db in skill_caps are trainable at different levels depending on what client your using. Same with a lot of other skills. It appears as if the server is trusting the client to handle what level all the skills are trained at and never checking to see if the client can actually train them by level.

Something is getting lost in translation. I actually believe its the server loading the skills. Bards to my knowledge have never gained pick lock at level 10. Even on live today still don't. Caps are correct unless you have them 0'd out till X level so when skills are loaded they are set to that level to train. Then they are using (5+(level*5)).

So far titanium is the least bugged client with only 4 skills out of wack. SoD it gets a lot worse.

Odd thing is this line in the code.

//you can only use your own trainer, client enforces this, but why trust it

I know its just a comment, but it appears we are trusting the client with the whole skill system. Thats bad. I'm not the best coder in the world but I can't find a check anywhere to make sure client can train at x level. There should be something somewhere storing level data a skill can be trained at but I can't find it, or this would be easy to fix. Looks like the skill system got overlooked. Or there is a valid reason why its like this.

If I had a bit more knowledge I'd try to write a hook client side to set the level down I bet I could train every skill at level 1. Well 5 of them at least.

The way skills are loaded looks to need redone.

Really though in titanium its not that bad its only 4 skills. meditate, sense traps, pick lock, and disarm traps. But maybe a dev wants to look into it cause it just seems highly exploitable.

[Mariomario]

Skills handled by client are what I posted about in your other thread. Within the resource folder for SoD+ clients there is a SkillCaps.txt file which holds literally your entire skill_caps table full of data. If something is changed around in that text file it is seen client side when you load in game. If you remove all of say skill_id 1 from paladins, in game you would no longer see them as being able to train 2 Hand Slashing.

[Envisage]

Right, I'm not disagreeing with you on that again if you move skill caps in that file and you can push the train button it trains server side. The issue is there are no checks what so ever for the skill against level. There isn't even a function in the code for it. No pointer storing the data for the skills unless I'm not seeing it. The way skills are handled especially when the train button is pressed shouldn't trust the client ever.

I haven't tried it but if it would work that would only further my point. Skills aren't being handled correctly on the server. I know skill ups check against the cap etc. Even though this might only allow someone to grab skills a few levels earlier then they should it still isn't right.

[KLS]

These aren't 100% related.

In terms of the verification server side see:

		if(!CanHaveSkill(skill)) {
			mlog(CLIENT__ERROR, "Tried to train skill %d, which is not allowed.", skill);
			return;
		}

		uint16 skilllevel = GetRawSkill(skill);
		if(skilllevel == 0) {
			//this is a new skill..
			uint16 t_level = SkillTrainLevel(skill, GetClass());
			if (t_level == 0)
			{
				return;
			}
			SetSkill(skill, t_level);
		}

It appears that it will bail out if you can't learn the skill. It will also bail out if SkillTrainLevel() is zero (never can train the skill). Though that doesn't appear to be good enough so I'll take a look at it.


The other bug you're talking about is a client bug that appears because sony's skillcaps does not play nice with the client.

The following script is one that's been tossed around a bit for creating a non-buggy skillcaps file from the current DB.

use DBI;

my $db = "eqdb";
my $user = "user";
my $pass = "password";
my $host = "localhost";
my $skill_caps_file = "SkillCaps.txt";
my $source = "DBI:mysql:database=$db;host=$host";
my $dbh = DBI->connect($source, $user, $pass) || die "Could not create db handle\n";

sub skill_usable {
    my $skill_id = shift;
    my $class = shift;
    
    my $sth = $dbh->prepare("SELECT max(`cap`) FROM skill_caps WHERE `class`=$class and `skillID`=$skill_id");
    $sth->execute();
    if(my $val = $sth->fetch()) {
        if(@$val[0] == 0) {
            return 0;
        } else {
            return 1;
        }
    }
    
    return 0;
}

sub get_skill {
    my $skill_id = shift;
    my $class = shift;
    my $level = shift;
    
    my $sth = $dbh->prepare("SELECT cap FROM skill_caps WHERE `class`=$class and `skillID`=$skill_id and `level`=$level");
    $sth->execute();
    if(my $val = $sth->fetch()) {
        return @$val[0];
    }
    
    return 0;
}

open(SKILLS, ">$skill_caps_file") or die "Unable to open skills file for export: $skill_caps_file\n";

for($class_i = 1; $class_i <= 16; $class_i++) {
    for($skill_i = 0; $skill_i <= 77; $skill_i++) {
        print "($class_i, $skill_i)\n";
        if(skill_usable($skill_i, $class_i) == 1) {
            for($level_i = 1; $level_i <= 90; $level_i++) {
                my $cap = get_skill($skill_i, $class_i, $level_i);
                my $line = $class_i . "^" . $skill_i . "^" . $level_i . "^" . $cap . "^0\n";
                print SKILLS $line;
            }
        }
    }
}

close (SKILLS);

[Envisage]

Right if they can never learn the skill or its set in OPGMTraining. Thats my work around for the moment I was hoping to get an answer glad your looking at it .

		if( sk == PICK_LOCK && GetClass() == BARD && GetLevel() < 40 ){
			gmtrain->skills[sk] = 0;

Honestly I almost never would have noticed but I thought okay I'll leave one skill out that has 0's in it to a high level just to check it. Even deleting the 0'd out rows in the DB it was still trainable at that level and thats when I thought something was off. Logged in and it was wrong and could train it at the level the client set it to with no problem.

Eager to see what you find.

EDIT: Forgot to include this, the fact the workaround works says its sending to the client right maybe skills need a struct somewhere to store values etc? I dunno if I'm even wording that correctly but its just a thought.

[DevaDestroyer]

is this still not fixed?