10 réponses à ce sujet

[stuntpope]

I think there should be a setting that allows a module designer to specify that the module should not be affected by other mods. That is, the module should just use the core along with any modifications that are made within the module or within any addins that are made specifically for that module.

Personally (and I expect there will be a lot of disagreement on this), I feel that in the vast majority of cases mods (as in modifications) should be made specifically for a certain module or campaign and not just affect every module. It is not possible for a mod designer to anticipate what their mod is going to do to a module / campaign that they have never seen.

As an example consider balance mods. Fine if they are targeting the single player campaign but what if another module author has already carefully rebalanced their game to suit the kind of experience they want to deliver? Or consider mods that give items or new classes and abilities. Again the mod designer can have no idea what affect this is going to have on someone's module. Nor can the player know this, and currently they are the one making the decision.

As an example of something that already exists consider some of the additional content that Bioware released as part of its preorder goodies. Really these should have been targeted at the single player campaign alone but unfortunately they seem to affect every module. e.g. the memory band and the Tome of Fomari. What if these don't fit in with my world? what if I want to carefully manage how much xp the player recieves? The items mentioned have minor effects but you can imagine that someone could do something similar which had a major impact. These items may also be lore breaking for a module.

Of course I could find a way to override these specific things in my module but that's not the point. I can't anticipate ahead of time what content people may have installed.

BIOWARE - please give module creators the option to turn off external mods (or tell me this already exists).

Note that with this in place someone could still mod your module - but the mod would have to be made specifically for your module. I think this is the most appropriate way to make mods anyway (I'm sure there will be exceptions though).

[Proleric]

I entirely agree, in principle.

Certainly, DLC shouldn't alter the content of community modules (other than by making any new models available to the builder).

The complication is that players will want to use "benign" general-purpose community add-ins (such as new races and classes). While this is, frankly, a pain for the module builder, the majority will be fairly harmless, so Bioware might be understandably reluctant to stop it.

In an ideal world, we'd develop community protocols for module and add-in design to minimise the risk of conflict. To be honest, until the community has a very much better understanding of integrity issues, I doubt whether this will happen.

So, I suspect we're stuck with advising players to switch off their add-ins (knowing that some of them won't, and will then waste our time with spurious bug reports).

As a win-win, maybe Bioware could change the client to allow all add-ins to be switched off by the player at a stroke. This will be especially important if there are to be dozens of minor add-ins like the Memory Band.

Modifié par Proleric1, 23 novembre 2009 - 08:46 .

[stuntpope]

Well I don't think things like classses being added to a module that isn't expecting them are actually benign. What happens to the dialogue options that have been written to be class selective? The player could miss out on an entire plot becasue the designer did not anticipate there being an extra class.
You could say it is the player's own fault but then how were they to know. Most players aren't going to understand it from the modders perspective.
I am only advocating a way to turn it off at the designer's discretion.

Modifié par stuntpope, 23 novembre 2009 - 12:43 .

[CID-78]

there is one simple way of turning most mods of rename the core scripts. and use those renamed scripts in your module the most OC mods will then fail to override and work with your module. basically if you don't want mod compability work against it. much much easier then working towards it.



and when it comes to new *(insert type here) they will simply get the default node in a conversation. ie if you have three responce depending on class you usually have:

*if mage

*if rogue

*else (warrior) <- All new classes would get this



so dependning on what the author has as default node in the conversation, the new class will be treated as it. one thing is for sure a new class will have less options then either supported class.

[Blissfulpain]

but there are other issues like the Respec mod and the Camp chest mod that apparently break each other...



I don't have both, so I'm going off other's comments, but I think if you have the camp chest mod, then the raven for the respec mod doesn't appear in camp.



these are both small little addins that change one single feature... it's a single bug that both authors can look into and fix, but what happens when people start making full campaigns and one campaign mod breaks another? (and there's no reconciling the error, ie. to fix one you HAVE to break the other)



I think there could be multiple solutions:

1. testing/trial and error is important, without a large volume of skilled modders just yet, we don't know where common conflicts are yet. This will just take time.

2. Whitelist functionality - My mod only works with xyz, all other mods are disabled upon installation of my mod and highlighted to indicate that they may not be compatible with my mod. The user can re-enable there mods, but they get a pop-up indicating there may be unforseen side effects.

3. Blacklist functionality - My mod will NOT work with xyz mods (mod name/version some unique method of ID'ing a project?) and has such and such known issue. Xyz mod is disabled when you install my mod and you are warned if you try to enable the other mod that it could cause game instability.



While it'd be nice for this type of functionality to be built into the game, I'm betting it'll have to be a community initiative to indicate on project pages their white/black listed mod compatibilities and it'll be up to individual downloaders to head those warnings.. It'll take time and experienced coders to achieve some standards or good practices for playing nice with each others' addins too.

[AND04]

erm if your talkign about mods that expand on the singleplayer campain ok - there isn't any way easy way to make ehm stop working.



but mods that extend the single player campain shouldn't also extend a custom Campain Module (unless i am mistaken thats why you got the hierachy options and what is extended by the module) - now however ich your not using a module (dazip) than that might not work for you

[elys]

Added to the Hierarchy options, there is also the Content Module field in Module Properties where you can specify for which module your DLC is made for. Core, Single Player etc...

But I don't know if it just informational or if it has any effect on determinating if your module will be loaded or not, depending of the initial module (campaign)

I think both Hierarchy options and Module content property should be tested to see if they have any effect in loaded your module or not.

Or maybe a dev could simply gives us the answer about that. 

There is also the Mod Priority property, which allows to change the module load order, so for your own module you can change the default priority so you will get loaded at last, and overwrite all other mods conflicting resources. (that is if other mods are not using a custom priority as well)

And finally for your own script that can run without being a conflict, it's better to do as CID-78 suggests, to use your own named script, even if that means to just duplicate original ones. At least you will be sure they will not be overwritten.
For example if you create a spell that works with the original spell_aoe_instant, then instead just make it call my_own_spell_aoe_instant, even if its just simple clone of original script, so any other mod that would modify spell_aoe_instant, would have no any effect on your spell.

Modifié par elys, 23 novembre 2009 - 04:25 .

[Qkrch]

I'm sorry to disagree with the OP but the fault comes directly from the builder/modders. Obviously if the module is an extension of the campaign you're running into the issue of any other game.. basically you're exposed to break your installation or game.



People should be awared of this danger in any project entry, and builders (many) should inform themselves of how to solve some issues as overriding stuff.



Same thing happened in nwn2, took time to convince people and patch the common issues.



Anyway, you're the one downloading and installing the mods, so... is your choice.

[EJ42]

The thing you're failing to acknowledge is that this is not "your" game or "your game experience" to dictate to other players. If you want them to experience your module the way you originally intended, then simply give a disclaimer that the presence of any other modules will affect the gameplay experience.

When you say that Bioware's add-on items may not fit in "your" world, it's not "your" world anymore once the files have left "your" PC.

As for editing items, people can skin things the way they like. However, if they are changing items' stats, then they are really doing it the wrong way. If you want a custom item, then make a new item entirely, leaving the core resources unchanged.

As for your module, just make everything custom new additions that won't be overridden. Anything you use that's part of the core game should be treated as something that may have been altered.

The reality of the situation is that people are probably going to mod your mod, if they decide to try it at all. If you can't accept that, then you're doing this for the wrong reasons.

Modifié par EJ42, 23 novembre 2009 - 09:38 .

[stuntpope]

@EJ42 ok I was expecting this kind of response. Did you actually read my posts or did you just want to espouse your favourite piece of gamer philosophy?

I am not objecting to someone modding my modules. If you read my posts carefully you will see that. I am talking about mods that were never written with my module in mind at all. If something is made as an add-in for my module then great. But a perfect example of what I am objecting to is the memory band and the tome of Fomari. These were not written with my module in mind at all. They are mods that simply affect every module without any thought to the consequences in that module.

Of course the player has the right to do whatever they want when they play my module, just as they have a right to take a biro to the novel they are reading. I'm not going to stop them if they really want it that way. What I am talking about is a situation in which the player (and the modder) does not actually know what the effects of the mod are going to be on a custom module. They could be anything from minor and benign but against the designer's wishes (like the memory band and tome of Fomari) or completely game breaking (ie mods that are simply not compatible with the module and break scripts and so on).

The player is not in a position of knowledage regarding this. It is far better to leave these decisions in the hands of the designer who understands the way in which his/her module has been crafted.

Modifié par stuntpope, 24 novembre 2009 - 01:56 .

[stuntpope]

CID-78 wrote...

and when it comes to new *(insert type here) they will simply get the default node in a conversation. ie if you have three responce depending on class you usually have:
*if mage
*if rogue
*else (warrior)

so dependning on what the author has as default node in the conversation, the new class will be treated as it. one thing is for sure a new class will have less options then either supported class.

Not only that - but it could completely break the game. Consider Reynen Starfire's class adding tutorial that was posted not long ago. This directly overwrites core resources. Suppose my module is written to intercept some of the chargen scripts and run its own version of some event handling but pass other events back to the core script. When that mod is written the author has no idea which events I am going to intercept and replace so he cannot know which bits of his code will run.

Consider the part of the class modification where the background plots need to be set - any mod that does this will only work with the single player game or a game that uses the standard backgrounds. If I have modded that part of character gen myelf so that I handle the setting of background plots in my own way then the code to set plots for the new class will never fire. Not only that but it won't matter if they do becasue my game will never be checking those plots.

The result is that when you play my game with your new class you will never get anything happening relating to those plots (which could be very significant in my game). Further what about 2DA conflicts here? If I have overwritten the background 2DAs to remove the standard backgrounds and implement new ones and the class mod has also had to overwrite the same IDs (no option here for either of us) then which will take precedence? In this case you could end up with a half implemented mod - with some 2DAs making it in and others not.