Rebellion.. The Fourth, and Final Expansion for SotSE....
For all that do not know what TSOP is, or have not been keeping up with current events at all for the last four years. Check this topic. The Original TSOP for Trinity topic.
TSOP was originally created to fix the very annoying 2 gig hard coded crash bug that plagued Trinity. IT WORKED. Without changing any game play aspects of Sins. Without changing the quality of the game itself. During the time we worked on TSOP we found many bugs, and errors that the Dev's missed over time, or that were created with the relentless Sins patches of the past, and new expansions. With the Diplomacy 1.32-1.34 series of patches some elements of TSOP: Trinity were incorporated into Diplomacy. Mainly the Errors, Typo's, and Particle fix's. We are all human, and we all make mistakes. A company as small as Ironclad was bound to make some mistakes. Especially on their first game. I want to make it clear once again that this project in no way is a disrespect of Ironclad, or Stardock. Quite the opposite. You guys made a great game! There is no denying that. We wouldn't be here right now if you did make a bad game.
The goal of TSOP:R Is to add what was NOT incorporated from the Diplomacy TSOP incorporation. We will Bug Hunt, Look for errors, and typos that were not seen before, and Fix it. Just like we did for Trinity. We will convert the TGA formatted textures to the highest quality DDS format possible (This includes the UI textures). Just like we did for Trinity. We will try to put back into Rebellion what was taken out from Trinity (the varying planet types). We will also look into optimizing the new rebellion shadow system some more (if it is at all possible).
Rebellion reduced the size of the ship textures (mainly all of the frigates) to the next size down (by a power of 2). So frigates that had a 2048 resolution texture now have a 1024 resolution texture in Rebellion. Which is brilliant, It is hardly noticeable, and it made lots of room for more Rebellion features. TSOP:R will expand upon that, and bring back the "Strategic Particle Texture Reduction" of TSOP Trinity. There is much more we can do to optimize if we look for it. However, the goal is to optimize without changing the quality of the game, or if there is to be a loss of quality. make it as minimal as humanly possible. Just like we did for Trinity.
We also plan on bringing the Trinity versions of TSOP up to date.
All of this, and more that TSOP:R will do will free up more Ram, and improve your Graphic Performance. So you should be able to run Rebellion on a slightly lower end system, or a not so hot video card. CPU lag is still, and will always be a problem. We tried to deal with it by reducing poly counts on meshes in Trinity. That failed. Poly counts surprisingly have very little impact in Sins. It is the sheer number of units on the map that a Single Core of your CPU has to deal with that causes the lag. The only way i can think of to deal with the Late Game CPU Lag issue is to remove, and/or lower the number of units on the map. We WILL NOT do that. We WILL NOT change any game play, or balancing aspect of Rebellion. Just like we did not change it for Trinity. Let the developers deal with the Game Play, and Balance. We only wish to improve upon the game itself. We Bring..
The Sins Optimization Project: Rebellion
So.. Here we are once again..
TSOP for Rebellion is more of a Graphic Optimization mod than it was for Trinity. Many of the issues that plagued Trinity were fixed by Ironclad/Stardock for Rebellion. So there is no need for any GameInfo folders any more. Also the 2 gig crash issue that TSOP was originally created for has also been fixed. TSOP:R is more intended as a performance improvement mod than anything else.
TSOP, and TSOP:R is an open community project. Anyone who wishes to contribute is welcome to do so. Also anyone who wishes to use TSOP/TSOP:R in their mods, or other projects are also more than welcome to do so. No Questions Asked. This project is for you. Use it!
Do not run TSOP with other mods. TSOP is intended to be a Stand Alone mod. Running other mods with TSOP. Especially Graphic Enhancement mods. Will defeat the entire purpose of TSOP. TSOP is intended to improve your Vanilla Sins experience. Other mods like Distant Stars have incorporated elements of TSOP into their mods.
I will ask that we please DO NOT discuss Multi Core support, 64 bit, or LAA on this topic. It is a dead horse issue that has been beaten down so many times that people are beating the dust on the ground where the dead horse was laying. Its not gonna happen! EVER! The Dev's said its not gonna happen. DO NOT DISCUSS THE ISSUE!!... please.
TSOP:R Release 1.1
All mesh, and particle bad file path names fixed.
Mesh fix's (Unnecessary team color entry's removed)
GameInfo files fixed by Stardock/Ironclad so it is no longer needed in TSOP
All particle, and UI textures converted to DDS format. Some very large texture resolutions reduced.
Optimized Sounds, Music ported from TSOP Trinity.
Optimized Trade ship, Strike Craft, and Constructor meshes ported from TSOP Trinity.
Game holds steady at 1.6-1.7 gigs ram usage using Random Vast Competitive map. Max settings for everything. 9 vicious AI's Results may differ for you depending on your system. No Dev.exe errors were present. No crashes. Late game lag still an issue, but game is playable much longer than vanilla.
See various "Fixed" text's for complete list of changes, and fixes.
Thank you Myfist0 for ModDB link
Bad path names greatly effect performance, and memory usage in a bad way! It causes the game to go into endless search loops for file paths, and files that do not exist. While one, or 2 bad path names may not be a big hit. Imagine hundreds of files with bad path names. That was pre-1.32 Diplomacy. We corrected this issue in TSOP: Trinity, and it found its way into the latest Diplomacy patches. Seems like we have to check EVERY mesh, particle, brush, and damn near every file that can be opened with wordpad in the Rebellion reference files. Just to be sure. Which i am doing now as i type. I have a feeling some stuff got reverted back to pre-diplomacy 1.32
Also can use assistance in looking for typo's, and other oddity's in the reference files.
Need help checking the mesh files to make sure all of the mesh null's are named correctly. The number of nulls matches the actual number of mesh nulls the model has, and to make sure there are no bad file path names. (this issue "should" have already been fixed as of diplomacy 1.32, but you never know).
We need to make sure the manifests are correct. As in the number on top matches the number of lines in the manifest's. If they don't that can cause issues, and crashes.
We are not going to change anything in game play, or balance unless it is an absolute last resort. I agree that the SC are the biggest problem. The even bigger problem is "how do we deal with it?" We can reduce mesh, and texture size (we already did that with TSOP). However it wont help the cpu lag issue.
It's the SC individually and as squadrons checking for an interacting with other units that's the big issue. Short of cutting down SC numbers. It's hard to imagine many fixes for it.
I'd be interested to know how much benefit is gained in selecting "trails off" in-game and things like that myself.
Thanks so much Major Stress,, Zombie and MyFist0 (and everyone else involved) for the work done and the work being done to help the community here. Awesome!
Posting to keep tabs on this.
I don't know if anyone else noticed, but something in the last patch for me anyway caused me to suffer late game lag like I was playing Diplomacy, not sure what they have been tinkering with but I definately noticed a change??? Can anyone else confirm if they have noticed anything?
http://soase.x90x.net/tsop/
So far the suggestion is the total damage per squad is the same, and the total hull points per squad is also the same. The abilities should not be influenced at all. The only problem I predict is that not enough strike craft will be getting destroyed to compensate for the increased damage per ship.
Advent also gets a research modifier that adds 2 strike craft to each squad at the hangers.
Brings fighters from 9 to 11 ---> After Reduced from 6 to 8
Brings bombers from 7 to 9 ---> After Reduced from 5 to 7
Stress, you really need Notepad++ for doing this. I repaired all the bad links in the particle folder in about 15 minsI replaced all the brush links at oncelooked through a list of every meshpoint in about 2 mins
sadly, I dont own rebellion and way to busy doing SOA half scale. Every model is getting a proper tangent map and optimized. Fixing bad faces on a few. Total rebuild of a few. Contact psy if you want access to our SOA-XSI project over SVN.
EDIT: Thanks to psy for installing a trial of softimage and redoing all the meshpoints for almost all the models. He knows whats what.
And I did not realize I had moved to greener pastures . I guess I can stop modding SOA and stop adding to the new soase.x90x.net
Generally speaking, larger units should have less HP per "supply" than smaller units...this applies to both frigates and SC...
For example, a vasari bomber squadron (3 SC) totals 420 HP, a TEC bomber squadron (5 SC) totals 500 HP, and an Advent bomber squadron (7 SC) totals 525 SC...as you can see, the smaller/more numerous the SC in a squadron are, the more total HP they have...
A reduction of the # of SC per squadron must be accompanied with a reduction in the total HP...if you simply keep the total HP the same, then you will be giving a massive buff to strikecraft...
Maintaining the same DPS per squadron is fine....
I think the simplest place to start for strikecraft is to reduce the individual fighter counts and increase their individual hulls and damage counts by the amount lost. Play it a bit like that and see how it goes. Theoretically it should be pretty close to the same effect.
The primary difference is that as you down individual SC in a squad normally, their fire power is reduced--so you in effect reduce their damage by hurting them--that would be lost in a "single fighter" conversion (unless someone has a genius ability in mind for the squad host?).
If someone wants to set up a SC test mod, I'll run it a lot and see how it goes or I can do it myself when I get...darn...time (don't hold your breath).
It would be better if we all started from a baseline and compared rather than everyone just doing their own thing..
Something to try:
This would reduce fighter squadrons by more than half on average and buffs that normally add strike craft to the mix could be factored to decrease weapons cool down rates or increase damage as well as armor.
What I am wondering though: is there that much of a difference in the engine tracking one fighter in a squad as opposed to two or three? Is it the squad itself taking the primary cpu cycles or the size of the squad?
I know from playing with both SC and mines with ranged AoE abilities that the speed and maneuver of them while calculating an area effect is a big bottleneck.
A way this might be approached is to consider the equivalent of a SC "sprint" ability activated by the hosting ship to allow for crucial intercepts and first engagement but otherwise radically slow down SC in unagumented combat.
I noted on corvettes that initially they were squirrely little things running al over and gradually they were turned down. What I notice now is both corvettes and SC "hang" after hitting or destroying a unit and then all start up again a second or two later--whereas before they just kept swooping and went immediately to the next target.
I don't like the behavior but I can guess the devs put in a pause so all the SC and corvettes could get caught up without lagging everything else?
So optimally, slower SC, single fighter squadrons, buffs and stat adjustments to compensate.
Thoughts?
@ Sele:Thats what's in the SC reduction DL. If you want to make a new one or edit the existing, be my guest.
@Selucia
You can play with increased firepower and proportionately less hull damage but it will take some prolonged experimenting to actually balance that. In that scenario, losing your SC costs you all your damage in one shot--which is farther away from the base game.
It is harder to use abilities to balance Advent squadrons on the Halcyon since it can be so variable. Incremental increases to the squad would have to be worked out.
It also leads back to the other question: Is it the strike craft individually or the squadrons themselves eating up most of the cpu?
Has anyone mass tested to see how much it helps?
Small ship squads in SOA2 did little to impact performance. They still tag you with the full brunt of the UI overhead in the empire tree, but combat performance goes way up as you reduce their numbers.
"Combat Performance"?
You mean lag or effectiveness/maneuver?
Think he means performance as far as lag. No doubt any reduction in SC numbers will help the lag issue.
UI issue is a simple fix, but it will be tedious to do. Convert the UI from TGA to DDS. Merge the multiple UI textures (that represent the same damn thing) into one single sheet. Including the textures where only 5% of a huge ass space is being used. We now know how to make a new UI. So this shouldn't be too much of a problem.
The UI icons (empire tree, and map) themselves do not make too much of a hit. They only use one texture for all icons as far as i can remember (its been a while), but ill look at this again to be sure. If not then they can be merged into a more efficient format.
Dont worry about reducing numbers of units right now. We will get to that later if it needs it.
Cool--I'll leave the brain stuff to you.
In the meanwhile I am going to mod some 100 squadron each scout-carriers and try some experimenting.
I really hope we do not need to touch this. The consensus with the original TSOP was that if we start actually changing game play values it becomes less likely to be used and adopted by the community, especially in multi-player. Many players like the vanilla game as it is and just want an performance boost, not have the gameplay itself change, especially if this is to be adopted into other mods more readily.
Yeah--the SC are one of the funnest parts. Nothing like a massive "Swarm!". Sadly, they are the most problem too.
I'm all for the Major's mojo finding savings first.
The perfect solution would be hardware. We need a pci compatible SCPU.
We need multi-core... Ah crap! I just opened Pandoras box... Nobody saw this post
stress, we REALLY NEED a NEW engine for the game, that has 64 bit (and can use at least 16gb of ram), multicore, AND texture/mesh offload to gpu so that the poor cpu multicore 64bit just has to track the location of all the ships/sc/structures/effects/weapons without dropping them.
harpo
NOOOOOOOOOOOOOOO!!!!! The particles were reverted back to pre-Diplomacy 1.32!!!!!!!!!!!! So the TSOP fix's that made it into Diplomacy are NOT in Rebellion! All of the old bad file path names are back! HUNDREDS of them! NOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!!!!!!!!
Looks like its time to do someones job for them....
We all need to get paid, Major
Every time i try to get out... It pulls me right back in!
I wish i seen this stuff in the beta, but i didnt have time to convert data every patch, and search every file.. Not that i need to search much because EVERY particle file has a bad file path name in it. I am almost counting on seeing paths that point to textures that dont exist, or are labeled TGA. When in fact the texture is DDS.. Just like pre-diplomacy 1.32/TSOP fix.... i feel a migraine coming.
Good news is at least the mesh's themselves arent that messed up. Some odditys in them that i need to find out why they are there.
Modding, you can check out whenever you like, but you can never leave...
Anyways, back to optimizations. I don't have as much data or have done much testing, so feel free to disregard me, but it seems like everyone has been missing another potential source for Optimization. Abilities.
While I doubt most lag is even remotely caused by abilities and buffs, anyone who has ever made a passive ability for a common unit and left the buff at "PrioritizeNewBuffs" can tell you, it can sure kill your frame rate if you do it wrong. So far I haven't seen any abilities do something wrong on that magnitude, but I think some could be quite a bit more efficient while doing the exact same thing they do now, mainly older ones that haven't been updated to use the new stuff they add in each expansion, most notably the new conditions we got in Rebellion.
For example, take the TEC Shield generator structure. This absolutely hate this ability, its so terribly written its a good thing they're not worth building, otherwise it might have caused more issues. Basically what it does is apply a buff to itself that then constantly tries to apply a periodic action every second to the local planet in case its player owned, regardless if the planet already has the buff or not. Also both buffs will end if the owner no longer has the labs for the structure, which is redundant since the planet buff will end if the shield generator buff is lost, though I'm not sure if additional finish condition checks hurt performance.
While not as bad as creating hundreds of new buffs a second, from my experience periodic actions are much more intensive than instant actions, and if you have lots of them going at once it can degrade performance. If you can possibly write an ability to intelligently use instant actions to do the exact same thing, I believe (not that I have any proof of it) that instant actions are much less intensive, as after they apply you can usually get rid of the buffs that have them. In general the only times I've seen where infinite periodic actions are absolutely needed are on passive area of effect abilities like targeting uplink or in cases where you want to simulate a weapon that can fire on multiple targets.
As a proof of concept, I have rewritten the TEC shield generator ability to use only instant actions, preventing the needed for it to apply a periodic action every second. To do this I had to make it an active ability rather than passive (this can be better since the ability can automatically only apply when they have a target available, rather than constantly trying to apply a buff via a periodic action), and create an additional buff file (which may increase RAM usage very slightly, but this buff only applies the other two buffs simultaneously then completely disappears). The end result is that you get a planet that's shielded and the buffs cancel themselves exactly like the original would, but there is no periodic action every single second checking if the buff went missing.
Note I made this for my mod and the shield is 20% more effective at all levels if you want to include this. If anyone wants to do some testing to see if this actually makes much difference even better.
Dropbox
Don't know if anyone has realized but late game lag seems to be linked with the mass debris fields From all the battles. I only get it during and after battles.
I have gotten rid of the lag using the orkulas star base by sucking the debris into it. Think of how many battles are going on late game i think the debris could have something to do with the late game lag
Debris does disappear eventually though.
Sure, after about 5 minutes game time right? So thats probably....idk....half an hour real time?
There are many great features available to you once you register, including:
Sign in or Create Account
