Event_cast

[Sion]

Would it be possible to add a player event like EVENT_CAST that goes off when a player casts a spell? I know there is EVENT_CAST_ON for an npc,
but that requires casting the spell on an npc in order to trigger the event. It would be nice if you could trigger an event when a player casts
a spell anywhere, regardless of target. That would make it way easier to make custom spells with scripted effects.

[trevius]

Yeah, I agree that event being usable in the player.pl would be awesome. Hopefully someone has time to get this added at some point. I know everyone is already pretty busy working on other things, so no idea if/when this would ever get added, but it is definitely something to consider at some point.

[realityincarnate]

It shouldn't be difficult to add EVENT_CAST to player quests, but I have a variation on the idea that I would like some feedback on:

If the intent is to make custom spell scripts, what about introducing a new spell effect, something like "script effect", that could be added to custom spells. Then, when a spell with that effect is cast, it would trigger a script corresponding to the spell id. That way you could mix and match normal effects and scripting without having to fill player.pl with if statements, and it should give a lot more versatility for making new spells. Any thoughts?

[Sion]

I would say that could be a better way to handle scripted spells. I don't know how much harder that would be to add but it would be awesome being able to attach a script directly to a spell. But I also think EVENT_CAST would still work fine and it wouldn't be that inconvenient checking for which spell was cast in the player.pl file. It's not a big deal to me. I guess whatever would be easier to add.

[steve]

That's how it's done on Live. Clickable items (like the 10th anniversary items and LoN items) have a generic spell associated with them that runs a script to award an item in-game and to swap an item for another.

[trevius]

That is a good idea, realityincarnate, but you would still probably need an EVENT_CAST to use it unless we made another default.pl/player.pl type quest file named spells.pl or something to handle all of the custom spell stuff.

Using the database loading spells would make adding an extra field to the spells fairly simple. The scripts AndMetal wrote might need to be adjusted so they don't export that new field though, I don't really know about that.

I was thinking about adding a couple more fields to that table at some point anyway. I would love to have a qglobal name and value field in the spells file. Then, have those fields reference the qglobal table when you scribe spells. If a value is set in the spells_new table new qglobal fields, it would check to see if the player scribing their spells (with a spell scriber script) has the matching qglobals to scribe them. This way, you could easily block certain spells from being autoscribed unless people have earned them. The reason to also have a value field is so you could have it check if the value is >= the value in the qglobals table. So, you could have multiple tiers of spells without needing to have multiple different qglobal names for them. The main reason for that would be for organization purposes.

You could have classes of spells and assign values for each tier you want for that class. An example would be if you wanted shaman to be able to get their RK1 spells without a qglobal, but their RK2 woudl require them to have the "shaman_RK" qglobal of a value of 1 or higher. Then, if they wanted to get the RK3 spells, they would need a value of 2 or greater and so on.

I would really love to get something like that implemented at some point, but I just haven't had any time to do it for quite a while now :P

[realityincarnate]

The EVENT_CAST player quest is in as of revision 604. It is triggered when a spell is successfully cast (not on fizzles, missing components, etc.) and exports $spell_id to perl.

As far as the custom spell script idea, what I had envisioned was along the lines of a "/quest/spells/" directory, where you could place scripts that correspond to spell ids. Any spell that had the script effect type would run the file for its id. I already have something similar working (mostly) for items on my test version, so much of the groundwork is in place.

The idea of adding things to the spells table is interesting too, although the extent of what I know about the table is that I noticed it existed the other day.

[Sion]

Awesome, thanks. This should help a lot.

[trevius]

Awesome, Realityincarnate

And to explain a bit about the spells_new table:

This is a table that AndMetal implemented a while back. Basically, you can import/export the spells_us.txt file into it or out of it. The PEQ DB now comes with that table fully populated, I believe, so there is no need to import or export unless you want a spells_us.txt (to share with players if it is custom, or to use the ailia/bleh spell editor). Basically, the table completely replaces the need to have the spells_us.txt in your server folder. This option is not defined by default, so the precompiled binaries still require the file. IMO, it is ready to become the default now.

There are quite only a few benefits to having the spells in the database vs using the file. One of them is that developers for your server that have access to your database could edit spells directly without requiring any special access to the file or anything. Another is that web-tools could be created to manage the new table. But, I think the most beneficial reason to have them in a table is that it opens up new possibilities like adding new fields to the table that we can use to do anything we want with, like the example I gave. I am sure there are more possibilities, but that is just the first one I have thought of so far that would be really cool to have.

I bet someone could even make a web-tool that would generate a spells_us.txt file on-the-fly from that table. So, then you could do edits to your spells table and then any player that downloads the file would get the latest version with your updates included.