Every file I create in the DA:O Toolset is read only and I can't apply any changes to it. I can create a file, then save it under a different name and everything seems to be working fine. But when I save that file and reopen it it's marked as "read only" again.
I tried to uncheck the "read only" box in the properties of the folder, in which my toolset files are stored, but everytime I open the properties box it is rechecked again (I'm using Windows 7 by the way).
I can, however, create and edit .lvl files, which I save under a completely different folder in My Documents.
It's kind of ironic, cause I've just recently switched to a new PC. On the old machine I had a problem with lightmapping which prevented me from building my own levels, but I could do everything else. Now it's the other way around - I can make my levels but cannot populate them or assign them to areas.
All files created in the toolset are "read only"
Débuté par
nametab
, févr. 04 2010 05:26
#1
Posté 04 février 2010 - 05:26
#2
Posté 04 février 2010 - 06:03
What type files are they and how did you create them? Most likely you just need to right click on your file in pallette window and do open local copy (not view source). Also make sure file is 'checked out'. Well, hope this can maybe get you started.
#3
Posté 04 février 2010 - 06:27
I mean all files, like areas, items, conversations etc. I tried doing a local copy and saving it but when I reopen the toolset all files are once again "read only" and are also completely empty (an area created by me is missing the area layout that I've assigned to it).
Perhaps I can somehow change the directory to which the toolset saves all the custom-made stuff?
Perhaps I can somehow change the directory to which the toolset saves all the custom-made stuff?
#4
Posté 04 février 2010 - 06:28
Sounds like you've toggled an option which automatically checks out files when you create them. By default, any file you create should be checked out.
The check in/check out mechanism is used to maintain sanity between multiple developers working on the same project, making it so people don't step on each other's toes by only allowing the file to be checked out by one person at a time (similar to tools like Perforce, if you've ever used it).
You should just need to right-click the entry and do 'Check Out', but also go through the toolset options and make sure you haven't toggled the options which automatically checks out new files you create.
The check in/check out mechanism is used to maintain sanity between multiple developers working on the same project, making it so people don't step on each other's toes by only allowing the file to be checked out by one person at a time (similar to tools like Perforce, if you've ever used it).
You should just need to right-click the entry and do 'Check Out', but also go through the toolset options and make sure you haven't toggled the options which automatically checks out new files you create.
#5
Posté 04 février 2010 - 06:38
Apparently, in this case it doesn't matter wether I've checked out the resource or not - it still remains marked as "read only" and the toolset does not save any changes I make to the local copies.
#6
Posté 04 février 2010 - 07:16
I wonder why you say read only files. Its a database, and the only thing that matters is check in or out. Well perhaps it also has a protection but i dont know . So if you wonder how to "somehow change the directory to which the toolset saves all the custom-made stuff".. it saves into database.
#7
Posté 04 février 2010 - 07:18
Wait, are you doing 'export without dependent resources' or anything? Those items on the right-hand panel don't actually exist as files without an export. They're somewhat abstract until you right-click the item and do 'export without dependent resources'. Then it'll compile the file and place it in the (usually) core/override/toolsetexport/ folder.
The data is stored in the SQL database you installed with the toolset until then. The files are read-only because its essentially latched onto them to prevent you editing them until you close the toolset to release them. I think its a concept they didn't really explain too well with the toolset's wiki. The files won't have updated info until you do an export, since all of the entries and values you tweak within the toolset (with some exceptions like Level files and head morphs and such) are stored in the DATABASE ENTRY, not the file. The file is just compiled, exported database data.
But, at the same time, the files cannot be modified while the toolset is active.
The data is stored in the SQL database you installed with the toolset until then. The files are read-only because its essentially latched onto them to prevent you editing them until you close the toolset to release them. I think its a concept they didn't really explain too well with the toolset's wiki. The files won't have updated info until you do an export, since all of the entries and values you tweak within the toolset (with some exceptions like Level files and head morphs and such) are stored in the DATABASE ENTRY, not the file. The file is just compiled, exported database data.
But, at the same time, the files cannot be modified while the toolset is active.
Modifié par Bibdy, 04 février 2010 - 07:26 .
#8
Posté 04 février 2010 - 07:22
you could check to make sure the directory that the TS is saving your content in not marked as 'read-only' in the "directory's" property tab. I believe that the TS can make new files in a 'read-only' directory, but will always say 'changes can't be saved' if the directory is mark that way.
#9
Posté 04 février 2010 - 07:48
I'll put it this way: When I choose File -> New -> any kind of resource except for levels and head morphs, I get an empty resource ready for editing... except that I can't do anything with it, all the properties in the object inspector are in gray and on the top there's the sign: "Read Only Copy - Changes can not be saved". So I really don't have anything to export, with or without dependent resources. So, maybe it's something about the database, I don't know.
#10
Posté 04 février 2010 - 08:00
And you are sure that what you made is checked out?
#11
Posté 04 février 2010 - 08:22
It doesn't matter, the effect is the same whether it's checked out or not.
#12
Posté 04 février 2010 - 08:40
Are you running in the Single Player module right now? It should tell you in the title bar of the toolset. If it says "Single Player" then you need to create your own module and do your work from there by going to File -> Manage Modules.
I think the Single Player module is locked for editing, so any new resources which rely on the database (i.e. anything but levels and head morphs) are going to be restricted.
Bear in mind you'll need to flip back to the Single Player module if you want to take a look at the in-game areas/scripts/whatever. Makes reverse-engineering and duplicating some stuff a pain in the ass, but you learn to deal.
I think the Single Player module is locked for editing, so any new resources which rely on the database (i.e. anything but levels and head morphs) are going to be restricted.
Bear in mind you'll need to flip back to the Single Player module if you want to take a look at the in-game areas/scripts/whatever. Makes reverse-engineering and duplicating some stuff a pain in the ass, but you learn to deal.
Modifié par Bibdy, 04 février 2010 - 08:43 .
#13
Posté 04 février 2010 - 08:52
Nope, I am running in my own module, so this can't be it
#14
Posté 04 février 2010 - 08:56
Try making another new module and switch to that. Maybe there's something wrong with the current one.
#15
Posté 04 février 2010 - 09:03
Same thing, I'm afraid.
#16
Posté 04 février 2010 - 11:16
Did you do a builder-to-builder load into this database at some point, and/or do any error messages come up when you try creating a new database resource? I recall running into some problems after doing a builder-to-builder load on a test machine a long time back that was caused by a problem with bad string ID ranges, it resulted in new resources failing to be created with a "cannot save resource" error. It didn't prevent things from being edited, though.
#17
Posté 04 février 2010 - 11:38
No error messages appear and I did not do a builder-to-builder load. I even reinstalled the toolset and the game but the problem remains the same.
#18
Posté 05 février 2010 - 04:32
Okay, this is a puzzler. I've asked around the office and nobody has any really solid ideas for why something like this would happen. A resource that's checked out to you should simply not be read-only.
One speculative idea for what might be wrong is that you've somehow wound up with read access but not write access to the database. Are you comfortable working with MS SQL Server Management Studio Express? It's a free download from Microsoft and will allow you to get under the hood and look at some of the settings for your database. For this particular situation you'll want to see if the dragon age content database has the "bw_db_write" role (http://social.biowar...se_from_scratch has some information on this area).
When you reinstalled the toolset, did you uninstall the old version and tell it to uninstall the database too when it asked? If the problem lies with the database, it's possible that a reinstall will leave the broken database installation intact in the bacground depending on which options you choose during uninstallation/reinstallation.
One speculative idea for what might be wrong is that you've somehow wound up with read access but not write access to the database. Are you comfortable working with MS SQL Server Management Studio Express? It's a free download from Microsoft and will allow you to get under the hood and look at some of the settings for your database. For this particular situation you'll want to see if the dragon age content database has the "bw_db_write" role (http://social.biowar...se_from_scratch has some information on this area).
When you reinstalled the toolset, did you uninstall the old version and tell it to uninstall the database too when it asked? If the problem lies with the database, it's possible that a reinstall will leave the broken database installation intact in the bacground depending on which options you choose during uninstallation/reinstallation.
#19
Posté 05 février 2010 - 05:20
Okay, I've downloaded MS SQL Studio Manager Express but I have no idea how to use this thing. Any explanation how to reach this "bw_db_write" thingy will be appreciated.
Also, I've reinstalled the whole thing along with the database and that didn't help.
Also, I've reinstalled the whole thing along with the database and that didn't help.
#20
Posté 05 février 2010 - 06:11
We're getting into a tool that I haven't used much myself here, so unfortunately I'm not able to give a huge amount of advice. I'll do what I can. 
When you run Studio Manager Express the first thing you'll be asked is which database server to connect to. There's a dropdown list, you'll want "<your computer name>\\BWDATOOLSET" (the default toolset database). Windows authentication should work.
I put up a screenshot of how the roles screen looks on my test computer. I think that all that's needed is for those roles to exist, I don't recall needing to do any special configuration to set them up once they were created.
http://social.biowar...se_installation and http://social.biowar...se_from_scratch may also have some clues to help you figure out what's going on in Management Studio Express.
When you run Studio Manager Express the first thing you'll be asked is which database server to connect to. There's a dropdown list, you'll want "<your computer name>\\BWDATOOLSET" (the default toolset database). Windows authentication should work.
I put up a screenshot of how the roles screen looks on my test computer. I think that all that's needed is for those roles to exist, I don't recall needing to do any special configuration to set them up once they were created.
http://social.biowar...se_installation and http://social.biowar...se_from_scratch may also have some clues to help you figure out what's going on in Management Studio Express.
#21
Posté 05 février 2010 - 06:22
Okay, I checked it out and all the roles are there. So I guess this is not the case, unless there really is something about their properties that has to be changed, but I'm not touching that on my own, without any instructions.
#22
Posté 05 février 2010 - 06:47
Totally a stab in the dark, but perhaps the toolset hasn't been given sufficient rights by the OS to write to the database? Try right-clicking on the toolset and using "run as administrator" to see if that solves it.
Unfortunately I haven't actually used Windows 7 before myself so I'm not too familiar with its permissions. We're still primarily a Windows XP shop in here.
Unfortunately I haven't actually used Windows 7 before myself so I'm not too familiar with its permissions. We're still primarily a Windows XP shop in here.
#23
Posté 05 février 2010 - 06:56
Normally you don't need to do anything in win7 to make it run as administrator, it's set to do that by default, I assume by the installer. You do probably need to make it do that yourself though if it hasn't done it for you.
#24
Posté 05 février 2010 - 08:15
I have it running on Win7 but i made the toolset run as admin so i wouldn't get enoying thing like that.
#25
Posté 06 février 2010 - 09:41
That didn't help either. Still the same problem.





Retour en haut






