[HOWTO - RAMDRIVE] Increasing SWTOR System Performance

[MartinSPT]

Prefetch gets disabled per default when Windows 7 is running on a SSD that minimum meets preset requirements.

Prefetch isn't that good caching technology when it comes to large game files either.

 

http://blogs.msdn.com/b/e7/archive/2009/05/05/support-and-q-a-for-solid-state-drives-and.aspx

 

Ok, both of these are incorrect.

 

1) When Windows 7 original shipped, prefetch, superfetch, readyboost were turned off on the 'faster' SSD installations. However since then, Microsoft's data has shown this was a mistake, especially for large files on SSD. Windows 7 should NO longer turn off SuperFetch, and if it off on your system, you need to turn it back on. (There were only a few high end server class SSD Raid configurations that do not get a considerable performance boost from Superfetch.) Go look up Microsoft Superfetch SSD, you should be able to find both the Microsoft released information on the performance data and I think there are a few articles from NT developers like Mark R. and maybe an interview stalking about this in detail.

 

2) Large Files, still benefit from Superfetch, as it uses byte level pre-caching technology, not FILE level caching technology, and it also does this on files that are very dynamic and changing like a large 20GB Outlook PST. Without Superfetch, loading a 20GB PST in Outlook can take a minute or so, with Superfetch, Outlook will start in a second or two. On program files it is even easier for Superfetch, as it doesn't have to track the byte location in the file to cache. So gaming files DO get a nice boost from Superfetch, especially if the game has anything that is 'predictable' that Superfetch can use in addition to its 'guesstimation' of what to cache into RAM next.

 

3) People often confuse Superfetch and Prefetch, however, they are two different technologies. Prefetch data is used for Defrag 'file placement' information for fastest linear reads, and also how an Application loads to initiate loading support files before the Application asks for them. Prefetch is the information stored in the Windows folder with all the .pf extensions, and Superfetch doesn't need these and works to utilize RAM by loading it with known things the user will be doing and guesses at what the user will be doing. It can do this because of changes in how Vista/Win7's I/O technologies work and the new memory priority flag/techniques, so that it is never stepping on an applications need for RAM and it is never saturating the I/O process. To fully explain would also require fully explaining how Vista/Win7 works versus XP and versus other OS technologies like Linux or OS X.

(For example how I/O travels is significantly different, no longer is there a fixed I/O request size, etc. DMA technologies are completely different, for general I/O and the new video model, where the offset new DMA concept came from the XBox 360 GPU design team. And on and on and on.)

 

 

 

 

Regarding this game though, and the engine specifically, which in many ways is brilliant, the file stage caching is INSANE.

 

If this game was running from a DVD and didn't have an OS that would cache it, then the Stage cache would make sense. If this game was designed for Linux or OS X, then the Stage cache would make sense. However this was designed for Windows, and even XP users lose performance with a Stage cache, that is reading and writing data usually on the same volume at the same time, making it really slow on loading.

 

This stage cache model also creates problems when 'unanticipated' content has to be referenced, as the client as to 'move to a new operation mode' to request the asset information, use it and move around or remove other data from the stage cache. This means that if you are on a large Planet like Tatoonie, and new players get in 'range' the game client stutters, loses FPS and often response time as well while changing modes to get the assets to draw the 'clothing' and other textures not in the Stage cache.

 

This is even Worse on SSD, because the constant writing that happens during a stage cache load, reduces the SSD lifespan faster than normal.

 

 

 

So what the game is doing is slow for everyone, taking life away from SSD users, and is trying to reinvent a cache model that Windows already does and will handle far better than the game itself will.

 

Windows is handling all of this at several levels, that go to the heart of the kernel memory management all the way to the application layer and computes a mind numbing number of variables from I/O saturation, memory prioritization, device speed, other application requests and priorities, driver level needs for I/O, ways to use I/O in different methods to offload collision, and on and on and on...

 

There is NO reason an application or game should be trying to do this themselves on Windows. With the emphasis on 'Windows' as this is the type of stuff a game developer would use on a PS3 or Linux or OS X as it would help performance. However, even on XBox game developers are discouraged from implementing their own caching and doing crap like this game is doing.

 

 

-----

 

Any SSD user, Go look up the SSD Superfetch information, and turn it back on if Windows 7 hasn't already turned it back on for you. (Prefetch, you probably want to leave off, as everything it is doing is mostly irrelevant to SSD, and is extra writes that the SSD doesn't need limiting its lifespan.)

[MartinSPT]

Additional Tip-Option...

 

For users that doesn't have a lot of RAM to create a RAM Drive but do have a second hard drive.

 

If you have a 'second' physical hard drive (not just a separate partition/volume), you can install the game to the second drive (the one that your \Users\ folder is not on).

 

This will result in a almost as large increase in performance.

 

Reason...

When the game is creating its Cache file in your User folder, it is reading from the same drive as it is writing, which on both traditional and SSD technology cannot happen at the same time. So it is reading info, writing info, reading info, writing info etc.

 

When the game is on a separate drive, one drive can be reading the information while the other drive is writing the information at the same time. So this makes loading at least twice as fast, and will result in less hesitation when the game is loading additional information, for example when you encounter other players in the game.

 

 

It is not quite as fast as the RAMDrive solution and requires two hard drives in your system, but it is another option.

[recsa]

just subbing for later review

[Lemon_King]

when doing the

 

mklink "<SWTOR Install Location>\Star Wars-The Old Republic\SWTOR\DiskCacheArena" "T:\DiskCacheArena"

 

it says i do not have the right to do so allthough im looged in as admin.

 

any advice?

 

thanks in advance

Make sure when you've opened the command prompt with admin privileges, and that you've replaced <SWTOR Install Location> with the location for SWTOR>

 

 

@MartinSPT: Dude, chill out a bit.

DiskCacheArena isn't a standard cache file, its closer to a VHD considering it has its own file system.

Edited February 5, 2012 by Lemon_King

[Montanaa]

fraid it didnt work out for me :/

 

same fps problem as befor

Edited February 5, 2012 by Montanaa

[Carousel_t]

Why this is going to fail:

 

Some of you got all technical and stuff, but you are forgetting one fundamental thing: the game is still writing/reading from the hard drive, meaning, it has to go all over the communication process. And where SSD shine, combination of hdd and ramdrive will fail.

 

I've seen someone saying, even two hdds are gonna make a difference - sir, you are simply wrong. The game isn't writing just because it likes to do it. No, it's writing to read it in the future. What you are doing, by linking two drives, is making the path from one hdd sector to another, a whole lot larger and more complicated.

 

While using one hdd, those sectors on a hdd, of cache file, are very narrow, so the hdd will have a short path between them.

 

When using two drives, you essentialy, are reading, communicating, and then writing and then communicating back, while with only one hdd, you are using simple read/write functions.

 

It would be a fine idea if those hdds were good at multitasking, but they aren't. Each operation is really just one big process divided in groups.

 

Think about a writer and a single book situation. If there's one writer, he writes and changes pages without having to stand up. If there are two, one writes, stands up, another one sits down, changes page, stands up to make room for the first one to sit down and write another page.

 

Again, this is a viable solution BUT if all of your game was on a ramdrive, and even then, your game would have to communicate with dx files so it wouldnt be as fast as you wish it to be.

 

My conclusion on this matter - either buy a SSD or don't bother.

 

Honestly, I've tried it, it doesn't help with anything on my end.

[IhaveNoGod]

Why this is going to fail:

 

Some of you got all technical and stuff, but you are forgetting one fundamental thing: the game is still writing/reading from the hard drive, meaning, it has to go all over the communication process. And where SSD shine, combination of hdd and ramdrive will fail.

 

I've seen someone saying, even two hdds are gonna make a difference - sir, you are simply wrong. The game isn't writing just because it likes to do it. No, it's writing to read it in the future. What you are doing, by linking two drives, is making the path from one hdd sector to another, a whole lot larger and more complicated.

 

While using one hdd, those sectors on a hdd, of cache file, are very narrow, so the hdd will have a short path between them.

 

When using two drives, you essentialy, are reading, communicating, and then writing and then communicating back, while with only one hdd, you are using simple read/write functions.

 

It would be a fine idea if those hdds were good at multitasking, but they aren't. Each operation is really just one big process divided in groups.

 

Think about a writer and a single book situation. If there's one writer, he writes and changes pages without having to stand up. If there are two, one writes, stands up, another one sits down, changes page, stands up to make room for the first one to sit down and write another page.

 

Again, this is a viable solution BUT if all of your game was on a ramdrive, and even then, your game would have to communicate with dx files so it wouldnt be as fast as you wish it to be.

 

My conclusion on this matter - either buy a SSD or don't bother.

 

Honestly, I've tried it, it doesn't help with anything on my end.

 

Probably that is why my SWTOR still Stuttering.

Edited February 6, 2012 by IhaveNoGod

[Lemon_King]

fraid it didnt work out for me :/

 

same fps problem as befor

 

This doesn't magically fix FPS issues, thats another ballpark. This works around underlying issues with HDD Cache speeds for loading worlds and/or objects/dynamic character models & textres (atlas).

 

Why this is going to fail:

 

Some of you got all technical and stuff, but you are forgetting one fundamental thing: the game is still writing/reading from the hard drive, meaning, it has to go all over the communication process. And where SSD shine, combination of hdd and ramdrive will fail.

 

I've seen someone saying, even two hdds are gonna make a difference - sir, you are simply wrong. The game isn't writing just because it likes to do it. No, it's writing to read it in the future. What you are doing, by linking two drives, is making the path from one hdd sector to another, a whole lot larger and more complicated.

 

While using one hdd, those sectors on a hdd, of cache file, are very narrow, so the hdd will have a short path between them.

 

When using two drives, you essentialy, are reading, communicating, and then writing and then communicating back, while with only one hdd, you are using simple read/write functions.

 

It would be a fine idea if those hdds were good at multitasking, but they aren't. Each operation is really just one big process divided in groups.

 

Think about a writer and a single book situation. If there's one writer, he writes and changes pages without having to stand up. If there are two, one writes, stands up, another one sits down, changes page, stands up to make room for the first one to sit down and write another page.

 

Again, this is a viable solution BUT if all of your game was on a ramdrive, and even then, your game would have to communicate with dx files so it wouldnt be as fast as you wish it to be.

 

My conclusion on this matter - either buy a SSD or don't bother.

 

Honestly, I've tried it, it doesn't help with anything on my end.

Full stop, I'm running the game on an SSD (Asset Files with Executable) with all the cache files in the RamDrive.

DX Files are loaded into system memory at runtime so it doesn't have to reload those files during gameplay if for some reason they are not already loaded. (Seriously go read up on API programming for game engines)

Third, go back and read what you're saying. Its like you've never worked with hardware & software before.

 

Lastly, your Pentium C2D E5200 is your biggest problem.

Edited February 6, 2012 by Lemon_King

[mrkitethreeeight]

Full stop, I'm running the game on an SSD (Asset Files with Executable) with all the cache files in the RamDrive.

DX Files are loaded into system memory at runtime so it doesn't have to reload those files during gameplay if for some reason they are not already loaded. (Seriously go read up on API programming for game engines)

Third, go back and read what you're saying. Its like you've never worked with hardware & software before.

 

Lastly, your Pentium C2D E5200 is your biggest problem.

 

 

Thank you, I didn't know how I was going to respond to that drivel without my head exploding.

 

@MartinSPT,

 

I think we've agreed that simply having a 64-bit game client would go a long way toward addressing some of the game / engine shortcomings. You raise some interesting points re: Superfetch, specifically, but I think you're right to say that the non-predictable nature of the cache files will greatly reduce, if not negate, the benefit Superfetch might give.

Edited February 6, 2012 by mrkitethreeeight

[Mineria]

Ok, both of these are incorrect.

 

1) When Windows 7 original shipped, prefetch, superfetch, readyboost were turned off on the 'faster' SSD installations. However since then, Microsoft's data has shown this was a mistake, especially for large files on SSD. Windows 7 should NO longer turn off SuperFetch, and if it off on your system, you need to turn it back on. (There were only a few high end server class SSD Raid configurations that do not get a considerable performance boost from Superfetch.) Go look up Microsoft Superfetch SSD, you should be able to find both the Microsoft released information on the performance data and I think there are a few articles from NT developers like Mark R. and maybe an interview stalking about this in detail.

 

2) Large Files, still benefit from Superfetch, as it uses byte level pre-caching technology, not FILE level caching technology, and it also does this on files that are very dynamic and changing like a large 20GB Outlook PST. Without Superfetch, loading a 20GB PST in Outlook can take a minute or so, with Superfetch, Outlook will start in a second or two. On program files it is even easier for Superfetch, as it doesn't have to track the byte location in the file to cache. So gaming files DO get a nice boost from Superfetch, especially if the game has anything that is 'predictable' that Superfetch can use in addition to its 'guesstimation' of what to cache into RAM next.

 

3) People often confuse Superfetch and Prefetch, however, they are two different technologies. Prefetch data is used for Defrag 'file placement' information for fastest linear reads, and also how an Application loads to initiate loading support files before the Application asks for them. Prefetch is the information stored in the Windows folder with all the .pf extensions, and Superfetch doesn't need these and works to utilize RAM by loading it with known things the user will be doing and guesses at what the user will be doing. It can do this because of changes in how Vista/Win7's I/O technologies work and the new memory priority flag/techniques, so that it is never stepping on an applications need for RAM and it is never saturating the I/O process. To fully explain would also require fully explaining how Vista/Win7 works versus XP and versus other OS technologies like Linux or OS X.

(For example how I/O travels is significantly different, no longer is there a fixed I/O request size, etc. DMA technologies are completely different, for general I/O and the new video model, where the offset new DMA concept came from the XBox 360 GPU design team. And on and on and on.)

 

 

 

 

Regarding this game though, and the engine specifically, which in many ways is brilliant, the file stage caching is INSANE.

 

If this game was running from a DVD and didn't have an OS that would cache it, then the Stage cache would make sense. If this game was designed for Linux or OS X, then the Stage cache would make sense. However this was designed for Windows, and even XP users lose performance with a Stage cache, that is reading and writing data usually on the same volume at the same time, making it really slow on loading.

 

This stage cache model also creates problems when 'unanticipated' content has to be referenced, as the client as to 'move to a new operation mode' to request the asset information, use it and move around or remove other data from the stage cache. This means that if you are on a large Planet like Tatoonie, and new players get in 'range' the game client stutters, loses FPS and often response time as well while changing modes to get the assets to draw the 'clothing' and other textures not in the Stage cache.

 

This is even Worse on SSD, because the constant writing that happens during a stage cache load, reduces the SSD lifespan faster than normal.

 

 

 

So what the game is doing is slow for everyone, taking life away from SSD users, and is trying to reinvent a cache model that Windows already does and will handle far better than the game itself will.

 

Windows is handling all of this at several levels, that go to the heart of the kernel memory management all the way to the application layer and computes a mind numbing number of variables from I/O saturation, memory prioritization, device speed, other application requests and priorities, driver level needs for I/O, ways to use I/O in different methods to offload collision, and on and on and on...

 

There is NO reason an application or game should be trying to do this themselves on Windows. With the emphasis on 'Windows' as this is the type of stuff a game developer would use on a PS3 or Linux or OS X as it would help performance. However, even on XBox game developers are discouraged from implementing their own caching and doing crap like this game is doing.

 

 

-----

 

Any SSD user, Go look up the SSD Superfetch information, and turn it back on if Windows 7 hasn't already turned it back on for you. (Prefetch, you probably want to leave off, as everything it is doing is mostly irrelevant to SSD, and is extra writes that the SSD doesn't need limiting its lifespan.)

Using Windows fetching methods (Superfetch included) does in no way improve the game loading times, tried it against other games too.

Also, my OS reacts a lot faster without.

 

I'm curious to see the official post from MS that states that Superfetch should be enabled with fast SSD's, so please post a link to that.

 

I got another link here supporting my statement, beside the official one I posted earlier

 

http://www.ocztechnologyforum.com/forum/showthread.php?63273-*-Windows-7-Ultimate-Tweaks-amp-Utilities-*

Edited February 6, 2012 by Mineria

[skarr_tor]

Will this also decrease the loading times when you zone ?

 

I have no performance issues when playing, but the loading times on the later planets is ridiculous.

 

edited for typo

Edited February 6, 2012 by skarr_tor

[Montanaa]

This doesn't magically fix FPS issues, thats another ballpark. This works around underlying issues with HDD Cache speeds for loading worlds and/or objects/dynamic character models & textres (atlas).

 

I wish. But it didnt change anything. The loading times are still a blast.

 

Thanks anyways

[Mineria]

Will this also increase the loading times when you zone ?

 

I have no performance issues when playing, but the loading times on the later planets is ridiculous.

 

Yes, that is what the caching is all about, decreasing the load time.

It will not magically increase fps or other things, but it will give a significant boost when loading.

Note, you will need enough ram on your system to avoid paging as well.

IF you run a 32bit OS and for some odd reason got way more RAM than the OS can handle, imdisk can be used to utilize that extra RAM too.

In which case it helps to assign some of it as a RAM drive for the paging file.

In such case it is a good idea to check memory utilization to determine how much one needs.

[recsa]

When i started playing SWTOR i had terrible FPS in wz, fleet, and mostly any place with a medium population, then i lurked the forums for fixing and went for cheap improvements, switched from 32bits to 64bits, increased RAM from 4GB to 6GB and upgraded my CPU from 2 cores to 4 cores.

 

Now i have almost no problem on fleet and wz, i have even improved my loading times, but theres a place where my system says "no, thats too much" and my FPS drops to 2-3, that's ilum when zerging the Republic base, looks like 60 ppl is too much for my system (although it is capable of many more in-screen ppl in the other infamous game).

 

Would this "fix" help me improve my FPS on zergs? or i need evn more CPU? im pretty sure its not GPU issue, since even on those 60 ppl zergs my GPU seems to be working below its maximun, i have the feeling that game rendering is more CPU based than GPU.

[Mineria]

When i started playing SWTOR i had terrible FPS in wz, fleet, and mostly any place with a medium population, then i lurked the forums for fixing and went for cheap improvements, switched from 32bits to 64bits, increased RAM from 4GB to 6GB and upgraded my CPU from 2 cores to 4 cores.

 

Now i have almost no problem on fleet and wz, i have even improved my loading times, but theres a place where my system says "no, thats too much" and my FPS drops to 2-3, that's ilum when zerging the Republic base, looks like 60 ppl is too much for my system (although it is capable of many more in-screen ppl in the other infamous game).

 

Would this "fix" help me improve my FPS on zergs? or i need evn more CPU? im pretty sure its not GPU issue, since even on those 60 ppl zergs my GPU seems to be working below its maximun, i have the feeling that game rendering is more CPU based than GPU.

 

No, you will not gain a fps increase.

Only solution to fix fps drops is on BW's hands.

I recently startet on a server with 150+ people on the fleet, and noticed a significent drop in fps compared to what I came from (60 people on the fleet)

All those characters are not even in visual view, so something is completely messed up in the game code.

Last mmo I remember such drops in was WAR with several hundred players in visual view.

Poorly optimized engine is all I can say.

Edited February 6, 2012 by Mineria

[Xruptor]

No, you will not gain a fps increase.

Only solution to fix fps drops is on BW's hands.

I recently startet on a server with 150+ people on the fleet, and noticed a significent drop in fps compared to what I came from (60 people on the fleet)

All those characters are not even in visual view, so something is completely messed up in the game code.

Last mmo I remember such drops in was WAR with several hundred players in visual view.

Poorly optimized engine is all I can say.

 

Funny I've read that people utilizing 4-cores have come across more problems then those with dual-cores. There are several posts where people have actually seen a performance drop upgrading their systems. This includes graphics cards.

 

Though it does seem logical that improving your system would improve the quality of the game. I have to question some of the posts I've seen saying otherwise. I do agree though that going from 32bit to 64bit should improve your performance.

 

I'm not completely convinced about the RAMDisk fix. It seems like an awfully annoying process to go through just to get a game functioning slightly better. Then again every little bit counts I still believe that folks shouldn't HAVE to go through this to get a game working correctly. I blame the fault really on the developers.

 

I wonder how much of an improvement an SSD drive actually truly does for this game? Been thinking of just getting one anyways.

[Mineria]

Funny I've read that people utilizing 4-cores have come across more problems then those with dual-cores. There are several posts where people have actually seen a performance drop upgrading their systems. This includes graphics cards.

 

Though it does seem logical that improving your system would improve the quality of the game. I have to question some of the posts I've seen saying otherwise. I do agree though that going from 32bit to 64bit should improve your performance.

 

I'm not completely convinced about the RAMDisk fix. It seems like an awfully annoying process to go through just to get a game functioning slightly better. Then again every little bit counts I still believe that folks shouldn't HAVE to go through this to get a game working correctly. I blame the fault really on the developers.

 

I wonder how much of an improvement an SSD drive actually truly does for this game? Been thinking of just getting one anyways.

 

I doubt that a C2D would run the game as well as a CPU with more cores.

Seen it run on i7 920, i7 2600K and i5 2400, no problem with any of those.

If people see performance drops something else is creating a bottleneck.

When I bought my GTX580, I was still with a DP45SG board and a Q9650, for some reason the board did not want to switch to PCI-E 2.0, which worked perfect with my HD5870.

No BIOS update was available for it either, and N fix the driver.VIDIA didn't give a flying since there where not enough requests to fix the driver (X38 had the same issue but was fixed).

I then switched to an Asus Sabertooth P67 with an i7 2600k, SWTOR runs smooth with exception for something that goes on when many people are in the same zone, which purely is a client or server issue, I didn't analyze it neither do I intent too, that is BioWare's job!

 

Going from 32 to 64 bit is only a question of utilizing more RAM and getting support for 64bit applications, a 32bit OS is not worse performance wise with 32 bit app's.

 

Ramdisk and/or SSD only addresses loading time for the game, but that can have some effect on the rest of your system since you remove some I/O bottleneck.

There is a huge difference between loading on my laptops 7600rpm HD and my desktops dedicated game store SSD.

You could try out Romexo's FancyCache beta 0.7, if you got enough RAM available, there is really no point in using it neither imdisk on 4GB systems, heck, even on 6GB systems Windows would start swapping a lot to the paging file when people got a lot of stuff running in the background.

 

If most of the client was uncompressed that would speed things up too, plus give a lower CPU load, on the other hand it would require some more disk space.

 

Main issue is buried elsewhere thou, which creates a bottleneck on our systems and by that making GPU drop down in fps.

I only experience that issue with loads of players as mentioned earlier thou, so it has something to do with the data related to it.

Something like getting data before requested, which is good in some circumstances, but not good if it causes 50% and more drops in fps.

Edited February 6, 2012 by Mineria

[cipher_nemo]

If anyone has an X79-based motherboard with quad-channel RAM and can afford $700 worth of memory (http://www.newegg.com/Product/Product.aspx?Item=N82E16820231508), then they can have 64GB of RAM and dedicated 32GB for the system and 32GB for the RAM drive to cache the ENTIRE CLIENT and room to grow over the years!

 

Then all you'd need is the software and no special instructions. Not sure if it's worth it to anyone out there, but it's too rich for my blood to justify it just for TOR.

Edited February 6, 2012 by cipher_nemo

[Lemon_King]

Did some more testing, and I gained a huge performance boost by moving the following files to memory - Requires a 4gig RamDrive.

 

As for the performance gain, character loading goes from a long series of dragged out bursts to one quick burst with characters popping in at extremely fast speeds.

 

swtor_main_art_dynamic_cape_1.tor
swtor_main_art_dynamic_chest_1.tor
swtor_main_art_dynamic_chest_tight_1.tor
swtor_main_art_dynamic_hand_1.tor
swtor_main_art_dynamic_head_1.tor
swtor_main_art_dynamic_lower_1.tor
swtor_main_art_dynamic_mags_1.tor
swtor_main_art_fx_1.tor

Hooray Atlas Generation, being slow.

 

Junction Script - Aimed at Advanced Users: USE THIS AT YOUR OWN RISK

 

copy "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_fx_1.tor" T:\
rename "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_fx_1.tor" swtor_main_art_fx_1_ORIG.tor
mklink "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_fx_1.tor" "T:\swtor_main_art_fx_1.tor"

copy "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_cape_1.tor" T:\
rename "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_cape_1.tor" swtor_main_art_dynamic_cape_1_ORIG.tor
mklink "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_cape_1.tor" "T:\swtor_main_art_dynamic_cape_1.tor"

copy "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_chest_1.tor" T:\
rename "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_chest_1.tor" swtor_main_art_dynamic_chest_1_ORIG.tor
mklink "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_chest_1.tor" "T:\swtor_main_art_dynamic_chest_1.tor"

copy "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_chest_tight_1.tor" T:\
rename "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_chest_tight_1.tor" swtor_main_art_dynamic_chest_tight_1_ORIG.tor
mklink "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_chest_tight_1.tor" "T:\swtor_main_art_dynamic_chest_tight_1.tor"

copy "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_hand_1.tor" T:\
rename "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_hand_1.tor" swtor_main_art_dynamic_hand_1_ORIG.tor
mklink "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_hand_1.tor" "T:\swtor_main_art_dynamic_hand_1.tor"

copy "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_head_1.tor" T:\
rename "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_head_1.tor" swtor_main_art_dynamic_head_1_ORIG.tor
mklink "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_head_1.tor" "T:\swtor_main_art_dynamic_head_1.tor"

copy "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_lower_1.tor" T:\
rename "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_lower_1.tor" swtor_main_art_dynamic_lower_1_ORIG.tor
mklink "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_lower_1.tor" "T:\swtor_main_art_dynamic_lower_1.tor"

copy "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_mags_1.tor" T:\
rename "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_mags_1.tor" swtor_main_art_dynamic_mags_1_ORIG.tor
mklink "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_mags_1.tor" "T:\swtor_main_art_dynamic_mags_1.tor"

 

 

Junction Reversal

 

del "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_fx_1.tor"
rename "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_fx_1_ORIG.tor" swtor_main_art_fx_1.tor

del "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_cape_1.tor"
rename "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_cape_1_ORIG.tor" swtor_main_art_dynamic_cape_1.tor

del "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_chest_1.tor"
rename "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_chest_1_ORIG.tor" swtor_main_art_dynamic_chest_1.tor

del "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_chest_tight_1.tor"
rename "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_chest_tight_1_ORIG.tor" swtor_main_art_dynamic_chest_tight_1.tor

del "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_hand_1.tor"
rename "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_hand_1_ORIG.tor" swtor_main_art_dynamic_hand_1.tor

del "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_head_1.tor"
rename "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_head_1_ORIG.tor" swtor_main_art_dynamic_head_1.tor

del "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_lower_1.tor"
rename "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_lower_1_ORIG.tor" swtor_main_art_dynamic_lower_1.tor

del "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_mags_1.tor"
rename "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_mags_1_ORIG.tor" swtor_main_art_dynamic_mags_1.tor

 

Edited February 7, 2012 by Lemon_King

[Shimakaze]

Did some more testing, and I gained a huge performance boost by moving the following files to memory - Requires a 4gig RamDrive.

 

As for the performance gain, character loading goes from a long series of dragged out bursts to one quick burst with characters popping in at extremely fast speeds.

 

swtor_main_art_fx_1.tor
swtor_main_art_dynamic_cape_1.tor
swtor_main_art_dynamic_chest_1.tor
swtor_main_art_dynamic_chest_tight_1.tor
swtor_main_art_dynamic_hand_1.tor
swtor_main_art_dynamic_head_1.tor
swtor_main_art_dynamic_lower_1.tor
swtor_main_art_dynamic_mags_1.tor
swtor_main_art_fx_1.tor

Hooray Atlas Generation, being slow.

 

Junction Script - USE THIS AT YOUR OWN RISK

copy "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_fx_1.tor" T:\
rename "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_fx_1.tor" swtor_main_art_fx_1_ORIG.tor
mklink "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_fx_1.tor" "T:\swtor_main_art_fx_1.tor"

copy "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_cape_1.tor" T:\
rename "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_cape_1.tor" swtor_main_art_dynamic_cape_1_ORIG.tor
mklink "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_cape_1.tor" "T:\swtor_main_art_dynamic_cape_1.tor"

copy "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_chest_1.tor" T:\
rename "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_chest_1.tor" swtor_main_art_dynamic_chest_1_ORIG.tor
mklink "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_chest_1.tor" "T:\swtor_main_art_dynamic_chest_1.tor"

copy "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_chest_tight_1.tor" T:\
rename "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_chest_tight_1.tor" swtor_main_art_dynamic_chest_tight_1_ORIG.tor
mklink "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_chest_tight_1.tor" "T:\swtor_main_art_dynamic_chest_tight_1.tor"

copy "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_hand_1.tor" T:\
rename "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_hand_1.tor" swtor_main_art_dynamic_hand_1_ORIG.tor
mklink "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_hand_1.tor" "T:\swtor_main_art_dynamic_hand_1.tor"

copy "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_head_1.tor" T:\
rename "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_head_1.tor" swtor_main_art_dynamic_head_1.tor_ORIG
mklink "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_head_1.tor" "T:\swtor_main_art_dynamic_head_1.tor"

copy "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_lower_1.tor" T:\
rename "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_lower_1.tor" swtor_main_art_dynamic_lower_1_ORIG.tor
mklink "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_lower_1.tor" "T:\swtor_main_art_dynamic_lower_1.tor"

copy "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_mags_1.tor" T:\
rename "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_mags_1.tor" swtor_main_art_dynamic_mags_1_ORIG.tor
mklink "<SWTOR Install Path>\Star Wars-The Old Republic\Assets\swtor_main_art_dynamic_mags_1.tor" "T:\swtor_main_art_dynamic_mags_1.tor"

 

Would that script work the second time after rebooting? Should we instead manually rename the asset files to have _ORIG suffix first, then have the script copy the files to ramdrive? Or I'm misunderstanding how the whole thing works.

[Lemon_King]

Forgot to write one up for reversal. Gimme a moment.

e: And Updated

Edited February 7, 2012 by Lemon_King

[Roezz]

@ Lemon King:

 

Do you need a total of at least 10 RAM to incorporate the "swtor_main_art" files into a RAM drive then?

 

I believe you said above you need 4 RAM for the second fix, and your first page said 6 RAM. Let's assume I am very dense on this subject. I am eager to try this out.

 

I have 8 RAM total.

Edited February 7, 2012 by Roezz

[Ocmer_]

@lemon_king

 

I think now with the assests also in your memory it would be adviceable to create an image of that disk and reload that image on startup. This will save you time with formatting and coping assests files, cuz they already are preloaded in the image file.

 

Once you mounted, formatted, and placed folders/junctions/assets in it, rightclick the drive and click, "Save disk content as image file".

 

Once you created an image you can ntfs compress it aswell to save diskspace but you won't loose any mounting time. (rightclick on the imagefile, properties, advanced and enable compression).

 

At startup use the following code:

imdisk -a -t vm -f c:\ramdisk.img -m T:\

-t VM because you want to load the image into the RAM, else it uses the file as disk.

-f filename and location of the precreated image.

-p (format) is NOT needed anymore.

 

I was already doing this with the fx asset file, but now you commented on that I might aswell say something about loading a created image

 

A ramdisk image of "-s 1500M" of size with only the folders, junctions and swtor_main_art_fx_1.tor.

uncompressed: 1.47 GB (on disk)

compressed: 159 MB (on disk)

Edited February 7, 2012 by Ocmer_

[Lemon_King]

I still haven't fully expanded it, but for that case it would be best to have the asset data in its own Image.

[gyMe]

Its amazing how much performance you gain when removing the particle effects. Why isn't there a low quality/performance version of them?