8 réponses à ce sujet

[FalloutBoy]

Has anyone had any trouble with module events that you have overridden and that were working great yesterday, suddenly stop working? I am overriding EVENT_TYPE_UNIQUE_POWER and EVENT_TYPE_DYING. Both were working great before, but now only the DYING one works. The only difference between the two is that one is a module event and the other is an area event.

I tried adding another module override, one that lots of people use, EVENT_TYPE_MODULE_START, and added the chargen stuff. That doesn't work either. I have rebuilt the GDA with ExcelProcessor several times. This is my M2DA:

19   EVENT_TYPE_MODULE_START   event_module_start
1023   EVENT_TYPE_DYING   event_dying
1032   EVENT_TYPE_UNIQUE_POWER   event_unique_power

Modifié par FalloutBoy, 17 décembre 2009 - 07:02 .

[Proleric]

I haven't tried modifying the 2da. I thought the recommended method was to specify a module event script on the module properties, within which the START and UNIQUE_POWER events are handled?

Does this post help at all?

Modifié par Proleric1, 17 décembre 2009 - 07:41 .

[wyvern14]

Try using logging to check if your events are actually happening or not. I had this issue where I had no way ingame to know if it recorded the fact I had looted a campaign item (if so, it was supposed to change a plot flag).

For this, add a line like below in your event scripts (events have to be handled by module core):

case Eventblablabla:
insert script here
PrintToLog("the text I want to see in my log when my event happens");
break;


Go in your dragon age/bin_ship folder, right-click, create new text and put only

[LogTypes]
Script=1

Save this file as ECLog.ini (force the extension)

It will then start using printtolog to record the information you entered between "".

You can make a shortcut to the following file to access and check your log when you want (I got it quick barred)
\\\\Documents\\\\BioWare\\\\Dragon Age\\\\Logs\\\\DragonAge_1.log

Modifié par wyvern14, 17 décembre 2009 - 08:44 .

[FalloutBoy]

Proleric, I don't know what the "recommended" method is, but the method everyone has been talking about, overriding the event, requires making an events M2DA file, which you can read about on the wiki if you search for "event override". This method was working fine but suddenly stopped working yesterday. The post you linked might help though. I'll try it later. Thanks.

wyvern, in this particular instance it is easy for me to tell that my event handler is not being called. It used to fire when I used my custom item and it did a DisplayFloatyMessage along with some other stuff. Now it does nothing.

EDIT: I should probably just ditch the whole overriding business and edit the core scripts directly to add my stuff. Or do like you say and change the module properties to call a different handler. At least I know that will work and it is less 2da files to have to deal with.

Modifié par FalloutBoy, 17 décembre 2009 - 05:50 .

[georage]

Are you quitting to the main menu or completely closing down DAO?



Every time you update a 2DA, it is best to totally restart the client. If you don't, events don't seem to be handled properly. It is like the client loses track of the 2DA if the filesize changes, but restarting the client restores things.



At least, that is my experience.

[FalloutBoy]

Yeah I always shut down completely. I even have to shut down Steam or else I get BSOD next time I open the area editor.

[georage]

Where is your engineevent 2DA?

Mine are in ... addins\\modname\\core\\override

I had weird results before putting my 2DAs there ... of course you probably knew where to put the 2DAs in the first place.  

Modifié par georage, 17 décembre 2009 - 06:33 .

[Proleric]

FalloutBoy wrote...

Proleric, I don't know what the "recommended" method is... ...I should probably just ditch the whole overriding business and edit the core scripts directly to add my stuff. Or do like you say and change the module properties to call a different handler. At least I know that will work and it is less 2da files to have to deal with.

Here's a link:

http://social.biowar..._(dascript_type)

In that approach, which is the one Bioware recommended, you would indeed change the module properties to call a different handler. Any event which can't be handled by the custom code is passed on to the core script, for good order.

On balance, I imagine that's safer than changing the core script or the event 2da, because there's less risk of conflict with official patches or benign community add-ins.

So far, I've found one exception. In the Bioware party member wrapper functions, it's assumed that the creature script can be switched freely from creature_core to player_core and vice-versa. Obviously, that has the effect of by-passing any custom handler on the party member.

Modifié par Proleric1, 18 décembre 2009 - 08:59 .

[FalloutBoy]

I changed it last night to use this method and it is working now.