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

Development::Development Forum for development topics and for those interested in EQEMu development. (Not a support forum)

Reply
 
Thread Tools Display Modes
  #1  
Old 08-11-2008, 01:39 PM
Derision
Developer
 
Join Date: Feb 2004
Location: UK
Posts: 1,540
Default

Quote:
Originally Posted by AndMetal View Post
"step" could be used to group each stage
Thanks! I think just adding a 'step' column to the activity table, rather than creating another table should suffice.

Anyway, I've hit upon another snag. I've just implemented the code to update 'Kill' and 'Loot' activities, based on NPCTypeID or itemid respectively, which works great, however ...

I wanted to add a Kill activity to kill 5 Orc Centurions, but there are 40 entries for Orc Centurions in the npc_types table!

As they say, no plan survives contact with the enemy! I would welcome ideas on this one. Doing a lookup against a list of 40 NPC IDs per kill seems a bit OTT. Maybe some sort of sub-string match again the NPC name may be a less expensive way to go.
Reply With Quote
  #2  
Old 08-11-2008, 02:07 PM
Andrew80k
Dragon
 
Join Date: Feb 2007
Posts: 659
Default

Hmm. Could be you just let any of them meet the requirements. Or you could just filter them out like you say. It probably makes more sense to filter them out and then let any of the resulting id's after you filter them to your satisfaction, meet the requirements for the task.
Reply With Quote
  #3  
Old 08-11-2008, 02:32 PM
AndMetal
Developer
 
Join Date: Mar 2007
Location: Ohio
Posts: 648
Default

Quote:
Originally Posted by Derision View Post
As they say, no plan survives contact with the enemy! I would welcome ideas on this one. Doing a lookup against a list of 40 NPC IDs per kill seems a bit OTT. Maybe some sort of sub-string match again the NPC name may be a less expensive way to go.
I think an easy way to do this would be to allow either a # (NPC ID for a specific mob) or a string. Then, the server can check to see which it is. If it's a #, use the specific NPC ID. If it's a string, allow multiples based on the string (SELECT name FROM npc_types WHERE name LIKE '%an_orc%'). I think it would be a lot easier to utilize overall (an_orc for example, instead of an_orc_warrior, an_orc_oracle, or an_orc_pawn). However, in the same token, I believe it could cause problems for mobs that have different names, but are different (lower) levels (read: exploit).

As much as I like the first option, I think the "better" way to do it would be to create a similar lookup table like I mentioned above. Yes, it is another table, but it makes it much more powerful overall. That way, you could also include named mobs that are rare spawns to include towards the kill target. Yeah, it seems like more work in the database, but that's also what relational databases are for: creating complex relationships between data sets
__________________
GM-Impossible of 'A work in progress'
A non-legit PEQ DB server
How to create your own non-legit server

My Contributions to the Wiki
Reply With Quote
  #4  
Old 08-11-2008, 02:45 PM
KLS
Administrator
 
Join Date: Sep 2006
Posts: 1,348
Default

Use quests for the kill component =p
Reply With Quote
  #5  
Old 08-11-2008, 03:00 PM
AndMetal
Developer
 
Join Date: Mar 2007
Location: Ohio
Posts: 648
Default

Quote:
Originally Posted by KLS View Post
Use quests for the kill component =p
*smacks forehead* I should have had a V8!
__________________
GM-Impossible of 'A work in progress'
A non-legit PEQ DB server
How to create your own non-legit server

My Contributions to the Wiki
Reply With Quote
  #6  
Old 08-11-2008, 03:27 PM
Derision
Developer
 
Join Date: Feb 2004
Location: UK
Posts: 1,540
Default

Quote:
Originally Posted by KLS View Post
Use quests for the kill component =p
Thanks

I've now mapped out some more of the activity types:

Code:

Activity Type Codes:

1 Deliver x to y
2 Kill n MobX
3 Loot n ItemA
4 Speak With x
5 Explore y
6 Create n ItemA using Tradeskills
7 Fish for n ItemA
8 Forage n ItemA
9 Use on 
10 Use on
11 Touch ItemA
So 1, 2, 4 and 5 can be handled through quests.

3 I already have handled by hooking into Corpse::LootItem, and I imagine 6, 7 and 8 should be done by hooking into the code as well.

I'm guessing that the 'Touch' activity means clicking on a clickable-object, like a door or something. I found a task on Alla that has 'touch' as an activity:

http://everquest.allakhazam.com/db/q...tml?quest=3151

But it's not clear what it means.
Reply With Quote
  #7  
Old 08-11-2008, 03:37 PM
Flare83
Sarnak
 
Join Date: Aug 2008
Location: usa
Posts: 43
Default

I'm guessing that the 'Touch' activity means clicking on a clickable-object, like a door or something. I found a task on Alla that has 'touch' as an activity:

http://everquest.allakhazam.com/db/q...tml?quest=3151

But it's not clear what it means.

It means zone into a certain instanced / zone basically ~.~
__________________
thenameless.site88.net
Reply With Quote
  #8  
Old 08-12-2008, 01:26 PM
Bulle
Hill Giant
 
Join Date: Jan 2008
Posts: 102
Default

When you say : for kills, handling through quests, do you actually mean patching/creating many NPCs Perl quest files ? There can be an orc_centurion in several zones, some of them actually "dinging" the quest..

As the kill activity is very common, having a lookup table (ID of activity, ID of mob) seems worth doing. Especially as you can attach this list/set to the activity in a field once it is loaded from the DB. It probably is not in the scope of Live-like, but extending this to several activity types you could then have activities that accept looting "any rusty weapon". Not trying to make my shopping list for the first implementation, just trying to keep doors open here

Or may be you thought of another way through quests ?

As a professional programmer let me say one thing : filtering on the name (or a part of the name) will inevitably create unsolvable situations, or to say it bluntly, it will suck. It always does when you start doing such things.
Reply With Quote
  #9  
Old 08-12-2008, 02:05 PM
Derision
Developer
 
Join Date: Feb 2004
Location: UK
Posts: 1,540
Default

Quote:
Originally Posted by Bulle View Post
When you say : for kills, handling through quests, do you actually mean patching/creating many NPCs Perl quest files ? There can be an orc_centurion in several zones, some of them actually "dinging" the quest.
I took it to mean calling the task activity update method from within sub EVENT_DEATH, which works.

Quote:
As the kill activity is very common, having a lookup table (ID of activity, ID of mob) seems worth doing. Especially as you can attach this list/set to the activity in a field once it is loaded from the DB.
My concern was, in the case of an Orc Centurion, having to check through a list of 40 NPCIDs every time the player killed something to see if he had killed an Orc Centurion. It occurs to me now that if the list is sorted, I could do a binary search on larger lists, so maybe it wouldn't be so bad

I could always include both methods and have a flag to indicate whether the activity count update was to come from a quest, or be checked from a list.
Reply With Quote
  #10  
Old 08-12-2008, 02:14 PM
KLS
Administrator
 
Join Date: Sep 2006
Posts: 1,348
Default

EVENT_KILLED_MERIT was designed with mob kill quests in mind. You could make 40 different quest files or you could just make a single an_orc_centurion.pl. It basically just simplifies the problem that was discussed above but is hardly the only solution.
Reply With Quote
Reply

Thread Tools
Display Modes

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 10:53 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 - 2025, Jelsoft Enterprises Ltd.
Template by Bluepearl Design and vBulletin Templates - Ver3.3