Well, that means heavy texturing optimization for us if we wanna allow MP games for our mod.
Guess so 
Yes and no - remember that for us total conversions, we can exclude most of the memory load of the stock ships I believe. Also, I believe @Bitvenom mentioned a while back publically that having all your textures be named the same may be a very bad idea for a very good reason. 
- Some pointers in this engine mask the upper bit for various reasons - using LAA is a great way to crash and burn.
- Memory limits have very little to do with multiplayer stability.
The main issue is people who over-res their 3D assets, or use UI artwork (which doesnāt scale with user preferences for texture size) that is too big, too plentiful, or just wasteful (like 90% transparent pixels, etc). In almost every single case it is a function of hubris and willful ignorance on their part⦠That sort of thing just makes me cranky.
Heh heh, yeah, I can imagine that. Thank God I donāt have this problem except for when different ships use the same texture files, of course. 
@BitVenom : For the UI, I tried to keep it as simple as possible, for the other issue, I told my modeller about it, but weāre also working with a set of ships offered by another team working on the same universe and they are a tad more detailled. However, what you said about multiplayer stability surprises me. I thought the problem was that as we went near or above the limit, the game was slowing down and might slow down differently on each end of the multi, causing the desynchronisation, thus why Iāve experienced desync in my test games after 20-30 minutes but could play hours at a time in SP.
In any case, thanks for the tip, it will save me a lot of frustration with trying to make LAA work. As for the resolution, Iāll have to see if our modeller is up to remove most of the hangar interior details we got on the gifted models.
Longest three days ever!
If Iām right, the 2GB limit wonāt make your game slow down when you use lots of memory; it just makes your game crash suddenly when you hit the limit, and give you an Access Violation telling you the game was trying to write to NULL.
Huh. If thatās correct, then Iām reassured for that since I managed to run a long game with all four new factions without any hiccup in Skirmish, but I have synchronization issues in multi. Thanks for the info, thatās useful. 
Syncro issues are an area the patch has vastly improved. It isnāt perfect (the simulation weāre trying to keep in sync is WAY more complex post-patch), but we found and killed a bunch of issues. That said, custom code and strange LUA can still cause an OOS, and thereās little we can do about that.
Can I hug you? Can I give you a pony? Two ponies? When Iāll forward this to my modeller, Iām pretty sure this will make his day, to not have to rework two dozen frigatesā and capital shipsā textures.
There are also some great texture optimizations possible now, for example you can size the team and stripe to be pretty low res and the diffuse and normal to be higher res, similarly you can have a diffuse that is small and use a large normal map (there are some specifics in the shaders on which combinations work together without custom shaders) You can also use a single larger texture and map different variations of a ship hod off of the same texture due to texture sharing (and some really neat other feature with shaders that will probably get discussed later.) Add to this the ability to share common textures like engines and the instancing of turrets, if you plan ahead you can greatly reduce memory footprint.
The older engine also causes issues with large polycount models, so donāt think that is a way around the memory limit, you just run into other limitations. This is actually a vertice count issue that includes extra vert counts for UV maps and smoothing groups. Blocky ships suffer the most because of the smoothing group edges, smooth ships that do not have split normals everywhere will be able to push closer to the 65K limit. This limits you to a practical level of around 25K per mesh (it will completely corrupt your mesh on export to try to fit the limit, though there may be some future switches in the config file to correct for this) You can split meshes up in the export process, but this is a performance hit by forcing redraw passes for each sub object. Also you need to watch out for LODs with different textures as well. The lower res textures require their own memory and it becomes a bigger resource change as the engine determines which version to render than just reducing tri count on the mesh and using the same texture.
The engines, inlets and that stuff are already using common templates and all my turrets are standardized subsystems too (though they were made this way to simplify my job during the integration of the ships rather than lowering the footprint ^^). As for the high polycount models, yep, thatās where I had the biggest issue when converting old HODs to new ones through HODOR, as the multimesh ships ended up warped, though I have some clues on how to fix the problem. For LODs, Iām not changing textures, so itās alright there.
Thanks for the advice!