Page 1 of 1

Table: spawn_scripts explained

Posted: Sat May 30, 2009 8:05 pm
by John Adams
This is my understanding of how our table `spawn_scripts` works.

First, an introduction. In EQ2Emulator, everything we put in the game manually is considered a "spawn" - whether it be an NPC, Object, Sign, Widget or GroundSpawn. You can assign LUA Scripts to most of these spawn types, but generally speaking, they are assigned to NPCs.

Spawns have a few components that are vital to their existence in the world; a Spawn ID, a Spawn Group, and a Spawn Entry (the latter being the link between the Spawn Group and the actual location the spawn appears in a zone). These 3 values are used in the table `spawn_scripts`, which is why I explained them a bit.

Here is a typical `spawn_script` entry:
spawn_scripts1.jpg
What this shows is the script "TrainerBordaGemseeker.lua" is assigned to spawn_id 2530005 - which is specifically, the Trainer on the Queen's Colony. This means, if a Spawn has a spawn_id 2530005, it is going to use this spawnscript when the zone loads. I would guess nearly 75% of our spawn_scripts are assigned this way, because most of our scripts are conversations or quests with NPCs.


Another type that is also used is the `spawnentry_id` assignments. First off, you have to understand how a spawnentry_id works. A spawnentry_id is merely the intersection between spawns and their spawn locations in a zone. Take this spawn for example:
spawn_entry1.jpg
In this example of the zonespawnentry table, you see 2 spawn ID's (340048 and 340049) that belong to the same spawngroupid. Since locations in a zone are assigned by spawngroupid, these entries tell the zone to load one OR the other spawn, on a 50/50 chance. These are called "Placeholders", for those familiar with camping mobs in MMOs.

So what happens when you as a world designer want the possiblity of 2 different spawns to appear in the same location? Furthermore, you want them to "behave" differently when they do? You build a Placeholder Spawngroup.

A functional example would be that you have a 90% chance that a KOS mob will spawn at x,y,z - and the players job is to kill that sucker over and over til the 10% chance that a friendly version of the same NPC shows up. Could be the same NPC, could even be the same spawn_id... but you need to tell the zone what Script you want to assign to the different spawns. spawnentry_id is your answer.

You'd assign spawnentry_id 99882 (the hostile) to "aggro_me.lua", and it would shout profanities at you as you fought and killed it. Opposite of that, you would assign spawnentry_id 99883 (same NPC, same spawngroup) the "likes_me.lua" script. How you do that is like this:
spawn_scripts2.jpg
Now when the zone loads, the same NPC in the same space, depending on which version spawns, will get two different scripted interactions with the player.


The last type is assigning scripts to spawngroup_id. This is basically a simplified version of the above, assigning to spawnentry_id. In this scenario, you have placeholder NPCs that will all behave the exact same, no matter which version spawns. Since all the spawns are in the same spawngroup, assigning the script to that spawngroup's ID makes them all use it.

Quick example, because if you understand spawnentry_id, this is a no-brainer ;)
spawn_entry2.jpg
This is the zonespawnentry setup for ONE of the "sparring partner" spawn locations on the Queen's Colony. You will see a possibility of 4 different NPCs that might appear in this x,y,z location. Some will appear more often than others (16%, 16%, 33% and 33% = 100% someone will always be there :))

Note all these spawns are in the same spawngroup 7872.

In our spawn_scripts table, we have assigned spawngroup_id 7872 the script "SparringPartners.lua", since all the sparring partners tend to say and do the same thing.
spawn_scripts3.jpg
Now, no matter what spawn_id or spawnentry_id pops in zone, only this script will be used.



So ends the lesson on spawn_scripts and how it is used. See the ServerPack for examples of how this works, or play with it on your own. If there are any questions, or if anything I've detailed here turns out to be wrong, please let us know in the General Support forums.