9 réponses à ce sujet

[JJM152]

I was wondering if there is any chance of Bioware rejigging the next release so that we get an honest to goodness "EVENT_TYPE_GENERATE_TREASURE" event being broadcast?

My idea is that the object in question (creature, placable) could signal the event (upon dying, or spawning events) and then it could be caught by the module handler and then re-routed to either the default treasure system that ships with the game or to another program.

The fact that the treasure system is invoked directly from the EVENT_TYPE_SPAWN and EVENT_TYPE_DYING handlers of placeables and creatures, makes overriding or extending this functionality a real pain in the rump.

Unless, of course, I'm missing some trivial solution here?

[Phaenan]

In my case, I believe I'll just intercept the module GUI_OPENED event, check for bodybag tags, and finally modify the inventories of nearby bodybags instances. Plus some local var in order to prevent bags to be altered twice. But that's just some plain ugly code concept.

If there was some cleaner way, be it now or in the future, which doesn't involve core modifications, I suppose I'd be interested myself.

[JJM152]

Phaenan wrote...

In my case, I believe I'll just intercept the module GUI_OPENED event, check for bodybag tags, and finally modify the inventories of nearby bodybags instances. Plus some local var in order to prevent bags to be altered twice. But that's just some plain ugly code concept.
If there was some cleaner way, be it now or in the future, which doesn't involve core modifications, I suppose I'd be interested myself.

Well, what I did that was slightly less hackish is create my own handler for EVENT_TYPE_DYING and EVENT_TYPE_SPAWN and modify the engineevents.GDA to point those two events to my own handler first for processing.

I actually use the built in treasure gen system to generate treasure, then I check what was made after that and decide if I want to modify it (add magical properties on the fly).

This was interesting to me because it doesn't actually increase the drop rate in game, and is extensible if someone else alters the treasure tables with new base items, although I'm thinking of adding a configuration option to let you force the generation of more magical items if you want to.

EDIT: 

Actually, what might be better than my original request would be instead of broadcasting an event when the treasure is created, make it so that the TS_Category_* spreadsheets have a new flag that triggers off an event that signals the event.

This way, you could trigger events only on certain items through modifying the 2da's or extending the default treasure tables with mda's. Just grab the object from the event args (like say a longsword) and if you wanted to, you could do any type of post processing on it that the game allows.

This would be pretty darn clean. Either that... or allow objects to catch their spawn event (I think Georg said that the reason why they don't is because their system doesn't discriminate on broadcast, so every object could potentially get signalled every event...gak)

Modifié par JJM152, 15 décembre 2009 - 12:40 .

[Phaenan]

JJM152 wrote...
Well, what I did that was slightly less hackish is create my own handler for EVENT_TYPE_DYING and EVENT_TYPE_SPAWN and modify the engineevents.GDA to point those two events to my own handler first for processing.

Yeah. But what'll happen if some other mod overrides the engineevents table as well ? 

[JJM152]

Phaenan wrote...

JJM152 wrote...
Well, what I did that was slightly less hackish is create my own handler for EVENT_TYPE_DYING and EVENT_TYPE_SPAWN and modify the engineevents.GDA to point those two events to my own handler first for processing.

Yeah. But what'll happen if some other mod overrides the engineevents table as well ? 

As far as I understand it (and I could be wrong, I just started modding DA 3 days ago here...) you can manually adjust the priority of which modules get processed through the heirarchy settings (I saw it in an xml file, the priority settings that is).

My mod doesn't nullify the event, it actually just does something like this:

catch event -> to treasure system -> signal event

The treasure system use local variables to avoid generating treasure twice.

At least, that appears how it's working currently.

[Phaenan]

Hmm. I understand you simply redirect the event to your handler, but some other mod can override the same events as your mod. For instance, I know the Nightmare Plus packages sometimes modify engineevents entries (not sure which, I can't remember). And if that's happen, a "priority competition" with the other author won't help that much, I guess.
I never checked that myself, just talking off the top of my head here.
Still, in the meantime you should maybe only include the lines modified in your engineevents M2DA, and not the whole sheet.

But that's pretty off-topic, sorry about the thread derailment. Especially as I am pretty interested in the original topic myself. ^^"

Modifié par Phaenan, 15 décembre 2009 - 02:40 .

[Craig Graff]

For custom creatures, there is no reason not to just intercept the events on the custom creature script.

[Phaenan]

You're right. But I'd say JJM152 is more interested in tweaking the treasures from the SP campaign creatures. And so am I. ^^

[georage]

But, if you do that the wolves won't drop potions!

[sillyrobot]

Phaenan wrote...

Hmm. I understand you simply redirect the event to your handler, but some other mod can override the same events as your mod. For instance, I know the Nightmare Plus packages sometimes modify engineevents entries (not sure which, I can't remember). And if that's happen, a "priority competition" with the other author won't help that much, I guess.
I never checked that myself, just talking off the top of my head here.
Still, in the meantime you should maybe only include the lines modified in your engineevents M2DA, and not the whole sheet.

But that's pretty off-topic, sorry about the thread derailment. Especially as I am pretty interested in the original topic myself. ^^"

[threadjack]

This is why I think the community seems to be too cavalier about overriding events.  It is a tool in the toolbox, but we should reach for it reluctantly.  As the add-in choices grow, more and more will be incompatible for the same game.  For an end-user, problem determination may be seriously difficult as the add-in seems to work some of the time or in unpredictable ways. 

[/threadjack]

Modifié par sillyrobot, 15 décembre 2009 - 10:54 .