SolarStrike Software

lisa wrote: Do you hold down the keys or just do a quick press?
I noticed with (1) if I hold the key down it spams the code constantly, was still accurate for me though.

a "normal" keypress, i am young enough to keep my fingers under control but all in all (1) is ok, with some chars the order is strange, char2 bevore char1 and char 1 comes twice. with the two english names (1) looks good, 1x Char1 then 1x Char2.

lisa wrote: That name should have been gotten directly from the Memory I suspect as the UI, try removing all addons except for the ingamefunctions and start up client again. It is possible an addon is messing with it.

Tried it, looks the same as before, (2)(3) scrambled, with two english named chars standing next to each other.

The strange thing is, with umlauts in name (for example ä and ß) only the umlauts gets scrambled in (2) and (3), the rest of the name is ok. But when i use english names, for example "abcdefghijklmnop" then i get for example only 4 cryptic literals in (2) and (3), so the length is not compareable.

Another question, is there anywhere a limitation in name length?

I had a response typed up but it didn't post =(

So short answer, the reading from memory function is part of MM and I don't know how it works exactly, Admin would know it best.

Are you using Linux or Mac?
Are the names very long?

I just created a char using maximum letters allowed in name and still worked perfectly.
1 has name of Eishoidfgfdgfdgg

Actually not so perfect lol
Party member 1 has the name of (bÆ,

Player has name of Char1
Party member 1 has name of (bÆ,

Have you tried removing all addons except ingamefunctions?

Ok I have some progress, this was a pain in the butt lol

So here is the story, if the name of the character is to long then the address that GetPartyMemberName(_number) gets is actually a pointer where the name is kept where as normally GetPartyMemberName(_number) gets the actual name.


This might take some looking in to as to how to deal with it but yes I can confirm the long name is the issue.

Maybe Rock has an idea for this but this is what I see at this early stage on investigation. Ok so top name is to long and so it points to another address that has the name
Second name contains the actual name as a string.

Main difference I see first is
4 bytes after where the name should be is 00000000, I would need to check what is after a name with few letters to see if it will also have the 00000000 after the name.

Ok checked and 4 letter name has 00000000 after it aswell.

This just gets worse and worse.

Once a name with to many letters has been in a spot of party then that spot ALWAYS has a pointer to the name held elsewhere, regardless of it party is disbanded and reinvited.
So once a long name has been in any position in party it is messed up until client restarts.

So basically if we are going to allow for long names then function GetPartyMemberName(_number) needs to be rewritten to allow for it being a pointer or string at the address.

Finally, you figured out the problem. That must have been getting fustrating, for both of you. So the problem has always been with names that are too long? So what's the maximum name length before it becomes a pointer?

The first solution I can think of is; if there are only 4 characters then check if all 4 are valid allowed characters. The odds are probably small that an address would be made up of all valid characters I think. Then goto the address and see if it holds a 1 word string. That's a bit messy though. It's a shame that the game allows 4 letter names or we could have just used the length to tell if it's a pointer or not.

How about checking the rest of the memory area? I see from the code that the memory area is 0x60 in size. Maybe there is some indicater whether it's a name or a poimter. In your picture, for example, I see one has a 1F and the other has a 0F. Maybe that's it. Or just compare the memory of names that are short and those that are long and see what you come up with.

rock5 wrote:How about checking the rest of the memory area? I see from the code that the memory area is 0x60 in size. Maybe there is some indicater whether it's a name or a poimter. In your picture, for example, I see one has a 1F and the other has a 0F. Maybe that's it. Or just compare the memory of names that are short and those that are long and see what you come up with.

Yeah been testing it out and nothing conclusive yet, still working on it.

For now I have replaced the partytable getting party names with RoMScripts, so pman give this a test, this is by no means what I want to use in the end but it might keep you going.

Hi, cool lisa, i test this in a few hours, when i get home.

As i see it, there are 2 probs rock:
1) long names (short german names are nearly impossible (allready used), except some things like "sdfkja", which are banned directly, because goldsellers use them )
2) (1) vs (2)(3) with umlauts in names. (1) is ok, (2)(3) replaces the umlauts with special characters

Update: Addons and PC are not to blame (tested on 2 PC's with and without Addons), last working char name length is 15 (16 results in much the same as lisa postet, 4 cryptic literals)

K all fixed, revert all files back to default and then use this functions.lua

Yes they had maximum 16 characters and 15 worked fine but the 16th is what caused the issue.

Tested with characters like Ý and worked fine, not sure about german characters.

tested everything again, long names work now, thanks for that. German literals (äöüß) still do not work. (1) is ok, with (2)(3) the literals get scrambled. So for me this is still a big move forward, because i have many chars with long names

have a nice day

The print from 2 and 3 arn't hugely important, did the 4 and 5 work though, that is the important thing.

with umlauts (äüö) and ß > false, with long charnames > true

If I understand correctly (1) shows the names using object table search but (2) and (3) are printing the names from the party functions. This is confusing as I thought both just read strings from memory.

After having a closer look are how (1) reads the name, I found this bit of code in object.lua Is it possible this has something to do with it? Maybe you need to do the same with the party function names.

So, i have tested it for a while now, i get a strange error. (about 10 times per hour)
party.lua:152 attempt to index field (?) a nil value

with 4 members, so the for in the code should work... and with the new functions.lua

Update: debuged it a bit, the crash occurs only for the char with the long name, he is party member 4 and i==4 when the crash occur

Ok 2 new files to test out, see if they help.

thanks, will test that as soon as the server maintainance with the new patch is done and the new adress offsets were figured out

Tested äüöß, works great now (1-5 is ok), thanks, the only thing i cannot test now is the error in the "for" loop for the long charname, our server is patched to death, so i have to wait till they fix all this shit...

I commited those changes to rev 728, so you should be able to do a revert when you update and have all green ticks again.