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.
why reducing the strike craft with all the former optimization we far away from lags or crashes even in the end of long games
the last time i checked my ram usage it was only 1/3 than without the mod (diplomacy 2vs2 map without mod need at the beginning more ram than with the mod in an 4vs4 map at the end )
Try a huge map with 10 players
My ram usage with TSOP enabled on Diplomacy, Max settings, 3 AI on the Systems of War map running windows 7 64 bit never goes above 1.7 gigs throughout the entire game. There still is bad late game lag from all the units, and structures on the map. Obviously the larger the map, and the more AI's you add the more system resources you will use. Vanilla Sins does indeed have Memory Leak which the opti mod all but fixed. You will notice that Vanilla Sins ram usage keeps steadily increasing as the game goes on. While the Opti mod holds at a certain point. I dont think we shored up the memory leak completely, but we nailed the cause's of the problem, and we are not programmers.
I would like all those who follow this topic to do a "Stress Test" (pun intended). Max your games out to absolutely ridiculous levels. Biggest maps. Max AI's. Do this on both Vanilla Sins with no mod enabled. Then with the Opti mod enabled. Compare the results, and post them. Mainly check your task managers to see how much ram Sins then the Opti Mod uses on your rigs. Try to play test as long as your machine can handle it, or 2 gig crashes. Which ever comes first.
I know the results from my machines. We need results from various other rigs. Post your specs as well. DO NOT post Mini dumps. We cant read them, and they are useless to us.
The Planets, and Skybox's will get fixed eventually. We just need time to research the problem. Ill get the master meshes to you SivCorp ASAP.
I guess the real question is whether or not there's a "default" modifier for this... or a way to emulate one...I don't see anything about it in the squadtechcombat entity file, but that doesn't mean there isn't one.
My question is why would'nt this be a natural setting in vanilla sins? Did the devs want SC to always be rendered?
I mean ships know when an enemy is in a well, why couldnt carriers and hanger bays react the same way.
And who has the time or remembers to launch SC manually? If all these SC only came out when needed I see this as a huge savings, why bother lowering their textures when half of the SC could be docked and a none or lesser issue.
You have a valid point, but it is what it is right now. If an auto dock/launch in combat ability can be made that does not effect game play then that would be great.
Right now the optimod strike craft look no different than they did at full res. At least from my point of view. No one really focus's on the strike craft eye candy during a fight anyway. The texture res was lowered because regardless if they are launched, or not Sins loads ALL of the games textures anyway. Despite if the mesh is on the map or not.
Thanks for your response. I'm new to mods, can I run this mod with the Requiem mod?
I would also like to know if this is compatible with SINS Requiem. Just a question if someone can help me, running diplomacy v1.011, with SINS optimization running, I'm about 3 hours into a game with 4 races and 50 or so planets and I'm minidumping all over the place. Already turned down my settings, from 4x to 2x to 0x AA, and some graphics settings are on high from highest, Bloom is off, cargo icons off, etc. Running on a laptop with 512mb or ram and a dual core 2.56ghz. Tried that .exe patch bumping ram limit from 2gb to 4gb, doesn't seem to work, and am running at 1920x1200. Figure I'll force it to run at 1680x1050 and try that, just wondering if anyone had any advice. BTW, thanks for all the time an effort put into these mods you guys.....
Your problem if i am reading your post correctly is that you only have 512 megs of ram. I do hope you are running windows xp, because if you are running anything else i would be amazed your laptop will function at all. Windows xp needs the whole 512 megs just to run smooth (despite what the system requirements say). Windows Vista, and 7 need a gig to run smooth.
If you can upgrade to at least a gig of ram that will give you a tremendous performance boost. You still will not be able to run sins at max settings. You need 2 gigs of ram to do that even with the opti mod enabled.
You can run opti with Requium. I dont see any reason why it shouldnt work. Make sure you enable opti first.
The issues we have been having running opti with other mods so far..
1) If the mod you are enabling over Opti has its own unique planets and/or Skybox textures (like Distant Stars) you will see graphic errors, because our planet and skybox meshes are different than vanilla sins. Mods like Distant stars created new planet textures but use the default vanilla sins planet mesh which is overrided by the opti mods mesh.
2) If you enable a "Graphic Enhancement" Mod over the opti mod. For example Bailknights graphic mod. You will defeat the entire purpose of the Opti mod. We cleaned and optimized every particle which was one of the biggest ram hogs in Vanilla Sins. Any graphic enhancement mod will override all of our optimized particles. Replacing them with the old ram hoggers again. Increasing your ram usage instead of decreasing it. Plus bringing back the memory leak. This is why i am encouraging other mods to look at our particles. To study, and adapt our methods into their mods. It makes a HUGE difference.
3) Any mod that overrides the opti mods DDS textures with TGA textures. Same reasons as above. Defeats the purpose of our optimizations.
MajorStress from what I understand Requiem uses some of if not all Bailknights enhance mod, so is that going to cause any issues?
If the file references are the same, the mod that is on top is the files that will be used. If TOP is on top of Req, all the particles of the same name that are in TOP will be used. If you place Req as the top most mod, its files of the same name will override TOPs.
Pretty much what Myfisto said.. I forgot about requiem using bailknights particles, and manshooters volumetrics. It would still be better to enable Requiem over TSOP because of the optimized vanilla sins meshes (strike craft, starbase textures, and constructor units). Your mileage may vary. It wont be much of a savings, but better than nothing at all. Plus no guarantee that it wont crash.
How does a game like x3 not hit this 2 gig limit?
After the update to 2.7.1 X3 removed the 2gig limit on the game to allow it to use more ram. There is also a 4 gig patcher out there that solves the issue to improve gameplay on x3 even more. With a game like X3 the more ram you have on your computer the better it'll run. Though of course a good CPU helps, comparing X3 to Sins though. I think is a no no seeing how X3 is a much more complex and difficult game to play. Sins is a RTS while X3 is a economic and combat flight simulator
eternalrequiem, the problem is THE GAME ENGINE. sins uses the iron engine which is hard coded to MINIDUMP at 2gb ram useage.
the engine would have to be re-written from the ground up into 64bit not just patched like other games eg supreme commander.
harpo
Yeah, I forgot to add that part about the hardcode and the game engine being a 32 bit one
Ironclad IMO had the right idea by having the engine load everything at once, and sort it all out as the game progresses. It reduces lag from constantly loading and unloading files. However the 2 gig limit was not foreseen as a major problem back in 2006. Original Sins doesnt hit the 2 gig limit (at least it didnt used to) It does come very close though. The memory leak does not help the situation.
X3TC uses 64bit code IIRC. That is why it can be patched to use 4 gigs. On a 32 bit game there will always be a 2 gig limit because that is all it can read (correct me if i am wrong). Some games can handle more eye candy because the game unloads what it doesnt need, or only loads what is needed for that particular instance (think doom 3/quake 4 series).
If you think Sins is bad with the hard code limit, You should have been there when we were modding Homeworld 1 with its hard coded 32 meg maximum texture limit. I am amazed i still have hair left on my head
I don't know if this means anything, but I noticed as I play Sins/requiem mod with Nvidia monitor running in backround, my ram useage is around 85%.( xp /priority realtime)
As I play for about a half hour I creeps up to 88/89% but when I back out to Windows with the game paused for a little as 20 seconds, the ram usage goes back to 85% right away.
Then I play for another half hour at 85%, contining the game. So I have been able to play games without minidumps( small maps 30 planets 5/teams ) graphics set to highest, all I've lowered is the AA from 4x to 2x. Adventually it goes up to 88/89% and I just take a 30 sec break back to windows and now have a little more breathing room for awhile. 85%
btw with the g19 keyboard I watch my ram usage in realtime on the lcd performance monitor, it also shows less ram being used when I back out.
Were you running requiem over TSOP, or just vanilla sins?. Signs of a memory leak is a steady increase in ram usage for no apparent reason. Ironclad has acknowledged that there indeed is a memory leak in sins, and word has it they are looking at the Optimod for a solution. The fact that we "modders" found so many ommisions, typos, and lines calling for bad, or non-existant textures, and/or files means they need a coding proofreader. I personally know SQUAT about coding, but i do know how to spell... most of the time TBH with all of the errors we found so far i am amazed that Sins runs at all. Most of these errors are so simple to fix it is stupid.
Requiem has not updated its particle files to the optimod standard yet (fixed the typos in the particles, Removed the redundant lines, or corrected the lines calling for non-existent textures). It is still using old vanilla as its foundation hence the memory problem.
The misspells, omissions, and typos now have us looking into other stuff like the pipeline effects folder, and window brush files. We already discovered errors in the galaxydefscenario file, sounddata, and soundmusic files. MyFisto is compiling a list of these bad files, or files with these types of errors on another topic. Fixes will find its way into optimod soon.
I am also going to experiment with replacing Sins core game files with optimod files. With the exception of the planets, and skyboxes until we can get them fixed. If this does work then TSOP will become a "patch" instead of just another mod.
Sorry if this has already been mentioned, but have you guys tried making the game Large Address Aware (LAA)? This is a simple flag you can apply to the Sins game executables to allow them to grow from 2GB to 3GB of virtual address space on a 32-bit operating system, or the full 4GB on Windows Vista 64-bit and Windows 7 64-bit.
You just have to download Visual Studio C++ Express (version 2008 or 2010 will do), then start the Visual Studio Command Prompt and run "editbin /LARGEADDRESSAWARE sins.exe" where you replace "sins.exe" with the path to the sins executable, and add double quotes around it if it contains any spaces. Make sure to do this for all your expansions if you run entrenchment or original sins but own diplomacy.
If you still run a 32-bit operating system, you also need to turn on the "3GB Switch" which is a boot-time option to tell the system to pay attention to large address aware. If a 32-bit OS does not have the 3GB Switch enabled, it will ignore the Large Address Aware flag entirely. Google around to find out how to enable the 3gb switch, but I'll give you a hint: boot.ini
It would be pretty difficult for you guys to include enabling the 3GB switch in the mod, but you could very easily (although perhaps illegally) distribute a modified version of the sins executables that has the LAA bit set. It's probably equally illegal to distribute editbin.exe and any of its dependencies to perform the bit flipping in-situ.
That said, LAA makes this project redundant under the following conditions:
(1) The content you need to load can fit in 4GB of virtual address space (or 3GB if you have a 32-bit OS);
(2) Users have 4GB or more of system memory (preferably 6GB+);
(3) Users are willing to close enough applications to allow Sins to take up 3 - 4 GB of RAM without swapping stuff to disk, which makes everything unplayably slow.
This project is still useful for people with low-end systems, or for trimming down the base sins resources so that mods on top of them can take up even more RAM.
Maybe the holy grail of modding headroom would be to combine the LAA-enabled executable with the 3GB switch on 32-bit systems, with the texture/poly shrinkage in this mod: the result would be a base sins that takes a relatively low amount of RAM, while allowing another 1 - 2 GB of extra virtual address space for mods, on top of the hundreds of megabytes available with this mod's enhancements.
Or, if you're feeling hardcore and want the absolute highest quality textures and polys, you can use the original sins resources, flip on LAA, make sure you've got your 64-bit OS and 6GB of RAM firmly in place, and enjoy virtually any mod with Sins taking up a peak of 3.5 GB of RAM or so during massive battles
EDIT: Before you ask, running editbin and turning on the LAA flag is *not* a hack. You're using a Microsoft-supplied development tool, which used to be locked away behind the expensive Visual Studio software (but now available for free with Visual Studio Express C++), to manipulate a single value in the Win32/PE header. PE headers are very well-understood, and they are as much a part of the operating system as a part of the game. You get absolutely no advantage in the game from enabling LAA, except that your game will not crash if you go past 2GB mapped private working set. This is an issue of Stardock/IC being too lazy, ignorant, conservative, or all of the above, and for any of those reasons, having failed to check a checkbox in Visual Studio when they compiled the game. Fortunately, editbin.exe allows you to modify the PE headers after the fact. I checked the license on editbin, and it's a very proprietary EULA. You aren't allowed to distribute Visual Studio Express or any part of it to others. The only way to legally obtain editbin.exe for free is by downloading the entire Visual Studio Express for yourself through Microsoft's website.
The subject you bring up has already been discussed several times over. The whole point of TSOP is to have a "simple" means of enjoying the game without having to screw around, or hack, and possibly break your system if you dont know what you are doing. You shouldnt have to go through that much of a "pain in the ass" factor just to play a game that shouldnt be broken to begin with. With a mod community trying to fix it. It is kind of sad because Original Sins was not broken before entrenchment. Dont get me wrong IC showed tremendous support for Sins in the past with a relentless release of patches. They are however "newcomers" to game making. Much like Relic was with Homeworld 1. The lack of experience shows with all of the mistakes made in the files that we fixed already.
That being said the option you mentioned is an alternative if you do want maximum unaltered graphics. However you should use that option ONLY if you know what you are doing, and dont mind the pain in the ass factor.
Ironclad never had any intention of ever rigging sins to use more than 2 gigs. This was to make sure sins was compatible with a wide range of systems. Mainly focusing on the mid ranged single core 32 bit systems of 2007 which are now low end industrial art compared to the quad core 64 bit windows 7 systems of today which are considered "mid ranged". It is also the reason why we are having this problem now. They did unintentionally push the game over the edge with the two expansions. You do have a point that IC could have unlocked more ram for sins. Unfortunately Ironclad is now all but done with sins. We may see one more patch if we are lucky. Then that will be all she wrote. They are focusing on Elemental, and other things now. I really dont want this to turn into a "lets bash IC" topic. Sins is great. However mistakes were made. Lets find a way to deal with them.
The main problem of sins now other than the 2 gig hard code limit IS the memory leak that is still there in vanilla sins. It needs to be fixed. TSOP is only a "partial" fix, because we have not looked at everything yet. We did however shore up one major cause of the problem which was the particle files. We are looking at other stuff that may be a problem. However we are not coders and we can only find the "obvious". No LAA or 3 gig switch which in xp service pack 3 is already turned on will help if the leak keeps consuming memory with no end in sight.
That is TSOP's next goal. To completely shore up the memory leak.
stress, are you SURE that ironclad is involved in the elemental program?
from what I have read in the forums, it is stardock ONLY for elemental.
I'm just running Diplomacy, with Requiem mod, havent installed the optimized mod yet. baby steps .lol
Though I don't understand the Stardock/Ironclad business model, They struck gold with Sins, it sold very well, but since then, we get to untried unknown games, Demigod, Elemental, instead of throwing us a bone ( even info) we get silence.
Stress -- Thanks for your reply.
Just wanted to comment that I am a software engineer, and so, my advice in this post might hold a little bit of water.
There are two types of memory leak: bounded, and unbounded.
A bounded memory leak is basically when you have unwanted data loaded into memory, but running more code in the program doesn't cause even more data to leak. You can think of this as having a "constant" amount of memory leaked. This just causes an inefficient, bloated process, but running the program for days or years will not cause more memory to be leaked.
An unbounded memory leak is where executing a particular code path in the program causes memory to be leaked (the system loses track of it) each time that code path is executed. It's "unbounded" because, if you run the program for days or years, your system will eventually run out of memory, as the size of the leak keeps growing.
I have no doubt that Sins has plenty of bounded memory leaks, but these just bloat the process, so we don't really care about them, because they won't bloat it "infinitely" over time. But it's probably also true that the Original Sins executable may have an unbounded memory leak that eventually would also eat up 4GB of RAM or more.
Since it is all but impossible for the community to edit the Sins code (which is where the leak is programmed), we would be unable to stop the leak, for all intents and purposes. The only thing we could do is either (a) increase the amount of RAM available for Sins to eat, or ( reduce the amount of RAM used by its sound / graphics resources.
These two methods are not incompatible, and in fact, doing both of them together is probably the most robust solution. The unfortunate fact is, you can shrink the resources down to just a few bytes each, but if the memory leak is truly unbounded, even a hypothetical 64-bit build of Sins running on a system with a terabyte of RAM will eventually crash or slow the system to a crawl.
What an unbounded memory leak does (if the leak is relatively slow) is it limits the lifetime of the process. The lifetime of the process is limited by (a) how much system memory you actually have (because it will either eat up all your swap space or you will get mad and terminate it due to the unbearable performance); and ( the amount of mappable address space available to the process before the system declares that it's out of memory.
The work you are performing with TSOP could increase the lifetime of the process by a constant amount, but an unbounded leak would still eventually crash the program. The LAA switch could also increase the lifetime of the process by a constant amount, but .. the leak still would crash the program or run you into swap hell.
The unbounded leak has to be fixed, and that's the bottom line. Let's hope that it is.
But even if it's not fixed, the combination of our two approaches might allow players to play significantly longer games before it crashes.
I'm currently working on a console program using GNU bfd (part of binutils) that will set the LAA bit. bfd does support win32/PE executables so it's just a matter of writing the program. This program would be licensed under an open source license so that anyone can read the code and compile it.
The ultimate goal is to create an installer that will find the user's Sins executable, back it up, then flip the LAA bit. This could be distributed as part of your mod. If you have anyone on your existing team who can read basic C code, you could have them run through my source code to be sure that I haven't put anything malicious in there. It is definitely not going to be a very complicated program. I should have it ready in a few hours to a few days, depending on how many roadblocks I hit.
There is already a very old, graphical program that flips the LAA bit that someone else wrote... the problem with that one is you have to manually click through and pick the executable to convert, and it's bundled in its own "installer" because it has to install several legacy (OLD) libraries on your computer.
The executable I'm working on should be one small file that you can invoke from the command line, like this: bfdlaa.exe sins.exe
That will make it very easy to wrap the bfdlaa.exe call into an installer package. Creating an installer is pretty easy with NSIS, for example.
So if i understand you correctly which i doubt because some of what you said is still greek to me, because my forte is modeling, and texturing (free time ever willing). Not coding. That the leak in sins has nothing to do with anything other than the executable? Correct?
I was told that if a particular file calls for, and/or searches for something that doesnt exist that it will keep on searching for that non existant file until ether the program crashes, or till doomsday whichever comes first, and that could cause a memory leak due to the repeated cycles that the file is taking up searching for something that doesnt exist. Vanilla Sins has quite a few of those files by the way. Is that true, or nonsense? Because when we fixed the particles there was no longer a noticeable "steady" increase in ram usage, or it may have slowed down just enough to not be noticeable.
If the leak is in the executable then there is nothing we can do about it.
Like i said before if the laa enabler is the route you want to go then that is an option. Just be careful. My feeling still stands that you really shouldnt have to do that just to play a game.
This will all probably be a moot point a year or so from now when 64 bit totally takes over the market, and 32 bit is phased out, and no longer supported.
If IC is not involved with Elemental then i stand corrected. I thought they were. If they are not involved then what are they doing? Nobody has heard boo from them in a long time.
There are many great features available to you once you register, including:
Sign in or Create Account
