Two questions, haven't found the answers.

[hexluther]

Is EQEmu still a 32 bit application (meaning, will it take advantage of 64 bit, whatever those advantages are precisely -- I can only assume 64 bit is better than 32 bit in performance if not, please do set me straight)?

Under what conditions does EQEmu have to be recompiled? (I simply want to get a good idea of just how much work is going to be involved, obviously the compiling process adds 5 minutes or so each compile)

[sorvani]

Use Perl 5.14, change your release to Release x64, update all the include and library references in visual studio, build solution.

[devn00b]

Is EQEmu still a 32 bit application (meaning, will it take advantage of 64 bit, whatever those advantages are precisely -- I can only assume 64 bit is better than 32 bit in performance if not, please do set me straight)?

Under what conditions does EQEmu have to be recompiled? (I simply want to get a good idea of just how much work is going to be involved, obviously the compiling process adds 5 minutes or so each compile)

64bit will let the zone/world use more than 3gb of ram. Really no zone server should be using that much (its a per proccess thing not total) so no real benefit to 64 in that sense. There are some performance gains but they are fairly minmal esp on a windows system.

EQEMu only needs a recompile if you update your source code (source edits/updates from SVN) Everything else is handled from pearl/xml/ini files.

[hexluther]

64bit will let the zone/world use more than 3gb of ram. Really no zone server should be using that much (its a per proccess thing not total) so no real benefit to 64 in that sense. There are some performance gains but they are fairly minmal esp on a windows system.

EQEMu only needs a recompile if you update your source code (source edits/updates from SVN) Everything else is handled from pearl/xml/ini files.

Thank you very much for the speedy reply, I greatly appreciate it. I'm still utterly new to Perl, so I wasn't sure if the Perl scripts were included in the build itself or read from the world (EQEmu) as a scripting language/parser real-time. Now I'm ready to go diving into this venture knowing what you stated above. I was not aware that x86 limited memory use to 3GB, interesting to know for sure. So, even the big legends servers are not using much more than 3GB? Why the overkill of 32GB for say, THF then? (not questioning or doubting what you said, incase it comes across as that -- rather just purely interested in knowing what I may very well be ignorant about as to why they have so much RAM).

I tend to be proactive, and just incase my server were to flourish, should I be so honored (or is it an honor? lol considering the work load as a result that surely ensues), I'd like to just set everything up on a real server now (1U for reloco ease on the wallet) so it's all done right away, but plan to run from home initially (no sense in spending tons of money on reloco or virtualized server before it grows, as it may not, the preferred and legends that exist now are great -- though wouldn't mind throwing in my own twist and new features and such).

Definitely a helpful crowd, its evident now no doubt. I appreciate the responses. @sorvani, thank you, I know how to compile, have done it successfully twice using the guides (though none of them were 100% precise in wording and such, but, installation screens change, so that isnt the fault of the guide producers I know that -- beggars cannot be choosers and I'm thankful for the guides for sure). I just wasn't sure -when- a compile was necessary.

Thanks so much again both of you for the expeditious replies, it is appreciated.

[lerxst2112]

Each 32-bit process is limited to a 4gb address space. This is usually split in half, where 2gb is the amount of actual memory the process can allocate. It is also possible to set the application to be able to use 3gb of memory but that has both benefits and drawbacks.

Each zone a server is running is a different process, so it is possible for multiple 32-bit zone processes on a 64-bit OS to collectively use as much memory is available. It's pretty unlikely you'd have a single zone process that needed more than 2gb of memory unless there was a giant memory leak.

Anyone running 64-bit on a highly populated server may have a different opinion of the performance versus 32-bit, but for most I'd say they are pretty much the same.

[bad_captain]

To answer you question about servers having 32 GB of ram: each zone uses a certain amount of ram, and so, the more ram you have, the more zones youc can load at one time. You can use dynamic zones, which only boot up when someone enters them, or static zones which are up all the time.

One benefit of dynamic zones is that it keeps the number of concurrently running zones down, which uses fewer resources. The main benefit of static zones, however, is it keeps the zones up to help preserve the states of raid events or quests. Events or quests may reset when unloading/loading zones.

If you are the only client in a zone trying to trigger a spawn, and you gate or die, and the zone shuts down, you will most likely have to start event over and have to deal with respawn times etc. A static zone would prevent that, but it comes with the cost of added ram being used. Most larger servers run many static zones of frequently used zones as well as critical raid zones as static, with the rest available as dynamic.

[hexluther]

To answer you question about servers having 32 GB of ram: each zone uses a certain amount of ram, and so, the more ram you have, the more zones youc can load at one time. You can use dynamic zones, which only boot up when someone enters them, or static zones which are up all the time.

One benefit of dynamic zones is that it keeps the number of concurrently running zones down, which uses fewer resources. The main benefit of static zones, however, is it keeps the zones up to help preserve the states of raid events or quests. Events or quests may reset when unloading/loading zones.

If you are the only client in a zone trying to trigger a spawn, and you gate or die, and the zone shuts down, you will most likely have to start event over and have to deal with respawn times etc. A static zone would prevent that, but it comes with the cost of added ram being used. Most larger servers run many static zones of frequently used zones as well as critical raid zones as static, with the rest available as dynamic.

That's what I was figuring. Starter zones (as many seem to modify this to a centralized place), main leveling and raid zones, etc. are ones that I assumed were static (finally an assumption gone right heh).

Now, one thing about your reply. Each zone uses a different amount of RAM you say? Makes sense depending upon (assuming here again look out) how many objects, size, etc. there is in the zone?

I assume besides the instanced zones, that all the zones on the live servers would have been "static" per se then?

I do wonder what P1999's server hardware is, as just about every other Legends server has their hardware listed somewhere, but, 1999 seems to have the most concurrent members on on a regular basis. I imagine it's equivalent to the others, if not superior, but, would be great knowing they get away with a server with less umpf.

[hexluther]

...Events or quests may reset when unloading/loading [dynamic] zones.

If you are the only client in a zone trying to trigger a spawn, and you gate or die, and the zone shuts down, you will most likely have to start event over and have to deal with respawn times etc. A static zone would prevent that, but it comes with the cost of added ram being used. Most larger servers run many static zones of frequently used zones as well as critical raid zones as static, with the rest available as dynamic.

Hmm, I just re-read this. From a resources stand-point, dynamic zones make sense, but, if that means the zone could essentially reset (are the times/timers not saved anywhere, say in the DB, etc.?) then, why would anyone that wishes to ensure they have a stable and consistent running server use them at all? Is a genuine question.

Were the dynamic zones implemented to allow those that may have say, only one group of people hanging out together on a server to play whilst the server's resource consumption is kept at a all time low?

I plan to have a public server up and running within 2 months or so (difficult to say with the utmost certainty as life throws a wrench in the works) so I'm really trying to get an accurate idea of what type of hardware I should look at. It sounds as though, at the very least, I should get an ample amount of RAM (16+? may as well go 32GB) to allow keeping the majority of the zones with notable/quest NPC's, raid mobs, etc. up and running at all times.

Too bad there isn't a post with all the server owners replying with the server hardware specifications, OS (and version), etc.

[lerxst2112]

I do wonder what P1999's server hardware is, as just about every other Legends server has their hardware listed somewhere, but, 1999 seems to have the most concurrent members on on a regular basis. I imagine it's equivalent to the others, if not superior, but, would be great knowing they get away with a server with less umpf.

You may have heard the term "Hack the Gibson" before, well P99 runs on the actual Gibson.

[bad_captain]

Hmm, I just re-read this. From a resources stand-point, dynamic zones make sense, but, if that means the zone could essentially reset (are the times/timers not saved anywhere, say in the DB, etc.?) then, why would anyone that wishes to ensure they have a stable and consistent running server use them at all? Is a genuine question.

Were the dynamic zones implemented to allow those that may have say, only one group of people hanging out together on a server to play whilst the server's resource consumption is kept at a all time low?

I plan to have a public server up and running within 2 months or so (difficult to say with the utmost certainty as life throws a wrench in the works) so I'm really trying to get an accurate idea of what type of hardware I should look at. It sounds as though, at the very least, I should get an ample amount of RAM (16+? may as well go 32GB) to allow keeping the majority of the zones with notable/quest NPC's, raid mobs, etc. up and running at all times.

Too bad there isn't a post with all the server owners replying with the server hardware specifications, OS (and version), etc.

I did a quick check of my zones running on my server with no one in them- they take between 16-39 MB of RAM each. Say average of 30, you could have ~34 zones running per GB or so of RAM if my math is correct. This is without any clients remember. With however many hundreds of zones, that's a lot of RAM. But mostly, dynamic zones were made to keep resource usage down (no need to have 100 zones running if you are the only one playing). So, someone running 1 GB of RAM could theoretically run the server, DB, and EQ on the same machine (which I have done before). Us poor people need our EQ, too. :D

TBH, I think the bigger limiting factor is bandwidth, not hardware. I think I could run a couple hundred players hardware wise, but I don't have the connection for it.