Log in

View Full Version : Invalid size for RecipeDetails Request


huntersan9x
06-14-2010, 10:31 PM
First of all, I want to thank the developers for their hard work in making this software available for us all.

The bug I would like to report is one that I don't think many folks have or will see, but an oddity none the less.

I have one server that is running eqemu's LoginServer, ucs, world, and 5 dynamic zones. I have the svn rev 1534 that i compiled with gcc 4.3.4 and compiled it from clean. This is an i686 Gentoo Linux box.

The second box is a much faster machine running ONLY eqlaunch with 5 static zones loaded. same revision, same gcc, but this is an x86_64 machine. It is compiled without the march flag in the make files and compiled as a 32 bit executable

Here is the weird part, I have a character in the static zone on the x86_64 box that can goto a trade skill container (forge, tailoring kit, zone based, item based) can search recipes, pick a recipe, but not see the components needed to make it. the combine works without it, but it is not showing items in the boxes.

In the logs, I get:

15368 [06.14. - 21:22:31] Invalid size for RecipeDetails Request: Expected: 8, Got: 4
15368 [06.14. - 21:23:26] Invalid size for RecipeDetails Request: Expected: 8, Got: 4
15368 [06.14. - 21:23:26] Invalid size for RecipeDetails Request: Expected: 8, Got: 4


NOTE: This was for three different tries at getting a recipe to show

I did a test where I stopped the static zones on the x86_64 box and started the zone on the i686 box (with the rest of the services) and did the same test. but this time it shows the items needed to make the recipe!

Now, I noticed a lack of info on making an eqemu server on multiple machines, and a search of the error on the forums turned up nothing and on google only leads me to the thousands of svn views of the error in client_packet.cpp.

So, as this looks like something that is not intended, I wonder if someone can help me fix this for the server?

gaeorn
06-16-2010, 04:58 AM
linux doesn't like to actually compile for 32bit, so you are having 32bit vs 64bit issues. compile on the 32bit box and copy the executable over to the 32bit box and try that.

in any case, i'll try to take a look at this later. something probably needs to be changed from int to int32 or uint to uint32.

huntersan9x
06-22-2010, 10:12 PM
Well, I copied zone, eqlaunch, libEMuShareMem.so and after an unsuccessful start, also libmysqlclient.so.* from my 32 bit box to the 64 bit box and it shows the items as intended. Is there anything more I can do to help with making this work on 64 bit?

gaeorn
06-23-2010, 01:54 PM
I have the information needed. I just need to get around to fixing it :-D

I'll see if I can get to this sometime this week.

c0ncrete
02-04-2011, 06:42 PM
I ran into this problem as well using a 64-bit Ubuntu system.

I resolved it by changing unsigned long to unsigned int (uint32) in the following:
Client::Handle_OP_RecipeDetails()
Client::SendTradeskillDetails()

It looks to me like the packet the client is sent is constructed in part using the bit length of unsigned long. From what I understand, this is the same on both 32-bit and 64-bit Windows systems, but can be larger on some other systems.

There are plenty of other areas in the source that use unsigned long, but I haven't run across any other issues just yet. I can't wrap my head around why unsigned long is used at all instead of unsigned int for the sake of portability.

DISCLAIMER: I'm no computer scientist. I just use Google to feel my way around any given subject. Reading is fun...

provocating
03-02-2012, 09:10 AM
I ran into this problem as well using a 64-bit Ubuntu system.

I resolved it by changing unsigned long to unsigned int (uint32) in the following:
Client::Handle_OP_RecipeDetails()
Client::SendTradeskillDetails()

It looks to me like the packet the client is sent is constructed in part using the bit length of unsigned long. From what I understand, this is the same on both 32-bit and 64-bit Windows systems, but can be larger on some other systems.

There are plenty of other areas in the source that use unsigned long, but I haven't run across any other issues just yet. I can't wrap my head around why unsigned long is used at all instead of unsigned int for the sake of portability.

DISCLAIMER: I'm no computer scientist. I just use Google to feel my way around any given subject. Reading is fun...

I am hitching a ride on the topic since I have the same issue. Did this fix it for good on your server?

c0ncrete
03-03-2012, 04:26 AM
the server no longer exists (redemption), but it solved the issue. sent pm.