PenUltima Online

Should packet.GetString return the string padded by null values?? Is that a bug in the core?

Depends on your length and offset for the starting point. With it involving packets, it would not be a bug, but rather a script issue. It gets what you pass, but if what you pass is not correct for the packet, it's on you

If a packet is malformed, like this case, the issue in GetString is a user error by not reading the packet correctly (but in fact, the packet itself was incorrect, so it worked correctly). Thus, the result would be as expected.

However, is Account creation somehow using those whitespace characters also?

The packet was correctly formed. I don't think GetString() returning null values was expected. I thought it might be intentional but I was just asking to be sure.

When it would try to find the account 'admin ', it wouldn't find it and would tell the core to create it, and the core created the account and possibly somewhere along the way stripped the nulls. I should have checked the accounts.txt file to see if there were nulls next to the name. Maybe the core should have stripped the nulls in the beginning and checked if that account existed and returned an error if it did.

Yes, and no.

GetString returns a literal of the offset and length, which is intended. have you tried the oldschool method of putting the result through CasZ() to see if that corrects it? Used to be used to fix exploits from web account creation.

I did that and got an array full of 0s. I just remove the nulls from the username and password using a shared function in strings.inc. I asked about the possibility of a trim command in the core and it got locked without so much as a "shut up tekproxy, that's stupid!" I only asked because I thought it would be really easy and small. I'm all for keeping the core tiny and doing most of the work with scripts.

Yeah, while all the basic commands like trim, find, sort, etc would be really nice, you have to think about it. eScript uses a frontend of it's own language, to interface with the core, so even adding something like trim(), means doing a lot more than simply added 4 or so lines.

I do agree, keeping it as simple as possible. It's a balancing act. Simple vs wide spread use to justify. It's all about "how much is this going to be used, and also be helpful". Some stuff put in, is far from it, some was only because it was felt to be more than simply helpful.

Thank you for explaining that. I understand things more clearly now.


...


So how about those outgoing aux connections I asked for last year? Just kidding.

Make a normal one...........

Set up a cron or scheduled task on the remote..........

bam

Yeah. I do that already. AuxServices rock.

Gotta love it