Core Bug - newest Core - different behaviour under Linux vs. Windows

Bug reports and feature requests. New features can only be added to the current development version. Bug-fixes may be back-ported.

Current release: 099 / Current development: 100
Post Reply
OWHorus
Grandmaster Poster
Posts: 105
Joined: Sat Feb 04, 2006 1:24 pm
Location: Vienna, Austria

Core Bug - newest Core - different behaviour under Linux vs. Windows

Post by OWHorus »

Hello,

I did not analyze this further, but in an rather obscure case the following happens:

Trying to form a packet 0x1A, to send to a client, used to 'send' an object (item or container) to a client.
The serial has to be masked with 0x80000000, i.e. the highest bit should be set in the serial. In EScript this is a problem, because there is no unsigned integer. The solution (was suggested by a core dev, Racalac if I remember correctly) was always:

packet.SetInt32(3, (object.serial + 0x80000000) + 1);
In the resulting packet a serial of - from the actual example - 0x512D607B becomes 0xD12D607B, as it should be.

This worked fine with 32 bit compiled cores, and it continues to work fine under Windows, even with a x64 core!

Under Linux it does not work anymore, the result for the serial 0x512D607B is now 0xD12D607C!
But if I write

packet.SetInt32(3, (object.serial | 0x80000000));

it works! But it does not work this way under Windows x64 Core!

This is rather nasty (I will fix it by setting the serial in two steps with .SetInt16), because a script which works perfectly under an Windows running Core will fail under the same Core if it is compiled and runs under Linux!

I suspect (but did not check) that the integer compilation under Linux is different and a 64 bit integer is used, while the Windows compiler uses a 32 bit integer and wraps correctly.

All in all (despite a lot of needed changes because of the changed behaviour of 'item.name') the new core seems to run fine with our script base. I hope this is the last problem I find :)

OWHorus

EDIT:
After testing on both, Linux-Pol and Windows-Pol, same scripts, this is the solution for now, if anybody needs it:

Code: Select all

		// Old way, does not work under Linux, but works under Windows (both x64)
		packet.SetInt32(3, (obj.serial + 0x80000000) + 1);
		
		// Workaround, works on both Linux and Windows x64 cores
		packet.SetInt16(3, (CInt(obj.serial / 65536) | 0x8000));
		packet.SetInt16(5, obj.serial & 0xffff);
Hope this helps...
OWH
Turley
POL Developer
Posts: 670
Joined: Sun Feb 05, 2006 4:45 am

Re: Core Bug - newest Core - different behaviour under Linux vs. Windows

Post by Turley »

I would say your problem is not the size of the integer, I would doubt that it's a 64bit integer. The problem is that signed integer overflow is undefined behaviour. Escript itself gives no guarantee what happens thus it's 100% the implementation detail of the c++ compiler.
I would recommend to the calculate in that way as if it's defined.
Isn't there a way to trick the core to send this packet for you?
OWHorus
Grandmaster Poster
Posts: 105
Joined: Sat Feb 04, 2006 1:24 pm
Location: Vienna, Austria

Re: Core Bug - newest Core - different behaviour under Linux vs. Windows

Post by OWHorus »

Hello,

yes - the problem is, that eScript has no unsigned integers. It is an old question, and I point it out here to help. It can be solved - see my update above - and it is not a serious problem.

'Trick the core to send the package' - have to look into this...

What we do (in special cases): Remove an object (item or mobile) from the client (packet 0x1D) and put it back again (packet 0x1A for example). This is used for several optical tricks mainly, for example a miracle, where a character can send a message to another character, and will 'ghostly' appear beside him, but without changing location himself.

Another usage was the problem, that when you open a chest, let it open (chest gump is shown) and then lock it, the chest gump remains and you can still handle the chest contents. This is not a serious problem, but if a character locks his chest, while another character has the gump open, it can be a problem. So we (the script is years old!) removed the chest and put it back again by locking it, which would close any chest gumps still open. I changed this now with the new function CloseWindow(), which is much better anyway.

I just wanted to point out, that eScript behavior can be different with the same core under different operation systems. I ran into this when a player locked his chest, and found, that the chest, while optically shown in game suddenly was not present, could not be handled and and did not react to a single or double click, until he went away and came back. This was caused by the wrong serial sent in the packet which should make the chest 'reappear'. Since this script worked for years without problems, I had to look into it and this was what I found...

OWHorus
Post Reply