8 réponses à ce sujet

[kilrex]

Alright, in trying to solve a number of problems with a mod I'm working on, it seems to be that the current "custom mod events" template really needs to have one small part left out of it, otherwise it seems like it causes all sorts of problems.

Basically it looks like this last part

    if (!nEventHandled)
    {
        HandleEvent(ev, RESOURCE_SCRIPT_MODULE_CORE);
    }


In this particular instance, I have defined a script associated with a single player addin. The script is a trimmed down version of this template. It calls a method from _h lib I created for the event

EVENT_TYPE_MODULE_LOAD

and nothing else.

I have just tested starting a brand new character off with 3 permutations of dealing with the HandleEvent line
1) I leave HandleEvent in place, and just set nEventHandled=TRUE when I see the event I want
RESULT: In chargen, when I spend on stat point, it increase the stat by 2.

actually thinking about, will this event even have fired yet?
Answer based on a test I just ran: YES

This event was fired and passed to my module, so case 1 is valid
(I added a printtolog to the case to see if my script was called, and it was)

2) I leave HandleEvent in place and leave nEventHandled = FALSE;
RESULT: spending one stat point increases a stat by 2

3) I remove the HandleEvent line
RESULT: 1 point spent yields a 1 point increase.

So basically, a mod that is an add in to the campaign should not normally call HandleEvent, but unfortunately the template provide has this left in.

I don't supposed there is any documentation anywhere on events that has more information than the wiki?

[ladydesire]

Are you setting the nEventHandled variable before the code that handles it or after? It should not fall through to the unhandled state if the handler code catches it.

[Craig Graff]

It's quite true that mods meant to modify another campaign should not have module scripts which pass events on to module_core. They should also not have module_core as their assigned script.



That template was made for standalone or base modules.

[kilrex]

Your question illustrates one of the issues.

I'm not sure if the event is completely handled or not.

The fact that there is the line to pass on the event would seem to indicate that for the mod to work, certain things need to be done in response to the event. So if you don't do all those things in your code, you should leave nEventHandled as false and let the core module script do the rest.

However, if I do that, it causes problems. (Case 2)



So wondering if maybe there isn't anything else that is needed in for this one event, I also tried setting nEventHandled to TRUE (Case 1). But the problem still occured



The only case that did not cause the problem was Case 3, where the event was not passed on to anything else.

However it still leaves me wondering whether or not I am breaking something by doing that since I do not actually know what passed the event to my mod, nor what else might be expecting to receive the event from my mod.



Really it's a matter or not enough information about events, or at least any events that can be passed to a module's script.

[Talian Kross]

I experimented with this yesterday just to satisfy my own curiosity.  I overrode module_core.ncs, and that along with my own module's script (tal_module_core.ncs) produced this:

Script (362535138)     [module_core] Event: [63] 
Script (362535138) [tal_module_core] Event: [63] 
Script (362537135)     [module_core] Event: [20] EVENT_TYPE_MODULE_LOAD
Script (362537135) [tal_module_core] Event: [20] EVENT_TYPE_MODULE_LOAD
Script (362537197)     [module_core] Event: [8]  EVENT_TYPE_ENTER
Script (362537197) [tal_module_core] Event: [8]  EVENT_TYPE_ENTER
Script (362537400)     [module_core] Event: [84] EVENT_TYPE_GUI_OPENED
Script (362537400) [tal_module_core] Event: [84] EVENT_TYPE_GUI_OPENED
Script (362537415)     [module_core] Event: [84] EVENT_TYPE_GUI_OPENED
Script (362537415) [tal_module_core] Event: [84] EVENT_TYPE_GUI_OPENED
Script (362537431)     [module_core] Event: [84] EVENT_TYPE_GUI_OPENED
Script (362537431) [tal_module_core] Event: [84] EVENT_TYPE_GUI_OPENED
Script (362537431)     [module_core] Event: [84] EVENT_TYPE_GUI_OPENED
Script (362537431) [tal_module_core] Event: [84] EVENT_TYPE_GUI_OPENED
Script (362537478)     [module_core] Event: [84] EVENT_TYPE_GUI_OPENED
Script (362537478) [tal_module_core] Event: [84] EVENT_TYPE_GUI_OPENED
Script (362537493)     [module_core] Event: [84] EVENT_TYPE_GUI_OPENED
Script (362537493) [tal_module_core] Event: [84] EVENT_TYPE_GUI_OPENED
Script (362537509)     [module_core] Event: [84] EVENT_TYPE_GUI_OPENED
Script (362537509) [tal_module_core] Event: [84] EVENT_TYPE_GUI_OPENED
Script (362537509)     [module_core] Event: [60] EVENT_TYPE_GAMEMODE_CHANGE
Script (362537509) [tal_module_core] Event: [60] EVENT_TYPE_GAMEMODE_CHANGE
Script (362537899)     [module_core] Event: [99] 
Script (362537899) [tal_module_core] Event: [99] 
Script (362545683)     [module_core] Event: [84] EVENT_TYPE_GUI_OPENED
Script (362545683) [tal_module_core] Event: [84] EVENT_TYPE_GUI_OPENED
Script (362545683)     [module_core] Event: [60] EVENT_TYPE_GAMEMODE_CHANGE
Script (362545683) [tal_module_core] Event: [60] EVENT_TYPE_GAMEMODE_CHANGE

Now, that's just a log of me starting the game, resuming, and then immediately exiting.

The pattern to note is that the game engine first sends the event to module_core and then sends it again to my module's script. For me to send it BACK to module_core would be incorrect as it has already processed it and, thus, would end up processing it twice if I did.

Now, I am also overriding specific events by updating the events.xls 2DA file, and for those, I do pass the event along. If a specific script is cited, I pass it to it specifically, e.g.,

HandleEvent( ev, HandleEvent( ev, RESOURCE_SCRIPT_RULES_CORE );

for the EVENT_TYPE_ITEM_ONHIT event. If no default script is specified, then I let the script engine sort it out, e.g.,

HandleEvent( ev );

for EVENT_TYPE_INVENTORY_ADDED. If I don't call that generically, I found that, for instance, I wouldn't get the Codex update when I add one of those "special" items to my inventory.

[kilrex]

That makes a lot of sense.

I just found out why the game was increasing an attribute by 2 points for each point spent. If you look at what was just posted, you can probably guess.



Basically, any time you are in the levelup or chargen screen, and are spending attribute points, the game sends an event for each point spent (EVENT_TYPE_CHARGEN_ASSIGN_ATTRIBUTES, type number = 50) to module_core.



As a side note, you would see the same thing for picking abilities, except that giving an ability twice does mean you have have it twice, unlike attributes.



So if you have any mods that still use the template and pass events on to module_core, it results in making the game think that it has to deal with increasing or decreasing an attribute twice per click. I wonder if you have more than 1 mod passing events to module_core, if it would keep increasing the number of points assigned, of if something manages to sanity check the behavior down to just twice.



Wow, I'm a little surprised that it doesn't cause worse problems. Unfortunately it means that one of the mods I dl'ed and want to use is doing just this. And I wonder how often this issue will crop up again.

Actually I guess by reading all the things that module_core does, you could tell what other problems it might cause.

[kilrex]

Looking at module_core, the main thing I think that will get messed up are game stats.
I'm not sure what other effects it might have.

Also this might explain some of other, hard to track down, weird issues I've seen.
In the case where there is more than just 1 mod making this mistake, I wonder what the results might be for a few things.

For example, I was having an issue where, in a new game, upon first meeting Allistair, it wouldn't correctly add him to the party. He ended up in a partially added state. He followed me around, but I couldn't access his character screen, ect. But he didn't follow the party to wilds.

Also on occasion, I've had the party jump to a nearby cutscene trigger. Sometimes even through walls ect.

Though these problem could come from other things too.

What I really would like to be able to do is override HandleEvents in someway so I could log each time an event is passed on, and get a list of source scripts and objects, as well as targets ect.
It might be interesting, and useful to scripters, to then generate a map of event paths to use sort of like a finite state machine diagram.

Modifié par kilrex, 29 novembre 2009 - 07:14 .

[kilrex]

I just tried out running a new game with 3 mods that all call HandleEvents in their module script.



With 3 such mods, cutscene dialogs start to crawl, and can even make it seem like the game has hung completely.

Also, when main plot followers are added to the party as part of the plot, something goes wrong, and they don't get added right. If you talk to them, they respond as like they were part of the group, but they aren't. There is no portrait for them and you cannot access their stats or inventory.

Once this happens, I wonder if they game is mostly messed up for good. I guess you could start the console and try to fix things, but other than that, your game is a mess.



So, if more people keep including this in their addins, and you run those addins, you're going to have lots and lots problems.

[kilrex]

Craig Graff wrote...

It's quite true that mods meant to modify another campaign should not have module scripts which pass events on to module_core. They should also not have module_core as their assigned script.

That template was made for standalone or base modules.

Unfortunately there's nothing in the template to indicate that it should only be used to for standalone or base modules.

There's at least on mod I've been trying to use that used this template for their addin, and probably actually 2. Which is why  when I made the same mistake with mine, it really messed things up.
If you check my previous post, you'll see how bad things can get with 3 addins that do this.

Now I'm trying to think of a way of altering the module_core script, so it won't process subsequent copies of an event, but unless events have a trully unique id, and that id is shared by all copies, I'm not sure I can do much about it.
That or some what of determining what the source script or module is calling handle event.

Until then I have to figure out to figure out which mods are contributing to the problem.