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

Archive::Development Archive area for Development's posts that were moved here after an inactivity period of 90 days.

Reply
 
Thread Tools Display Modes
  #1  
Old 08-16-2004, 02:02 AM
fathernitwit
Developer
 
Join Date: Jul 2004
Posts: 773
Default Proposal: spawn conditions

Hello,

I thought of a potential feature, and I was wondering what you guys thought about it. This was inspired by the ldon level segregation thing, but is a more general, broader solution. There is a certain overlap with the current quest system, and thats one reason I am asking if it might be useful.

What I am proposing is the idea of 'spawn conditions'.
This is basically where you are able to set a conditional which is checked before a spawn is even consitered for spawning.

Potential uses:
1. LDoN level segregation. Setup all the possible spawns, tag them each with a conditional, so only one spawns.
2. progressive spawns. Kill one mob (or several), it sets a conditional which changes the spawn pattern of the zone to spawn bigger mobs.. for example, kill over a set number of craig chicks, cause the momma craig to spawn. etc...
3. zone 'plots'. A quest can alter a zone, such that camps spawn different things, aka one group of NPCs 'takes over' another camp, etc..

there are prolly more, post them if you can think of them.


The way I propose to do this is:
- there are a fixed set of conditions avaliable:
e.g. == x, != x, < x, > x, > x > , etc...
- each entry in spawn2 gets extra columns which represent the conditionals, something like:
- variable_name - name of the variable
- condition - which condition to apply
- arg1 - one arg to the condition
- arg2 - another arg to the condition, if it needs it
- code to check these conditionals at the same time the 'chance' to spawn is checked.
- perl functions to get and set these spawn variables.
- Option to set a decay time on a variable, so it fades back to 0, or whatever over time, for things like progressive spawns which need to revert if nobody plays with them
- variables will be global, not per-zone.


Let me know what you think, if enough people think it will be useful, then I will start working on it when I get bored of other stuff.
Reply With Quote
  #2  
Old 08-16-2004, 02:11 AM
sotonin
Demi-God
 
Join Date: May 2004
Posts: 1,177
Default

It sounds pretty cool. Although i was hoping you might use your programming skills to rewrite some more emu systems like you've done with tradeskills. =)

There's a lot of bad code to be rewritten apparently!

Zoning has been whacked hardcore for us with any version past 7-17-04. Zones fail to bootup properly leaving the player hanging at loading screen. Happens on a regular basis causing said player to be stuck.

Also the biggest problem is the one that says zone unavailable at least once every try to log on. (client doesnt give server enough time to properly boot zone and thinks its down)

I'm sure there a number of other issues with the zone bootup shutdown processes, I just lack the knowlegde to correct it myself. TCSMyworld is looking into a multithreaded solution he used before. We are at our wits end )
Reply With Quote
  #3  
Old 08-16-2004, 02:23 AM
fathernitwit
Developer
 
Join Date: Jul 2004
Posts: 773
Default

Well i'll be 100% honest with you:
If it isnt bothering me, it isnt going to get fixed.

I like tradeskills, thats why I rewrote them.

I havent experienced any of the said problems, I am using the client between 7-27 and 8-11 on a pair of private, fast servers. I have seen minor problems with zones not booting up fast enough (specifically with lots of perl quests), but there is little that can be done about that one. Theres obviously a lot of potential solutions, few of which invlove programming.


Theres lots of code cleanup that could be done, and some I might do (warnings, perl function dispatch, and more extensive #if debug level support to get rid of debug code when compiled come to mind), but that is not a task that I would even consider without commit access, because I sure as hell am not going clean up somebody else's mess without knowing that it is going to get used.
Reply With Quote
  #4  
Old 08-16-2004, 03:38 AM
KhaN's Avatar
KhaN
Dragon
 
Join Date: Mar 2004
Location: France, Bordeaux.
Posts: 677
Default

Quote:
there are prolly more, post them if you can think of them.
- Time of the day : merchant will spawn only during work time.

Quote:
There's a lot of bad code to be rewritten apparently!
Someone is speaking about PERL ? :/

Also, thanks for all the fix/add to eqemu code you are doing fathernitwit, i can say you that you freeing a lot of Nemo's time, so he can work on others thing :p
__________________

Reply With Quote
  #5  
Old 08-16-2004, 03:46 AM
daeken_bb
Discordant
 
Join Date: Mar 2003
Location: Chambersburg, PA
Posts: 469
Default

Though many of those things can be implimented in the quest system (there _are_ time-based triggers, right?) a more elegant solution may be a better idea. But you have to question whether these are things that need to be explicitly coded into eqemu... could they not just be simple skeletons of quests that people could customize as they see fit?
__________________
Keep me unemployed and working on OpenEQ, PM me about donating

Check out my deviantART page at http://daeken.deviantart.com/
Reply With Quote
  #6  
Old 08-16-2004, 05:10 AM
fathernitwit
Developer
 
Join Date: Jul 2004
Posts: 773
Default

Quote:
Originally Posted by daeken_bb
could they not just be simple skeletons of quests that people could customize as they see fit?
Well this would just be a method of accomplishing the things mentioned above... using the quest system. So that in the future, quests could be written to accomplish the things above... if it gets done, it will still not do/change anything unless people write quests to manipulate it. The only thing that is not this case is the LDoN stuff, which I really dont see being done with perl quests in the long run, since we lose so much of the functionality.
Reply With Quote
  #7  
Old 08-16-2004, 06:37 AM
killspree
Dragon
 
Join Date: Jun 2002
Posts: 776
Default

I actually made a change to be able to do most of this and posted it in a thread in quest creation which was about the subject(somewhat). It was a pretty basic implementation right now, I just added a field to the database in spawn2 and zone, then compare the two to spawn NPCs for that zone.

http://www.eqemulator.net/forums/viewtopic.php?t=16650 That's the thread with the changes in it.

That was a temporary solution until I get instancing going, as I explained there. Eventually the advlevel field will be removed from the zone table and added to the instance table, so that each individual instance can have its own level range associated with it.
__________________
Xeldan
Lead Content Designer
Shards of Dalaya
Reply With Quote
  #8  
Old 08-16-2004, 06:42 AM
fathernitwit
Developer
 
Join Date: Jul 2004
Posts: 773
Default

Yea,
that was the thread that inspired this... i just felt like what you were working on was more of a hack to get one specific thing working, than it was a general system which could be used for more things...
Reply With Quote
  #9  
Old 08-16-2004, 06:46 AM
killspree
Dragon
 
Join Date: Jun 2002
Posts: 776
Default

Well I definitely think it will be useful...I was planning on expanding it eventually but not until I had other things working correctly.
__________________
Xeldan
Lead Content Designer
Shards of Dalaya
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 12:32 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