313 réponses à ce sujet

[Vegielamb]

Can we get a list of things updated in this release?

[Cat Lance]

*dances about in a wacky and ecstatic manner* Thank you! *goes to download*

[Awildawn]

I never thought that I would play with SQL dos commands in my life and succeed in not breaking anything... I'm a sociologist and this is a hobby for Gygax's sake !

Well, at least I learned something new thanks to the DA toolset...again

[Rodro Lliv]

So, installing this new toolset should have repaired old saves that suffered the Plot GUID bug? Cause there are no party members on the camp in my last save yet.

[giskard44]

Some feedback for you Bioware.

I am sure your not going to like it but its intended to be constructive and due to a failure of common sense at bioware, this feedback as become necessary.

Builder to Builder Backups.

I hate to say this Bioware but I read the wiki about the builder to builder back it and its so vague i found my self having to guess which parts are my mod needs backing up. Your example of a builder to builder create lists 1 amulet, my mod has 2000 entries and i have no idea which parts belong to my mod and which parts are the old database I should avoid loading.

For example is Genip_shrub something I should be backing up, it says it exists already in the backup of my mod. So why is it in the backup in builder to builder ?

And what about 1999 other entries that also say EXISTS ?

Why is zz_upgrade listed with a ResRefID of 6924 ?

Is that part of my mod ?

And the sound sets for zz_ss_legionaire, i am pretty sure i never touched those but they are in my back up anyway.

Do you see what I am getting at ?

Ticking only the new items

Now try and tick only the new entries and you will be there all day, its quicker to remake the mod than to use your backup system. Your own example has 1 listed, mine has over 2000 and 15 minutes in to this I had hardly made a dint in the list.

The problem.

You have created a system that requires us players to be system administrators and the result is a complete and utter desaster that will result in thousands of complaints appearing on this forum in the coming weeks.

The system is long winded, overly complicated and prone to errors which in it self leads to complaints when following the vague wiki instructions fails to work and a modder loses his work.

The number of problems with the old toolkit combined with the poorly explained features on the wiki has already lead to some mods becoming tainted by problems that will exsasparate issues when upgrading from v1 to v1.1 of the tool kit. After the messy V1 toolkit, there is not going to be any simple upgrade not matter how you try.

Also currently we modders face losing our work every time you update your toolkit because of the above system being so complicated and the solutions you offer are no solutions at all. Many will in fact result in errors that are unpredictable, for example how would you know if a player forgot to untick 1 box out of several thousand in his mod, he might be using a single old file after accidently catching it whilst trying to import just his mods new entries. 

Backing up any database from any version of the toolkit in its entirity will just result in any new database being completely replaced and that will just cause even more problems.

So like i said, your system sucks, its going to create problems and it will be you not me will be left chasing your tail trying to guess whats wrong as modders like my self call you all the names under the sun when we lose our work because you failed to a little common sense here.

The Solution.

I think it is time to admit defeat bioware, V1 of the toolkit had problems from the start. The wikis vague instructions on just about everything left many of us guessing how to use what is a very user unfriendly editor and now you have an incredibly complicated, long winded and error prone sql backup system that requires a system administrator to fully understand.

I think its pretty clear the Toolkit V1 and all the solutions offered to solve its problems going to cause even more problems unless you draw a line under it and use V1.1 with its new database as the foundation you build on from now on.

The database errors alone when upgrading from v1 to v1.1 are going to be unpredictable.

So I recommend the following.

1) Declare the toolkit version 1 and everything made in it to be incompatible with Toolkit v1.1. Unless you enjoy playing wack the mole, in which case, ignore this. Explain the 1001 possible ways to create problems when upgrading as a reason for it.

2) Promise to provide a simple mod backup option in 1.2 that any halfwitted ape can understand, and test it using real apes and not system admins, make sure its easy to use and backs up ONLY the modders work and not everything else too. If you need a volenteer, I will put my money where my mouth is and step forward as the lab rat for this is nessessary.

3) Start rewritting the wiki instructions ( or encourage others to do so) on exporting of mods so the export with and without dependances at least are fully explained because I suspect that might be why some problems are appearing right now.

Simple SQL Backup option.

I know your commited to the current system now having developed and used it so I am not expecting you to change everything. But a decent program to take the pain out of backup and restoring mods database options is pretty much required to bridge the gap between players and your system administrators expections of us.

All the program needs to do is allow us to select the mods we wish to back up and have a backup button and the program should then automatically back up that mods database entries. Theres no reason why you cannot impliment backups cannot be decided in to groups so team support remains if you wish to go that far.

Just keep it nice, simple and no SQL experience required.

Otherwise, each time you update the toolkit, we risk will lose all our work and you can probably guess how we peasants with oru pitch folks will respond to that

I ask 1 Favour.

If you intend to leave everything as it is, eg continue using the system presented with 1.1 can you please say so, so those of us who see major problems ahead can move on and leave you to it. I would like to have the choice between risking hundreds of hours of work or spending that time else where basically. I am sure you understand.

PS I am following my own advice here and have given up trying to get the old work to important safely in to 1.1. I consider it far too risky even if it does work and ticking thousands of boxes over and over to find the right combination to make a safe import is more than I am willing to do, if I am honest.

Modifié par giskard44, 11 décembre 2009 - 04:48 .

[BryanDerksen]

Rodro Lliv wrote...

So, installing this new toolset should have repaired old saves that suffered the Plot GUID bug? Cause there are no party members on the camp in my last save yet.

No, this won't fix old saves that have been affected by the plot GUID problem. This update only means that if you export core resources from it in the future it won't cause any more savegames to become corrupted.

The problem is that when you play the game with broken plot GUIDs in core override, the game records changes to the plot flags under those GUIDs and not the old ones. Saving the game records those new broken GUIDs in the savegame file, and so even when you switch the GUIDs back the flags you set during that time are "lost" (they're still in the savegame, but they're saved under incorrect GUIDs).

[blondesolid]

****** and rehashed gear, I hope you guys are happy!

[BryanDerksen]

giskard44 wrote...
I hate to say this Bioware but I read the wiki about the builder to builder back it and its so vague i found my self having to guess which parts are my mod needs backing up. Your example of a builder to builder create lists 1 amulet, my mod has 2000 entries and i have no idea which parts belong to my mod and which parts are the old database I should avoid loading.

For example is Genip_shrub something I should be backing up, it says it exists already in the backup of my mod. So why is it in the backup in builder to builder ?

The builder-to-builder process automatically brings along copies of all of the dependancies of the resources you selected. The reason this is done is because the database checks whether a resource's dependancies exist before it allows you to add a resource to it, so if you were to try loading a resource with missing dependancies it would fail to do so. We'd wind up with builders whose B2B backups were useless because they'd forgotten to include some little thing somewhere.

When you do a B2B load, the B2B load screen will have a "hide/show dependancies" button that should allow you to exclude all the auto-included dependancies from your view. Other things you can do to sort through these extra resources and keep your work organized:

* If you're importing something into your database for the first time, sort by the "exists" column to find which resources will be created anew by the B2B load.
* If you're importing an entire modules' contents, sort by the "core" column and exclude the core resources. Provided, of course, that you didn't edit core resources. You should probably avoid editing core resources until you're familiar with resource organization in any event or producing a tidy builder-to-player package with core overrides in it will be difficult.
* Place all of your module's resources into consistently-named folders within your toolset. You can then sort by folder name in the B2B create/load screen to get specific groups of resources easily.

And what about 1999 other entries that also say EXISTS ?

"Exists" simply means that there's already a resource in your database with that resref. Whether you want to import it or not will depend on the details of what you're doing - if you're importing a module into your database that you didn't have in it previously, you probably don't want to import those. Importing a resource that "exists" will replace the version in your database with the version from the B2B package.

Why is zz_upgrade listed with a ResRefID of 6924 ?

Is that part of my mod ?

ResRefID is only used internally by the database to keep track of individual resources. If you were to load the B2B package into two different database, I believe wind up with different ResRefIDs associated with the imported resources. Under most circumstances you probably have no need to pay attention to ResRefIDs, they're exposed for troubleshooting purposes. For example if you somehow wind up with a resource that's missing its dependancy, despite all the safeguards in the system that should prevent such a situation from happening, those dependancies would be identified by ResRefID in the error message.

And the sound sets for zz_ss_legionaire, i am pretty sure i never touched those but they are in my back up anyway.

It's in there because something you selected to include in the B2B package depended on it, somewhere down the chain of dependancies. If it _wasn't_ included in the B2B package, you would be unable to import your resources into a database that didn't already have zz_ss_legionaire in it. Imagine the complaints we'd get then.

Now try and tick only the new entries and you will be there all day, its quicker to remake the mod than to use your backup system. Your own example has 1 listed, mine has over 2000 and 15 minutes in to this I had hardly made a dint in the list.

Sort your resources by some appropriate column or click the "hide dependants" button, and then use shift-click to select the group of resources you want to include. Click "uncheck all" and then "check selected".

If there's no column to sort by that will group your resources appropriately, you may be able to alter the directory structure of your mod to organize it better.

You have created a system that requires us players to be system administrators and the result is a complete and utter desaster that will result in thousands of complaints appearing on this forum in the coming weeks.

Given that we don't have the resources to completely rewrite the foundations the toolset is built on, there are unfortunately limited options for how we can approach managing it. We can of course do better - there's always room for improvement - but some of the issues you raise are the result of things we've had to do to avoid far _worse_ issues. The automatic inclusion of dependancies in B2B packages is I think one of those things that's likely unavoidable because the alternative is worse.

There could be improvements to the B2B interface to more clearly explain what's going on in it, I suppose. Something we could look at.

Also currently we modders face losing our work every time you update your toolkit because of the above system being so complicated and the solutions you offer are no solutions at all. Many will in fact result in errors that are unpredictable, for example how would you know if a player forgot to untick 1 box out of several thousand in his mod, he might be using a single old file after accidently catching it whilst trying to import just his mods new entries.

This particular update to the toolset was much trickier than future updates will be because we had to change both the default core resources installed in the database _and_ the B2B file format at the same time (the plot GUID bug was intertwined into both of these things). I don't expect we'll have to do that again. In future, it should be a simple matter of just unchecking the "install database" options when you run the installer.

Simple SQL Backup option.

I know your commited to the current system now having developed and used it so I am not expecting you to change everything. But a decent program to take the pain out of backup and restoring mods database options is pretty much required to bridge the gap between players and your system administrators expections of us.

All the program needs to do is allow us to select the mods we wish to back up and have a backup button and the program should then automatically back up that mods database entries. Theres no reason why you cannot impliment backups cannot be decided in to groups so team support remains if you wish to go that far.

Just keep it nice, simple and no SQL experience required.

In a nutshell, this is what the B2B process is there for. We could perhaps put in an interface to allow you to more easily auto-select all resources in a particular module to include in a B2B export, but it would still wind up including core dependancies in the B2B package.

A "backup entire database" menu command would be nice to have, to avoid messing around with those batch files, but that falls under your other objection because restoring it would overwrite any mods that weren't in it.

If you intend to leave everything as it is, eg continue using the system presented with 1.1 can you please say so, so those of us who see major problems ahead can move on and leave you to it. I would like to have the choice between risking hundreds of hours of work or spending that time else where basically. I am sure you understand.

PS I am following my own advice here and have given up trying to get the old work to important safely in to 1.1. I consider it far too risky even if it does work and ticking thousands of boxes over and over to find the right combination to make a safe import is more than I am willing to do, if I am honest.

Well, I guess I have to say that we're unlikely to change the fundamental structure of how the toolset's database works - we just don't have the resources for it right now. And that the basic B2B system is also unlikely to change. But I think that it should be quite possible to manage it in a way that doesn't require picking through thousands of entries one by one, and there are some tweaks I've mentioned in this post that we may be able to include in the future to simplify matters. Now that we've got Single Player out and have stomped the plot GUID bug we can start looking at improvements like that.

[TimelordDC]

Edit: This post was written in response to Leopard's post.

As long as you have the database backed up (which you should have done before installing this version) and have the Toolset 1.01 installer, you can go back to using the version which was working for you till they identify and fix the bugs in 1.02.
That said, without installing 1.02 and giving feedback/logs/information, those bugs might never get resolved since they won't have the issue information to go on.

Just shouting at them is not going to get the issues fixed, regardless of how severe your issues might be. Would you just walk into the Customer Service section at a regular store and yell at them if their product is broken? I don't understand why internet boards should be any different.

Modifié par TimelordDC, 11 décembre 2009 - 05:39 .

[giskard44]

To be honest Leopard73.

The upgrade process for existing mod makers is too risky. The 1001 issues with v1 cannot be all accounted for using the existing vague instructions but can easily be transferred to 1.01 accidentaly and make it appear like the upgrade failed.

Meaning you could break your own 1.01 install as you try and work out how to import just your mod and nothing else.

There is no information for example as to what files we should be looking for to back up. I put my entries in their own folder, so i spotted the 3 files in that folder easily, but what about the other 2000. Some of which are marked NEW and are Strings. I have not written anything that requires 1500 strings and the maps level is saved off as a separate file so I have NO idea what they do or if they are needed.

What I do know is that if 1 of them is old database information and I import it and make a new mod based on it. My new mod will harm the players saved games and I and they will have no idea whats happening.

Its far too easy to select the wrong file when importing an old mod and far too many problems that can reappear here.

The entire system is error prone and asking for trouble IMO.

But I think Bioware will learn this the hardway if we simply sit back and wait for the penny to drop over at Bioware HQ.

Modifié par giskard44, 11 décembre 2009 - 05:38 .

[Challseus]

@ giskard44

Builder to Builder Backups.

Here's what I did, to successfully back my stuff up. I went to Tools -> Builder -> Builder To Builder Create. As far as what needs to be backed, I just sorted the list by the Owner Module column. That way, I could determine what was in my Sandbox module (the stuff that needs to be backed up), and what was in the Core Game Resources module, which is stuff I obviously didn't want to back up.

Then, I unchecked ALL rows. Then, I selected all the rows under the Sandbox module, hit the Check Selected box, and hit OK. Then, I just saved the DADBDATA file in the area of my machine where I keep all my backups.

Ticking only the new entries

As stated earlier, once you sort my Owner Module, this issue goes away.

EDIT - Curse you Bryan. I should have known you were writing a more in depth response

Modifié par Challseus, 11 décembre 2009 - 05:40 .

[giskard44]

Challseus wrote...

@ giskard44

Builder to Builder Backups.

Here's what I did, to successfully back my stuff up. I went to Tools -> Builder -> Builder To Builder Create. As far as what needs to be backed, I just sorted the list by the Owner Module column. That way, I could determine what was in my Sandbox module (the stuff that needs to be backed up), and what was in the Core Game Resources module, which is stuff I obviously didn't want to back up.

Then, I unchecked ALL rows. Then, I selected all the rows under the Sandbox module, hit the Check Selected box, and hit OK. Then, I just saved the DADBDATA file in the area of my machine where I keep all my backups.

Ticking only the new entries

As stated earlier, once you sort my Owner Module, this issue goes away.

Thanks Challseus

I did the same thing you did, only me New entries ran in to the thousand and had to be selected 1 box at a time. A real pain in the butt. Most where strings, why my mod which considers of a world map icon and some levels needs that many strings is a mystery.

I easily identified the resources i put in a folder, such as doors etc. But could not find anything related to maps, icons or the door links etc. I appear to have objects used in my mod, not the mod it self.

[BryanDerksen]

Challseus wrote...
EDIT - Curse you Bryan. I should have known you were writing a more in depth response

Heh. No worries, I'd actually forgotten that there was an "owner module" column you could sort by too. Makes things even easier, thanks for mentioning it.

[stzehn]

I did have a lot of problems to get that database running with 1.0 and it didn't run with 1.1 because it was not able to restore the db. Even usage of Management studio failed because vista would not allow writing to the required folder.

The main problem is that MS SQL Server 2005 was not made to run on Vista or Windows 7 Systems or even X64 Variants. It is not compatible with UAC and folder rights those systems use (every folder within programme (x86) is write protected).

The conclusion for me was, after messing around with sql 2005 several hours today, to kick it and switch to SQL Server Express 2008. It just worked plain and simple and runs the toolset DB and the toolset can connect to it. Mainly because SQL Server Express 2008 has no Problems with Vista or W7 and will run without problem with UAC and all other rights management systems those have.

All I did was manualy create a server with the correct Tag  "BWDATOOLSET" and restored the DB Backup that came with 1.1 to it (naming the db correct of course)  using  SQL Server Management Studio (it will auto set the db to sql 2005 compatibility mode) . After that started the toolkit and it conncted instantly to the DB without any trouble.

Modifié par stzehn, 11 décembre 2009 - 06:47 .

[Kaldir II]

Not to question or contradict what you're saying, Giskard, but just for clarification:

giskard44 wrote...
So I recommend the following.

1) Declare the toolkit version 1 and everything made in it to be incompatible with Toolkit v1.1.

Isn't that what they are saying on the wiki?
Unfortunately there have been changes in the builder-to-builder format of the toolset in the most recent version (...) so it will not be possible to migrate old content directly to the new toolset version using a builder to builder export/import.

Agreed, it's not a very clear statement, but doesn't it say what you ask?

giskard44 wrote...
2) Promise to provide a simple mod backup option in 1.2 that any halfwitted ape can understand, and test it using real apes and not system admins, make sure its easy to use and backs up ONLY the modders work and not everything else too.

A very valid remark, especially on the testing part. But the B2B is meant for this, right? They "just" need to make it fool (ape) proof.

giskard44 wrote...
If you intend to leave everything as it is, eg continue using the system presented with 1.1 can you please say so, so those of us who see major problems ahead can move on and leave you to it. I would like to have the choice between risking hundreds of hours of work or spending that time else where basically. I am sure you understand.

Again the wiki:
In the future, assuming we don't find any more fundamental bugs like this one that require the builder to builder format to change again, DADBDATA files should be compatible across toolset versions. Furthermore, unless once again we find more fundamental bugs in the core resources as distributed, it should not be necessary to replace your database in future updates.

This sounds like they're not intending any database updates/replacements in next version(s), which should prevent loss of own-made mods.

Bioware messed up big on the toolset, which they don't deny themselves. They are trying hard to fix it, which unfortunately causes loss of work for some/many with this patch. But maybe the information they supply gives you some hope for the future versions.
I'm not trying to deny the many problems people have, but I do think Bioware is doing a better job than most game developers in their information.

Modifié par Kaldir II, 11 décembre 2009 - 06:35 .

[Sunjammer]

BryanDerksen wrote...

Odd, the stages all export correctly for me on my test machines. Anyone else having export problems?

When I open a stage I get a run of these popups:



Afterwards the properties have database references:

[BryanDerksen]

Ah! This could be a cautionary example where BioWare didn't follow the proper best practices that we recommend for other builders to follow. The stage "3p_a_pattern" is a core resource that has been set to use a single player resource as a dependency (in this case the area layout that's being used as a visualization source). That means that whenever you're not in the single player module, its dependency doesn't exist. Try switching to Single Player and it should work again.



There's a handful of these in the core stage resources. They shouldn't actually cause a problem in the game, since a stage's visualization is used only in the toolset for ease of editing and isn't part of the exported resource, but it's sloppy nonetheless and you may wish to edit it so that it isn't using that area for visualization purposes. Our bad.

[Sunjammer]

Naughty BioWare

[DecalGuy]

DecalGuy wrote...

Does DA need to be patched to version 1.02 first? If not can I patch DA later, like after I beat the game after the toolset 1.01?

Can I get a quick response please so i can get back to my game and some modding?

[Allan Smith]

you do not have to update to game patch 1.02 first, but it would probably be a good idea to patch your game anyway.

[BioSpirit]

Is there a list of known bugs and issues regarding to the Toolset ?