Dragon Age Forum News

Remove all ads!

Here are today's Dragon Age forum highlights, collected by NWVault. Please take into account that these are only single parts of various threads and should not be taken out of context. Bear in mind also that the posts presented here are copied as-is, and that any bad spelling and grammar does not get corrected on our end.

Georg Zoeller, Designer

Persistant Variables?

---

My understanding with object variables is that they can be moved from module to module within a campaign using the database functions (at least with NWN). This works well for planned campaigns when all modules are released at once. When you instead have the release of modules over many months, or if the player wants the character to go into a different module by another author, then the database functions don't work as well. At this point, we rely on the exported character itself. I've typically used special tokens to maintain the game state between modules and campaigns. It works well if all you care about is a few different variables. When you have hundreds, though, it can get difficult to do this way (it's borderline possible using multiple items and modifying tags). Ideally, you could set item variables and they'd stick around on the exported character. That way when the player's deck of cards is taken into a module that's "deck aware", it can read the variables and react accordingly. The simple solution would simply be to allow object variables to be stored on exported characters, perhaps with a cap on the maximum size. Campaign variables essentially do the same thing, though they don't seem as portable to me. Anyway, just my two cents.

---

Objects in NWN are just object id's. Since those are not static between modules or even game sessions, they can't be transported. NWN just cheats by exporting the whole object into the database if you use BioDB. It's possible to live without object variables at all - we don't have them in Jade as the game handles area transitions similar to a module restart, and I haven't really missed them so far, except for very few occasions.

Brenon Holmes, Programmer

Persistant Variables?
More robust... referring to variable storage in general in NWN? Or 'more robust' referring to the database variable storage functionality in NWN? If it's the latter, variable storage in DA for campaigns should work fairly similarly to regular variable storage. That is to say it'll have a var table that will persist across module transitions. Besides that, I don't think we're too certain at this point.

Event Handlers: pre/post/modify/override
Hmm... sounds possible. It would definetly be quite powerful if done properly. I'll have to poke around and see how difficult it'd be to add and how much time we're talking. No promises, but it sounds interesting.

More:

---

A simple pre-spell cast event (that actually runs before the mumbo-jumbo, unlike the NWN pre-spell event!) that is a conditional would be neat by itself. With this, the builder could decide to run a seperate script, have neat things happen, etc. but the end result would still be a yes or no answer to the question: "Does the spell abort before it is even cast?".

---

For what's being talked about here, I believe the answer is "no". The pre-event script would run before the event was processed - not before it was sent. So you'd get the pre-event script run just before you got the regular event, which would allow you to change (or cancel) functionality / behaviour. In the case of a spell cast though, there would be an animation (whatever is defined), then probably the projectile (whatever is defined), then on the impact just before the impact event was received - you'd probably get this theoretical pre-event event.

More:

---

How about a "pre-conjure-animation event" or a "pre-throwing-of-projectile event"? If you add the existing NWN spellhook to the spell script for say, fireball, the caster will still hurl a fiery projectile at the target before being informed that spells don't work here, but they do in a visual way.

---

Essentially you're looking at this as a way to disable specific (or all) spells?

More: Heh, well... perhaps I should explain a bit about how things work with events just so everyone's on the same page. Confusion is bad. Let's work with an SpellImpact event since it's fairly straightforward. (I'm going to use NWN as the system example since we don't quite have the system for spellcasting working yet in DA - so it'd be confusing to explain. Also, for the purposes of the example I'm going to ignore client server distinctions as it tends to confuse things )

I) The user initiates a spell cast. The game goes to the 2da file and looks up what projectiles and animations to use (queueing them at the appropriate times and attaching them to the model at the specified positions). This is the conjure phase.

II) After the specified amount of time specified for the spell, it is 'cast'. This is the cast phase. An event is generated that is sent to the caster which causes the spell script to run on that object.

I'm fairly certain we're talking about adding an event that would be sent just prior to the handling of the event which would normally run the spell script. This way you could modify the behaviour, write your own handler for the event or simply cancel (!) it.

(Added) Clarification:

Combat is only loosely based on 2da's - generally most of the rules (at least in the case of NWN) were fairly hardcoded. For spells and the like most of the values were 2da driven.

The way the system works is that the animations associated with a command aren't exposed - it's a hardcoded call in the engine. To be able to change a projectile for a spell on the fly you'd have to either:

a) Be able to modify the 2da/data on the fly as that's where the data is retrieved from.

or

b) We'd have to change the spell system so that all the data in the 2da was actually in individual scripts (which isn't too likely as that's a *lot* more work than simply using the 2da - which is fairly easy to work with and make changes to.)

Hopefully this clarifies things a little? I'm not really sure - I think I might just be rambling... not enough sleep... Anyways, if I'm still not explaining myself well enough - keep prodding, eventually I'll probably say something coherent.

More:

---

You mention an event being sent to the caster, but is this the case in NWN or just in DA? I understood the spell hooking mechanism in NWN to be hard coded, i.e. there are no object-level events for spell casting; the hook script name is looked up explicitly by the engine in a local attached to the module and called directly.

---

In NWN it was an event, just one that wasn't exposed to scripting of which there are a few... I can't quite recall off the top of my head but I believe most of them are now exposed.

Those that aren't (exposed) are small things... like decrementing stack sizes, mostly the engine messaging itself with small post-it note reminders.

I'll add what we've been talking about to my investigation... again, no promises - but we'll take a look at how hard it'd be to add.

More:

---

I just thought I'd add another observation about this event model, Brenon, if you didn't already see it.

In Aurora, all the events, when they occur, before calling the scripted handler set up static variables accessible through GetXxx() engine functions. If the events were objects passed to the handlers instead, with all the details of the event as data members of the event structure, quite a number of engine API functions could just go away.

For me, small == beautiful when it comes to APIs.

---

*nods* This is something that already exists in the DAScript spec.

Edit: Clarity.

There is now one event handler script. You can handle an event in a separate script by using the

HandleEvent( event eEvent, string sScriptName );

function.

All the parameters on events are now exposed (there will even be documentation detailing what they all do ).