A Homeworld Universe Mod

I have 109 working now, seems I had to set 'choose race above' for the blank cpu player.

version 108 is crashing as well, anybody happen to have a copy of version 107?

Will there be a download for us Moddb's?

Every mod will be coded different and hold a different amount of data to the next mod, that will always cause a differentiation in the operational effectiveness of the devices hardware. For example the more visual effects a mod has, the more RAM it will suck up while the CPU deals with bigger chunks of data than the visual data that was made 15 years ago, the higher content of texture (+ shading) and general detail, then the more demanding it will be for the CPU and/or GPU... The more intensively the AI is scripted, the more it will build things, control those things, demanding more from the CPU, and because more objects are moving about from what the AI built, the more RAM the CPU (/and GPU) will need to make sure every computational action is visually fulfilled while the CPU (/and GPU) contents with the additional data (Weapon info, ship info, any other relevant non-visual data.)

Small solutions -
*I understand if that isn't possible for every modder* Get a benchmark PC rig set up, maybe a pc no less than 5 years old, has adequate cooling and a reasonable hardware benchmark to work with that is commonly buy-able for home-use PC's.
Maybe something like a dual core processor, 3gb of DDR3 RAM, SATA harddrive and a low-end GPU or a motherboard with decent onboard inbuilt graphics. A modern OS with the OS configured for performance instead of 'normal' or 'power saving'. Nothing fancy, just a low-end typical setup to hit the now unknown minimum requirements of game + mod...
Make sure the game works on the pc, run some hardware monitoring tools, there are many free tools that tell the temperature of hardware, the voltage and the general output of performance of particular hardware. If all else fails then task manager will just have to do.
If you can run the game in windowed mode then it'll make life easier to actively read the information outputted.
Leave the pc on for half an hour or an hour, let it sit at idle basically for a while, take notes on the information outputted from the tools.
Run the game as vanilla, 6 player game, any difficultly will probably suffice, due to there being 5 AI's building at a constant rate against you anyway. Take notes on the data outputted, if there were issues then sort the hardware out, if it needs cooling then chuck another fan in somewhere logical and get the game up to performing standards.

Once it's all setup then start testing the game again, do a 2 player skirmish, on hard (If you struggle with hard, simply use a trainer or mod your starting fleet or something just don't spam objects in continually or in large amounts, play like somebody who is playing the released uploaded version of the mod) observe the frame rate, the temperature of the hardware, that all textures have loaded up properly etc. Take notes on everything, compare this data to the data obtained when the pc was at idle, plus the vanilla data and see in a reasonable, rational manner whether there was any relevant or major performance issues versus the vanilla benchmarking. - Keep working up to a 6 player match to fully observe any potential hardware performance problems, but don't be too ambitious it is only a minimum requirement benchmark.

If there are problems - for example the frame rate is terrible, the CPU is climbing in temperature, certain objects lag more than any other objects in-game...
Reduce the LOD level from the objects that have the highest LOD counts, gradually working backwards to an ideal performance benchmark. Skim what can be skimmed from the visual side of the game/mod as that type of data typically breaks itself into bigger chunks than a simple script does, in terms of data transfer, in turn taking that bit longer for the CPU or GPU to get through those types of data files.

A mod will be parsed much more quicker when it is being loaded if it is coded neatly, every keystroke takes up space on a file. If there are many things simply 'commented out' then it will still be read > then ignored, it still has to parse through this data, which will add time to the loading sequence.
*Few* (older) games will maybe have a .ini file that dictates the order of what files get loaded via the game .exe, this was typically done for games like Freelancer where the engine decides to be pedantic as it loads every file up.
If there is something like that for HW2 (Just cant remember) then you may be in luck..
With something like that, especially for the older games where configuration files didn't use set templates, these files are generally messy to read, as if 3 config files got lumped into one when they were developed.. When you mod, you are constantly adding more data into these messy config files, generally following the script and table layout done by the dev's. - (Great for learning and small mods) This isn't always the best thing to do when the mod becomes big, suddenly these files are so diverse in the referencing of different files, though, of course each example would vary, it's just too much data to coherently send through the machine, it's coming in 'blurts' of multiple data rather than an organised 'blurt' of data at a time, or simply it will take a long time to read it all correctly, especially on a hard *disk* drive, usually prompting further issues in game with frame rates and general stability.

Try cleaning any of those files up, if you can split 1 heavily modded and messy file into 2 neat config files, have them scripted into the load sequence then it should work, if not then it's a hard code issue requiring a hex editor and that area of expertise. These sorts of things may or may not work, but if they do they make a massive difference to having a mod load quicker as the data is being parsed at a more organised rate, a table per file, not multiple tables in one file.
It may require a bit of confidence with modding to do something like this as it means breaking away from the way the devs organised the code into the way you think it should go, suddenly random errors may come up, suddenly the odd file wont be read in the load sequence, all depends on the engine and the hardcode, it's good experimentation to learn though.

Take away empty paragraph spaces where you can (preferably none unless necessary to have the code function), take away any unused code. Make sure all filename references are in the same lettering case, if you save in all caps then code the references in all caps, if no caps then use no caps etc. The shorter the name of a file the less keystrokes are made where you reference said file(s), in turn taking up less data per reference. If you need unused code then make a text document in the folder of the file that had the unused code and save it on that. Essentially streamline the mod until it meets the performance benchmark that it was reasonably and rationally intended for, by yourself.

Some of these things would likely resort to requiring an installer simply to make life easier for the end-user.
Once that's all done you could even start listing your own self-analysed "Minimum hardware specifications" on your readme's and front pages of stuff for the mod :P
I wont be afriad to admit that some of what I said here might potentially be incorrect, but I hope at least the basis of each point should be understandable to give the gist of all the things I've wrote about.