It is difficult to explain the issues of Sins have without going into too much "technical detail" which some may not understand. The main problem is that Sins is an older generation 32 bit game. With a two gigabyte memory limit. This is nothing new. All 32 bit games have a 2 gig memory limit. However Sins is NOT like other 32 bit games. Most games have an ability to load their assets "on the fly", or only as needed. Some games can also unload assets that are not needed. This is how they prevent themselves from reaching the 2 gig limit. Some games have been patched to where they can use up to 4 gigs of ram on 64 bit systems.
Sins also can load only what is needed at game start up, but Sins does NOT unload what it does not use. Any assets that are loaded remain loaded throughout the entire game! If you use all three factions (Six in the case of Rebellion), Then Sins will load ALL of its game assets at start up. Entrenchment, and Diplomacy in some games loaded between 1.7 to 1.9 gigs worth of assets at game start up! Graphic settings, The size of the Map, and the amount of Players, or AI opponents also determine how much ram Sins will use in any given session.In 2006 when Sins was first conceived 32 bit Windows XP was the standard OS of the time. Single core CPU's were also still the standard. Though dual core CPU's were starting to become mainstream, and 2 gigs was considered to be "plenty" of memory. So most game developers at the time didn't have to worry about hitting that dreaded 2 gig brick wall. As time went on Computers, and Sins itself evolved into their present state which is now Rebellion, and soon to be Windows 10 running in multiple core 64 bit systems. With 16+ gigs of ram. Things have changed so much over the years. However Sins still remained the 32 bit game as it was designed in 2006. That uses only a single core of your CPU. With a two gigabyte hard coded memory limit. Sins WILL CRASH when the game reaches that 2 gig limit.There is some misunderstanding about the 2 gig crash issue. The dump happens when Sins reaches 2 gigs of Ram Usage. That means the ram that Sins uses by itself. NOT what your entire operating system, and/or other programs you are running combined uses. Only the ram that Sins uses. No matter how powerful your system is. If it is 32, or 64 bit, or if it is Windows XP, Vista, 7, 8, etc. etc. Sins WILL CRASH when it hits its 2 gig ram limit. It is hard coded into the game.Nobody was aware that this would be a major problem back when the game was first designed, because Sins was designed based on the hardware standards of 2006-2007. Before 64 bit OS's, Quad Core cpu's, and 4+ gig ram systems became the standard that they are now. There is nothing that can be done about it. Except to re-write Sins in 64 bit. Which is out of the question, because it is too cost prohibitive for the developers to do this (Ironclad said so themselves). Sins is a great game, and it is a shame that this is happening. With the Entrenchment, and Diplomacy expansions Ironclad had unintentionally pushed the game over its own hard coded limitations with all of the new added content.
Over the years as of the release of Diplomacy 1.3, and Rebellion. Stardock, and Ironclad did indeed fix all of the major game crashing issues of Sins. Using the fix's from This Project as a guide. However, NONE of these fix's ever made it into Entrenchment, or Original Sins! While the Stardock, and Ironclad developers have fixed most of these issues over years. They can not do anything to change the game itself short of reprogramming Sins over from scratch. The developers can do no more, but there is something that WE can do as modders to prevent Sins from hitting that dreaded 2 gig brick wall, and improve the performance of Sins "just a little bit more". I have taken the initiative, and applied to Sins what i have learned from my Homeworld Modding days. I present to you....
The goal of this project is to improve your Vanilla Sins gaming experience, and to eliminate the 2 gig crash issue. No changes will be made to Original Sins, or any of its Expansions in game play at all. No stat changes will be made. Nothing "new" will be added. There are other mods that can do that. Original Sins will remain Original Sins, and the Expansions will remain as they are. What we are doing is taking what game assets that Sins already has, and we are "optimizing" them to improve the performance, stability, and to moderate the ram usage in game. The side benefit will be that some lower end systems can enjoy almost the same gaming experience as the high end users do (Especially Laptop Users).The project initially started out as an idea to reduce the texture sizes, and poly counts of some models. Not just arbitrary reductions. The goal was to maintain the quality of Sins in game. To make it look as if nothing has been changed at all. We started with optimizations to the Planet's, and Skybox's, because they were the "worst offenders" as far as ram usage, and performance was concerned. Unfortunately my modeling skills left much to be desired in Softimage XSI at the time, and there were un-fixable mesh errors on the optimized planet meshes. Despite that the "proof of concept" was established. A lot of ram was saved, and there was a very noticeable increase in performance.Then we studied the Particle files, and Textures. Many of the particle textures in our opinion were way too high in resolution for the purpose that they served. A reduction in texture resolution by HALF showed no visible difference in game at all! There were some exceptions where the particle resolution reduction difference was very noticeable in game, and those textures were reverted back to their original resolutions. Remember the goal was NOT to reduce in game quality. Also all of the particle textures were changed from TGA format to DDS format, because DDS uses a little less memory, and is much more efficient, because DDS format loads directly into video memory. The particles can also utilize the mip mapping features of DDS format. Where TGA format does not. Therefore enhancing in game video performance (increased FPS). As of version 0.07 no TGA format textures load in TSOP. With the exceptions of the Mouse Cursors, and Scenario Pictures. This is due to those textures being controlled by the hard coded exe. When you change the texture format those textures do not show up in game.The developers mentioned something about a Memory Leak. I heard that a memory leak can be caused by a file searching for something over, and over again if it is not there. Example a mesh file calling for a texture that does not exist. Vanilla Sins had MANY particle, and mesh files that had that issue. We removed all of the entries that pointed to non existent textures in the mesh, and particle files. We also removed the entries that have lines like for example "C;\g\main\datasource\textures\effects\aura4.dds", and just used "aura4.dds". This will default the search to Sins, or the Mods "Textures" folder, and speed things up a bit. Also various typo's were corrected in some mesh, and particle files. Some ships had mesh nulls that were Miss-Labeled. For example the Akkan had nulls, and flairs that were miss-labeled. The engine trails, and flairs didnt show up in game. the Marza was missing its bomb nulls. etc. etc. All of this has been corrected as well. If there is a ships mesh file in the mods "Mesh" folder then it had something wrong with it that was fixed. The Soundata, and Galaxydef files had errors too. Regardless if any of these issues caused any memory leaks, or not these issues MUST be fixed! (and they were as of Diplomacy 1.3, but NOT for Original Sins, or Entrenchment).After the Meshes, Particles, Textures, and the User Interface were optimized, and the very obvious issues were fixed there was a tremendous boost in game performance. Sins ram usage was greatly reduced. As of TSOP 0.07 I could run a game of Entrenchment, or Diplomacy ALL DAY, and I NEVER used more than 1.5 gigs of ram! This was using Maximum Settings. Including Bloom enabled. Tested on Huge Random Multi Star maps with 9 AI's. The 2 gig crash problem has been solved! Our primary goal with this project has been achieved! Without having to use any external memory increasing programs! Stardock, and Ironclad took notice, and they used TSOP as a guide in the Diplomacy 1.3 patch, and for developing Rebellion.Now that the Stardock, and Ironclad have fixed the issues of the game as of Diplomacy 1.3, and Rebellion. TSOP has been focusing more on Original Sins, and Entrenchment. Since the Ironclad/Stardock fixes never made it into Original Sins, or Entrenchment. However, That is not stopping us from optimizing Diplomacy, or Rebellion "just a little bit more" You can also use Large Address Aware to give Sins an extra gig to play with, but in vanilla Original Sins, and Entrenchment the Endless Search Loop issues that were never fixed will cause the game to eventually go over that extra gig (Run vanilla Entrenchment, and watch your ram usage keep going up, and up, and up). TSOP is a solution that will stop that issue.
____________________________________________________________________________________________________________________
Downloads
The Sins Optimization Project v1.0
For Original Sins 1.195
For Entrenchment 1.055
For Diplomacy 1.37
Stardock, and Ironclad fixed all of the issues that compelled us to make TSOP. Therefore there is no TSOP for Diplomacy
For Rebellion 1.82
As with Diplomacy, Stardock, and Ironclad fixed all of the issues that TSOP pointed out, and then some in the case of Rebellion. Sins: Rebellion is as optimized as any Sins game is going to get.
NOTE: TSOP 0.07 is still hosted on ModDB, and it still works in the current versions of Trinity (OS, E, and D), but you will be playing as if Sins was patched to an older version of the game. Plus some Icons and Buttons wont be visible.
Changes in TSOP 1.0
TSOP 1.0 updated to the latest versions of Original Sins, and Entrenchment.
The User Interface is completely overhauled to use pure DDS format.
Trade Ships, Strike Craft, Mines, and Constructor Unit Meshes, and Textures are Optimized.
Starbase Textures are optimized mimicking the Stardock Rebellion Optimizations.
Sounds, and Music are optimized.
All TGA format Textures are replaced with DDS format, and TSOP "force" loads them. The only TGA textures that remain are the Mouse Cursers, and Scenario Pictures. This is due to hard code in the EXE.
"Strategic Texture Reductions" for the Particles return using newer methods to create a better looking texture.
(Original Sins, and Entrenchment) Many Mesh Null issues, and various File Errors were corrected, and Unnecessary Text Entry's were removed in both the Mesh, and Particle files. Entry's pointing to Non Existent Textures in both the mesh, and particle files removed. See the various "Fixed Files" texts in the mods Read Me for details.
(Original Sins, and Entrenchment) The Diplomacy 1.3 graphic fix's have been incorporated into the Original Sins, and Entrenchment versions of TSOP (Pipeline Effects, "White Line" error fix, and Corrected Mesh files).
TSOP 1.0 for Trinity will see the return of Optimized Planets using the planet meshes from Rebellion! but with our Optimized Original Sins Textures!
There will be no version of TSOP made for Diplomacy, or Rebellion, because there is no need for it. Only Original Sins, and Entrenchment need TSOP, because the 2 gig issue, and various other issues were never fixed in those two versions of the game.
This is the FINAL version of TSOP that i will make. If the community wants to take over the project they are more than welcome to.
Community input, and contributions are more than welcome, and they are encouraged! This is a Community Project! All can pitch in!
Note: TSOP does not fix the known issue of "Late Game Lag". It does help prolong the lag until further into the game in some cases, but sooner, or later the lag will happen. The late game lag issue is a CPU issue due to the fact that Sins (including Rebellion) is optimized to use only single core processors. Therefore Sins will use only one core in multi core CPU's. To help with the late game lag issue we recommend the following:
Playing on smaller maps.
Using fewer AI opponents.
Disabling the Trade Ship icons (this actually helps out a lot)
Stacking the icons in the empire tree (same as with disabling trade ship icons the less icons rendered the better).
Using a Strike Craft Reduction mod (The many strike craft in the game are a big CPU hog. There are some good strike craft mods that reduce the number, but maintain the balance. Search for them).
You do not need to download all versions of TSOP. You only need to download the version of TSOP for the specific version of Sins you wish to play. The Retail version of Trinity is just all three versions of Sins bundled into one package. Installation for Trinity versions of Sins are no different than if you purchased each version of Sins separately.
_____________________________________________________________________________________________________________________
Other mods are more than welcome to use TSOP. No questions asked! In fact we encourage it! Learn from it! Use it as guide, and an example! Merge it into your projects!
TSOP is intended to be a Stand Alone mod. Run with no other mods enabled. There are issues enabling TSOP with other mods. Enabling with other "Graphic Enhancement" mods is NOT recommended, because the graphic enhancement mod will defeat the entire purpose of TSOP. All of our optimized files will be overridden by that enhancement mods "enhanced" files. Increasing your ram usage instead of decreasing it. Some enhancement mods like Distant Stars are incorporating elements of TSOP into their future updates.
Read the included READ ME text's for installation instructions.
I am not exactly sure how he did it ether, or if it was a TGA or DDS he was working on. No DDS file i worked on no matter what it was for was able to be saved as 16 bit, and work correctly in game. All DDS's need to be dxt5 including the UI. The only difference is the UI doesnt need mip maps.
The DS team is more than welcome to study what i have done with the particles, and textures. You guys seem to have the right idea with the planets UV mapping (spherical). Look at my skybox. It is basically a lower poly "planet" with its faces flipped, and uv mapped spherically. Not planiar at the poles and cylindrically at the center. Which is why people get the funky skybox, because DS uses the default sins based skybox textures, and my skybox isnt mapped for those type textures. Skybox is kinda the wrong term. It should be called "skysphere".
I still have yet to start on the mesh optimizing itself. There are quite a few models in sins that can use to lose some wieght. Especially the Advent Starbase. Others are the Trade Ships, and some of the defensive structures. The Combat ships themselves seem to be ok. I have been studying the trade ships, and have a few ideas on how to optimize them so far, but what i have in mind may screw up the tangents. I now understand why Sins meshes are the way they are. The tangents are why some of the models are so poly, and texture heavy (for an RTS). There is no reason why a trade/refinery/NPC ship should be over 3100 tri's. They should be 1500 or less if possible. The heavy tri counts are what make the meshes so CPU intensive. In most games high polys would tax the graphics cards, but sins doesnt seem to work that way.
I think Micael456 was referring to particle and UI textures, which are all in .tga format by default. I think those are all set to 32 bit in stock Sins files, and I know for fact they are in SoA 2.
Well, he was changing the textures for the Fleet Supply Level buttons, so I guess it was UI, yes.
Sin Sound Optimize 96kb
You did not specify which quality. Let me know if I need to repeat at 112 kb. Easy merge with your mod, no sounds over written.
Has nothing to do with ur CPU & Ram, u can have 64GB of Ram and will have Lag after a while. I have a moderat GPU (8800GTS G92) and no problems at all when i start - at the End there is the same Performanceissue and it doesnt matter if i play on a 20 Planet Map or 200 (tested).
Maybe a little off topic but what the hell.
I would like to buy a new car from a new company so I go to the dealer. The dealer explains all the good points of the car, one of them being it will do 250km/hr.
Upon signing the deal and taking my brand new machine on the road, I let her rip. The engine starts to smoke and the wheels fall off. Repair after repair and still nothing. So they drop a new engine in. Nope. nothin. Repair after repair and another engine later, it runs even slower. So I was told to reduce the weight of the car and I took out the stereo. Took out the comfie seats sitting on a milk crate. Wind shield, air, everything. Well my lemon goes faster now but I get I hell of a lot a bugs in the face.
What would you do?
I would begin work on Sins of a Solar Empire 2.
you mean buy a new car
not the same car^^
He told a story as an analogy to all of the patching up people keep doing to Sins. So, rather than give a literal answer to his story, I just made the connection and answered the "real" question.
It would be nice if the new car at least used some of the same parts in a more efficient manner, that way the mechanics don't have to learn an entirely different structural anatomy.
Has anyone from IronClad seen this? Would be amazing if they added all this in a patch. Wouldn't need to worry about merging mods together.
They wont even make it a sticky. I think because it points out all the errors.
The car dealers not getting more from me and its a good thing I know a good mechanic or my car would have been scrapped after my 1st drive.
This project was never intended to be a diss of Ironclad. They were a brand new game company when they made sins. Mistakes happen. We all learned from those mistakes. We move on.
You can intergrate this project into sins itself. All you have to do is overwrite the core game files with the files from the project. I would however recommend you make a backup of sins first before you try it. Nothing "should" go wrong, but you never know. At least if it fails the worst that will happen is you need to re-install sins.
I approached Ironclad with this very proposal before i did it. I pretty much was dissmissed, but was told "you can try it, and see if it works, and if it does then great". This tells me that the support for sins is soon coming to an end.
However you cant deny that at least Ironclad "tried" with Sins. I would rather have many good intentioned patches that are abysmal failures than a one patch wonder (which would be a fail anyway), and its up to the community to fix the issues ("Cough" Battlefield Series). EA sure as hell wouldnt have supported more than one patch.. Relic probably would have patched it once... DRM'ed it to death, and said hahaha you are on yer own guys as they laugh all the way to the bank.. You also cant deny that Sins IS a good game despite its flaws. Otherwise we all wouldnt be here having this conversation right now. The point i am trying to make is that Ironclad supported Sins far more than the other big name companys would have. Even if that support was a failure. The good intention was there, and it shows. Thats is what earns IC my respect.
I just got back after a few days away and read the lip biting posts here and wanted to say this...I will enjoy wheeling the game out and playing with it for some time to come. Stress has made it run better for free and with a great attitude. It's appreciated and I'll use it.
As a beta tester I have watched more groups of people pick a game to death thinking they were being shrewd and all that happened is the project gets dropped and they never get asked to beta again. Stress is doing something appreciable here--the other stuff can be found in abundance on other threads.
I'm not bashing IronClad and I hope they start on either Sins 2 or a new IP. But it would be nice to see some kind of integration as the last patch for Sins 1. So from there they can go into their new game which I'm looking forward to.
Point is that the nm map use only two channel, so it is possible to move the two alpha from the cl and da to the nm map and save these nm map in dxt5 format... since the alpha channel from the cl and the da are removed, these can be saved in dxt1 format ( taking half of the size )... various shader fx files will need to be modified in a way that the shader know where to found the team color and the bloom map...
Fileosoft / Thoumsin, please believe me on this, the normalmapping can use more than 2 channels (and does it too) of the -nm.dds file except the red channel (which is posted into the alpha for compression reasons - as nvidia suggests)
In the B5 mod I do use the green channel (vertical vector information), blue channel (height information, I'm not sure this is really used by sins, I doubt it, but am not certain), and alpha channel (the former red channel, stores horizontal vector information). As an example take a look at the Asteroid nm texture files, which use all channels.
Real normalmaps are far superior in effect to bumpmaps (grayscale heightmaps) because you have control over the vector information yourself! I'm not sure why the devs chose to use grayscale heightmaps on the ship textures. I prefer normalmaps.
The only unused channel in the Normalmaps is the red channel. Though it is said that it should remain white - perhaps for file size reasons as I couldn't find any other reason in the shader files.
If you take a look at the FX shader, only the alpha and the green channel is used... in fact, when you generate the normal map in your photoshop/gimp, if you don't move the reed channel to the alpha and save in dxt5 ( or save in dxt5n, it move the channel for you ), you will have only one channel...
So, for the actual sins, it remain two channel unused...
Now, it is possible ( maybe ) that the engine is able to use 3 channel ( like the nm map generated with the nvidia melody tool who use a high and low poly model )... in the .mesh, you have a field for a displacement map ( nm map with 3 channel ) but there is no shader/FX able to use it... maybe it was planned before the release of sins and canceled due to performance issue...
I was under the assumption the video GPUs converted bump info into normal info anyway. I never bothered with the grayscale bumps on my models because of that assuption. I would create the bump, then convert it to normal using the nvidia dds plugins. So the game wouldnt have to waste gpu cycles converting them. This information is good to know, because that means we must use the grayscale bumps for the sins to properly use the correct shaders.
The Textures for Sins were created in XSI along with the models. This could explain why a standard normal map was not used. The dev's would creat the model. Then unwrap it in XSI. Then "paint" the texture in XSI. Not the method i would chose to create a texture, but i didnt build the game.
I have never had any issues using a standard nvidia plugin created normal map. The hieght info would show just fine. The blue channel would remain almost white, and i would duplicate the red channel as the alpha as per the dev's method. If there are unused channels how would one get rid of them? Fill the unused channel white to save memory?
...So the game wouldnt have to waste gpu cycles converting them. This information is good to know, because that means we must use the grayscale bumps for the sins to properly use the correct shaders.
For ship, the shader code for normal is :
float4 sample = 2.f * tex2D(TextureNormalSampler, texCoord) - 1.f; float x = sample.a; float y = sample.g; float z = sqrt(1 - x * x - y * y); return normalize(float3(x,y,z));
So, for any gray scale bump, two channel or 3 channel nm map, it change nothing about GPU use... the same code is used for any nm map, same a fully blank one !!!
The max info retrieve from the nm is sample.a and sample.g ( alpha and green channel )...
If there are unused channels how would one get rid of them? Fill the unused channel white to save memory?
Will change nothing at the GPU speed and at the memory use... format of the nm map is dxt5_nm... compression ratio of 4... mean that a map from 2048x2048 will always be 5.3 mb for the dds...
The only way to save memory is to move the two alpha from the cl and da in the empty channel of the nm and save these new cl and da in dxt1 format who use a x8 compression... so, in place of 3x5.3mb, you will have 2x2.7mb and 1x5.3mb ... since this ask a modification of the fx shader, it is not a universal solution and cannot be used for your mod...
Believe me, you have already made a great work and the best thing is that your mod is universal... in fact, Danman have apply your method for the 7DS 2.5 alpha mod and since the alpha playtester price the result on the DMG forum : fewer crash and more speed !!! So, thank you for your very good work...
Sorry I haven't been on for a while, went up to Wales for a few days.
Regarding the 16-bitting, yes it was just with UI files which I'd checked before. About half of them work happily at 16 bit (the 32bit ones as far as I could tell), but the 24bit ones simply don't like it.
And yeah, I hadn't tried the actual ship textures before. I saved the Psi Starbase at 16bit with dxt5 (it didn't crash but took a minute to do), and it came to the exact same size as stock, so I'm guessing some of Stock sins has already been optimised.
You can save it at a lower texture type (eg dxt1) and sins won't dump or anything, but the lighting goes screwy on it, and develops team colour issues.
What thoumsin is saying makes sense, as if the ship textures are already 16 bit to get them any smaller we'll have to either resize them or shift channels and cut down to 8 bit, but I'm afraid I don't know Photoshop that well to go playing with the channels like that.
@Fileosoft / ThoumsinThanks for confirming this to me. I was not sure if sins would use the heightinformation of the blue channel for normalmapping (I believe it's absolutely required for parallax occlusion culling with self shadowing, but not necessary for normalmapping). So this means, as you said before, we have two channels not used in the nm files (though, if you are able to change the nm shader to use the height info for relief mapping or parallax occlusion culling or other ways of deepening the nm map, I'd gladly appreciate it)
@Major StressAs Thoumsin (aka Fileosoft) pointed out, the shader uses two channels.The Alpha channel (which should contain the information of the red channel) is the horizontal vector informationThe green channel is the vertical vector information(I refer to the channels created, for example with the nvidia normalmap plugin. Just be sure that the "invert y" checkbox is set)So, if you want to use normalmaps, convert the heightmap texture to a normalmap, cut out the red channel, paste it into the alpha channel. Save as DXT5.Still don't understand why IC chose to use grayscale bumpmaps on their models...
They are not grayscale bump map... take a look at CapitalPhaseCarrier-nm.dds by example... decompose the dds in layer ( RGBA will give 4 layer )... check the 3 first layer ( from red, green, blue ) and you will see that each are identical... the last layer, the alpha is different...
Now, remember the code from the shader... x come from the alpha and y from the green channel... texture from stardock/IC have these x and y data... like any dxt5nm map...
In fact, if you delete the red and blue channel, and move back the alpha to red, you will have a usual normal map...
Since dxt5 have a fixed compression level by layer, it change nothing that the red and blue are empty or with data... it will always use the same size...
Check all the dds, they are 32 bits image ( 4*8 bits, 8 bits for each channel and alpha ) and not 16 bits ( grayscale and alpha ) or 8 bits ( grayscale )...
So what you are saying if i am reading this right is that pretty much nothing can be done about the normal maps.
Still--my game plays hugely faster and no crashes.
Some examples:
Start Screen: My time from clicking the game icon to reaching the start menu screen has gone from taking 2-3 minutes to about 45 seconds.
Panning and Zooming: No more jittery or lagged motion. Smooth pans in and out and across.
Combat: No more massive slowdowns with large fleets moving or fighting.
Audio: No stuttered or delayed audio in big fleet segments.
Stop Game: Still takes awhile to unload (3-4 minutes for a long and large game but no more windows program crash messages when I finally exit out (Goodbye Dr. Watson).
Complete success from my point of view.
I have an Athlon XP 3000, 4gb of single channel RAM (about 3.25 usable), Windows XP Pro, 512 mb ATI pci graphics card, 7200 rpm IDE HD's.
The textures are pretty much as optimized as they are going to get. If they are reduced in size any more severe detail loss will occur. So now the focus should be on the meshes themselves, and the UI. All of the capital ship meshes are pretty much right where they should be. At around 4000 tri's, and under. Frigates and Cruisers are pretty slim too. With only a few exceptions. It seems the poly hoggers are the NPC ships, and the structures. Why so many triangles for models that will be spammed all over the map in the hundreds is beyond me. Why level of detail meshes werent used as well is also beyond me. Regardless optimizing just one mesh will take a long time to do, because it will involve reverse engineering, and rebuilding the model. Poly reducing programs tend to screw meshes up. So that wont work. Ive put the mesh optimization on the back burner for now till i can find the free time to dig into the meshes.
The UI however can be worked on now. The most important thing i need to figure out is how to "force" the UI to use only dds textures. Past attempts have failed. I dont know why the UI pulls tga's from the game itself despite a dds in the mod folder. I need help in figuring this out.
Have a huge fleet and am working on colonizing 3rd star. Had some huge beautiful battles and am starting to love this game again. Even had 2 AIs gang up on me, what a battle. Well past the point I quit other games due to lag.
I don't know anything about texturing but I do know if the game wants a .tga, it needs to be .tga in the mod folder. I have not tested in Sins but tried in other games for different file types. And yes I know to change the extension in the reference file.
There are many great features available to you once you register, including:
Sign in or Create Account