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!
) 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)
