Sorry about the forums being down for the last bit.  Turns out ICANN needed domain name verification but they were using an old email address so I didn't get the notification and boom they had the domain name suspended.  So after some dancing around I think these issue should be resolved now.

Again sorry about the interruption.

This topic has been moved to Forum and Website Discussions.

http://www.hydlaaplaza.com/smf/index.php?topic=40276.0

Hi.

We've got some reports with users having some issues trying to register on the forums.  Most reporting not getting their email confirmation.  I activated a bunch of accounts from the last month so but need a few people ( using different email addresses ) to try to register new accounts to see what the issue is.  If you do please post what address you used and if it worked or not.  You don't need to give the total address just the domain ( ie everything after the @ ).  I want to see if there is some common element here that is blocking the emails.

Thanks,

Results:

googlemail.com	Possibly in Spam Filter
@gmx.de	Failure to send Email

I have setup doc.hydlaa.com in an attempt to develop some documentation about PlaneShift the engine.   However, right now it's pretty just me adding some details here and there.   What is needed are people to be editors to keep the pages organized and making sense and some people to start adding some of the required pages.     Right now I am not sure what required pages are but once people start adding pages I can start to add in details.   Maybe a good page to add would be a "Request" page then I can read those and start adding in some of the requested pages.

In an attempt to start documenting more about how it works I thought I would toss out some ideas and see what area people would like to see more Documentation.  I know that 'all' is probably what most people would like but needs to start somewhere.

In an effort to help us narrow down bugs I will try to offer some some advice on how to improve the bug reporting on bugs.hydlaa.com.  First up is this bug:

"It seems we have the ability to repair stocks, after combining 2 of different quality and getting a difference like 235/267 for example. What is even more wierd is the fact that it doesn't eat up a repair kit when I repair it.
Also quality related issue, when combining some stocks of different quality (it depends on the order of combining), I get 265/235 quality of a stock."

Seems pretty good at the start but it's missing a couple of key pieces of information.
1) Which stocks? If I run this query
mysql> select id,name from item_stats where name like "%Stock";
I get over 22 results.  I can't check them all to see if the behaviour is the same for all of them.
2) The quality and quantity in the stacks.   Is 235/267 the before or after values?
 
3)  For the second part, again what stocks, what values, what qualities are involved?  "It depends on the order", means that order is important so that should be given as well.  The highest quality on the lowest?  The largest stack on the lowest,  the largest on the lowest quality, etc. 

With the above information I can quickly create the same condition in my test server.  Otherwise I have to make guesses which might not lead to the same bug here which will result in me closing the bug because I cannot find it.

For all of you that\'s wondering what\'s going on with the server here\'s an example of what we are trying to deal with.   After a crash a core dump is generated.  This is a large file ( 500+MB ) that contains what the program was doing up to that point.  So after every crash we can examine that and try to figure out what went wrong.  Think of it as a black box like on an airplane.

This core file contains a back trace which is how the programming was flowing before the crash and looks something like this:

0  0x08255a55 in psCharacter::CheckQuestCompleted(psQuest*) (this=0xabb0228,
    quest=0x8674770) at src/server/bulkobjects/pscharacter.cpp:2820
2820        if (IsQuestAssigned(quest->GetID())->status == \'C\')
(gdb) bt
#0  0x08255a55 in psCharacter::CheckQuestCompleted(psQuest*) (this=0xabb0228,
    quest=0x8674770) at src/server/bulkobjects/pscharacter.cpp:2820
#1  0x0823127a in VerifyQuestCompletedResponseOp::Run(gemNPC*, Client*, NpcResponse*) (this=0x8676b90, who=0xaecaf48, target=0x11348488, owner=0x86763e8)
    at src/server/bulkobjects/dictionary.cpp:957
#2  0x08230f92 in NpcResponse::ExecuteScript(Client*, gemNPC*) (
    this=0x86763e8, client=0x11348488, target=0xaecaf48)
    at src/server/bulkobjects/dictionary.cpp:902
#3  0x081b2a89 in PlayerToNPCExchange::HandleAccept(Client*) (this=0x13774c30,
    client=0x11348488) at src/server/exchangemanager.cpp:1200
#4  0x081b3926 in ExchangeManager::HandleMessage(MsgEntry*, Client*) (
    this=0x8488c30, me=0xc438a78, client=0x11348488)
    at src/server/exchangemanager.cpp:1369
#5  0x082fc3e9 in MsgHandler::Publish(MsgEntry*) (this=0x8529cb8, me=0xc438a78)
    at src/common/net/msghandler.cpp:97
#6  0x0830c3f6 in EventManager::Run() (this=0x8529cb8)
    at src/common/util/eventmanager.cpp:154
#7  0x08282b4c in csPosixThread::ThreadRun(void*) (param=0x84a3980)
    at libs/csutil/generic/cspthrd.cpp:479
#8  0x40021941 in pthread_start_thread () from /lib/i686/libpthread.so.0

Most crashes are a result of null pointer errors.  So in this case the line:

if (IsQuestAssigned(quest->GetID())->status == \'C\')

has 2 potential pointers to check, quest and the result from IsQuestAssigned()


(gdb) print quest
$1 = (psQuest *) 0x8674770

Seems ok.

(gdb) print quest->id
$2 = 13479

Seems ok

So lets look at the code a bit here now:

bool psCharacter::CheckQuestCompleted(psQuest *quest)
{
    if (IsQuestAssigned(quest->GetID())->status == \'C\')
        return true;
    else return false;
}

So now we should check IsQuestAssigned to see what that is doing:

QuestAssignment *psCharacter::IsQuestAssigned(int id)
{
    for (size_t i=0; i    {
        if (assigned_quests[i]->quest->GetID() == id &&
            assigned_quests[i]->status != \'D\')
            return assigned_quests[i];
    }
    return NULL;
}

So this returns NULL if the quest is not found in the assigned quests list.  

So lets take a look at that:
(gdb) p assigned_quests
$3 = {count = 5, capacity = 16, threshold = 16, root = 0x12204fa0}

Ok there is only 5 elements in there.  Lets take a look and see if we
can find the one with our id in it.

(gdb) p assigned_quests.root[0]->quest->id
$4 = 11
(gdb) p assigned_quests.root[1]->quest->id
$5 = 15
(gdb) p assigned_quests.root[2]->quest->id
$6 = 19
(gdb) p assigned_quests.root[3]->quest->id
$7 = 20
(gdb) p assigned_quests.root[4]->quest->id
$8 = 23


Aha so we can see that our quest we are looking for is not found so
IsQuestAssigned(quest->GetID() is returning NULL therefore when we try
to use ->status on this it falls down and goes boom.


Solution?
Fix the
bool psCharacter::CheckQuestCompleted(psQuest *quest) function to check
for null pointer first.

QuestAssignment* assignment = IsQuestAssigned(quest->GetID());
    if (assignment && assignment->status == \'C\')
    ...
   
Now this will make sure assignment exists first before trying to use ->status on it.

So that bug should be fixed ( I hope ) and I can delete that core file and move on to the next one.