ExperienceRO scratch pad

[kali]

I am attaching the modified Receive.pm here. Make a backup of your original file and copy over.

[kali]

Some suggestions to improve the unpack string:
* Currently hp and maxHp are 16ibt ints, we can just unpack them as 32bit ints since the field format seems to support it (though I've personally never seen a server using that high values for hp)
* The same seems to be true for sp and maxSp
* We're skipping 22 bytes just after jobLevel - what are they? Maybe they're the ones that show if you have a falcon or a cart, or something else entirely.

[andy12345]

Yup, your new patch indeed works (Thank you so much), I will do a bit more wide testing after some time (The current problem is unknown packet 016 C). So, yeah good luck in your coding

[Technology]

And btw, it seems that whatever I do to change the charBlockSize doesn't work. Changing it in servers.txt or in config.txt doesn't seem to stick (I checked with placing trace messages and logs). Maybe it's just me, but it seems that the function broke somehow, or the specific config.txt entryis not being loaded.

Hmm, this could be the cause, look in receive.pm:

Code: Select all

sub received_characters_blockSize {
	if ($masterServer && $masterServer->{charBlockSize}) {
		return $masterServer->{charBlockSize};
	} else {
		return 106;
	}
}

But some serverTypes override this method by:

Code: Select all

sub received_characters_blockSize {
	return 108;
}

In other words, they have a hard-coded charblocksize.

We could support all servers in 1 receive.pm using all kinds of 'hacks', but imo the benefits will never outweigh the disadvantages.
The hacks I'm talking about are: packet length based handling, serverType based handling, ...
Instead of these hacks, we need an universal approach for all packets.
Something serverType specific does not belong in receive.pm...
Once we see that a new packet has reached every server, only then we may move it to receive.pm.
The biggest issue atm is the following scenario: "Am I allowed to change something here? There is a chance that it will affect other servers..."
I believe that its best to divide everything server-specific per server(type) to gain better control and to allow for much easier maintenance.
Devide et impera!

[kali]

I know that the patch above does not belong there. It was made specifically for Andy, since I do not currently have the proper environment to comfortably code a proper fix (I'm doing this on an eeepc 701).

Besides, there isn't an easy way to move away 006B specific stuff based on the current implementation. That is why I mentioned I'm not yet doing a separate servertype supporting this unless we properly refactor (at least) 006B

I also agree that we should not handle serverType stuff in receive.pm - in fact I am experimenting with my ports on how to best abstract the packet information. I'm leaning towards an implementation where each packet is represented by an object, which knows how to serialize and deserialize itself. It's the approach I sed on the java version of Poseidon (Neptune) you might want to look at it.

[EternalHarvest]

Maybe these changes in ST 8_5

Code: Select all

sub received_characters_blockSize {
+	if ($masterServer && $masterServer->{charBlockSize}) {
+		return $masterServer->{charBlockSize};
+	} else {
		return 108;
+	}
}

should be applied to ST 8, 8_1, 8_2, 8_3, 8_4 too?

[kLabMouse]

Maybe these changes in ST 8_5

Code: Select all

sub received_characters_blockSize {
+	if ($masterServer && $masterServer->{charBlockSize}) {
+		return $masterServer->{charBlockSize};
+	} else {
		return 108;
+	}
}

should be applied to ST 8, 8_1, 8_2, 8_3, 8_4 too?

yep.