13 réponses à ce sujet

[KaylaKaze]

Currently, there's an issue with core script modding. Right now, a single core script handles all events triggered on the object. This is bad for modding because  if someone makes a change to the core script in one place, that mod will conflict with a mod that changes the core script somewhere else, even if they're not related. The best way to handle this is to break the core scripts apart so that each event is handled in its own separate ncs file. For example, in my "Items Received" mod, I added a line of code to the function in the player_core script that is called on an INVENTORY_ADDED event. In testing, I found that I could move the contents of this function to another script called pc_he_Inventory (for "Player core, handle event inventory" the name doesn't really matter but it's important to have a consistent naming scheme) and replace this function with

int HandleEvent_InventoryEvent(event ev)
{
   HandleEvent(ev,R"pc_he_Inventory.ncs");
   return TRUE;
}

In reality, if I was doing more than just testing, I should have kept the switch statement in the original function and had separate scripts for the INVENTORY_ADDED and the INVENTORY_REMOVED events which are both currently handled in the InventoryEvent function.

Doing this with how the core scripts handle all events would greatly reduce the potential for conflicts from mods. I also suspect that, unlike the core scripts, the handle event scripts could be located in Addins for easy management.

Modifié par KaylaKaze, 14 novembre 2009 - 07:56 .

[CID-78]

you should bundle them up. all inventory events in one script. because if you change one your most likely to change the other. you should also do a performance test. doing this might slow down large combats, and effectly making the game unplayable on some systems.

[KaylaKaze]

Why would a change to INVENTORY_ADDED have anything to do with INVENTORY_REMOVED? The scripts should be broken into as small of pieces as possible. There's no more overhead caused by using smaller chunks than larger ones (and maybe less overhead since the scripts would be smaller to load). And of course benchmarking will need to be done, but it can't be done until the work is done.

Modifié par KaylaKaze, 14 novembre 2009 - 10:48 .

[ladydesire]

Actually, I would suggest testing this to see if you hit a situation where calling multiple scripts causes a "Too Many Instructions" error when the event is triggered; this happens quite often in NWN and NWN2 when there are a lot of functions called with the ExecuteScript function, which is depreciated in dascript; this is likely the reason that CID-78 suggested pairing them.

Modifié par ladydesire, 15 novembre 2009 - 02:39 .

[ChewyGumball]

If you are just moving things around, and then using #include statements to tie them back together, there would be no extra function calls.

[KaylaKaze]

You can't use includes because the script would have to be recompiled, and that's missing the point.



I have tested it and it doesn't throw any errors. Pairing them would have no effect on the number of functions called. You're either doing a switch in player_core to decide which script to pass to HandleEvent, or you're sending a grouped script to HandleEvent, and then in that script running the switch. It makes more sense to do the switch in player_core if your goal is to break it into smaller pieces to avoid potential conflicts. jwvanderbeck is working on using the RegisterEventListener function to hopefully make it not matter.

[Lieutenant08]

The observer pattern for programming is what he may be talking about. Where your module would subscribe to all of the events offered by the engine. However, I do believe that the true test would be to create two seperate modules each catching the same event and seeing which is execute if not both.

[AND04]

Take a look here:

http://social.biowar.../Event_override

Modifié par AND04, 17 novembre 2009 - 02:27 .

[Challseus]

AND04 wrote...

Take a look here:

http://social.biowar.../Event_override

That's really nice to hear. I have been wanting to point custom ability events to my own custom script, and not ability_core, and I didn't know how. This may be what I'm looking for. Thanks!

[AND04]

Challseus wrote...

AND04 wrote...

Take a look here:

http://social.biowar.../Event_override

That's really nice to hear. I have been wanting to point custom ability events to my own custom script, and not ability_core, and I didn't know how. This may be what I'm looking for. Thanks!

np, your welcome

[TheMutator]

The problem is, that each event can only be overriden once in this way and that's hardly practical for modding. So only one item added override, only one level up override. It works well, yes but only if you are the only person modding your game.

[Lord Thing]

TheMutator wrote...

The problem is, that each event can only be overriden once in this way and that's hardly practical for modding. So only one item added override, only one level up override. It works well, yes but only if you are the only person modding your game.

One way to get around this would be to make some sort of linked list that stores all scripts of a certain type (ie all ability scripts, all trigger scripts etc.), then call the next script in the list at the end of each script.

There would be other ways too, but I agree that we need to come up with a community-wide solution for compatibility.

[CID-78]

another thing you must be aware of is that if there is a incompability it's better that one system override the other completely then you got two system that is flawed. that's why i suggested the boundle together. one bundle will then allways take precedence. instead of maybe one from one set and another from another set.

It also might effect the script cashe on the computer more small compiled script might be swapped out more often then one with fewer slightly larger ones. which might effect performance.

[stuntpope]

mods shouldn't need to touch the core scripts at all. If you're doing that then you are doing it the wrong way. Simply write your own script to handle the event you want to override and then pass any other events back to the core script to handle.



So in fact I think the OP has it completely back to front. You should use the HandleEvent function to pass an event from your custom script back to a core script (or to another custom script) but I see no reason to do it the other way around.