Go Back   EQEmulator Home > EQEmulator Forums > Development > Development::Feature Requests

Development::Feature Requests Post suggestions/feature requests here.

Reply
 
Thread Tools Display Modes
  #1  
Old 11-04-2004, 11:23 AM
Cisyouc
Demi-God
 
Join Date: Jun 2004
Location: Heaven.
Posts: 1,260
Default The ability to...

COMPLETELY turn off the new quest system...all new files related to the quest system, I don't want them..is that possible?
__________________
namespace retval { template <class T> class ReturnValueGen { private: T x; public: ReturnValueGen() { x = 0; }; T& Generator() { return x; }; }; } int main() { retval::ReturnValueGen<int> retvalue; return retvalue.Generator(); }
C++ is wonderful.
Reply With Quote
  #2  
Old 11-04-2004, 01:14 PM
Edgar1898
Senior Member
Former EQEmu Developer
Current EQ2Emu Lead Developer
 
Join Date: Dec 2002
Posts: 1,065
Default

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.
__________________
Lethal Encounter
Reply With Quote
  #3  
Old 11-07-2004, 09:43 AM
Cisyouc
Demi-God
 
Join Date: Jun 2004
Location: Heaven.
Posts: 1,260
Default

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?
__________________
namespace retval { template <class T> class ReturnValueGen { private: T x; public: ReturnValueGen() { x = 0; }; T& Generator() { return x; }; }; } int main() { retval::ReturnValueGen<int> retvalue; return retvalue.Generator(); }
C++ is wonderful.
Reply With Quote
  #4  
Old 11-07-2004, 11:35 AM
sotonin
Demi-God
 
Join Date: May 2004
Posts: 1,177
Default

The new quest system is simply behind the scenes changed. the same commands still work in it that used too.
Reply With Quote
  #5  
Old 11-07-2004, 01:34 PM
Cisyouc
Demi-God
 
Join Date: Jun 2004
Location: Heaven.
Posts: 1,260
Default

Quote:
Originally Posted by sotonin
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.
__________________
namespace retval { template <class T> class ReturnValueGen { private: T x; public: ReturnValueGen() { x = 0; }; T& Generator() { return x; }; }; } int main() { retval::ReturnValueGen<int> retvalue; return retvalue.Generator(); }
C++ is wonderful.
Reply With Quote
  #6  
Old 11-07-2004, 06:45 PM
m0oni9
Hill Giant
 
Join Date: Dec 2003
Posts: 166
Default

Quote:
Originally Posted by Cisyouc
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.
Reply With Quote
  #7  
Old 11-08-2004, 03:37 AM
fathernitwit
Developer
 
Join Date: Jul 2004
Posts: 773
Default

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.
Quote:
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?
Reply With Quote
  #8  
Old 11-08-2004, 07:29 AM
RangerDown
Demi-God
 
Join Date: Mar 2004
Posts: 1,066
Default

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.
__________________
<idleRPG> Rogean ate a plate of discounted, day-old sushi. This terrible calamity has slowed them 0 days, 15:13:51 from level 48.
Reply With Quote
  #9  
Old 11-08-2004, 08:34 AM
sotonin
Demi-God
 
Join Date: May 2004
Posts: 1,177
Default

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.
Reply With Quote
  #10  
Old 11-08-2004, 09:26 AM
RangerDown
Demi-God
 
Join Date: Mar 2004
Posts: 1,066
Default

Actually, didn't they manage to talk FNW into doing that for them?
__________________
<idleRPG> Rogean ate a plate of discounted, day-old sushi. This terrible calamity has slowed them 0 days, 15:13:51 from level 48.
Reply With Quote
  #11  
Old 11-08-2004, 10:46 AM
sotonin
Demi-God
 
Join Date: May 2004
Posts: 1,177
Default

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


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

   

All times are GMT -4. The time now is 04:55 PM.


 

Everquest is a registered trademark of Daybreak Game Company LLC.
EQEmulator is not associated or affiliated in any way with Daybreak Game Company LLC.
Except where otherwise noted, this site is licensed under a Creative Commons License.
       
Powered by vBulletin®, Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Template by Bluepearl Design and vBulletin Templates - Ver3.3