WesQuests.cpp on 2.4 Pre 5

[Stud]

Need a bit of help from someone in the know. I'm attempting to create quests scripts on my Linux server.

At first the zone was unable to locate the Quests folder and the zonename.qst files inside it. This I was able to correct by changing line 125 from reading:

_snprintf(filename, 254, "Quests\\%s.qst", zonename);
if (pFile = fopen ( filename , "rb" )) {
printf("Reading quests from %s\n", filename);
}

to

_snprintf(filename, 254, "./Quests/%s.qst", zonename);
if (pFile = fopen ( filename , "rb" )) {
printf("Reading quests from %s\n", filename);
}

Now it locates and attempts to read the file whenever you hail an NPC but immediately crashes the zoneserver with a segmentation fault when you do.

As long as you have no quest script in the Quests directory for the zone you are in, it functions fine. But if you have a .qst file, even a blank one, for the zone you are in in the Quests directory. It immediately crashes the zoneserver when hailing an NPC.

The quests do however work properly on a windows server.

Can someone possibly you Misa (wink wink) take a look at WesQuests.cpp and see what else other than the backslash problem would keep it from functioning the same under Windows as it does Linux, I've looked at it, and I just don't see it.

[Pyrotek]

I'm guessing it's having difficulty parsing the file due to the difference in linefeeds etc.

[Stud]

Okay, narrowed down a bit.... I think.... when it hits this chunk of code from WesQuest.cpp , is when the segmentation fault occurs...see anything non-linux friendly?

char * command;
char * temp;
temp = sep3.arghz[i];
if (temp == NULL) return;
Seperator sep(temp);
Seperator4 sep4(temp);
command = sep4.arghza[0];
if (!IsCommented(temp)) {
if (ps) {
char * nmessage = strreplace(sep4.arghza[1],"%CHARNAME%", this->GetName());

nmessage[strlen(nmessage) - 1] = '\0';
if (strstr(strupr(command),"SAY") != NULL) {
if (tt2 || ti2 || td) {
entity_list.Message(0, MT_Say, "%s says, '%s'", this->target->GetName(), nmessage);
}

[theCoder]

I don't know if this is the problem, but the implementation of strreplace contains a local static char array newstringza (OT: what's with all the za's all over the code?), which it fills with the new constructed string. At the end, it returns this array as a char*. I don't remember all the intricacies of C++, but I think this may be a problem (I'll write a quick program to see). A quick fix would be to change the last line (line 92) from:

return newstringza;

to:

return strdup(newstringza);

which allocates a buffer the correct size, copies the string to the buffer, and returns a pointer to the buffer.

Or, you could try moving the declaration of the char[] outside the function (just before it should work).

It's probably not a good idea to return a pointer to a local variable in any case. Anyone with more extensive C++ experience want to comment (I've been doing Java too long...).

[theCoder]

nevermind... that's not it... I just wrote a quick program showing that the static modifier should make it just fine (even non-static works, but generates a compiler warning). The problem must be something else...

Maybe some excessive printf's are in order...

[Stud]

Here's an strace of the segmentation fault, if this helps:

recvfrom(7 0xbfffe5d0 1024 0 0xbfffe5b0 0xbfffe5a = -1 EAGAIN (Resource temporarily unavailable)
gettimeofday({1016517324 915707} NULL) = 0
recvfrom(7 " ""\22\0\0A\200%\1\31\7!\0\0\0\0\377\377\377\377\36 5\26\365""..." 1024 0 {sin_family=AF_INET sin_port=htons(1440) " sin_addr=inet_addr(""12.232.20.23"")}}" [16]) = 117
nanosleep({0 1000000} 0) = -1 EINTR (Interrupted system call)
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++

[Stud]

Has anyone managed a work around on this yet, and have NPC scripting working on linux on their servers? I really don't want to suffer the performance hit of going back to Windows, but NPC scripts, and customized quests are the one feature I was looking forward to.

[misanthropicfnd]

With any luck quests should work in Linux in the next release (IWFMATM (It Works For Me At The Moment)). It appears a memory management problem was the cause of the segfaults. While it no longer segfaults, it's not clear if memory leaks exist. If you are able to test quests on a public server and determine if the zone server grows as quests are invoked let us know.

[Baltar]

trying to get scripts to work, but don't know the syntax for SETSKILL. Been tracing wesquests and it seems the separator datatype is used to parse the line (sep). Can't find where Seperator is declared though because separator-2.h has separator2, separator3, separator4. If anyone understands wesquest, please help me thanks.

[theCoder]

I don't know how to do the SETSKILL directive (I haven't messed around with quests at all yet, and in the next couple weeks I won't have time to either), but I can tell you that the Seperator class is defined in common/seperator.h. Notice that it is spelled (incorrectly) with an 'e' instead of an 'a': seperator.h. I know it confused me when I grepped for serarator and found nothing even though I knew I had seen classes like that before.

HTH

[Baltar]

thanks found it. Yeah it looked like the syntax needed a space
or some div as they call it in the end:

SETSKILL x y (space here)

Thanks for the help coder