eqemu / server Goto Github PK

The problem appears to be that the query result in the current code is freed before it's used. This crashes the world server on windows (as it correctly should, but I assume for some reason it works on Linux or else this would have been caught).

Here's my suggested patch fix for the problem:

diff --git a/common/database.cpp b/common/database.cpp
index 04e4d3b..dafcac2 100644
--- a/common/database.cpp
+++ b/common/database.cpp
@@ -2514,6 +2514,7 @@ bool Database::GetUnusedInstanceID(uint16 &instance_id)
    char errbuf[MYSQL_ERRMSG_SIZE];
    char *query = 0;
    MYSQL_RES *result;
+   MYSQL_RES *result2;
    MYSQL_ROW row;

    uint32 count = RuleI(Zone, ReservedInstances);
@@ -2522,22 +2523,21 @@ bool Database::GetUnusedInstanceID(uint16 &instance_id)
        safe_delete_array(query);
        if (mysql_num_rows(result) != 0) {
            row = mysql_fetch_row(result);
-           mysql_free_result(result);
            if(atoi(row[0]) <= max) {
                count = atoi(row[0]);
            } else {
-               if (RunQuery(query, MakeAnyLenString(&query, "SELECT id FROM instance_list where id > %u ORDER BY id", count), errbuf, &result)) {
+               if (RunQuery(query, MakeAnyLenString(&query, "SELECT id FROM instance_list where id > %u ORDER BY id", count), errbuf, &result2)) {
                    safe_delete_array(query);
-                   if (mysql_num_rows(result) != 0) {
+                   if (mysql_num_rows(result2) != 0) {
                        count++;
-                       while((row = mysql_fetch_row(result))) {
+                       while((row = mysql_fetch_row(result2))) {
                            if(count < atoi(row[0])) {
                                instance_id = count;
-                               mysql_free_result(result);
+                               mysql_free_result(result2);
                                return true;
                            } else if(count > max) {
                                instance_id = 0;
-                               mysql_free_result(result);
+                               mysql_free_result(result2);
                                return false;
                            } else {
                                count++;
@@ -2545,7 +2545,7 @@ bool Database::GetUnusedInstanceID(uint16 &instance_id)
                        }
                    } else {
                        instance_id = 0;
-                       mysql_free_result(result);
+                       mysql_free_result(result2);
                        return false;
                    }
                } else {
@@ -2554,6 +2554,7 @@ bool Database::GetUnusedInstanceID(uint16 &instance_id)
                    return false;
                }
            }
+           mysql_free_result(result);
        } else {
            instance_id = 0;
            mysql_free_result(result);

We're using a source from around September or October. Since then, we've noticed some odd issues with Twincast, Sympathetic procs, and TriggerOnCast effects being resisted 100% of the time.

After some digging, it appears that these effects do not include resists into the calculations. Can anyone else confirm/deny this?

Source: http://www.eqemulator.org/forums/showthread.php?t=37351

-Hate

Currently slow mitigation messages ("Your spell was partially successful, etc.") seem to consistently spam the caster of the slow spell, I think this happens every time a spell or proc is casted (or updated?) on the NPC.

I'm getting a segfault in PerlembParser::ReloadQuests() from zone/embparser.cpp that seems to be caused by line 131.

I haven't looked into this much yet due to lack of time, but changing the check if(perl == nullptr) back to if(perl == NULL) seems to fix it.

I hesitate to submit a patch since this was a project-wide change from NULL to nullptr.

Edit: Okay, maybe not. I'm still getting a segfault. I'll have to do more research.
Edit 2: It's segfaulting in Embperl::init_eval_file(void) called from Embperl::DoInit() on line 139 of zone/embperl.cpp.

GDB says:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7accb81 in Perl__invlist_intersection_maybe_complement_2nd ()
from /usr/lib64/perl5/core_perl/CORE/libperl.so

OS:
Linux XELEV 3.10.10-1-ARCH #1 SMP PREEMPT Fri Aug 30 11:30:06 CEST 2013 x86_64 GNU/Linux

Perl:
This is perl 5, version 18, subversion 1 (v5.18.1) built for x86_64-linux-thread-multi

The segfault occurs every time the server reinitializes. I hadn't even noticed it while using eqlaunch since it kept relaunching the zones for me after they crashed.

AZone was broken in the latest maps update (which is bad).

A new version is in the works to address this as well as enhance much of the map functionality but for now anyone who needs it should go back and use the AZone in the v1.0.1 tag.

EQGv4 zones cause high CPU utilisation:

http://www.peqtgc.com/phpBB3/viewtopic.php?f=1&t=13908

Whether this is due to the number of faces in the .map file, or the grids generated from packet collects or a combination of both is yet to be determined.

We have a npc quest event for EVENT_DEATH but not one for player quests.
There is EVENT_SLAY but it's far more limited as it is on a npc by npc basis.

Reproduce:

Give a level 4 nec pet a 1hs and a torch. He can now duel wield

Check probaby looks like:
https://github.com/EQEmu/Server/blob/master/zone/inventory.cpp#L943

Should only attack if weapon&&canduelwield instead of negating all the way

When I go to source the Merc_Spells.sql file on a fresh install, I get this error.

ERROR 1146 (42S02) at line 1 in file: '/home/eqemu/source/utils/sql/git/optional/2013_02_18_Merc_Spells.sql': Table 'peq.merc_spell_list_entries' doesn't exist

I followed this guide, except adapted it to my Linux server.
Is there another patch that I need to run to create the merc_spell_list_entries table under the peq database?
I did find a reference to that particular table name in this file: mercs.sql but the guide never mentions specifically needing to source it. If it does need to be sourced, does that mean that the bots.sql and or botsconvert.sql in the same folder also need to be sourced?

Thanks and I apologize if this is not the appropriate place to bring this up.

ucs, queryserv, and eqlaunch will all read the eqemu xml file to determine the IP and port of the World server. If you change the port, the other servers will honor it and attempt to find the world server on that port.

Yet, World insists on starting on port 9000 because the value is hardcoded in world/net.h and world/net.cpp.

World should read the config file for that value like any other process, and the log message should be updated to accept the port variable rather than a hardcoded string.

details here: http://www.eqemulator.org/forums/showthread.php?t=36577

Clients that are already in a zone do not get informed an NPC has changed to a charmed pet and still targetable by F8

Similarly, a client that zones in after the NPC was charmed will always see the NPC as a pet, even after the charm breaks

The client never gets informed of the recast timers on item being active (epics 1.5+, various healer clicky staffs from VP). Potions appear to work as intended.

Fairly certain this pertains to all clients.

There are a lot of random crash reports..but, not a lot of references that point to the cause...

Here is one from 2009: http://www.eqemulator.org/forums/showthread.php?t=37449&highlight=zone+crash+dump

And, of course, (one of) Akkadius's EZ server crash lists: http://wiki.eqemulator.org/i?M=Pastebin&Paste=d5sv9C8A (expires)

I did find a way to reliably reproduce these crashes..I chose 'firiona' due to there being opposing factions and I knew there would be some npc-on-npc action.

Basically, at the #zone-in point, doing a '#invul on -> #aggrozone -> -> #zoneshutdown firiona' will cause any of a series of crashes.

(I actually tried some hit-and-miss stuff in the beginning and found that I had two bug paths..A->B->D and A->C->D. regardless of the order, I still arrived at the same end point.)

I wasn't comfortable with the fact the hate was changing during zone shutdown, so I added code to the beginning of Zone::ShutDown() to turn off mob ai and to clear its aggro... (Later I found that a Wipe() is called in Mob::AI_Stop(), so I removed that.)

This led to a number of crashes going away..but, new ones crept in. (I also added a missing ';' in Mob::AI_Stop() and that appeared to have helped as well.)

(At this point, I had to define 'Zone::IsLoaded() { return ZoneLoaded;}' to get the next portion to work. I'm uncomfortable with using this since it's file scope..and I don't understand its use between instances..but, it does work in a test environment.)

My next crash was in '..\zone\quest_parser_collection.cpp:QuestParserCollection::GetQIByPlayerQuest(std::string &filename)'

The first line of code here is to check 'if(!zone)' and return nullptr.

the problem is that zone is defined..but, in a closing state. I added '|| !zone->IsLoaded()' because ShutDown() has just set 'ZoneLoaded' to false.

This is where non-apparent zone shut-down crashes are occurring. The are being processed after the shut down call thread is processed and are, likely, processed timers.

This fixed the 'GetQIByPlayerQuest' crash..but, still others were creeping in. So, I did a grepwin search for '(!zone' and found 8 more occurences and fixed those. (I have since gone back and found a lot of inclusion checks (i.e., 'if(zone)') that will probably need to be addressed similarly..weather check is one...)

I was still getting the occasional hate crash..so, I went into Mob::AI_Stop() and 'safe_deleted' the 3 pathing timers and 'Disabled()' ALL hard-coded timers and iterated SpecialAbilities[] to disable those as well.

It helped some more..but, no cigar...

The next two crashes were here:
https://github.com/EQEmu/Server/blob/master/zone/client_process.cpp#L698
and
https://github.com/EQEmu/Server/blob/master/ucs/clientlist.cpp#L626

And that's about where I am... Comments welcomed and here's a copy of my current test code:
http://wiki.eqemulator.org/i?Module=Pastebin&Paste=ZdfMAHUI

Reference issue #205.

Code at line 14970 in bot.cpp looks as follows:

            Bot* targetedBot;

            if(c->GetTarget() != nullptr) {
                if (c->GetTarget()->IsBot() && (c->GetTarget()->CastToBot()->GetBotOwner() == c))
                    targetedBot = c->GetTarget()->CastToBot();
                else
                    c->Message(13, "You must target a bot that you own.");

                if(targetedBot) {

It's possible that the targetedBot pointer is used uninitialized by the if() statement on line 14978, which can subsequently lead to a crash.

To fix, I suggest line 14970 to be changed to either:

            Bot* targetedBot = nullptr;

or

            Bot* targetedBot = 0;

Insufficient Perl knowledge to figure this out myself, sorry ...

Let's say I am rigorous about manually updating my database, but DON'T update db_version.version manually. When the script runs, it sees the mismatch and asks for an update check. The update check sees everything is current, nothing to do. Nothing changes the db_version.version, so the script bounces back and forth until I exit manually.

It would be nice if, when the update check ran and it found that, really truly honestly, nothing needed updating, it would set db_version.version to the correct value and just exit.

I looked into this issue and found an inconsistency between 'Zone Entry' and 'Zone Repop' packet construction. (Could be the difference between Queue and FastQueue builds.)

ref: http://www.eqemulator.org/forums/showthread.php?t=38623

I tested Ti through UF and all have the problem identified in the thread.

All are fixed by a zone #repop.

I added a PacketDump() call on the Encode of Ti's OP_ZoneSpawn.

Not counting the 'SpawnID' field, which obviously changed, everything else was the same..except for the last line of the dump:

624: 00 00 00 00 00 00 00 [zone entry]
624: FF FF FF FF FF FF FF [zone #repop]

These are the last three 'destructible fields'

Obviously, they're being handled by two different handlers..I just need to trace which is doing what.

Hopefully, this will solve some other issues too.

Newer clients support more than the current cap of 9 spell gems (12?)

(This is as of 09/26/2014 00:44:51 revision)

Compiling with MSVC2013, at line 1864 of zone\trading.cpp I get "error C2082: redefinition of formal parameter 'Name' " ... this is in function SendBazaarResults.

Not sure from context if you are meaning to send back out the same Name that was a function parameter, or a Name that was returned from searching items on offer. Commenting out this one line, i.e. send back out the same Name that was a function parameter, makes it compile OK. But if that is not what you really meant ...

Standing by.

Need to:
-Change all 4 white spaces together to tabs (in spaces vs tabs: tabs won)
-Remove trailing white spaces
-Fix other indentation problems (some places have inconsistent indentation or will use something like 2/3 spaces for indentation instead of tabs or 4 spaces)

Given the number of spells in current clients we're running up against int16 limits (esp when cast to a signed int).

We should at some point consider going through and changing all places we store spell_id to int or int32.

If a melee tome has a name starting with "Skill:" it cannot be learned, name test is hard-coded in. I tried to send a proposed update, not sure if it actually submitted.

This crash:

http://www.peqtgc.com/phpBB3/viewtopic.php?f=17&t=13906

Is caused because no check is made for owner == NULL in QuestManager::say, This will stop the crash in the given example:

diff --git a/zone/questmgr.cpp b/zone/questmgr.cpp
index 8474691..6b42ade 100644
--- a/zone/questmgr.cpp
+++ b/zone/questmgr.cpp
@@ -207,7 +207,13 @@ void QuestManager::echo(int colour, const char *str) {
entity_list.MessageClose(initiator, false, 200, colour, str);
}

-void QuestManager::say(const char *str) {
+void QuestManager::say(const char *str)
+{

•   if(!owner)
  

•   {
  

•           LogFile->write(EQEMuLog::Quest, "QuestManager::say called with NULL owner. Probably syntax error in quest file.");
  

•           return;
  

•   }
  

but all other pointer references in functions called from Perl also need checking for NULL before use.

I have recently added a few functions and exported them to Lua. They could be useful in Perl also if someone exports them.

QuestManager::RemoveFromInstance
QuestManager::RemoveAllFromInstance
Database::GetCharactersInInstance

When using #gassign a target with no grid, it returns "#gassign [num] - must have an npc target!"
When using #gassign 1 on a target where grid is a valid number and the spawn exists from the default PEQ database, it returns "ERROR: Unable to assign grid - can't find it in spawn2".

Line 1108 waypoints.cpp, change:
"if(matches == 1)"
to
"if(matches > 1)"

-Hate

GCC below 4.6 requires nullptr definition.

Since implementing the 2012 Dec 10 RoF compability version of eqemu, the UCS has stopped functioning properly - does not allow for friends list to be updated, does not allow for email, and other UCS related features.

This is a critical issue.

The function takes the parameter 'hater' which is never used. I assume at some point the intention was to have the method return the number of pets 'hater' has on the HateList however at the moment the function will just return the total number of pets/swarm pets on the list.

Steps to reproduce:

1. Launch a zone with Lua enabled and enter it
2. Have an NPC create an ItemInst() and then PushItemOnCursor() to you
3. Delete the item
4. Zone out in some manner and allow the zone to automatically shutdown
5. Segmentation fault

Here's a backtrace:

*** Program received signal SIGSEGV (Segmentation fault) ***(gdb) backtrace
backtrace
#0 0x0000000000e94f8b in ItemInst::Clear (this=0x7ffff7ff1000) at /home/user/EQEmu/source/common/Item.cpp:432
#1 0x0000000000e946cb in ItemInst::~ItemInst (this=0x7ffff7ff1000, __in_chrg=) at /home/user/EQEmu/source/common/Item.cpp:208
#2 0x0000000000e94fab in ItemInst::Clear (this=0x3205ad0) at /home/user/EQEmu/source/common/Item.cpp:433
#3 0x0000000000e946cb in ItemInst::~ItemInst (this=0x3205ad0, __in_chrg=) at /home/user/EQEmu/source/common/Item.cpp:208
#4 0x0000000000a7238b in Lua_ItemInst::~Lua_ItemInst (this=0x31e8670, __in_chrg=) at /home/user/EQEmu/source/zone/lua_iteminst.h:25
#5 0x0000000000a723fa in Lua_ItemInst::~Lua_ItemInst (this=0x31e8670, __in_chrg=) at /home/user/EQEmu/source/zone/lua_iteminst.h:25
#6 0x0000000000b63069 in std::auto_ptr::~auto_ptr (this=0x31e3528, __in_chrg=) at /usr/include/c++/4.7/backward/auto_ptr.h:170
#7 0x0000000000b83a9f in luabind::detail::pointer_holder, Lua_ItemInst>::~pointer_holder (this=0x31e3510, __in_chrg=) at /home/user/EQEmu/source/luabind/luabind/detail/instance_holder.hpp:79
#8 0x0000000000f5d198 in luabind::detail::object_rep::~object_rep (this=0x32403f8, __in_chrg=) at /home/user/EQEmu/source/luabind/src/object_rep.cpp:42
#9 0x0000000000f5d3af in luabind::detail::destroy_instance (L=0x1ee37c0) at /home/user/EQEmu/source/luabind/src/object_rep.cpp:88
#10 0x00007ffff70f73b4 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.1.so.0
#11 0x00007ffff70f77c4 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.1.so.0
#12 0x00007ffff70f8f4a in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.1.so.0
#13 0x00007ffff70f95b8 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.1.so.0
#14 0x00007ffff70f6a5a in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.1.so.0
#15 0x00007ffff70fe7d0 in lua_close () from /usr/lib/x86_64-linux-gnu/liblua5.1.so.0
#16 0x0000000000c2d2d1 in LuaParser::ReloadQuests (this=0x1e5fbe0) at /home/user/EQEmu/source/zone/lua_parser.cpp:759
#17 0x0000000000da17e5 in QuestParserCollection::ReloadQuests (this=0x1e5fa90, reset_timers=true) at /home/user/EQEmu/source/zone/QuestParserCollection.cpp:78
#18 0x0000000000e33cd7 in Zone::Shutdown (quite=false) at /home/user/EQEmu/source/zone/zone.cpp:882
#19 0x0000000000c946e6 in main (argc=1, argv=0x7fffffffe7e8) at /home/user/EQEmu/source/zone/net.cpp:419

Anyone else tried compiling with tests on linux?

I get a 'no rt link library' error. It looks to be because of the recent OSX change in the tests/CMakeLists.txt

Pretty sure we don't want rt linked in on tests for linux builds.

Details: http://www.peqtgc.com/phpBB3/viewtopic.php?f=17&t=13837

It seems there are some errors with their timers and maybe spell? HT will say 35 mins or w/e reuse but once you zone it goes back to what it would of been w/o the redux AA

EDIT: Underfoot at least.

This is a really inconsistent issue for us and one I'd like resolved; especially within the global scope.

http://www.peqtgc.com/phpBB3/viewtopic.php?f=17&t=13833

Currently one cannot interact with a trader/buyer in the bazaar if they started their trading while you were in the zone. /baz search window only shows active traders from before you zoned (trader tab), though a general search does show from all traders.
As is, if you wish to interact one needs to log or zone 1st.

Via Image:

void Mob::CalcBonuses()

if ( IsNPC() )
CastToNPC()->CalcNPCRegen(spellbonuses.HPRegen,spellbonuses.ManaRegen);
thats what I think is missing

Will look at it later if no one gets to it.

Consider addding a structure to the item table or an expansion of the texture fields in all tables to accomodate these new features

also would need to update quest system as appropriate

Created a public branch with a bunch of changes for implementing infuriate.

This NPC behavior only seems to be on selected raid mobs in the GoD expansion, but it is a nice feature for custom designers also.

The bad news; it's entirely unsupported right now.

The good news:- I know how the data is set in the structs in the current Live client, I just need to check a few more items to verify. The only thing I'm missing right now is the link to the final result, but tbh I have not worked on that just yet.

I'm currently levelling up an evolving item so want to get a pcap of when it "dings"- not sure we've ever found the opcode for that (if there is one). Unfortunately they level rather slowly :P

Once I understand how it's done on the current live client I can make some educated guesses on where to put things for the EqEmu supported clients.

EQEmu code isn't conforming to client specification. Client attempts one initial OP_SessionRequest plus 3 retries. Currently if OP_SessionRequest is received more than once EQEmu will disconnect the client from the server.

Changes are being tested, since this is intermittent it will require a good period of time to test.

http://pastebin.com/HWGKsadT

Unknown opcodes from the client will cause login to hang or rather the login connection between client and server to hang. Making the client do a very slow timeout instead we should disconnect the client.

Group Leadership AAs don't work in raids.

Raid Leadership AAs don't work at all.

Expeditions are not implemented.

Before the LUA changes, Mercenaries used to work just fine. Since the LUA changes, it is no longer possible to obtain a mercenary. Trying to do so will report "Mercenary failed to spawn". Also, I noticed that "zone" will crash when a person with an active mercenary is trying to enter it.

Related post:
http://www.eqemulator.org/forums/showthread.php?t=37086

Would this be of any use here, or better sent directly to cavedude? Thinking the latter, but it can't hurt to ask.

On windows, zone crashes with illegal address/heap corruption error when Client::ProcessMovePC is called after clicking a door (like for example in Tower of Frozen Shadow, the right side mirror which teleports the group to position "B" inside the dungeon).

I've narrowed the issue to line 414 in zoning.cpp:

    ClearDraggedCorpses();

When this is called on a Bot, it crashes the zone with above errors. The solution I found to work best is to check if the client is AI controlled and not execute the command when it is:

    if(!IsAIControlled())
        ClearDraggedCorpses();

Suggested patch to fix:

diff --git a/zone/zoning.cpp b/zone/zoning.cpp
index f69598c..930aa9f 100644
--- a/zone/zoning.cpp
+++ b/zone/zoning.cpp
@@ -411,7 +411,8 @@ void Client::MovePC(uint32 zoneID, uint32 instanceID, float x, float y, float z,
 void Client::ProcessMovePC(uint32 zoneID, uint32 instance_id, float x, float y, float z, float heading, uint8 ignorerestrictions, ZoneMode zm)
 {
    // From what I have read, dragged corpses should stay with the player for Intra-zone summons etc, but we can implement that later.
-   ClearDraggedCorpses();
+   if(!IsAIControlled())
+       ClearDraggedCorpses();

    if(zoneID == 0)
        zoneID = zone->GetZoneID();

A failed connection to mysql in the login server will cause it to crash. Ideally the program should bail out with a log error if it can't connect to the database.

MySQL servers that have STRICT_TRANS_TABLES enabled will fail to execute this function as leadership_aa is a tinyblob and under STRICT_TRANS_TABLES rules text/blob cannot have default values.

I had worked on this before and given up due to what would be required to make it work..at least until the new inventory system was implemented.

That is, until Secrets gave me an idea...

I managed to code the RoF client opcode encoder to handle out-going limbo (buffer) items..and that works without issue.

The problem is with how RoF treats its limbo versus the older clients.

PREMISE:
RoF+ (VoA+) uses a linear-ordered mapping system to store limbo items. (This means that newer items sent to empty, lower indices will be referenced before any older, higher indexed ones.)

UF- uses a list (FIFO) system to store limbo items.

Server uses a list system to store limbo items.

I have a modified ItemInstQueue class that will handle both a mapped and listed style of storage. It initializes properly..but, access behavior is modified to allow RoF+ clients to control location shifting.

PROBLEM:
External process calls to ItemInstQueue expect a pop() action to advance the limbo buffer.

This is not possible with a mapped system when no item is 'pushed' back on to the front. Major desyncs will occur between the client and server.

It is also not possible to push an item onto the front of the mapped list queue. The best that can be achieved is an insertion into the middle, or onto the end of the queue. Pushing onto the front of ItemInstQueue results in the pointer for m_cursor_ being updated and a problem with the original
cursor item being placed at the end of the mapped queue..a different behavior than being pushed back one position in the list queue.

EXAMPLE:
I successfully created an infinite loop when the RemoveDuplicateLore() code that I recently modified tried to empty out ItemInstQueue for processing:

[log] Inventory::GetItem(2) - Calling iteminstqueue->peek_front() (ItemInst_)
[log] ItemInstQueue::pull_limbo_front() - Returning limbo pointer as nullptr
[log] ItemInstQueue::pop() - m_cursor_ was assigned nullptr return from pull_limbo_front() (limbo list)
[log] ItemInstQueue::pop() - Returning pop_front() as ItemInst_
[log] ItemInstQueue::limbo_ptr() - Returning limbo list index 0
[log] ItemInstQueue::limbo_ptr() - Returning limbo list index 0
[log] ItemInstQueue::limbo_ptr() - Returning limbo list index 0
ad infinitum...

The lore check procedure is setup to check queue size and pop() the front of it while size() != 0. The return after the first pop() was nullptr.

In this case, I could bypass the required client-originating limbo to cursor move request since the queue has not been sent to the client. This, however, would not work in any case post zone-entry due to the resulting limbo desync.

SOLUTION:
Nothing that I can see at the moment...

http://wiki.eqemulator.org/i?Module=Pastebin&Paste=4XhHK3hS - RoF Patch
http://wiki.eqemulator.org/i?Module=Pastebin&Paste=grQ5CRcT - ItemInstQueue

The most likely solution is to wait for the new structure-based system to be implemented..this, and other issues, can be resolved much easier. Otherwise, a complete review of the entire inventory system will be needed.

OVERLOADING:
The queue can no longer be overloaded.

Since we will need to use a specific index when sending the client information, any duplication of index reference will simply over-write an existing object in the client.

ItemInstQueue now has an overload buffer to prevent more than the size of limbo from being stored/sent.

Two method are added in the modified ItemInstQueue to check the occupied size of limbo and return either a true or ItemInst pointer if space is available and there is an item in the overload. External processing is required so that a new limbo packet can be sent to the client.

via Akkadius:

Issue: When client enters zone and this call is made too early (alternate currency variables not initialized) it will write a new value of what is added instead of existing amount + new addition of currency.

My opinion on how to fix this was asked:
We need to either load alt currency earlier in the client creation timeline or change it so additions to alt currency will only take effect after the client is fully loaded (eg with a queue of alt currency operations until it is loaded).

When changing race. the following is true with rof

if you get permachanged through quest or gm. upon gettijg booted to char select, you can.load the character as you would expect

if you login to an account that has the non standard race it wont let you load the toon.

Is this a serverbor.client problem? if its a client problem, someone could implement male human packets for char select?