Outpost Universe Forums

Projects & Development => Outpost 2 Programming & Development => Topic started by: Hooman on January 27, 2005, 09:51:52 PM

Title: New DLL interface
Post by: Hooman on January 27, 2005, 09:51:52 PM

Well, all the DLL coders seem to be here so this seems like a good place to bring it up. I've spoken with a few people about ideas for creating a new interface for DLLs to use. This would be meant as a programming library that has a set of functions similar to the ones exported from Outpost2.exe. Now I'm sure most coders have found the exported functions to be somewhat restrictive and don't really allow you to do everything you might want to do. The idea behind this project is to allow you to do those extra things, and to do so easily.

As a quick warning, I should mention that this project will likely make use of our knowledge of where things are in memory from Outpost2.exe. This is of course generally frowned upon and considered a somewhat bad coding practice. However, many of the reasons this is a bad programming practice don't really apply in our case. Outpost2.exe is not being developed anymore (and the source code is supposedly lost) so we don't have to worry about recompiles changing the memory layout. Also, it seems unlikely that an EXE would ever be loaded anywhere in memory except at it's preferred base address. This would probably break compatibility with a lot of old programs and seems like an unlikely move for future versions of Windows. However, there is no official documentation that says this won't happen and technically any program that relies on this assumption is somewhat "incorrect". We could write code to lessen the likelihood of any problems, but I doubt we can eliminate the possibility entirely. Thus any DLLs coded with such a library could potentially fail in future versions of Windows.

For the above reasons, I would suggest that the propsed library be a DLL itself. If in the unlikely event there are problems, we could just update this DLL and all the levels using it should continue to work. If we had used a static library then all DLLs written to use the library would have needed to be recompiled, which of course would be a huge pain and require access to the source for those DLLs, which might no longer be available. Now, making this library project a DLL means we won't need to recompile other DLLs that use it, but we will need to recompile the library DLL, which of course means we need access to it's source code. For this reason, I think such a DLL should be (at least to some degree) open source. People in this forum should have access to the latest copy of the source, but not necessarily allow everyone on the Internet to access the source. The point of making this a DLL is to avoid potential problems with future compatibilty issues. The idea of fixing them by recompiling one library DLL requires that everyone use the same library DLL. Hence we don't want every joe blow on the Internet to mod it to their own satisfaction (which is sometimes a problem with open source projects and smart people generally never being able to agree on anything  :( ) So in short, we need enough people to have access to it that the source will always be available to the community, and hence and up to date DLL, but not so much that there are hundreds of mods of it floating about. All changes should be made to one central copy that everyone uses. People working on this project or that get access to the source should understand this point.




Now with all that said, there is still some question about what kind of DLL we want to use. We could use a standard DLL with simple exported functions, or we could do something more fancy like make it a COM DLL. I'm interested in what other people think. If a DLL is written in C++, using COM will require slightly more complicated code, but not by much (and only for object creation and destruction and some possible COM initialization/termination calls, which might not even be an issue anyways). Using COM from other languages is largely transparent, and in the case of VB, it's probably even easier, especially with Type Libraries. Of course, we could probably use a Type Library for a regular DLL to make accessing it almost as easy. (Some slightly ugly things about that with VB and having to have a copy in the folder where the executable is, which is VB.exe unless you compile your project). Also, since COM is essentially a way of accessing objects from another language rather than straight functions, we could use it to access the objects OP2 uses internally directly rather than through some kind of proxy. (Efficiency!  :D ) Anyways, I think COM can really open things up to other languages which is nice because not everyone knows C++, but many people know other languages. Of course there are still some issues to be worked out. Implementing things like InitProc still need to get put into the DLL and I don't know of any (standard) way of doing that with VB. (InitProc can't really be put in the library DLL since OP2 expects it in the DLL it's loading which wouldn't be the library DLL. Same for the other required functions.) Of course, there are ways around this that could allow code to be written in any language that supports COM (including scripting languages  :ph34r: ).

Also, Triggers couldn't really be used in their current form with VB for the same reason. However, it could be possible to overwrite sections of code in memory when the library DLL loads to insert hooks so a new trigger system could be implemented. (Just make sure to undo the changes when the library unloads.) Not a bad idea since triggers are kinda weak they way they are now anyways.


Anyways, does anyone think COM is worth it? Or should it be a normal DLL with only exported functions. Or is this project idea even worth it?


Anyways, here are a few things I was hoping to expand our capabilities to:
Player.GetColor()
Player.MarkResearchIncomplete(int techID)
Unit.DoRepair()
Unit.GetCargo()
Factory.GetCargo(int bay)
Building.GetPower()
Lab.DoResearch(int techID, int numScientists)
RoboDozer.BullDoze(Region r)
Earthworker.Build(Region r, map_id/int type /*tube, wall, lava wall, microbe wall*/)
Playlist.SetCurrentSong(enum SongIds song)
 

Title: New DLL interface
Post by: HaXtOr on January 27, 2005, 11:08:51 PM

cargotruck get rubble and cargo truck unloading for a food or ore, ex when a you start a land rush ai can unload te trucks

Title: New DLL interface
Post by: Eddy-B on January 28, 2005, 09:18:49 AM

It all looks well. Some of these functions have already been done, either by me or others, i'd say we'd have to give the vehicle-instruction high priority (things like DoRepair, BullDoze etc..)
As for the triggers, i believe it is better to create a new event-system, to be carried out in AIProc() so other events can be added, and we're not restricted by 127 maximum triggers.

Title: New DLL interface
Post by: BlackBox on January 28, 2005, 03:23:55 PM

I think flat calls are just fine.
Most, if not all, languages that can compile DLL's are capable of calling a normal procedure inside another module.
COM is pretty sick for most people to have to use (unless the language supports it easily, i.e. Visual Basic).

Yes, most definitely a shared DLL. (I have already begun the project - the op2ext.dll is loaded into the game's address space and thus is available, from version 1.3.2 forward).

I can't say for certain about the open source. (If it stays within this group, it's perfectly fine).

Remember that the extension DLL will contain other things than just interfaces to the game. For example, the NAT fix, and later on things to allow mods (like controlling the VOL start-up list) will be inside the DLL, and this is the type of stuff that not everyone should be able to get at.
(Yes, I know the people here aren't gonna start going through this code and changing it, as some of it is critical).

I don't consider this to be a full replacement for the OP2 set of functions, instead I consider it to be an EXTENSION.
I wouldn't even necessarily consider using classes (though that would be nice), instead using something like UnitGetColor(Unit refUnit); and it returns the value. That might be messy tho, it might be easier and more elegant to use inheritance, eg

Code: [Select]

class IUnit : public Unit

As far as features go, here are some ideas I've had:
(This might not make a lot of sense to some of you yet, since Hooman and I haven't discussed it with you much yet)

- (Big) Easy way to produce CommandPackets and inject them into the engine.
- Read data from the loaded in techtree, and possibly modify them.
- Change colors on text, etc (in the command pane. This can easily be done)
- Hook certain parts of the game engine to obtain certain data for the mission.
- Better sound control system. (Play your own music and effect files)

- (sorta big) A mod system where the mission can specify what things it wants to patch, and the extension does it for them. The extension can deny modifications to certain parts of the game like the networking code or other things that shouldn't be changed. This could include changing VOLs loaded, etc. The extension would replace the original data after the mission finishes execution.

- Ability to read game variables like version, etc.

- More precise control over triggers, groups, etc.

Anything else you want?

Hooman and I can get a basic project going soon, most likely.

Title: New DLL interface
Post by: Hooman on February 16, 2005, 07:09:40 PM

Well, first of all I hadn't even thought of using that DLL for this project. I was thinking more of a standalone DLL that would only get loaded if the player chooses to play a level that makes use of it.

But anyways. I've been thinking about this and it seems like COM is really less of an advantage than I thought it might originally be. I guess what I really like is the use of type libraries which make it easy to export the functions to other languages. I also like the use of classes. So, I'm thinking maybe a semi COM project? The whole COM object creation is a load of crap and who really wants to initialize the COM DLLs from C++ anyways? So, I'm thinking more of a quasi COM implementation like DirectX does. (Yes, I'm still caught up on the idea of using classes, and those classes being available across languages.) So instead of the big ugly COM way of creating objects (which it might as well support anyways) we could just have a simple export to create the initial object. Then it should be just as easy to use as any other DLL really, and from any language including C++ (unless you REALLY wanted to do it the full COM way). I think the plain function type of interface could get kinda confusing and annoying. But that doesn't mean we can't have a few plain functions. Any thoughts?
 

Title: New DLL interface
Post by: BlackBox on February 17, 2005, 02:03:54 PM

Possibly... going semi COM like DirectX uses would be nice, since you don't need to install component information into the registry (and you need admin rights on NT/2k/XP, something a lot of people who play the game may or may not have).

Good point about the plain exports. I seem to have forgotten that we are using classes here and not flat functions.

It might just be easier to implement it all in op2ext.dll (you know that it's loaded already, which would make mods possible (it's loaded at the start of the game, so it knows all the game state information, etc). It just seems another DLL would cause unnecessary bloat. (There are already 50+ dll's in the game folder)
 

Title: New DLL interface
Post by: Hooman on April 05, 2005, 07:05:26 PM

OK, I've been getting some increased interest in this idea lately but for the next few weeks I'm still gonna be busy with school to do much myself. People who want to help with this idea should at the very least become VERY familiar with pointers. Especially function pointers. Familiarity with COM (Component Object Model), IDL (Interface Definition Language), or TypeLibraries would also help.

I think the best approach is to take a pseudo COM way, much like how DirectX has done things. It should be possible to create any needed objects in a COM way, or just by calling regular exported functions to do it. The regular exported function way will probably be the main way to do things. I mainly want to use COM for the binary compatiblility. This allows upgrades to the library without breaking existing code (but existing code can still benefit from the upgrades). It also makes fixing errors in the library easier than recompiling all the client code. The downside is that we really need to get a good interface down early on that we can stick with. The binary compatibility will also open things up to other compilers. The Microsoft specific name decoration on the exports from Outpost2.exe kinda limits current DLLs to being written with MSVC only (or ASM for people with a thing for pain). Using a standard like COM will mean that other C++ compilers (and probably many other languages too) will be useable for creating DLLs. The one catch for most other languages is that they still need to export certain required functions and variables. But for now, we'd at least be able to use any C++ compiler, like ones that are free to download and are a smaller download. This should help broaden the user base for who can make new levels.

Also, since not all compilers can use the exported functions (due to name decoration), I think we should offer a complete replacement. So we'd need functions to handle all the things currently available, plus the new functions to handle new things we can now do. The main focus of this project initially will probably be making the current functions available to other compilers. Then expand on what units can be ordered to do. Eventually we can add pretty much anything that's useful and can't be done normally. I know Eddy has done some work on the music, and changing the currently playing song. I have a few similar ideas that I eventually wanted added. I've also heard the occasional good idea from other people that we should have support code for.


Currently, I have about enough info to tell any unit to do anything a player can tell it to do. I just don't have the support code for all of it. That's what I hope this project will become. Ordering a lab to actually do research will be nice. Then research won't have to be faked for the AI. It can also offer better control over things like creating untis at a vehicle factory, building a mine without the cheap (+1, +1) offset (not that most people really notice), seting up an ore route without losing control of your ore trucks (for a level where an AI can give a player a starting boost). There are many more ideas but how it's done has a few ugly details that need to be hidden. But that's what this is for.

I don't really have time to teach people how to code, at least not the sort of things needed for this project, but for those who are able, I can certainly provide you with the information you need to work on this. I don't really want people running off and doing their own thing with the info, for various reason explained at the start of this thread, so I may leak the info out in bits that relate to parts you are working on.



I guess probably a good place to start is with some IDL. In other words, we'll need a list of the classes (and class hierarchies) this project will use and the functions on those classes. I kinda feel like I'm rambling though, so maybe I'll let other people comment before I go jumping into any technical details. Perhaps someone wants to do some grunt work in creating some initial IDL defintions? Maybe go through the existing header files from the current SDK and define important classes and functions for this project?

 

Title: New DLL interface
Post by: BlackBox on April 05, 2005, 08:12:08 PM

hmm. If I remember to do this I'll whip up some IDL or something sometime.
(If I can be arsed to do it, heh heh, I dislike IDL) But I'll probably do something sometime.

Btw.. not sure about this, but is the COM IDL microsoft uses compatible with CORBA IDL? (that would be important for opening it up to gcc-based compilers, stuff that originally ran on Unix). Anyone know?

Also... exporting functions. I have an idea for the languages that don't support it.
We could write a wrapper library which contains all the necessary exports, etc and a special program would compile the user's compiled library (eg. a COM InProc server) as an overlay or some other way onto this wrapper.
Then, it can relay calls to triggers, etc into the COM library in the overlay.
Only problem is the exported data as the game doesn't map the library into memory, it does a raw file read to get the data (so you couldn't create it in DllMain). I'm sure that's not a problem though, the wrapper compiler could do it.

Title: New DLL interface
Post by: Hooman on April 05, 2005, 09:05:03 PM

CORBA IDL isn't quite the same as Microsoft IDL. I think there is a compatibility compiler option though. But still, it doesn't matter if you use Microsoft VC++ for this project, the compiled DLL will still be useable by other compilers. Which is the important part. Everyone in here who is likely to work on the source has MSVC. Anyways, one of the main differences in the IDL that I've heard about is only being able to declare one class per file, whereas Microsoft lets you lump it all together in one file, if you want to.


I was kinda wondering if there was a way to just link in required exports somehow. Probably not a very general solution, but hacks could be made for specific languages like VB. From what I hear it uses the exact same backend for it's compiler as MSVC does. But still, I don't think we should even worry about this right now. That's something you have to get the language you're using to export, not stuff we're importing from this library. It seems very tempting to link the two ideas together, but I can't think of any clean way of providing support in the library for the required level DLL exports. This library idea makes it inherently shared, and those exports must vary from level to level. If we want to provide support for those required exports, it'd probably have to be some sort of statically linked option, but then you're right back where you started with compiler specific hacks. It'd probably be better to just let the language worry about those exports.


Oh, any thoughts on using ATL? It's got some nice things that should help write this library, and reduce the potential for bugs. I'm just not so comfortable with it yet. All my COM coding experience so far hasn't used it. Also, anyone tried to use a TypeLibrary with VB for objects not derived from IUnknown? I'm pretty sure VB uses calls to the IUnknown functions implicitly with things like new. Just wondering since the Outpost 2 classes don't use those functions so they can't be exported directly if those functions are needed, but then we'll probably be writing some sort of wrapper classes for everything anyways.

And yes, thanks for stepping up, Hacker. I'm sure you can do a good job on it.
 

Title: New DLL interface
Post by: BlackBox on April 06, 2005, 02:33:02 PM

lol, thx :)

Regarding ATL: I'm not sure. I've never used ATL so I wouldn't know the advantages or disadvantages of it. Does it increase file or memory bloat from using it? and how much more support code is needed for it (in both the library and the final missions which will use it)? I'm absolutely clueless when it comes to ATL so I don't really know the answer to anything about it, lol.

With VB I'm not sure if it's even possible to use interfaces that don't inherit from IUnknown. I think I tried it once and got some sort of error (I think it might actually refuse to add a reference in the "References" page)
I think it does implicitly use IUnknown (well, it'd have to in order to do garbage collection)
I don't see why this would be an issue though?

Required exports: Yeah we should let the language handle it on its own, and just have hacks for specific examples (like VB) where it doesn't "normally" support exporting functions from a DLL. (Not to mention VB can only create COM server DLL's, no "standard DLLs"). This might not be good since it's a lot of nasty work in order to get it to work (something we'd have to teach people), involving an add-on to VB and having to look at asm listings to figure out the function decoration.
Linking a static library or something else wouldn't necessarily be any better since it's still a hack to get VB to link with that library. And how would that work? remember, data like the LevelDesc, DescBlock, MapName, etc are static data and it can't be dynamically changed or loaded. (It has to be present in the file -- OP2 actually uses a file read to get this data, not a LoadLibrary/GetProcAddress type of thing)
This isn't our primary concern for now though, like you said. Most of the people who will be using it off the bat have MSVC or some compiler that can export functions. (We can't blow it off though, eventually, we'll need to open it up to other languages that can't export data or functions).

Anyway, that's my two bits. :P

Title: New DLL interface
Post by: Hooman on April 06, 2005, 06:09:30 PM

The IUnknown things was just a random thought. I can't imagine it working without it. Not important.

ATL won't affect clients using the DLL. The external interface doesn't change at all. It just affects how things are written withing the DLL. Like how every IUnknown derived class has to implement those 3 basic functions that are always essentially the same, and a pain to keep rewriting. (And copy and paste tends to be error prone since there is just enough to change to foget something from time to time.) Anyways, ATL handles things like those 3 functions, just some autogeneration so you don't have to. It also handles the registration functions to add entries to the registry on install, or remove them if you unregister the DLL. Those registry entries are used by the COM libraries if you want to use the COM way of creating the objects. If we also have plain old functions exported to create objects then the registry entries aren't needed, but they're nice if you ever want to do things the full COM way. (It would make using the library from a language like VB a little easier with the registry entries there.) As for code bloat? I'm not too sure, but I don't think it's too bad. ATL was designed to be lightweight, but it is still somewhat general. Besides, most of the code it generates, we'd have to write ourselves. Who knows, maybe it even generates more efficient output that'd you'd care to write by hand. At any rate, any code bloat will be contained to this one DLL.


As for that VB hack. We could hack the hack and make it more suitable for OP2 programming. We could probably do something really specific like define one module filename, where all functions/data in that module are exported. Or, the required names shouldn't be too bad since we can probably determine in advance what they'll be. But things like trigger callbacks would need some special care. But again, this is sorta a seperate project.
 

Title: New DLL interface
Post by: BlackBox on April 07, 2005, 02:50:59 PM

Yeah that's true Hooman.

One other thing to remember. Linking an .obj and linking a .lib file is essentially the same thing. (So say VB doesn't support one, it doesn't support the other either). Actually in fact a .lib file is just a bunch of .obj files in a UNIX ar-style archive. (That's how static libs are made on UNIX systems; ar thearchivename.a thefirstobject.o thesecondobj.o ...) I think the MS format is almost the same. (It'd make sense, it has the !<arch> signature on it). Their object files are different. The Unix files are standard COFF, the ms ones are MS-COFF (I think).

Anyway... I was wondering how the interfaces would work.

I was thinking of letting it be possible that you could create each interface separately, instead of having to say create interface IOutpost2 and then call a method of that to create interface IOutpost2Game. Instead the person should be able to create the Game interface directly, and all the interfaces reside in the same coclass.

Also, implement methods in a "main" interface, eg IOutpost2 which let the DLL do certain stuff like retrieve the game version. (This would be a good idea, as we could have binary compatibility of the COM object, and if we added or changed stuff in the COM DLL, the DLL can check the version to be sure it's not going to use features that are in a later COM DLL release (in turn a later game release).
Also implement stuff so you can avoid using the API for. Examples are things like SetTimer/KillTimer, GetModuleFileName (It might be useful to know what the DLL's name was), etc.

I also think writing a more advanced trigger/victory system is a MUST. A big thing would be allowing the DLL to forcefully set the victory condition (so it ends the game). One application of that is the Capture the Flag mission. (In order to end the game when a player brings the flag to their base, I use a Lastone trigger and enumerate all the other player CC's except the winner CC, and call .DoDeath() on them. It works but I shouldn't have to do that)

Other ideas:

Obviously a better unit system. Allow the user of the library to send CommandPackets (maybe raw ones even)

Data sync across the network layer. It should be possible for DLL's to share simpler data like ints, shorts, strings, simple structs, etc across the multiplayer connection.


And I can't think of anything more rite now. :P

Title: New DLL interface
Post by: Hooman on April 07, 2005, 05:22:57 PM

There probably will be a few main interfaces you can get at directly. Certainly one to handle the game map, or just general aspects of the game. (Essentially an equivalent to TethysGame and/or GameMap). Not all interfaces will necessarily be on "creatable" objects though. (It doesn't really make sense to use New on TethysGame, or GameMap, which is probably why the designers of Outpost2 made those classes static. But it does make sense to retrieve an instance of a global copy of those classes.) Of course this really all depends on our design and layout of this project.

As for versioning, COM kinda handles that already through the use of QueryInterface. We start with some basic interfaces and their implementations. Then when we need to expand, we either create interfaces derived from the old interfaces, thus adding new functions, or we just plain create new interfaces. It is perfectly allowable for COM objects to hold many different types of interfaces. It just doesn't always make sense to merge them all onto one class. Anyways, "version checking" of the COM DLL can be done by calling QueryInterface for the interface containing the functions you need and seeing if it fails. But yeah, if you really wanted, you could write something to retrieve some sort of version info for anything you want. Just keep in mind that QueryInterface gives a lot more info abotu what exactly the current DLL version is capable of doing, rather than a global version number.

I strongly disagree with the Set/Kill timer idea. If you need timing information, you should be getting it from the game, not from Windows. Think what will happen if you tried that in a multiplayer DLL. Also, I'm not sure I see the point in providing Windows API functions through this. It seems like extra bloat for little use. Besides, the level DLLs are still free to import and call them if they want. It's not like there is a huge statically linked library issue for this like snprintf might have caused. The amount of overhead to import from this DLL is probably about the same as importing directly from Windows, plus the extra code stuck in the shared DLL to redirect the call, along with the inefficieny involved with doing that.


You are definately right about a new trigger system. I was thinking we could add hooks into the code that would cause events to be fired. There is some interesting callback/event system specified by COM. I've used it from within VB before, and it was kinda nice. (using VB client code with VB written classes). That's one of the main reasons why I wanted this project to be a dynamic library. If we patch the exe, it might interfere with a hook. By updating the dynamic library, we'd still be free to use both the patch and old code that assumed it wasn't there. The internal unit classes already have a function that's called when they die. It'd be really nice to get feedback as to when a unit is lost. I can think of a number of AI related problems where an AI is stuck waiting forever for a dead unit to complete something. This would be a nice solution to that problem.


I was hoping to seperate out CommandPacket stuff into different layers. One layer would just send raw CommandPackets to the game engine. (I want it seperated out in case we need/want to change which function it sends the CommandPackets to. Remember that the main one doesn't handle ALL cases. So there may be other procedures that process them. Actually, there are if you look in Outpost2App.h). So that would mean we probably also want functions for building raw CommandPackets so you can decide where you want to send them. We also probably want to have those first two integrated into the unit classes so you can call functions on them directly, and they'll issues the right commands needed to carry it out.
ex: roboDozer.Bulldoze(rect);

Data send accross the network would be really nice to have support for. But I'm gonna say, leave it for a future version. If we allow too much scope creep, this project will never get finished. Besides, for most cases you should not need to do this. Putting it in may confuse people and make them think they are responsible for sending data accross the network that really doesn't need to be sent. Remember, execution on all clients is symmetric, and it needs to be to stay syncronized. There are very few cases where I can see this being useful, and most of them are dirty underhanded tricks. (or cheats). I can't really think of anything we can currently do that would require this. (I can think of a few that almost seem to require this, but the ideas always seem to be flawed).

I'd say for now, with version 1, just what the current functions exported from Outpost2.exe can do (at least the really important ones), plus a few extra CommandPacket goodies. I think that should remain our focus. Feel free to suggest more ideas. If we want to add something in later, it may effect our design decisions now so that it can be easily integrated later. I just don't want to get carried away with these other ideas and lose our focus.

 

Title: New DLL interface
Post by: BlackBox on April 07, 2005, 07:56:41 PM

Yeah, I agree with that.

I think another good thing to do would be error checking. For example, if the user tries to do something dumb like setting factory cargo for a Laser Lynx, catch that and either return a failed HRESULT, or raise errors somewhere else, or just simply ignore it, something that would prevent it from actually executing in the game and crashing.

As far as the COM event system: Oh yeah! I forgot about that totally. That would be a good idea for triggers.

Anyway, I'm short on time, so is this post too. :P

Title: New DLL interface
Post by: Cynex on April 13, 2005, 11:23:30 AM

Just read over all your stuff and got very confused...
Actually I agree to most of you're points (since i don't know better).

There is a way to build entry-point dll's in VB.
You only have to catch the linker-commands and change them to build a dll (when building a normal exe).
However you can only export functions this way, and only stdcall afaik, so we still need the lib to call game functions over VB. It might also cause problems that functions like 'GetSaveRegions' need cdecl.

As for IDL it seems to provide the right interface, and ATL makes it even easier.
Nevertheless i don't know anything about IDL, so i just started to read some tutorials about it.
(For anyone interested: http://www.devx.com/vb2themax/Article/19830/1763/page/1 (http://www.devx.com/vb2themax/Article/19830/1763/page/1))
I know far too less, so i won't be able to help in near future.

Title: New DLL interface
Post by: BlackBox on April 14, 2005, 05:13:25 PM

Well, GetSaveRegions isn't really important. We could probably even implement something similar using the COM method.

If you want an addin that can intercept the linker calls, search for "VB Compile Controller" on google. we could modify that to be OP2 DLL specific.

IDL's not too bad to learn, the syntax is kinda annoying though.