Very simply, this is a request that Spring load all game objects into memory during initial startup of a game. This very specifically includes models, their texturemaps, and sound data.
Why? Simply put... if Spring doesn't do that, then mods with hi-resolution texture-maps simply aren't playable. An uncompressed TGA map (the only texturemap format that is 100% compatible with video cards, in my tests) at 1024/1024 (which is not gigantic, by today's standards) takes up nearly 8 MB of data. If compressed via DDS DXT1 (which is acceptable for the color channel), then it's about 512Kb, but the main color and alpha map still won't compress to very small without really yucky compression flaws that will be obvious. This takes considerable time for a hard drive to load into RAM- we're talking a noticable pause here- and that will mean a whole series of sync errors during play, when players will be creating the units for the first time (and, under the current Spring build, that's when the geometry/script/texture is being loaded).
S3Os are the only things really impacted by this. 3DO textures are effectively pre-loaded, since that 2048/2048 texture is being loaded when the game starts (or the Commander is built at start- I should test that with an invisible Commander with no polygons hehe).
Yes, I know that this will mean a drastic increase in RAM usage, and high-resolution mods will take longer to load during startup. But... uh... that's inevitable, when mods move to S3O anyhow. Not preloading just means that such mods are, effectively, not going to be playable online, which is bad.
With today's high-RAM machines available, it should be able to have every single unit, script, sound, texture, etc. pre-loaded if at all possible, for performance's sake. S3O mods will probably require something on the order of 200-300MB RAM at that point (assuming 1024/1024 maps, DDS compression, etc., so that a typical unit comes in around 1.5MB apiece, so a 200-unit mod would run about 300MB, plus about 10MB for sound data, and a tiny fraction of that for Everything Else- scripts, etc., are a tiny part of the dataset in modern games).
But what about people with low-end machines and less RAM then that? Should we leave them in the cold? Nah.
[Edit]After thinking on all of this for a bit, here's a possible solution that would make everybody happiest, I think, including you poor developers. Yes, I do have sympathy for you, despite showering you with lengthy wishlists on a regular basis
This solution is very simple. Allow for mods that featured low, medium and high texure sizes... specified in the unit's TDF description. Instead of having S3O's point towards each texture, it might be preferable to have the TDF do so... but either way would work. Lazy modders would just do one level, but most modders would go ahead and do three (I mean, how much work is it to shrink your 1024/1024 map to 256/256 using Photoshop...). That might be the best solution of all- make preloading mandatory, let users decide what they'd like, and what will perform best for them, but leave all of the work needed to give users available performance options in modders' hands, so that it's not your problem. The more I think about this, the more I think this is the best possible solution- easier to code on your end, and it leaves modders with choices- if I, say, want NanoBlobs to have a "low-end graphics" option with 128/128, crappy-looking maps at the low end, for super-high speed... let me do that- don't force users to wait for their processors![/edit]
