Redhat 7.2 compling problem

[penfold1972]

Well, I have been lurking for a while now and must say that I am excited about finding this project. I've gone and purchased a C++ book so I can get more involved too!

I initally ran a windows server, but want to move it over to my Redhat box. I think I got all the libs I need, but I am still getting errors.

I only get one (in the common/database.cpp) when compiling world, and a few more when compiling zone.

Anyone have any ideas for me to look at with these? (This isn't all ov my zone errors, but hopefully whatever I'm missing will take care of them as well.)

==============
# when compiling world

../common/database.cpp: In method `bool Database::LoadNPCTypes ()':
../common/database.cpp:1945: warning: assignment to `int16' from
`double'
../common/database.cpp:1945: warning: argument to `short unsigned int'
from `double'


#when compling zone

gcc -c -g -m486 -pthread -pipe -DLUCLIN -D_GNU_SOURCE -DINVERSEXY -DFX -I/usr/include/mysql attack.cpp -o attack.o
attack.cpp: In method `void Client::Attack (Mob *, int)':
attack.cpp:165: warning: initialization to `int32' from `float'
attack.cpp:165: warning: argument to `unsigned int' from `float'
attack.cpp: In method `void Client::Damage (Mob *, int, short unsigned
int, unsigned char)':
attack.cpp:320: warning: initialization to `int16' from `float'
attack.cpp:320: warning: argument to `short unsigned int' from `float'
attack.cpp: In method `void NPC::Attack (Mob *, int)':
attack.cpp:406: warning: initialization to `int' from `float'
attack.cpp:406: warning: argument to `int' from `float'
attack.cpp:542: warning: assignment to `int' from `double'
attack.cpp:542: warning: argument to `int' from `double'
attack.cpp:557: warning: assignment to `int' from `double'
attack.cpp:557: warning: argument to `int' from `double'
attack.cpp: In method `void NPC::Damage (Mob *, int, short unsigned
int, unsigned char)':
attack.cpp:694: warning: initialization to `int16' from `float'
attack.cpp:694: warning: argument to `short unsigned int' from `float'
attack.cpp: In method `void Mob::MonkSpecialAttack (Mob *, unsigned
char)':
attack.cpp:878: warning: passing `float' for argument passing 1 of `abs
(int)'
attack.cpp:878: warning: argument to `int' from `float'
attack.cpp:882: warning: assignment to `sint32' from `double'
attack.cpp:882: warning: argument to `int' from `double'
attack.cpp: In method `void Mob::RogueBackstab (Mob *, Item_Struct *,
unsigned char)':
attack.cpp:1119: warning: assignment to `sint32' from `float'
attack.cpp:1119: warning: argument to `int' from `float'


gcc -c -g -m486 -pthread -pipe -DLUCLIN -D_GNU_SOURCE -DINVERSEXY -DFX -I/usr/include/mysql spells.cpp -o spells.o
spells.cpp: In method `void Mob::MakePet (char *)':
spells.cpp:1105: warning: passing `double' for argument 1 of
`Mob::MakePet (unsigned char, unsigned char, short unsigned int,
unsigned char, unsigned char, float)'
spells.cpp:1114: warning: passing `double' for argument 1 of
`Mob::MakePet (unsigned char, unsigned char, short unsigned int,
unsigned char, unsigned char, float)'
spells.cpp:1123: warning: passing `double' for argument 1 of
`Mob::MakePet (unsigned char, unsigned char, short unsigned int,
unsigned char, unsigned char, float)'
spells.cpp:1132: warning: passing `double' for argument 1 of
`Mob::MakePet (unsigned char, unsigned char, short unsigned int,
unsigned char, unsigned char, float)'

[theCoder]

All of the output you posted were warnings, not errors. Unless you got some explicit errors during the compile process, the binaries should have been produced. Though they probably should be fixed, I believe that the code still works (to the extent that 0.3.1 works since there were a few bugs that will hopefully be gone in 0.3.2 :)). I personally get the same warnings when compiling world (and I assume zone; I don't feel like recompiling it just to find out, but I seem to remember a lot more warnings in zone than in world), so don't worry about it.

If you go and look at line 1945, you'll see this:
npc_type_array[atoi(row[0])]->fixedZ = atof(row[21]);
It looks like fixedZ is defined in zone/mob.h (line 265) to be an int16. It looks like the atof call should be an atoi or fixedZ should be defined as a double/float. Since I don't know what fixedZ defines, I don't know if it should be integral or floating point. I guess minimally, there should be an explicit cast there. But that's why this is version 0.3.1 and not 1.0 :)

I don't know what the other warning is all about though. It could be related (caused by) the first one, or it could be another problem in the line that I don't immediately see...

[penfold1972]

You're right, the binaries were created and I was able to run them, but I was having problems with the zones.

After i moved to the linux box, I changd my static NAT translations in my cisco box, and had host entries mapping my public domainname to the internal address of the Linux box.

I saw people connecting to world, and they were able to create characters, but it looked like they disconnected during zone boot up, and I'm assuming they were dumped to the server select screen which is what happens to my client from behind the firewall.

I am at a loss as to what is causing this problem. The only errors I got from the zone servers were some NPC errors, which is what made me suspect these warnings during complie. I guess it was just a fluke that the database warning were in the LoadNPCTypes routine.

So I guess it's back to the drawing board... I've reloaded my linux box, so I guess I'll rebuild my database and bring my server back up. (Evil Petting Zoo) Maybe it is some sort of NAT problem, but since I'm connecting to world the problem is avoiding me... :(

I suppose I can give your NAT patch a shot to see if that fixes the problem. But if it's not a NAT problem I have run into the proverbial brick wall.

[theCoder]

The NAT patch is only for EMU servers that are running on the NAT server, not behind it. The patch forces the EMU server to bind to only one of the network interfaces (namely, the external one). This is only really necessary because of how the login server works. And even then, I've since found out you can work around it with creative name resolution.

What the NAT patch won't help with is if the EMU server is behind the NAT server (it has a private IP). This is the classic server behind a NAT problem. Unfortunately, no one has developed a really clean solution to it :(. The best you can do is setup your NAT server to port forward the world and zone ports. From your post, it sounds like that's what you did. I would guess, however, that you only forwarded the world port (9000) and not the zone ports (I use 9001-9005, but it's based on the command line arguments when you run zone). Check to make sure you're forwarding those ports as well.

For you to log into your server (if it is behind a NAT), you're going to have to resort to creative domain name setup. You're going to want to do something like the following. If you have a domain name, say bobsdomain.com, pointing to your IP, say 1.2.3.4, and your EMU server is really on 10.2.3.4, you'll need to edit the hosts file on the EQ client computer to an entry:
10.2.3.4 bobsdomain.com
Even though bobsdomain.com should be 1.2.3.4, you want to override it on the client to be 10.2.3.4. That way, the EQ client will go to the EMU server instead of to your NAT server (I don't know if you can set up an iptables based NAT server to reflect back into the network or not... in any case, it would be inefficient to have the NAT server as a go between).
Then, in your loginserver.ini file on the EMU server, you have to specify your world address as bobsdomain.com.

There are some problems with this (such as if you wanted one machine to be the world server and another to host the zone servers), but in general it should work.

btw, I'm planning on reworking the NAT patch when 0.3.2 comes out to be more generic (probably introduce a bindaddress in the configuration file) instead of the pseudo-hack that it is now (relying on the worldaddress field to dictate what to bind upon).

[penfold1972]

Well, I am at a loss as to why, but it seems to be working now. :)

I didn't mess with the NAT maps on my router, but my client isn't going through them, so they may still be an issue.

The only thing I did was wipe and reload the linux server. I just finished and attempted to login, and it worked!

The next test will be to see if anyone can login and actually spawn in a zone. When I get back tonight, I will see if anyone will have left a petition, or summoned items on their characters for confirmation that they were able to get in.

Essentially, I am doing the creative domainname method of running my server. It happens that roadrunner appears to have DNS entries for their IPs, so I just have to pay attention when it changes and edit the files on my PC and server.

Thanks for your advice! Now, back to my C++ book! I want to see about adding a command to let normal users to level and set their skills... maybe figure out how other servers have an NPC to do that...

Since I am a total newbie to eqemu and C++ coding, this might take a while.... :) Wonder if it would mess up the servers if I just had a cron job to edit the entries directly to the MySQL database..... Hmm, something else to play around with... :)

Edit:Well, I have noticed since I posted this that some people were able to get all the way in. I also noticed that I forgot to put the spelldat.eff in the proper folder. After I did that, and restarted the server, I am having a problem I have seen before, and am not sure what got rid of it...

basically, the NPCs are floating in the air. As you walk to them, they come down until you are right next to them and they are only a couple of "feet" off the ground.

it just so happens that I was screwing with my database and reloaded it before, which appeared to take care of the problem... Since this is a fresh database, I don't see why this would do that.

The only mention I have seen of this is in Malevolent's version, and I was wondering if anyone else has seen this in the vanilla EQemu, and what could be done to correct it? (malevolent didn't go into details)