need some help with my server

[avvery159]

how would i change the max lvl and is there a way i could make GMs and PMs do more dmg?

its a 5165 server

[badguy4you]

I think for the damage you can change the attribute points for the character @ the entities table in the database {if you are using Impuls Source or Trinity Source} if albetros{it would be character table}

Give it a try

About The Max Level Why do you want to change it ?

[hazemz]

if it was in 5525+ it was very easy

[avvery159]

i want to change the max lvl for the heck of it lol me and my bro and sis are gonna be the only 1s useing it..

and im using NewestCoServer

[Zeroxelli]

If I remember correctly, the Level in the packet is a byte, meaning the maximum value is 255. Just keep that in mind. As for changing it, search for something like

[B]Level <=[/B]

to find any checks.

[I don't have a username]

If your source uses properties.

private byte _level;
const byte MaxLevel = 137;
public byte Level {
	get {
		return _level;
	}
	set {
		_level = (byte)(value > MaxLevel ? MaxLevel : value);
	}
}

To block users from getting experience afterwards:

private ulong _experience;
public ulong Experience {
	get {
		return _experience;
	}
	set {
		_experience = (ulong)(Level >= MaxLevel ? 0 : value);
	}
}

Note: This is pseudo code.

[badguy4you]

ah and if you gonna need to change the lvl of you and your sis and bro only in your server and dont wanna others to be more than 140 , you can simply EITHER use the GM command @level 140 , /level140

OR simply go to entities(in Trinity & impulse) OR character(in albetros) table and go to the level tap and simply change it for the characters you want

[avvery159]

is there any way to go above lvl 255? and on NewestCoServer how would i change me chars att and hp and stuff?

[Zeroxelli]

I wouldn't recommend trying to go above level 255, as the Client does (or should) read the level as a byte from the packet. Going over 255 would likely cause a whole load of errors in the client; crash the client; or corrupt the heap inside the client's memory space. It is not a good idea.

[I don't have a username]

Originally Posted by Zeroxelli

I wouldn't recommend trying to go above level 255, as the Client does (or should) read the level as a byte from the packet. Going over 255 would likely cause a whole load of errors in the client; crash the client; or corrupt the heap inside the client's memory space. It is not a good idea.

He would only have one issue, incorrect packets.
Let's say you have a packet like this:

byte
ushort (2 bytes)
ushort (2 bytes)

He's only supposed to give the byte a value.
However he gives it an ushort value.

The new packet is:

ushort (2 bytes)
^- sharing an offset -v
ushort (2 bytes)
ushort (2 bytes)

Notice: The last byte in the new packet is not the byte storing the value. It's the remaining byte from the packet. (Will make sense later.)

Now what if we give the last 2 ushorts values as well.

Let's look into the bits.
A byte consist of 8 bits.
An ushort is 2 bytes, so that's 16 bits shared between the 2 bytes is stored at.

So right now it's:

0 ushort 1[1 - 8]
1 ushort 1[9 - 16]
2 0
3 0
4 0

Then if we add a value to the next ushort, which starts at offset 1, this will happen:

0 ushort 1[1 - 8]
1 ushort 2[1 - 8]
2 ushort 2[9 - 16]
3 0
4 0

And let's add the last values:

0 ushort 1[1 - 8]
1 ushort 2[1 - 8]
2 ushort 2[9 - 16]
3 ushort 3[1 - 8]
4 ushort 3[9 - 16]

Conclusion the last 8 bits of the first ushort is overwritten by the bits of the ushort starting at its offsets.

So here is what will happen:

• Client will crash, because of invalid packet.

OR

• He'll get a completely invalid value.

[Zeroxelli]

Originally Posted by I don't have a username

He would only have one issue, incorrect packets.
Let's say you have a packet like this:

byte
ushort (2 bytes)
ushort (2 bytes)

He's only supposed to give the byte a value.
However he gives it an ushort value.

The new packet is:

ushort (2 bytes)
^- sharing an offset -v
ushort (2 bytes)
ushort (2 bytes)

Notice: The last byte in the new packet is not the byte storing the value. It's the remaining byte from the packet. (Will make sense later.)

Now what if we give the last 2 ushorts values as well.

Let's look into the bits.
A byte consist of 8 bits.
An ushort is 2 bytes, so that's 16 bits shared between the 2 bytes is stored at.

So right now it's:

0 ushort 1[1 - 8]
1 ushort 1[9 - 16]
2 0
3 0
4 0

Then if we add a value to the next ushort, which starts at offset 1, this will happen:

0 ushort 1[1 - 8]
1 ushort 2[1 - 8]
2 ushort 2[9 - 16]
3 0
4 0

And let's add the last values:

0 ushort 1[1 - 8]
1 ushort 2[1 - 8]
2 ushort 2[9 - 16]
3 ushort 3[1 - 8]
4 ushort 3[9 - 16]

Conclusion the last 8 bits of the first ushort is overwritten by the bits of the ushort starting at its offsets.

So here is what will happen:

• Client will crash, because of invalid packet.

OR

• He'll get a completely invalid value.

Basically explained what I said in a way that people can actually understand it.. shame on you. xD

Anywho, yeah. I believe I tested this back on 43XX and around 15% of the time the client crashed with the other 85% of the time resulting in the packet being corrupted and all the values being nulled or random numbers (heap corruption.) That's assuming that they weren't so off that the client didn't throw the packet out. Given the structure of the packet these days, there's an even higher chance that the client could crash.