Don't have Stardock's sales figures or ICO logs. ICO log-ins especially is rather irrelevant. I'd guess total number of 1.1 patch downloads would be a good enough indication of how many are actively playing, if anything.

You and me, Kit! We can take 'em, eh? Superzombie Fox and an Assless Dude.  Where's Monk with his gun arsenal, though. And those rockin' shades, man..

I don't know He just disappeared.. haven't seen him post for a long time. So I felt it was my civic duty to pick up the slack as the Universal Flame Target. Working on that one..

Eet.

Very true, but it is an indication of your loyal fan base as online players will tend to spend a lot more gaming hours with a given product out of choice:

- they enjoy it (majority)

- they are addicted (small minority)

- they just want to cause problems and have nothing better to do  (very small minority, who probably didn't get any Christmas cards either)

Also a single player gamer who loves the game will naturally migrate to MP for the additional challenge and variety.

So these figures are important not least because it will be a telling sign for predicted growth and perhaps the more controversial questions of 'did the success of SoaSE hang off the success/expectations from the Homeworld series?' or relevent to any game 'did the media and presentation oversell the game?' hopefully one would see a growing community supporting the view 'SoaSE is a unique game leading the field of space themed titles'.

I don't know btw, neither am I taking sides here but I am supporting the arguement, arguement is healthy sometimes if it can steer a path to the point or some results. <-- sarcastic use of said smiley <-- getting silly now <-- aww dude stop <-- Medic !

Actually, with Entrenchment, on a huge multi star map,  all setting on very high, all graphic option on...with one player and 10 AI, after a little more of 15 hours gaming, the memory use is a little over the 10 gb ( crash appear only in the second day of game, when i am over the 12 gb )... of course, this result is made by using a unsupported OS who allow me to use multicore...

There is a leak but it is almost nothing... same when like in my case, texture are located in the graphic ram in place of the main ram, more that one hour is needed to reach the saturation... in my case, a CTRL-ALT-F1, followed by a CTRL-ALT-F7 will flush the leak... have not yet find a way to flush a leak in main memory but saving your game, stopping the game, reboot, and start the save game will help if you made it one time day ( lower the delay if you have not 16 gb ram like me )...

Again, limit in game have no reason to exist... with limit or without limit, the game will always work in the same way since memory used will be always the same... if a mod break the game, nobody will use the mod... it is the job of the mod to know what will be the minimum spec needed... can be something like : "Mod xxx, minimum 2.4 ghz dual core, min xp with /3g and /pae enable with 4gb ram"...

The real reason of limit is more related to the ease of coding... fixed size array are more simple to use/programm that dynamic size array... if sins use fixed size array ( who is very possible ), it mean that change them will need some major related to how the code is made and written... it mean almost remake a new engine...

Of course, it is possible to increase the array size... but vanilla sins will use the same array that a mod... meaning that the amount of disposal ram will be lower for a original game and that some low end system will not be able to use the game...

Dynamic array adapt the size in function of what is loaded... few content, few ram used... big content, a lot of ram used... seem great but they are more complexe to integrate in the code...

A easy method will be to use a 64 bits game... Stardock have already say that it is technicaly possible but they will not make it since it will lead to sync problem in online game... since sins is already broken with sync problem, i don't see how a 64 bits engine can break it more... maybe rethink from zero a new online code will be the best solution that a lot of patch who don't really change a lot...

What about these with processor who don't support 64 bits... first, 64 bits is from 2003... 6 years ago... very long time when related to computer technologie... maybe we need a pool for see how much user ( people who have pay for the game ) have a processor able to run a 64 bits OS... processor who can run in 64 bits mode are :

- Intel : Celeron D ( LGA775 socket, not the 478 socket ), Pentium 4 ( model from 2004 (Prescott ) and later ), Pentium D, Xeon, Core 2, and Core i7 processors

- AMD : Athlon 64, Opteron, Sempron, Turion 64 and Phenom processors

- VIA : Nano processors

Almost sure that the big majority of people have one of these processor... and 64 bits game engine will resolve a lot of the memory problem and allow more high limit...

crikey thats such a long post I'm gonna have to digest that over a large steak with a strong ale <-- doh!

kitkun neither you nor I represent the majority just discussing the point proves that, my assumptions are sound but it is complete speculation without the supporting evidence I'll not step into  'the paddock of swine'. SD and IC will know where they stand they ain't stupid.

About online, you are right... to much sync problem for online game, and ICO who is down several time month help this too...

He's basically saying that with or without the engine hard-codes, the base game would work the same, which is true. On a lot of things, Sins is below the limit (not counting minor things like number of weapons since capitals are at the limit ) So, as far as Sins is concerned, hardcodes or no it will run the same.

And that it's up to the mod maker to make sure their mod then works in that scenario. Which is also true (even now )

The rest is a distinction between fixed size arrays and dynamic arrays. Fixed are used when you know exactly how much of whatever you're going to have. It's a lot easier to work with them as far as coding is concerned. Dynamic arrays are made on the fly. The code doesn't know how much of what it needs memory for, so it figures it out when it's run and then it tries to allocate enough memory. Working with these is more complicated in the code.

For a game example, reading the GameInfo folder pretty much has to be done dynamically. There's a set amount of stuff in there for the base game, but when you put your own files it picks them up. So it basically goes through and allocates memory on the fly. Same thing with the strings file. The first line is for the number of strings, and it creates an array (assuming it's an array, anyway) for that number. That's why if the count is at 50, it'll create the array of 50 and stick the first 50 strings in there. The rest will either crash or not do anything, depending on the error checking in the code. So on, so forth..

I think in the programming world, though, it's generally considered to be poor form to leave your code prone to crashes. If they left it open, Sins would still work, but it would be a lot easier to break - and IC would take a lot of flak for having an 'unstable' game, which they would actually deserve because it really is their responsibility to make it as stable as possible and not crash regardless of what the user/modder does to it.

If Sins gets to 12 gigs of RAM use after any amount of time as Thoumsin said, then this tells me there's a serious problem in memory management for the game. I mean, you have apps like Z-Brush which need to have models nearing some eight million polygons to reach the 2GB cap on RAM... consider the amount of memory needed to store all the relevant information about a single polygon, including color, and I find it hard to believe a game can so easily top that, even on huge maps with max AI, unless there is a problem with flushing memory and/or keeping only relevant data in.

That said, it does not worry me as such. Very few people actually can enjoy huge games against max AI - not to say that many wouldn't want to, but I tried it and the game bogged down after a while. Just as long as trying to put in three extra factions doesn't hit a hardcode of some sort - to that end I fully agree that a list of hardcode limits would be very nice to have.

As for textures causing minidumps, as far as I know, video memory is used for storing texture data needed for the rendering process on screen. These textures are then purged from the video RAM when they're no longer needed. A simmilar process should be going on with system RAM, but with a greater range of stuff being kept loaded as to minimize stuttering. But RAM as such, if you have enough to actually load the executable and relevant libraries, should not be a problem since Windows can simply use the page file to supplement physical RAM if there's not enough (unless you go through the roof of even that, which is entirely possible if RAM usage goes to insane 12GB).

Ah well. I can always tell people to keep the map size and AI number down when playing. Just as long as I don't hit a hardcode limit with ships or something like that. Its somewhat stresfull not to know untill you hit the wall.

Entrenchment beta... not the normal game 1.12 ... mainly due to 150 and more planet spam with several thousand of mine... once the mine problem resolved, it will become better... sometime, reducing the planet detail from very high to high spare a lot of memory... or trying not to zoom the planet elevator at max help too ( sins texture use mipmapping, more you zoom, more detail meaning more memory )... or in the menu, choose for not show the cargoship... on a fully developed huge map, you have thousand of them...

Some people will say that a game like Crysis work good on their computer, that they don't understand why sins have difficult... First, managment in Crysis is mainly related to bullet... Sins have a lot of more thing to make... In crysis, you have a few ennemy who attack you, not 500 hundred like in sins ( a few carrier with their fighter/bomber make already a lot of object )... but the main difference... Crysis load the map by piece, sins need to have the full map... imagine a Crysis game where all episodes are loaded in the same time in memory ( map, textures, mesh, etc )... the best computer will run out of memory

For the little memory leak, it is not a problem on windows... DX cache the texture in the main ram... in case of Linux, opengl use 256 mb video ram ( yet, need more that the min of windows ) and use the remaining ( in my case 768-256 = 512 mb ) for cache ( buffers ) the texture... it allow a more fast rendering...

Now, the leak is not fully the fault of Stardock... by example, for Vista, a Microsoft patch was released some time ago who reduce greatly (but not suppress ) similar leak in game...some Vista people have report that the KBxxxx ( forget the nummer ) have reduce greatly the mini-dump in sins for huge long game... so, it is maybe a dx implementation who is at fault, on the microsoft side