EQEmulator Forums

EQEmulator Forums (https://www.eqemulator.org/forums/index.php)
-   Archive::Development (https://www.eqemulator.org/forums/forumdisplay.php?f=621)
-   -   Proposal: spawn conditions (https://www.eqemulator.org/forums/showthread.php?t=15363)

fathernitwit 08-16-2004 02:02 AM

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.

sotonin 08-16-2004 02:11 AM

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 )

fathernitwit 08-16-2004 02:23 AM

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.

KhaN 08-16-2004 03:38 AM

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

daeken_bb 08-16-2004 03:46 AM

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?

fathernitwit 08-16-2004 05:10 AM

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.

killspree 08-16-2004 06:37 AM

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.

fathernitwit 08-16-2004 06:42 AM

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...

killspree 08-16-2004 06:46 AM

Well I definitely think it will be useful...I was planning on expanding it eventually but not until I had other things working correctly.


All times are GMT -4. The time now is 02:36 PM.

Powered by vBulletin®, Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.