Nope, since all our spawn_ids are unique now you will not have to specify the type of spawn it is when you are spawning a new spawn. It will automatically determine that for you. You just have to supply a valid id.
Since the LUA stuff is global, I need a reference to which zone it was called from. That is why the first parameter is a spawn in the current zone. It doesnt matter which one. Say you want to spawn another Spawn when a player hails a particular spawn. Here are a few examples:
function hailed(NPC, Spawn)
Spawn(NPC, 4) -- Spawns a new spawn with an id of 4 for all to see
end
function hailed(NPC, Player)
Spawn(Player, 5) -- Spawns a new spawn with an id of 5 for all to see
end
function hailed(CoolNPC, CoolPlayer)
Spawn(CoolNPC, 6) -- Spawns a new spawn with an id of 6 for all to see
end
function hailed(CoolNPC, CoolPlayer)
NewSpawn = Spawn(CoolPlayer, 7, true) -- Spawns a new spawn with an id of 7 that noone can see
AddSpawnAccess(NewSpawn, CoolPlayer) -- give the player access to the private spawn
end

oh btw a safer approach to that last example would be:
function hailed(CoolNPC, CoolPlayer)
NewSpawn = Spawn(CoolPlayer, 7, true) -- Spawns a new spawn with an id of 7 that noone can see
if NewSpawn ~= nil then
AddSpawnAccess(NewSpawn, CoolPlayer) -- give the player access to the private spawn
end
end
The reason being if there is an error and the spawn wasnt spawned for whatever reason like maybe the id was invalid, the previous LUA script would crash.

Ok cool so I can give the "Spawn" param the questgiver parameter passed in through a quest script. Easy enough
Thanks!

Awesome. Nevermind that first thing in your JA Tasks request then hehe. I'll keep an eye out for commits, and get it to Tess for us to try out. Looks cool.
And speaking of planes - while these days I am crashing networks, once upon a time (10 years ago) I worked for Boeing as well - formerly McDonnell/Douglas Helicopter (Apache/Longbow project) as a network engineer.

I just thought of another one but I'm not even sure if it's possible yet. We need a questUpdate function to allow us to update quests after inspecting a certain item (or reading a book). One of the quests on the noobie island requires this so that's when it came to mind.

Here's another LUA function that would be popular, especially for getting off the tutorial islands.
ZonePlayer(zone_id|zone_name [x,y,z,h])
...where zone_id|zone_name are either the zone_id or zones.name field from the zones table, and optionally x,y,z,h are the coords to drop the player. If omitted, the zones safe_? coords could be used.
ZonePlayer, or ZoneTarget, ZoneSpawn, whatever you want to name it.

And yet another!
SpawnAnim(visual_state_id) or SpawnEmote(visual_state_id, text) something like that. Unless there is already a function for this in the Play* stuff, which I haven't figured out yet.

OK, I added the GetZone and Zone functions as well as made a few modifications to the Spawn function.

Sweet! Thanks LE.

Bah, I just realized that I didn't add any parameters to tell it WHERE you wanted to spawn the spawn. heh Anyways, I'll add x, y, z, heading to the function with heading being optional.

Lol, we all have our brain farts

Another LUA function we need is one to be able to tell which step of a certain quest we are on. Like, GetQuestStep(Spawn, quest_id) because sometimes you have to return back to the same quest NPC and each time you return back to him he says something different depending on which step of the quest you are on.

OK, I added it as GetQuestStep(Player, quest_id). It returns 0 if the player doesnt have the quest, or the last completed step + 1.

Perfect, thanks!

LE, are we storing our character_quest and character_quest_progress data yet? If not, can you predict when we might get that? It is not vital for us learning how to write quests, but doing the same steps repeatedly to test new steps will eventually get annoying. How many waterlogged britches can one man wear?
Thanks