Concerning mod conflict:
First, if you haven't already, please prime yourself by looking at the example mods that I gave in
the latter part of this post.
Notice that, the way I have structured mods and game logic in general is in such a way as to absolutely minimize mod conflicts. Even thought the last mod (Ancestry) adds a new section to part of the information UI for a 'Player,'
and even adds new data to a class in C, it will not conflict with other mods that do so, because it simply inserts itself as a callback. As much logic as possible will be written in this manner. Adding new behaviors, pieces of UI, etc. will be virtually conflict-free, although combinations of added behaviors may make for strange final results, despite each mod 'working as intended.'
For mods that need to
destructively modify existing logic, there are several approaches: first, one can flat-out override the game's files. E.g. ai/moveto.lua can be replaced with your own, upgraded version of movement AI. Recommended only as a last-resort. By replacing the file, you are saying "I am fundamentally changing how AI performs the MoveTo command." By definition, this means another mod that tries to overwrite the same file is a non-resolvable conflict. You
shouldn't be able to run two mods at once that say "I am fundamentally changing how the AI performs the MoveTo command." There is no well-defined operation to resolve such a conflict. Despite that, LT will still let you run them, and will resort to TES-style mod-order resolution. It will be
clearly marked for you that the mods conflict (since it's trivial to see that two mods try to overwrite the same file). You will be able to change the load order. In these cases, I will not try to provide any special merging logic, because IMO it is not the job of the game to do so
Again, if two mods genuinely have such different ideas of what MoveTo should look like that they need to completely override the default, then they are incompatible.
Now...changing the
details of specific pieces of, e.g., MoveTo, is still possible without overriding the function! Mechanisms for doing so:
constant data and
callbacks. You saw examples of both in those example mods. If you want to change how close MoveTo gets to the target, this will surely be a constant, not hard-coded into the script. So you simply make your mod change the value of said constant, just like I did with the drag-removal mod. If you need to do other things, I will insert as many 'hooks' as possible into the game so that you can register callbacks to change behavior. For example, AI.MoveTo.onCalculatePath(path) might be a hook that gets called when MoveTo has calculated a pathfinding solution to the target. If your mod registers a callback here, it can change path, so you could, for example, optimize the pathfinding / make it smarter / make it take into account some new navigation device that your mod introduces, and you can do so just fine without overriding the function itself. All of this comes very naturally when you start thinking about game logic as being comprised of events that trigger callbacks. The logic will already be designed in such a fashion.
Finally, as a midpoint between the above techniques, since we're talking about
Lua here, you can actually override helper functions in a particular script without overriding the entire script (provided I provide access to the function). So MoveTo might be comprised of several sub-functions that run depending on the state of the MoveTo command: findPath(), flyTo(), jumpTo(), finalApproach(), etc (although these might also be factored out as separate AI routines altogether). For the sake of discussion, let's say they are exposed helper functions. Your mod can override a single sub-function of MoveTo by doing something like AI.MoveTo.flyTo = betterFlyTo, where betterFlyTo is a
function that your mod defined. This is very similar to overriding constant data, except that the data happens to be functions
Now another mod may do the same but instead override jumpTo, and this is
generally OK, since you've both modified different parts of the overall script. This is really the only way that it makes sense for two mods to destructively modify the same script, and indeed, the engine will allow it! That's the absolute best I can offer...!
With all of this power, modders should be able to write really clean mods. If and when they don't, I leave it to them to resolve the conflicts