ALFA2 Item Scripting

[Ronan]

I know this should have been decided on a long time ago, but I've just been too busy. Here is my proposed solution to item scripts in ALFA, keeping in mind that we can't really depend on local variable persistance. DMs save items to their avatars too often, and that erases all locals on the item.

Every item has a single script which handles all events on it. The upside to this is we can add tons of functionality not normally possible, the downside is that scripting a simple OnActivate is a bit harder.
http://www.alandfaraway.org/docs/Techni ... mScripting
(Note, if anyone needs any more hooks or events than are present here to script an item, let me know!)

So you'd have something like,

Code: Select all

#include "acr_events_i"

void main() {
  switch(ACR_GetEventType()) {
    case ACR_EVENT_ACTIVATED:
      // Do the activated thing.
      break;
    case ACR_EVENT_PC_EQUIPED:
      // Run some OnEquiped script
      break;
}

Thoughts?

[Fionn]

Simple and effective. Until a more elegant solution presents, I'm for this.

[ç i p h é r]

I know this should have been decided on a long time ago, but I've just been too busy. Here is my proposed solution to item scripts in ALFA, keeping in mind that we can't really depend on local variable persistance. DMs save items to their avatars too often, and that erases all locals on the item.

Did you dismiss the idea of a toolset plugin to faciliate item transfers to bic files?

Every item has a single script which handles all events on it. The upside to this is we can add tons of functionality not normally possible, the downside is that scripting a simple OnActivate is a bit harder.
http://www.alandfaraway.org/docs/Techni ... mScripting

So you'd have something like,

Code: Select all

#include "acr_events_i"

void main() {
  switch(ACR_GetEventType()) {
    case ACR_EVENT_ACTIVATED:
      // Do the activated thing.
      break;
    case ACR_EVENT_PC_EQUIPED:
      // Run some OnEquiped script
      break;
}

Thoughts?

If the only alternative is to use a global activate script, then yes, I much prefer independent item scripts.

Also, what does the "aes" prefix (noted in the wiki) stand for?

[Ronan]

I know this should have been decided on a long time ago, but I've just been too busy. Here is my proposed solution to item scripts in ALFA, keeping in mind that we can't really depend on local variable persistance. DMs save items to their avatars too often, and that erases all locals on the item.

Did you dismiss the idea of a toolset plugin to faciliate item transfers to bic files?

No... its just that DMs often save items to their avatars, which erases all local variables. I'm loathe to make things more complicated for DMs to add additional features which will rarely be used.

Also, what does the "aes" prefix (noted in the wiki) stand for?

Alfa Event Script. Guess we could change it to Alfa Item Script, since I think the original plan for the custom events system will probably only be used on items.

[strangerson]

should also have

ACR_EVENT_PC_AQUIRED

and

ACR_EVENT_PC_UNAQUIRED

if posable.

[Ronan]

should also have

ACR_EVENT_PC_AQUIRED

and

ACR_EVENT_PC_UNAQUIRED

if posable.

They are of course. I need to do testing on how those events differ from the creature OnDisturbed events (PCs can trigger creature events in NWN2). If possible I'd like to include only OnDisturbed and not the aquired and unaquired, since they could be redundant. So far I haven't been able to get the OnDisturbed to fire... I'll test more in 1.03.

[Ronan]

Acadius will soon be starting on item scripting (wewt!)

But... does everyone thing the current spec is ok? Since we cannot depend on local variables staying intact, basically every item needs its own, unique script in order to do anything.

I'm thinking maybe we should re-think things. Even with a badass SQL DB, matching up data to specific items is going to be problematic at best. Maybe we should define a spec for data to be stored in the tag (independant of the part of the tag used to pick a script to run), and offer an API to retrieve that data?

I don't know... I can't think of any solution which really seems good to me. I suppose we could create a set of item properties only ment to be used to store data about a scripted item...

[ç i p h é r]

Can you explain the scope of the issue so we can better decide which method to endorse? Specifically, what items need their own scripts and what behaviors need to be scripted? There will naturally be some unusual items we create for our own systems, but for D&D items, I presume these scripts will fill in the gaps between the NWN2 implementation and 3.5ed.