Larian Banner: Baldur's Gate Patch 9
Previous Thread
Next Thread
Print Thread
#626850 05/10/17 11:29 PM
Joined: May 2017
enthusiast
OP Offline
enthusiast
Joined: May 2017
I'd like to discuss how we can go about making mods compatible with one another.

The major issue we're currently facing are mods that modify base scripts, such as Base.charScript, Player.charScript, DefaultCharacter.charScript. These mods are inherently incompatible with one another, unless extra steps are taken to create a "compatibility patch", which is just another base script file that includes all scripts both mods need.

Possible Solutons:
+ Make your player code work within an itemScript, and attach that itemScript to a unique item distributed by your mod.
+ Move player-specific script code to a story script, if possible.
+ Override whatever root templates are used for the player characters and attach your scripts to those.
+ Make compatibility patches with all includes needed, and/or provide multiple bundled options for your own mods. (Bleh)

Possible Problems:
- How much player code can actually be moved to an itemScript?
- What key functions/event listeners are we losing by avoiding charScripts?

Questions:
â—˜ Is there another way to include charScripts on base player characters?
â—˜ Are story scripts compatible with other mods?
â—˜ What can be done with gameScripts?
â—˜ Are included gameScripts compatible with multiple mods?

As someone who loves to make smaller mods that improve the quality of life in games, the issue of mod compatbility is a crucial one, as I believe giving players more choices is important. Yet, to be blunt, having to choose between a complete overhaul mod and a small sprint mod sucks, so we need a good way to make mods play together.

Joined: Dec 2016
Location: United States
member
Offline
member
Joined: Dec 2016
Location: United States
- Most of what people are doing by attaching charScripts to base scripts can be accomplished with game scripts, but they do have some limitations. Most notably, game scripts have no parent object, and as such their vars cannot be accessed or set from other scripts. Game scripts do not support timers and some events which inherently reference __Me will not work.

- I believe multiple game scripts from various mods will pose no problems.


- Almost all code done in charScript can also be done in itemScript, except for some calls and events which solely reference the __Me object (the OnDamage event being a key example).


- Story script should be compatible across multiple mods, with the caveat that they do not modify the same files.

- A mod that overrides player root templates to add script will have compatibility issues with other mods that do the same, as likely only the final one to be loaded will take affect.

Last edited by Ameranth; 06/10/17 07:58 AM.
Joined: Aug 2014
old hand
Offline
old hand
Joined: Aug 2014
Indeed, this is a major barrier to modding right now. I feel like there's probably a simple solution somewhere, but it's eluded me. Using Game Scripts might work for some things. I tried to stress this to the devs in testing the editor, but I'm not sure the scope of the problem was quite apparent at the time. Considering compatibility is mostly the difference between one line of code, Larian ought to be able to cook up something without too much effort. Pretty please smile

Joined: Jan 2010
Location: USA
F
enthusiast
Offline
enthusiast
F
Joined: Jan 2010
Location: USA
Originally Posted by Ameranth
Story script should be compatible across multiple mods, with the caveat that they do not modify the same files.

Unfortunately, this does not seem to be the case. When two different scripts in two different mods are attached as subgoals to _Start, for example, only one script will run. See: http://larian.com/forums/ubbthreads.php?ubb=showflat&Main=76896&Number=626046

Joined: Dec 2016
Location: United States
member
Offline
member
Joined: Dec 2016
Location: United States
Originally Posted by fireundubh
Unfortunately, this does not seem to be the case. When two different scripts in two different mods are attached as subgoals to _Start, for example, only one script will run. See: http://larian.com/forums/ubbthreads.php?ubb=showflat&Main=76896&Number=626046


I see... good to know. I would guess that this is something there is intention to remedy, then.

Last edited by Ameranth; 06/10/17 07:59 AM.
Joined: Jul 2014
Location: East Coast
journeyman
Offline
journeyman
Joined: Jul 2014
Location: East Coast
Only way around this I can think of is a 3rd party application that has a listing of installed mods that each contain a root script for the offending articles and it would compile a list of imports and usings and inject them.

Something in-editor would obviously be preferable, or just having something built into the editor where we can place root scripts to be injected would probably be ideal but those are more hopes than solutions.

Last edited by Sinistralis; 06/10/17 05:01 PM.
Joined: May 2017
enthusiast
OP Offline
enthusiast
Joined: May 2017
Originally Posted by Sinistralis
Only way around this I can think of is a 3rd party application that has a listing of installed mods that each contain a root script for the offending articles and it would compile a list of imports and usings and inject them.

That is a solution for creating compatibility "patches", yes. A way around having to do that would be ideal, because otherwise you'll have to do that for any number of combination of mods, or mod users will have to learn to do that.

Making a tool like that should be pretty straightforward, since all you need to look for is the text after "#INCLUDE" and "USING", copy it, and insert it into the right areas in a default template for that script. Then it needs to be exported and placed last in the load order.

Originally Posted by Sinistralis
Something in-editor would obviously be preferable, or just having something built into the editor where we can place root scripts to be injected would probably be ideal but those are more hopes than solutions.

Yeah, it would be nice if we could have a property like the Game Scripts projects property, but one for players, characters, and maybe the default base.


I'm hoping we'll get an official response on this, and maybe some hope that they'll look for a way to make mods more compatible. I like to split up smaller mods to give players choices, but that becomes difficult if they require specific scripts to be included in default scripts.

Joined: Jul 2014
Location: East Coast
journeyman
Offline
journeyman
Joined: Jul 2014
Location: East Coast
So, after talking with Laughing a bit tonight, we came upon the quesiton of what happens when we need to alter vendor tables, as it involves modifying a roottemplate (compatability issue).

The game can handle modifications done to a level by seperate mods, so it looks like if you need to modify vendor tables, you are best off making your own vendor and placing them in town somewhere.

Is there a better solution than this? It gets the job done but then you have a town with 20 vendors if you have a lot of addons installed!

Joined: Dec 2016
Location: United States
member
Offline
member
Joined: Dec 2016
Location: United States
You can use CharacterAddTreasureTable() within object scripts to add a single treasuretable entry--no root modifications needed.

There's also CharacterSetCustomTradeTreasure() in story code, but I am less-sure of its functionality.

Last edited by Ameranth; 09/10/17 09:09 AM.
Joined: May 2017
enthusiast
OP Offline
enthusiast
Joined: May 2017
Originally Posted by Ameranth
You can use CharacterAddTreasureTable() within object scripts to add a single treasuretable entry--no root modifications needed.

There's also CharacterSetCustomTradeTreasure() in story code, but I am less-sure of its functionality.

Awesome, I was hoping for something like that. Where would you suggest calling that function?

Joined: May 2017
enthusiast
OP Offline
enthusiast
Joined: May 2017
So after some testing, it seems CharacterAddTreasureTable() is for the loot treasure, not the traded treasure. CharacterSetCustomTradeTreasure() also seems to override the initial trade treasure, rather than add to it.

Side note, InventoryLaunchIterator() doesn't seem to trigger the completion event. I've checked StoryEvent and ObjectFlagSet.

Joined: Dec 2016
Location: United States
member
Offline
member
Joined: Dec 2016
Location: United States
Ah, sorry to hear that. In DoS1, there was no distinction between loot and trade treasures, so this worked then. Not sure about the iterator completion event--from my experience iterators use StoryEvents, but I've never used the completion event.

Joined: May 2017
enthusiast
OP Offline
enthusiast
Joined: May 2017
Turns out InventoryLaunchIterator()'s completion event triggers with GlobalFlagSet() (Thanks Norbyte!).

I actually figured out a workaround for my situation that means I don't need any treasure tables at all.
Currently I'm scanning designated traders when they're talked to, seeing if any players know the skills / talents my books grant, and then adding the amount needed to the trader (if any are needed). These items appear in the trade menu, so that works for what I wanted.

Joined: Dec 2016
Location: United States
member
Offline
member
Joined: Dec 2016
Location: United States
Good stuff to know! I suppose it means that the items aren't regenerated alongside the usual vendor resets, but that's probably not a huge issue.

Joined: May 2017
enthusiast
OP Offline
enthusiast
Joined: May 2017
I actually prefer it this way, since the vendor doesn't get cluttered with extra books.

I didn't add a check to scan the player for the books, so in theory someone could buy them and not use them to generate more the next time they talk to the vendor.

Joined: Jul 2014
Location: East Coast
journeyman
Offline
journeyman
Joined: Jul 2014
Location: East Coast
Bumping this, as this is still an issue as the recent patch has made very clear with all the script conflicts going on.

Joined: Jun 2014
veteran
Offline
veteran
Joined: Jun 2014
I don't doubt it - could you post a couple examples of the most blatant issues?

Joined: Jul 2014
Location: East Coast
journeyman
Offline
journeyman
Joined: Jul 2014
Location: East Coast
Well, right now the one that comes to mind is the OnDamage event. Osiris has a terrible OnDamage event, but charscripts have a much better one. If you needed to hook into that generically, you basically have no choice except to override base.charscript or defaultcharacter.charscript, which will cause your mod to become incompatible with any other mod that does this.

I've been working around this stuff by using gamescripts and so far it's worked, but I've also seen a lot of screenshots on the forum of people injecting their logic into shared scripts. I suspect many don't know that if you do this, it not only makes their mod incompatible with other mods that edit the same file, but they also need to update those files when patches come out or risk causing reversions.


Joined: Jun 2014
veteran
Offline
veteran
Joined: Jun 2014
Originally Posted by Sinistralis
Well, right now the one that comes to mind is the OnDamage event. Osiris has a terrible OnDamage event, but charscripts have a much better one. If you needed to hook into that generically, you basically have no choice except to override base.charscript or defaultcharacter.charscript, which will cause your mod to become incompatible with any other mod that does this.

I've been working around this stuff by using gamescripts and so far it's worked, but I've also seen a lot of screenshots on the forum of people injecting their logic into shared scripts. I suspect many don't know that if you do this, it not only makes their mod incompatible with other mods that edit the same file, but they also need to update those files when patches come out or risk causing reversions.



Maybe something similar to the KOTOR2 "TSLPatcher" Utility would help for mod compatibility?
See here: https://www.youtube.com/watch?v=vh8CERG_a0I

Joined: Jul 2014
Location: East Coast
journeyman
Offline
journeyman
Joined: Jul 2014
Location: East Coast
As mentioned above, ideally we wouldn't have to patch mods and create an entire 3rd party ecosystem to solve this issue when it would be much simpler and straight-forward for it to be officially supported.

Third party tooling always splits up modding communities and increases the barrier of entry.

That being said if Larian came out and said "this will never happen" then that changes things, but that hasn't happened yet.


Link Copied to Clipboard
Powered by UBB.threads™ PHP Forum Software 7.7.5