Basically, the way that I overhaul client mouse procs, this library needs to be last in compile order, but it can't be, because I have a bunch of top-level declarations that need to be first in compile order.
Otherwise, you can't really use all the features of this library. If it's included last, you can't use the declarations.
If it's included first, you can't use any of the behavior overhauls.
So this is the compromise I had to come up with:
// BEGIN_PREFERENCES
#define DEBUG
// END_PREFERENCES
#define TILE_WIDTH 16
#define TILE_HEIGHT 16
// BEGIN_INCLUDE
#include <ter13\mouselib2\MouseLib2.dme>
#include "Datastream.dm"
#include "nodes.dm"
#include "ui.dmf"
#include "test.dmm"
#include "code\core\bodyparts.dm"
#include "code\core\controller.dm"
#include "code\core\footprints.dm"
#include "code\core\items.dm"
#include "code\core\lighting.dm"
#include "code\core\scheduler.dm"
#include "code\core\vis_components.dm"
#include "content\container.dm"
#include "content\foraging.dm"
#include "content\ui.dm"
// END_INCLUDE
#include <ter13\mouselib2\overrides.dm>
This is an example of a portion of a DME file that uses the new library. I actually unincluded the overrides file from the library itself, so that I could include that code file as a separate entity.
This allows me to actually leverage the library as it was intended. I've spoken to Lummox about this issue and we batted some ideas around to make libraries like this more functional in the future, but I think we left the conversation convinced that 514's proposed overhauls to how mouse procs get into the engine itself make this point moot, and will probably invalidate some of the benefits of this library to begin with, and necessitate a third mouse library from me.