The ability to...

[Cisyouc]

COMPLETELY turn off the new quest system...all new files related to the quest system, I don't want them..is that possible?

[Edgar1898]

Well if you dont have perl defined it shouldnt use any of the stuff. It might say its compiling the file, but if you look in the file, you will see that it checks to see if perl is defined and if it isnt then it just skips everything in the file. Thats what I think your talking about, if not please let me know and try to give me an example of a specific feature that is enabled but shouldnt be.

[Cisyouc]

I want perl defined, because I want the -old- quest system. I don't want anything to do with the recent quest changes, however I want to use the other fixes released in DR2. Is this possible?

[sotonin]

The new quest system is simply behind the scenes changed. the same commands still work in it that used too.

[Cisyouc]

The new quest system is simply behind the scenes changed. the same commands still work in it that used too.I have found an equal performance with this system compared to the old system front side.

However, I find the old system is ALOT easier to manage when working with the server source itself, editing and creating quest commands. Not to mention the code I have had and will have to port into the new system.

If its not possible, thats fine, I'll just stick with DR1 for now. I just thought it was a little unfair to impose this new system without any choice nor documentation about it, and I wanted to see if I would be able to use DR2 without it.

[m0oni9]

I just thought it was a little unfair to impose this new system without any choice nor documentation about it.
There are two options: one, keep both systems functional; two, have only the new system functional. The problem with option one is that people will use the easier system, leaving the other unused and wasted. Also, having both systems together feels kind of flaky IMO. As far as documentation is concerned, I'm sure it's forthcoming. Much will be as it already is, to aid in backward-compatibility. Option two will end up being the best system overall, and if chosen, a speedy transition is necessary (less code to port, etc).

Also, this system is not all about performance. The command queue was really sort of a kludge to begin with. This system makes the quest commands real functions, instead of what they were. It has a steeper learning curve -- there is some initial stuff you will need to learn. But after that, I think you'll find it is worth the small inconvenience.

[fathernitwit]

im sorry, but theres NOTHING that cannot be ported to the new quest system that was avaliable in the old quest system.... It took me about 45 minutes to port EVERY command in the old system to the new stuff.

And actually, if you disable EMBPERL_XS, you can do everything exactly like it was.... pile all your code in parser.cpp like a giant pile of crap, I dont care, it will work just fine...

Emu will not remain a pile of crap just to make it easier to work with. The new system is much more cleanly defined, and works in all circumstances.

also, if you take the time to read the code, heres the text at the top of questmgr.cpp that tells you how to add a quest command.

Assuming you want to add a new perl quest function named joe
that takes 1 integer argument....

1. Add the prototype to the quest manager:
questmgr.h: add (~line 50)
void joe(int arg);

2. Define the actual function in questmgr.cpp:
void QuestManager::joe(int arg) {
//... do something
}

3. ... perl parser.


4.
If you want it to work in old mode perl and .qst, edit parser.cpp
Parser::ExCommands (~line 777)
else if (!strcmp(command,"joe")) {
quest_manager.joe(atoi(arglist[0]));
}

And then at then end of embparser.cpp, add:
"sub joe{push(@cmd_queue,{func=>'joe',args=>join(',',@_)});}"


it even skips over the perl stuff that you hate so much, isnt that nice of me?

[RangerDown]

I noticed Cis that your main complaint is because this will break compatibility with your customized code. Sorry, but lots of server ops customize their code and Emu would never move forward if the stock Emu code was required to stay compatible with their customizations.

If you make custom modifications, you assume the risk that your mods won't be compatible with stock code down the road. It's that simple.

[sotonin]

Hence why Winter's Roar is still using 5.3 code. heh. In order to use the newer codes they would need to merge in all their completely custom features.

[RangerDown]

Actually, didn't they manage to talk FNW into doing that for them? :D

[sotonin]

They still use the old client i beleive. The merge was just to improve the stock cvs greatly