Who wants to be the first to tell him about the multicore/x64 issue?  I don't feel like beating the dead horse again.

On a side note, an easy way of getting better lag out of the game is to reduce the fleet cap., play smaller maps, and direct connecting seems to help (bypassing ICO).

Also, the core maximizer for SC/FA works by separating the threading of the game to different cores.  I don't see how it'll work with this.

/thread.

Edit:  I'll run this by my LAN group when we go to (hopefully) wrap up our game this weekend.  I gotta give them mod updates, anyway.  If it helps out the game on any level, we'll see it then (it'll be running across 3 computers).

Also, is your EXE LBAA flagged?  That'll help out while playing on larger maps.

Are you referring to Large Address Aware? I was going to try that this evening. Due to it fixing the crash, albeit it would be nice if it would expand the hard coded amount to 3 gigs.

Seriously my system was god tier as of last year... it's entirely frustrating to have performance problems because the game was designed to operate above the limits hard coded into its engine.

I mean the first thing I did when I got this game is decide the fleets were too small and expand the game's fleet sizes to twice their normal size.... (I realize this is part of my problem, but I could not help myself)

And of that 4 mil, let's say SD get's half.  That leaves 2mil to support the dozen or so people at IC for their past year of work plus the time/money it'll take to finish Sins of a Dark Age.

EDIT: Oh, and don't forget Steam's share.

I'm known for making them.

It wasn't so much to have the "epic fleet" it was to support more capital ships. Additionally to allow for multiple fleets functioning in multiple theaters at the same time.

I also doubled the effectiveness of counter damage types aka how effective anti heavy is vs heavy armor and so on and so forth. I thought that the actual engagements took too long, we're talking futuristic ordinance here, a frigate should not be able to withstand direct hits from capital ship weaponry that is nearly the size of the craft it is hitting.

TaleWorlds

Why is it I mod everything I touch?

Perhaps that's why I will never be a console jockey.

I'm going to do some tweaking tonight. We'll see how it goes.

Edits: knocking the fleet sizes back to 100%, halving the supply cost of capital ships, toggling LAA. Eating a sammich.

To be fair major, it should have been tweaked in the fashion your mod depicts before its release.

I'm testing now with the LAA and the core balancer utility running. seems to be running fine. This is after decreasing my fleet sizes back to 1.25

There again, that's standard for most people so that should be well within the acceptable limits of the game the way it was intended to be played yes?

I'm not here to troll. I know there's already enough of that. I honestly looked through at least 10 threads on similar issues before posting. The only reason I bothered to register and post was because I thought I had a potential help for the issues people were facing.

On a side note though... maps that support 150+ planets 10+ players, game engine realistically capable of 6 players on 60 planets = wtf?

That's like saying "The titans are an optional feature, just because they put it in the game does not mean you need to build one."

It's true that you don't have to play with 9 AI. However, it's a functionality which is present, and based on it's availability, should work properly. 

Performance should be limited by hardware, not code. I'm not even referring to the cpu usage of the process here, it never goes above 70% on the core that I'm sticking it on.

On that note, The alterations I've made seem to make the game slightly more... manageable? I believe this is mostly due to the LAA as the game still slows to a snail's pace at ~1.9 gigs of memory usage.

It is hard to talk about this without being augmentative. I'm not trying to haze you brah. In fact I'm not even arguing. There's nothing to argue. The game functions, sub par. Which sucks because it's an awesome game...

I don't think anyone is trying to bash anyone here. I am skeptical too, because for the last four years we have been trying to deal with the late game lag problem, and failing each, and every time. TSOP helped, but it only helped a little bit. TSOP deals with the optimization issues more on a Graphics level than a CPU level. Though we found issues that can cause CPU lag while working on the project.

I guess the bottom line is "Does this program work?" Does it make Sins use more than one core of your system? If it doesn't then nothing is solved. Because the cause of the late game lag is that sins runs everything on ONE core of your CPU. If Sins was multicore compatible, then we wouldnt even be having this discussion. Sins wouldnt have the late game lag problems, or at least not to the extent it has now.

Major my testing indicates exactly what you've been suggesting LAA is not an answer. Neither is specifying core affinity. These problems are inherent due to the application attempting to run too much at once inside of it's own prescribed constraints. 

Which leads me to my next question. How can I help your progress? (Edit, deleted superfluous crap.)

I have been reading this thread in its entirety but had refrained from responding to you up until that point.

Regarding your "solutions," you had been saying that you were testing them and they seemed to be helping.  People have tried many of those same things before and the results yielded zilch improvement, so someone coming in saying that things were suddenly better for them gets a bit on my nerves.

Regarding your "because it can, it should do it well" idea..

A game I'm a developer for has a weapon in it called the mortar which is also the most powerful gun in the game, instagibbing light units and can only be carried on heavies.  Because of the nature of the gun, it can cause lag in certain situations.  Now, the game has unlocked classes so everyone can theoretically play as the heavy with the mortar at the same time.  If they did and they fired even vaguely at the same time, there would be unplayable lag for an extended period and depending on the server, they could crash the game altogether.  Players could do that but don't because everyone carting around mortars simply isn't fun (and neither is a laggy or crashed game).  I wouldn't call our game sub-par because of that issue with the mortar.

I never said anyone was hazing.  You said that you weren't trying to haze Xathos so I responded by saying that if anyone needed hazing (which in this case means getting told that optimizing Sins of a Solar Empire is incredibly difficult and many before you have tried and failed with the exception of TSOP), it was you.

Late-game performance is a dead horse that has been beaten for years.  The only real solution to it would be to..

a.) decompile the code, translate it back into a readable format instead of things such as function1_3(int var1, double* var2){} and then proceed to manually make it 64bit and multithreaded.  This is absurdly time consuming, is an EULA violation, and probably is illegal (though I'm not sure).

b.) ask the devs nicely for the source code of the game and the Iron Engine.  I doubt they'd give it to us.  It would take a very long time but eventually someone would have a multi-threaded version of the game out and it would be very widely used by the playerbase.

c.) use TSOP:R and suck it up for the remaining problems

C is the only realistic action here.  The game has limitations.  It is limited by two things, one of which is software and one is hardware (but could be fixed via a software change).

1. 2 Gig Limit: this is the source of late-game minidumps because the game exceeds its ability to maintain addresses and fails.  This has been largely remedied by the devs and TSOP by reducing memory requirements, particularly of the art elements.
2. Single-threading: because the game is written as a single thread, it cannot deal with late-game unit masses.  It never will unless A or B above happen.  The result is lag.

So, honestly and quite frankly, yes, you need to "adjust to its limitations."  You can tweak a few things like the TSOP is doing, but trying to run it through something else first to try to make everything all wonderful isn't going to work.  People have tried; people have failed.

I'm sorry for the outburst in my prior post, but in all honesty, this is a dead horse and I'm just getting sick of these threads.

I'm sure that any Sins II would be multi-threaded, but it would never be done by the dev team for Sins I.

Wait, XATHOS, where did you hear that Sins 2 was in early development? This is great news, but I wasn't expecting them to finish Sins 1 and then jump straight on to Sins 2 without at least a year or two of break for other games (Sins of a Dark Age, Galactic Civilizations III).

I wouldn't put too much weight on it if it was just mentioned in passing. Unless Ironclad makes an official announcement for Sins 2 don't hold your breath. Rebellion is still young despite the dated engine. Ironclad needs to finish what they got on their plate first (Sins of a Dark Age). Before diving into any kind of Sins sequel. AFAIK Ironclad is still the very same dev team that developed Original Sins. Minus one modeler. FYI Ironclad has former members of Barking Dog studios (can you guess what they made? Give you a hint. It was a space RTS back in 2000).

We don't need any conflict here. Guys find a way to give it a rest.