New Mod

posted on July 26th, 2010, 6:17 am

Well, since no one has access to the source code (and never will), the devs 'just' write what some of us used to call a "trigger engine" - basically inserting key bits of code at certain points to cause the old A2 engine to do what they want. And yup, it's coded - though since I'm no coder I've no idea where that is contained. Perhaps in the exe as the odfs simply are storage of the information I believe? The Data folder merely contains the 'outputs' of the program - the devs don't really even use the odfs much except for bug checking, as they are simply the output of the FO engine (and of course the A2 engine). Of course, they also rewrite other parts of the engine I presume, such as the graphics engine (hence why newer ships have a metallic finish in recent patches), integration of the sound engine, etc

The bit about the engine is about right if I had to guess, being a bit of programmer myself. I believe though that it may go as far as completely overriding certain functions in the original engine and making it run the new versions. The code and its mechanisms are contained in "Install dirFleetOps.exe", "Install dirFleetOpsHook.dll", and "Install dirFleetOpsHook.map". My understanding about the ODFs is that they are essentially soft-coded ship definitions. That is rather than hard code the stats of the ships into the engine, they put the definitions in separate files which are then parsed by the engine at run-time and I'll bet a class (a type of code structure) is created for each one. This way new ones can be added and existing ones modified without completely rewriting the engine. But since the ODFs don't contain any functions, just variables, there is no need to "debug" them.

So they recompiled the whole game? (I only say this because I can't find and C++ files in the data folder I may just be blind)

There are still a number of header files (.h files) kicking around in the Data folder; but most of these existed in the original. Again, however, all they contain are variable definitions which are read at run-time and used by the engine as if they were hard-coded. Unlike the ODFs however, these .h files are actually written in C/C++ and if you don't get the syntax right you can really screw things up. For example, if you study the "Dynamic_Localized_Strings.h" files you'll see it's actually a giant array of strings, if you don't close a set of quotes or forget a comma, look out. I did this once by mistake and it essentially created a memory overflow and crashed.

[Sulu]

posted on July 27th, 2010, 4:31 am

Last edited by Sulu on July 27th, 2010, 4:39 am, edited 1 time in total.

Personally, I've always wanted to make large multiplayer games where players could join and drop out at their leisure.  Games big enough where a single map could be 50 x 50, but you could warp onto other sectors, and use wormholes to travel even greater distances.  You could have multiple maps running in the same game.  You could select, upon starting the game, the maps which would be included, and then the game could randomly generate npc's and the order at which the selected maps were set up.  You could have many different players, some could be AI controlled.  You could get ship bonuses for controlling a whole sector, the amount of possibility could be endless.  It would be soo cool   And it would allow warp to be used, but only for travel to other systems.

But that all seems a little beyond a2 to me.

You and I are on the same line on the same page

The bit about the engine is about right if I had to guess, being a bit of programmer myself. I believe though that it may go as far as completely overriding certain functions in the original engine and making it run the new versions. The code and its mechanisms are contained in "Install dirFleetOps.exe", "Install dirFleetOpsHook.dll", and "Install dirFleetOpsHook.map". My understanding about the ODFs is that they are essentially soft-coded ship definitions. That is rather than hard code the stats of the ships into the engine, they put the definitions in separate files which are then parsed by the engine at run-time and I'll bet a class (a type of code structure) is created for each one. This way new ones can be added and existing ones modified without completely rewriting the engine. But since the ODFs don't contain any functions, just variables, there is no need to "debug" them.
There are still a number of header files (.h files) kicking around in the Data folder; but most of these existed in the original. Again, however, all they contain are variable definitions which are read at run-time and used by the engine as if they were hard-coded. Unlike the ODFs however, these .h files are actually written in C/C++ and if you don't get the syntax right you can really screw things up. For example, if you study the "Dynamic_Localized_Strings.h" files you'll see it's actually a giant array of strings, if you don't close a set of quotes or forget a comma, look out. I did this once by mistake and it essentially created a memory overflow and crashed.

I see thank you for the information. I don't know if I said it already but I have done things with OO languages before including C++, however; most of the experience is on websites and I have not had to compile or work with executables. Am I correct in thinking that once compiled one cannot modify or even view the code, and therefore
any logic in the fleetops.exe is inaccessible for understanding?