Why can't these two simple changes coexist? (mod compatibility)

[BoogieMan]

One of my subscribers mentioned a mod incompatibility to me which I am looking in to.

The other person's mod which isn't compatible has one single .sql which contains:

UPDATE Units
SET Moves = '3'
WHERE Type = 'UNIT_EXPLORER';



Which looks a like easier to do than what I did to update the same unit's combat strength in an XML (other units excluded):


<GameData>
<Units>
<Update>
<Where Type="UNIT_EXPLORER"/>
<Set>
<Combat>5</Combat>
</Set>
</Update>
</Units>
</GameData>

They both affect the same unit but are different values, I was under the impression that it didn't matter if they didn't try to change the same variable. I had a feeling my could be done with fewer commands, but it does work as is I know that much.

 

[Lord Shadow]

This is how I do XML updates:

<Update>
	<Where Type="UNIT_EXPLORER"/>
	<Set Combat="5"/>
</Update>

But there should be no conflict between those two changes to begin with...

 

[Alunisiira]

I would also think that this shouldn't be a problem.
What i would try is to make my mod optionally dependant - so the order in which the database is updated is constant.
From a developers point of view you HAVE to make sure, either alterations are indepent or the order in which they applied is strict.
You want to have always a "deterministic" state of the game (database)

 

[BoogieMan]

I would also think that this shouldn't be a problem.
What i would try is to make my mod optionally dependant - so the order in which the database is updated is constant.
From a developers point of view you HAVE to make sure, either alterations are indepent or the order in which they applied is strict.
You want to have always a "deterministic" state of the game (database)

I'm still pretty new to modding in this game, so I'm not exactly sure what you're meaning. Could you clarify?

 

[Nutty]

There should be no conflict between the 2 mods. The XML syntax you used and Lord Shadow's are BOTH correct.

Alunisiira is merely pointing to the fact that you may need to control when your mod updates the database relative to other mods (either using the Associations tab of the mod properties in ModBuddy [i.e., Dependencies/References/Blocks], or by using SQL triggers). In this case, that shouldn't be necessary.

 

[Alunisiira]

In Modbuddy in the property section of your "solution" (mod) there is a tab called Associations. I would suggest to put the other mod in References.
So you can create an enviroment where the outcome is "clear".
Than you can try fixing that - i hope this will be enough - but my experience tell me otherwise :/

Edit: Nutty explained what i meant better, and i aggree with him

 

[lilgamefreek]

This might sound patronizing, but are you certain there is a conflict? You haven't specifically mentioned running the two together on your own machine. Maybe the user was confused and misreported a conflict with a different, larger mod?

 

[Baleur]

Yes, one must Always include human error in the possibility space.
If 10 people report the same incompatability, its cause for investigation.
If 1 person reports it, it might be a mistake.

 

[BoogieMan]

Seems that is probably likely, I can't find any problems myself. Thanks for the input and information everyone!