Topics

ç i p h é r · Post by **ç i p h é r** » Thu Mar 23, 2006 10:49 pm

Since I'm essentially working through the list of "optional" features at this point, feel free to make suggestions as to which of the features on the list you'd like to discuss next. I have little or no preference. I'm going to try and limit it to 2 or 3 at a time since we still have a fair number of open stickies in this forum.

I should note that we are behind in wrapping up these discussions as far as my original estimates are concerned, but I expect this process to be iterative particularly for the more elaborate features so some of the refinements in definition will likely occur the further along we are. Also, if anyone has any interest in being the technical lead on this team, please speak up now. Having someone to rely on to think about architecture and consider high level visual modeling would be a real boone. It'll be far easier to see all the relationships between the systems graphically than textually if we have the time to create this.

Overfilled Cup · Post by **Overfilled Cup** » Thu Mar 23, 2006 11:17 pm

Redacted because other people know what there talking about.

indio · Post by **indio** » Fri Mar 24, 2006 12:35 am

Ciph, I've never really done the sort of thing you want before, but if you like this thing I've done quickly here, I'll continue with it.

ç i p h é r · Post by **ç i p h é r** » Sat Mar 25, 2006 1:23 am

Indio,

I think that's a good start for a graphical overview of what we're building. What I want to see represented are not only the systems and objects but the shared resources between them, based on our discussions. These could be models, data (persistent or session), files, or any game related resource supported by NWN which we care about. So, if you're headed in that direction, please continue.

It would also help if we understood the underlying semantics in your diagram, if you're using any (ie do the shapes hold any specific meaning). This is generally defined based on the modeling language used but you can define your own if you're simply drawing it out.

Thanks for tackling this. It should help immensely.

indio · Post by **indio** » Sat Mar 25, 2006 1:32 am

Right. Shared resources is where I'm heading. I'll try to devise a simple symbol library also.

indio · Post by **indio** » Sat Mar 25, 2006 4:06 am

Refresh your borwser to see the latest.

I could really use some help from here. Not sure where the next move is to establish relationships.

Ronan · Post by **Ronan** » Sat Mar 25, 2006 4:33 am

ç i p h é r, I know what you want, and I think I can say with relative certainty I've got most of it my head, but I know thats not much of a help

I've got 3 classes this semester with projects each easily as big as the ACR, so its kind of rough (the good news is one of those projects is a membership database application designed for ALFA). Its also very hard to predict what resources need to be shared until we know all of what we have to work with in terms of the API. And I'm trying to limit my involvement until I know for sure if I will participate in ALFA2.

As he says, its easy to make systems which are independant of each other, that requires no organization. Its hard to make systems which depend on each other, and all-too-often software requires features to be added after the fact, changing other dependant systems. Organization bewteen the different people building these different systems can be tough.

This probably isn't the thread for it, but I'd like to propose a more flexible solution to adding content, one that I hope will enable new systems to be added without the need for any changes to the core module event scripts and hopefully increase the modularity of our features. I call them alfa event scripts, and their definitions would be ALFA_EVENT_*. You could associate an event script with anything, but mostly I expect them used for custom feats and items (cursed, magic, etc). Each custom feat would have an event script associated with it, and that one script would handle one or more of the events needed to make that feat work. Items would have an array of any number of event scripts attached to them as local variables. The events would be called from various places

For example, want to make an item cursed? Add a local variable AES_SCRIPT_1 with the value "aes_cursed_item". Want to give it some unique power, or have it turn the wearer into a badger when its equiped? Add the local variable AES_SCRIPT_2 with the value "aes_052_curse1" and submit your custom script to the global tech team. No changes to the ACR would be needed, and the script would be run automatically.

The event scripts themselves would look something like this,
aes_cursed_item.nss:

Code: Select all

switch(event_type) {
  case ALFA_EVENT_ONFIRSTCLIENTENTER:
    // Entering for the first time, curse the sucka
    // (probably based on other local variables)
    break;
  case ALFA_EVENT_ONUNACQUIRE:
    // Don't allow it, the item is cursed!
    break;
  case ALFA_EVENT_SPELLCASTAT:
    // Was remove curse just cast on the item's owner?
    break;
    //etc.
}

Now as we said before, this item could have a custom power associated with it. We could define that with another script like the one above,
aes_052_curse1.nss:

Code: Select all

switch(event_type) {
  case ALFA_EVENT_OWNERCASTS:
    if(GetSpellId() == SPELL_ID_MAGIC_MISSILES) {
      // The curse also turns his magic missiles into assorted vegtables.
    }
    break;
  case ALFA_EVENT_ONEQUIP:
  case ALFA_EVENT_ONENTEREQUIPED:
    // Turn the sucka into a badger.
  break;
}

Now under the cover, this system would be a bit more complex (such as getting all a PC's and NPC's custom event scripts somewhere they can be quickly retrieved in the case of events like ALFA_EVENT_ONDAMAGED and ALFA_EVENT_SPELLCASTATOWNER, looping through items and feats in those instances is just not an option), but this is the general idea.

Any comments? Off the top of my head, the events I can think of we could need are,

Code: Select all

ALFA_EVENT_ONACQUIRE // called from module event.
ALFA_EVENT_ONUNACQUIRE // ditto
ALFA_EVENT_ONEQUIP // ditto
ALFA_EVENT_ONUNEQUIP // // ditto
ALFA_EVENT_ONFIRSTCLIENTENTER // Called from OnClientEnter, during the ONE loop through the entire inventory.
ALFA_EVENT_ONCLIENTENTER // Ditto, but every time the PC enters.
ALFA_EVENT_ONENTEREQUIPED // Ditto, but if the item is equiped
ALFA_EVENT_PRESPELLCASTAT // Called from spellhook code before spell is fired.
ALFA_EVENT_SPELLCASTAT // Called from spellhook code after spell is fired.
ALFA_EVENT_SPELLCASTBY // Called from spellhook code.
ALFA_EVENT_ONUSE // Called from the module event
ALFA_EVENT_ONREST // Called from the module event
ALFA_EVENT_ONSPAWN // From the creature event.
ALFA_EVENT_ONDEATH // From the module event and creature event.
ALFA_EVENT_ONDAMAGED // From the creature event.
ALFA_EVENT_ONBLEEDING // From HCR code, on-death.
ALFA_EVENT_UNCONSCIOUS // Ditto as above, spells, subdual.
ALFA_EVENT_RAINING // From weather scripts
ALFA_EVENT_SNOWING // From weather scripts
ALFA_EVENT_ONKILLED // From module event and creature event, when something else is killed by the owner.
etc.

These do not have to be limited to items or feats. If we can create some sort of custom effects in NWN2, they could be used there. Also, areas could have event scripts, such as wild magic having an ALFA_EVENT_SPELLCASTS script defined. There are many possibilities.

ç i p h é r · Post by **ç i p h é r** » Sat Mar 25, 2006 4:35 am

I'll review it carefully and comment accordingly. Looks promising though.

Oh, and Ronan, that's exactly right. The interdependance of modules is where the main complexity lies in maintaining software. Modularity is essential in achieving *minimal* impact of changes, so I'm more than happy to review your thoughts as well.

Thanks for the contributions, both of you. I'll comment as soon as I can.

Ronan · Post by **Ronan** » Sat Mar 25, 2006 4:49 am

I just remembered NWN2 is supposed to have ways of organizing resources better than NWN1 did. If thats the case, it might be best to define each event type as a seperate script. That way events that needed to be accessed quickly could be pushed someplace more accessable (than say, attached to an item buried in a PC's inventory). This could be done with the single switched scripts I guess, but that would involve some unnecissary calls since the caller would have no way of knowing what events the script handled... I do tend to be too stuck on effeciency, as I've spent quite a bit of time working on embedded systems. The shear number of string operations NWN does makes me loose sleep at night

Swift · Post by **Swift** » Sat Mar 25, 2006 8:06 am

/me hands Ronan a set of

Code: Select all

 tags :D

ç i p h é r · Post by **ç i p h é r** » Sat Mar 25, 2006 5:40 pm

Ronan,

That's precisely the sort of architectural planning I was referring to. I think the key in your implementation is the ability to abstract function calls (the event handlers) for specific subsystems when a module level event occurs. Obviously, specific variable names would have to be defined and, assuming it's possible to invoke more than one subsystem per object, they would have to be labeled in sequence (arrays are apparently not going to be supported last I read), but it makes sense. More importantly, I think it should work to establish better modularity. My only thought on what you've suggested is, if we can deduce anything from object blueprint (resrefs, names, or tags) to avoid individual configurations, that would be ideal. I think that only works if there is a 1:1 relationship between blueprint and event.

At the object level, the engine already provides similar capabilities for events with UDE. I think X2 introduced the ability to specify which events to trap using flags on the object. I haven't examined it all that closely and there's no telling if it will remain, but if it's not a sensible solution, we should also devise an alternative using global pre/post spawn scripts in much the same way you're proposing for a global module event script. Have you given this any thought?

I strongly support the definition of all events (especially custom ones) as global constants and I'd like to do the same with conversation tokens, if that remains, to avoid duplication and collision between subsystems or their instances in-game.

Indio,

You've got a top level diagram at the moment, so to illustrate the relationships, I think you'll need to delve at least one level down. If you think you can wing it, try and represent the individual subsystems (go off the stickies in the tech forum) graphically and their dependencies as we discussed and see what you end up with. Hopefully, not a finger-painting master piece the envy of all 3rd graders.

I've got some comments about your top level diagram, I'll post those separately. This one's getting long.

Fionn · Post by **Fionn** » Sat Mar 25, 2006 6:10 pm

Nice vsd Indio. I'd include a relationship between Data Tracking and Persistance. Anything we track needs to be in the DB so we can access. Log files should be mostly for tuning performance IMO.

ç i p h é r · Post by **ç i p h é r** » Sat Mar 25, 2006 7:10 pm

Persistence is more broadly applicable than its representation in the diagram. I think the process really belongs within the basemod group, but the database container can exist where it is. What you might put under the database are the actual objects/data that are stored. What you might put up above the database beside the server are the reporting/web components.

ACR should also be more conceptualized I think...it's just a compilation of a number of things, so a more accurate representation might be the ACR containing persistence, rules, and admin in your diagram. It's really nothing more than a grouping of features which you could represent any number of ways in the diagram (circle, box, dotted line, text label, etc).

I think there's a bit of a disconnect between palettes and what's in basemod as it's currently diagramed. There is a dependency on all those palette objects within ACR. I think it might make more sense to move utilities under basemod (that's where they'll be) and leave the palette container where it is with its assorted objects beneath, going into specific detail as to which objects we're dependent on. This should eliminate the need for a lower level diagram. It would be nice to have specific local variables represented somewhere as well (can I be more demanding?

).

BTW, what does security represent?

Very well done though Indio and thanks for doing the work. I hope my comments were constructive.

Looking forward to v3.

Ronan · Post by **Ronan** » Sat Mar 25, 2006 8:22 pm

ç i p h é r wrote:Ronan,

That's precisely the sort of architectural planning I was referring to. I think the key in your implementation is the ability to abstract function calls (the event handlers) for specific subsystems when a module level event occurs. Obviously, specific variable names would have to be defined and, assuming it's possible to invoke more than one subsystem per object, they would have to be labeled in sequence (arrays are apparently not going to be supported last I read), but it makes sense. More importantly, I think it should work to establish better modularity. My only thought on what you've suggested is, if we can deduce anything from object blueprint (resrefs, names, or tags) to avoid individual configurations, that would be ideal. I think that only works if there is a 1:1 relationship between blueprint and event.

I planned to use pseudo-arrays to store multiple events on an object. ie,

Code: Select all

AES_1 = "AES_CURSED"
AES_2 = "AES_BADGER"
AES_3 = "AES_SPELL_REFLECTION"
AOES_1 = "AES_SPELL_REFLECTION"

etc.
Yeah, the overhead makes me want to vomit, but thats all we've got (normal NWN events should still continue to do the vast majority of the grunt work, of course). These local variables could be either assigned from the toolset (and thus stored on the blueprint) or set in-game. Most would be set via the former method I'd think.

At the object level, the engine already provides similar capabilities for events with UDE. I think X2 introduced the ability to specify which events to trap using flags on the object.

Well, your still limited to the events BW allowed for that object, right? I think we would really want the flexibility these custom event scripts would offer. I see the benifits as the following,
-Totally scallable, any number of events can be attached to any object.
-Totally independant of object type, entities that do not normally have events (such as items and feats) can be given some.
-The ability for events to passed off to an objects owner, or whoever. For example, when Bob picks up the helm of spell reflection, the item's ALFA_EVENT_SPELLCASTAT (and all other events in its alfa owner event, or AOES_*, list) would automatically be pushed onto his event list.
-More modular. Since we can attach any amount of events to an item, we can seperate each custom event into smaller independant objects.

I don't see any reason to actually replace BW events with our own, though I suppose we could. It seems like that would be more confusing for your lay-builder. Though I intend to include a well-documented template event script, I just don't see any need to make your average builder learn something which he will rarely need the full capabilities of.

I strongly support the definition of all events (especially custom ones) as global constants and I'd like to do the same with conversation tokens, if that remains, to avoid duplication and collision between subsystems or their instances in-game.

I figured we may as well splurge on the number of custom event definitions. We don't have to use them, and they won't take up any sort of meaningfull overhead if they aren't used.

BTW, conversation tokens are often set on each AppearsWhen script as they are used (at least, thats how I do it), making it impossible for another script to steal them before they are used in the convo (gotta love single-threaded simplicity).

ç i p h é r · Post by **ç i p h é r** » Sat Mar 25, 2006 8:45 pm

Sounds good Ronan. And I agree, it doesn't hurt to define more constants than we need. Hopefully, you'll be around to help architect the system.

BTW Indio, if we make your image interactive (image map using HTML for instance), we could really diagram the system as extensively as needed. For instance, if you drill down the database objects, you could see the schemas for each object, or if you drill down the palette objects, you could see variables on them, or if you drill down on process objects, you could get function definitions and event triggers....it could become quite a valuable development tool. Just thinking aloud though.