While testing packet handling we ran into a behavior that seems inconsistent in GetUnicodeString.

Calling GetUnicodeString(offset, 0) appears to throw an "Offset too high" error when the offset is at the end of the packet, even though no bytes are actually read. From a scripting point of view, requesting a zero-length string should probably be a valid operation and simply return an empty string.

We are not completely sure if this is intended behavior or a bug, so I’m opening this issue for clarification as Turley told us so.

Test Case

Example script:

var packet := CreatePacket(0xB0, MSGLEN_VARIABLE);
packet.SetInt16(1, 116);

print("a " + packet + " -> " + hex(packet.GetUnicodeString(3, 0)));

// ..........1..2..3
// packet = b0 00 74

In this case:

• The packet size is 3 bytes.
• GetUnicodeString(3, 0) requests a string of length 0 starting at offset 3.
• No bytes should be read.

However, this generates:

error{ errortext = "Offset too high" }

Environment

POL version:

POL 100.1.0 - Never Gonna Give You Up - Windows 64bit
Rev. 469a454
Compiled on Apr 28 2023

(Older version, not sure if this has already been addressed in newer builds.)

Reasoning

Conceptually, requesting zero bytes should not violate packet bounds. The function could simply return an empty string.

Something like:

if (length == 0)
    return empty_string;

In fact, the implementation already contains:

https://github.com/polserver/polserver/blob/master/pol-core/pol/packetscrobj.cpp#L254

Which suggests returning an empty string when len == 0, but in practice the bounds check appears to trigger first.

Expected Behavior

GetUnicodeString(offset, 0) should return an empty string, even when offset == packet size, since no data is read.

Actual Behavior

Throws:

error{ errortext = "Offset too high" }

Notes

This situation came up while testing packet 0xB1 where text blocks may appear at the end of the packet and lengths can evaluate to zero in some parsing scenarios.