I’m not sure how it happened but on some of our machines the profile directory is not “username” but “username.domain”. so it would be, for example c:\documents and settings\User1.ANATOMICALTRAVEL instead of c:\documents and settings\User1. Yet krakatoa still puts it’s cache into c:\documents and settings\User1\local settings\application data\prime focus\krakatoa. I’ve only seen this on one XP machine so far. The env var USERPROFILE=c:\documents and settings\user1.ANATOMICALTRAVEL
B.
I assume you are talking about the temporary location where PRT files are generated before being copied to their destination. There are a couple of factors for this location. See http://msdn.microsoft.com/en-us/library/aa364992%28v=VS.85%29.aspx for the details.
This is what’s in that folder:
“\rn033\c$\Documents and Settings\Farm\Local Settings\Application Data\Prime Focus\Krakatoa\history”
“\rn033\c$\Documents and Settings\Farm\Local Settings\Application Data\Prime Focus\Krakatoa\Macros”
“\rn033\c$\Documents and Settings\Farm\Local Settings\Application Data\Prime Focus\Krakatoa\MagmaFlows”
“\rn033\c$\Documents and Settings\Farm\Local Settings\Application Data\Prime Focus\Krakatoa\presets”
“\rn033\c$\Documents and Settings\Farm\Local Settings\Application Data\Prime Focus\Krakatoa\samples”
“\rn033\c$\Documents and Settings\Farm\Local Settings\Application Data\Prime Focus\Krakatoa_HistoryCache.List”
“\rn033\c$\Documents and Settings\Farm\Local Settings\Application Data\Prime Focus\Krakatoa_PresetsCache.List”
“\rn033\c$\Documents and Settings\Farm\Local Settings\Application Data\Prime Focus\Krakatoa\Background Color.Cache”
“\rn033\c$\Documents and Settings\Farm\Local Settings\Application Data\Prime Focus\Krakatoa\Override Absorption Color.Cache”
“\rn033\c$\Documents and Settings\Farm\Local Settings\Application Data\Prime Focus\Krakatoa\Override Color.Cache”
“\rn033\c$\Documents and Settings\Farm\Local Settings\Application Data\Prime Focus\Krakatoa\Override Density Color.Cache”
“\rn033\c$\Documents and Settings\Farm\Local Settings\Application Data\Prime Focus\Krakatoa\Override Emission Color.Cache”
“\rn033\c$\Documents and Settings\Farm\Local Settings\Application Data\Prime Focus\Krakatoa\Paths_ParticleFiles.Cache”
“\rn033\c$\Documents and Settings\Farm\Local Settings\Application Data\Prime Focus\Krakatoa\Paths_ParticleFilesBase.Cache”
“\rn033\c$\Documents and Settings\Farm\Local Settings\Application Data\Prime Focus\Krakatoa\Paths_ParticleFilesName.Cache”
“\rn033\c$\Documents and Settings\Farm\Local Settings\Application Data\Prime Focus\Krakatoa\Paths_ParticleFilesProject.Cache”
“\rn033\c$\Documents and Settings\Farm\Local Settings\Application Data\Prime Focus\Krakatoa\Paths_ParticleFilesSequence.Cache”
“\rn033\c$\Documents and Settings\Farm\Local Settings\Application Data\Prime Focus\Krakatoa\Paths_ParticleFilesTake.Cache”
“\rn033\c$\Documents and Settings\Farm\Local Settings\Application Data\Prime Focus\Krakatoa\BlackOps”
Ahh nevermind, that’s the location where Krakatoa’s settings are stored which is not what I was thinking of. I’m not sure why they are called .Cache files (Bobo could enlighten us once he’s back from Vancouver). I’ll log this as a bug.
They are called .cache because they cache the names of all files history and preset files found in the respective sub-folders. This allows me to display the sorted lists immediately without ever sorting by date again. When a new file is created, it is appended to the end of the text file and is thus also in order.
The folder structure is not resolved using the Max user directory methods so it IS a bug. The current code looks like
global Krakatoa_PresetsDirectory = (“C:\Documents and Settings\”+sysinfo.username+"\Local Settings\Application Data\Prime Focus\Krakatoa")
This is not a good idea - I will see if I can get to the correct path using some of the built in MAXScript methods.
I fixed this internally using
global Krakatoa_PresetsDirectory = (dotnetclass “System.Environment”).GetFolderPath (dotnetclass “System.Environment+SpecialFolder”).LocalApplicationData + “\Prime Focus\Krakatoa”
which in the general case should produce the same result as before, but in those cases where the folder and the user name are not the same, it should “see” what Windows sees.
This and the other relevant storage paths will be printed to the Krakatoa Log on startup in the next build.