16 réponses à ce sujet

[anakin5]

With Awakening and Darkspawn Chronicles (and other standalone module), modders face the problem of creating module that are available for all this content.

I am especially talking about module that Extend "Single Player" because they need a module core script, and not because they handle "Single Player" content.
Extending "Core Game Ressources" let the module beeing available in all standalone content but the module core script is no more called.

So I would like to know if it possible to have one of these three improvement in order for us to provide functionnals modules :

1. Let module that extend "Core Game Ressources" to run a module script once the player load a standalone content.

Or 2. Creating a pattern that let us extend all possible standalone module, like ExtendedModuleUID="*". Or let us provide a list of module we want to Extend : ExtendedModuleUID="Single Player;DAO_PRC_EP_1;DAO_PRC_DRK;".

Or 3. Allow DAupdater to install multiple AddInItem with same UID but different ExtendedModuleUID.


Thanks for giving us information about this problem.

[mikemike37]

is the functionality provided by the folder: H:\\Documents and Settings\\Mike\\My Documents\\BioWare\\Dragon Age\\packages\\core what you are describing? i think stuff put in there affects all modules?

[anakin5]

Core resources affect all modules. But you cannot have a module script (i.e a script that handle events defined in module_core) when you extend core game resources.

By design, if you have a module script and extend Core Game resources, this script is never loaded. So you have to chose a module to extend, and here is the problem because you don't want to extend a specific module.

[CID-78]

you can override module_core, you can also override the event.



So if you want to override all modules it's the core resources you should work with. if you want to override some specific modules you use the extend module or add a hook in the core for loading extra content.



this only leave one case which you can't touch it's when the module doesn't use the default module core at all. but in that case it's better to leave it alone. it likely to not be compatible with your module.

[anakin5]

You can only override module_core if you replace the whole file. I don't want to do that because module_core file can be different depending of the module. I just want to have an additionnal feature on a specific event of the module_core file.
Contrary to other events, module core events cannot be overrided by adding a line in engineevent GDA table, it doesn't work.

The problem is not "How to make a script working in each module ?", and is not "How to have a module script ?". The problem is, "How to handle events defined in module script when you extend Core Game resources ?".
Let me give an example :

Create a module that Extend core game resources. Create a mymod_core script and define it as module main script.
In this script, write :

void main()
{
event ev = GetCurrentEvent();
int nEventType = GetEventType(ev);

switch(nEventType)
{
case EVENT_TYPE_GUI_OPENED:
{
int nGUIID = GetEventInteger(ev, 0);

if (nGUIID == GUI_SKILLS)
{
DisplayFloatyMessage(GetMainControlled(), "Hello World !", FLOATY_MESSAGE, 0x888888, 10.0f);
}

break;
}
}
}


You will see nothing appear. So, how to display "Hello World !" each time the player open the skill GUI whatever is the main module loaded?

Modifié par anakin5, 31 mai 2010 - 03:07 .

[CID-78]

Well, usually you do have a "custom" module script which then call the core module script that handle any unhandled events. in this case overriding the core_module will work most of the time. unless it's already have a custom version of that event and in this case it's good that your universal code doesn't work. because that would most likley screw up the module.



but in the end it's me as a module builder that decide what my module will support and what your allowed to mess with. if it require scripts it's likely to be effecting gameplay and may not be okay.



the community can easily post a framwork for plugging this kind of things into any module. By using that framework the module maker gives his blessing to use this kind of addons. by rejecting the framework he disallow it.

[ladydesire]

We've already seen one Stand-alone module removed from distribution because people were "refusing" to follow the module maker's request to disable or remove mods while playing his module, and I believe allowing modders to extend Core Game Resources directly would cause even more of them to do so. It's already possible to do something similar with the current toolset, as long as the required scripts and string table entries are made available for modders to use in their mods.

[anakin5]

@CID-78

You are talking about standalone module. Add-on module doesn't have necessarily a custom module script. And if they have one, they don't call the core module script for unhandled events (because module events are passed to all loaded module).

There is no problem for standalone module, the problem is about add-on modules. So for these add-on module, there is no problem if they don't need a module script because they just have to extend Core Game Resources in order to run with all standalone modules. But for the ones that need this module script (because the purpose of the add-on is to make something on a module event), it is impossible. Because having a module script and extending Core Game Resources is not compatible. You have to choose one of the 2.

Conclusion : I am asking for a solution to let add module handle module events whatever extended main module is.

[ladydesire]

If your module that extends Single Player has resources that are marked Core Game Resources, but owned by the module, that module will be loaded no matter what module you load; I've seen this happen with numerous stand-alone modules, including Awakening. Also, and I've said this numerous times, you cannot extend Core Game Resources the way you can other modules, since it is not a separate module like the Single Player campaign; I tried this back when the toolset first came out to avoid having to supply any extra resources for modders and it did not work.

[CID-78]

we know what you are asking. but the creator of the standalone module you intend that your addon shall work with has the right to support and not support addins. and that goes beyond your wish to make it work with all modules.



in the end any module that require scripting is likely to effect gameplay and in worse case break the whole module or cause bugs.



most of your addins is harmless and would be fine in most modules using the default core system. but they would screw up all modules that contain their own rule engine.



so there is no way you can make a universal plugin without the authors behind you. so if you need a hook in the module script. encourage the module builders to add that hook or use a community framework that contain it.

[ladydesire]

anakin5 wrote...

There is no problem for standalone module, the problem is
about add-on modules. So for these add-on module, there is
no problem if they don't need a module script because they
just have to extend Core Game Resources in order to run with
all standalone modules. But for the ones that need this
module script (because the purpose of the add-on is to make
something on a module event), it is impossible. Because
having a module script and extending Core Game Resources is
not compatible. You have to choose one of the 2.

Which is as it should be; I do not have the right, as a modder, to go against the wishes of a fellow modder that does not want my module to interfere with his, no matter how much those that use my mod might want otherwise.

Conclusion : I am asking for a solution to let add module
handle module events whatever extended main module is.

The game/toolset would support it already if Bioware had wanted this to be possible. Since I have seen Bioware developers actively discouraging using modified core scripts and custom gda files, especially ones being placed in packages/core/override, I don't foresee them making this change, nor do I foresee either of the other ones you asked for happening.

[anakin5]

ladydesire wrote...

If your module that extends Single Player has resources that are marked Core Game Resources, but owned by the module, that module will be loaded no matter what module you load

Once again, it is not true for your module script in a non-standalone module. Your module main script is not loaded if you extend Core Game Resources.

CID-78 wrote...

we know what you are asking. but the creator of the standalone module
you intend that your addon shall work with has the right to support and
not support addins. and that goes beyond your wish to make it work with
all modules.

I never see such a system. If I create a custom player_core file, it will override all player_core file in all module and the owner of the module cannot do anything against that.
In addition, if I decide to override an event in engineevent GDA table, it will override this event for all module and the owner of the module cannot do anything againt that.

So it seems the architecture let modders override what they want. Everything except the module core file, and I don't understand why.

[CID-78]

sure i doesn't need to use it. his module can use a completely new core and have it's own .gda. messing with them will only cause one thing. a broken module. the author will allways have the upperhand.



in the end you can't win a fight against the author, if he/she doesn't want to give in.



so be a diplomat and encourage module builders to support your addins and make sure that the hooks allows you to update your plugins without the author need to release a new version of their module.



that's the way to go.



and if you extend the core resources you should work with the existing module core and not make your own. the core resources isn't a standalone module it's a set of resources used by all modules and don't have a "module" at all. this will of course conflict with other core resource addins. and that's why you need a community framework.



which give you a "module core" for each addon. ie add a new .2da/m2da that contain the module script and let it call them all. but you will still get compability problems when two addons trying to change a thing into two diffrent beasts.

[Proleric]

The approach to script compatibility mentioned in the wiki depends on using both the event 2DA and a pass-through to the campaign's event script.

If that's acceptable, the original request here could be implemented by allowing the event 2DA to override module events (if it doesn't already).

[ladydesire]

anakin5 wrote...

ladydesire wrote...

If your module that extends Single Player has resources that
are marked Core Game Resources, but owned by the module,
that module will be loaded no matter what module you load

Once again, it is not true for your module script in a non-
standalone module. Your module main script is not loaded if
you extend Core Game Resources.

Which is because the module never gets loaded at all when you extend Core Game Resource.

CID-78 wrote...

we know what you are asking. but the creator of the
standalone module
you intend that your addon shall work with has the right to
support and
not support addins. and that goes beyond your wish to make
it work with
all modules.

I never see such a system. If I create a custom player_core
file, it will override all player_core file in all module and the
owner of the module cannot do anything against that.
In addition, if I decide to override an event in engineevent
GDA table, it will override this event for all module and the
owner of the module cannot do anything againt that.

They can remove their module from distribution, which one modder has already done for precisely the reason you are asking Bioware to make this change; because other installed mods were causing the players to think his module had bugs in it.

[nezroy]

Option #2 (providing a list, not wildcard) would be the ideal solution by far. It is simply a functional replacement to what everyone already does; releasing a bunch of different mod files that do nothing but tweak the XML. I'm not holding my breath however...

[ladydesire]

nezroy wrote...

Option #2 (providing a list, not wildcard) would be the ideal
solution by far. It is simply a functional replacement to what
everyone already does; releasing a bunch of different mod files
that do nothing but tweak the XML. I'm not holding my breath
however...

Some modders might just be tweaking the XML, but others of us actually have to have separate modules for Origins and Awakening, even if we allow some of the scripts to be Core Game Resources. But then, I too doubt that Bioware will change how it works, since doing so would contradict what they have been telling us about making things Core Game Resources.