56 réponses à ce sujet

[BryanDerksen]

I don't think there's a way to fix it with changes to the database, since I don't think it's a toolset-related problem. It might be that you could fix it by editing the savegame file in the toolset (it's a GFF file with a different extension) to repair the shale plot's flags, but I have no idea what flags would need to be set. My advice would be to go with the existing solution; revert to the last good save and re-play from there.



Sorry, I wish there was a quick and easy fix for this. But I don't think we even know exactly what's wrong in the first place yet.

[Adaram]

OK. No problem.



I will move forward with testing the plot flag fixes using the new DB, now that we are sure that the new DB was not the cause of the issue.



I'll let you know if I run into any issues on that front (with my good saved games)

[Adaram]

Happy to announce that I have restored the new DB, created and exported a new module with dependent resources, and tested a few saved games. All of my plot conversations seem to be in order.



I am pretty positive the Shale issues I had before this were pre-existing.



Thanks for the support!

[Xeveniah]

You Bio Ware guys kick arse... Thank you for giving the modding community the same support as NWN



Xeveniah Darkwind

[Trampzabout]

I have also updated to the new database and have done a small amount of testing with exported resources. I am please to report that it all seems to be working properly. I havent encountered any plotID bugs or missing clothes/conversation or anything else that I had experienced with the original database while playing the OC.



So, Thank You Very Very Much Bioware.



Please keep up the good work.

[stuntpope]

What I don't understand is why core resources are ever being exported if they haven't been changed.



If we leave the core resources alone then surely they should not have been exported at all and this bug would never have caused so many problems.



It seems to me that while this happens there will always be a chance that the toolset and game get out of step.



I know there are a lot of modders out there who are doing things by modifying core resources but there are much better ways to work. I feel that nothing should ever be going in my packages core overide directory while I am not modifying core resources.



Can BioWare clarify this?

[Proleric]

Good job, Bryan!

(Or should I say... Packrat? Any truth in the rumour that you're doing a Simpsons cameo next season?).

Seems like the big bad bug is fixed, and the string editor looks OK now, too. Just some minor stuff...

Standalone custom modules still show up in the client as Installed under Downloadable Content. If you save the OC then disable the custom module, you have to force the OC to load.

Exporting areas with dependent resources works, but in every case I'm getting a compilation error on placeable_core (no right bracket in sys_traps_h at line 1521) even though I haven't touched any core scripts.

Export also seems to create a lot of core scripts in documents > bioware > packages > core > override > toolset export. May be benign, but possibily unintended?

Inventories created during beta testing now contain different OC items e.g. a leather helmet is now an apprentice cowl. Items belonging to my module are unaffected. My guess is that the GUIDs for OC items have changed since beta - if so this is not a big deal.

Modifié par Proleric1, 04 décembre 2009 - 09:14 .

[Seamhainn]

The "unable to connect to database" error is really a big issue. I tried really every solution the wiki offered, but could not get the toolset to work. As I restored much of the deleted content for KotOR I was looking forward using the DA Toolset, but, alas, no success until now...

[FalloutBoy]

I'm happy to say that everything seems to be in working order for me now. I did updated my db, messed with my test module a little bit, did a full export, then went and played the OC for a while. No problems at all.



I did get the compile error in sys_traps_h. I looked at the code and couldn't figure out why it would be failing there. The code looks right to me.



I don't know why all those scripts that I haven't touched are being compiled, but w/e.

[Proleric]

On another thread, it appears folk aren't clear how to apply the fix. This is what I did:
1. In the toolset, use the Tools > Export option to empty the export folders.
2. Do a builder-to-builder export of your module, ensuring that core resources are NOT checked.
3. Do a backup of the toolset data base for safety.
4. Restore the toolset data base from the fix (i.e. the .bak file you downloaded from Bryan's project page).
5. Your module should have disappeared from the toolset. Make a new module.
6. Do a builder-to-builder import into the new module, checking the option to assign new string ids.
7. In the module properties, reinstate the module script, start area and start waypoint information.
Thanks to FalloutBoy for reminding me about backups!
Corrections / improvements welcome!

Modifié par Proleric1, 04 décembre 2009 - 06:41 .

[Xeveniah]

Gentlemen,



I am having an issue downloading the repaired DB I am a member of the group but all I get is The little yellow caution symbol in the lower left hand of the browser saying there is an issue with the page.....



Any ideas on why this is happening? Windows 7 Ultimate X64 Edition



Thanks,

Xeveniah Darkwind

[BryanDerksen]

stuntpope wrote...
What I don't understand is why core resources are ever being exported if they haven't been changed.

If we leave the core resources alone then surely they should not have been exported at all and this bug would never have caused so many problems.

"Leaving core resources alone" in this case would require not #including them into any of the scripts that you export, which would be nigh impossible for any meaningful mod. The problem is that when you #include a script (or a plot) you are telling the toolset to pretend that you've cut-and-pasted the contents of the #included resource into the script you're working with. So as I understand it there isn't really a way to not export an #included resource along with the original.

It seems to me that while this happens there will always be a chance that the toolset and game get out of step.

I know there are a lot of modders out there who are doing things by modifying core resources but there are much better ways to work. I feel that nothing should ever be going in my packages core overide directory while I am not modifying core resources.

Can BioWare clarify this?

Well, all I can say is that it was a good design decision for us while we were developing the game internally with this toolset. And if we hadn't made that one mistake with how B2B handled plots, it would have been fine for end users too - you'd have been exporting core resources that were completely compatible with the existing game resources and no problems like this would have occurred.

It does mean we'll have to patch the toolset's core resources whenever we patch the main game's core resources, but that would be desireable to do in any event.

[BryanDerksen]

Seamhainn wrote...

The "unable to connect to database" error is really a big issue. I tried really every solution the wiki offered, but could not get the toolset to work. As I restored much of the deleted content for KotOR I was looking forward using the DA Toolset, but, alas, no success until now...

That error message is actually a symptom of a whole constellation of possible root causes, so it's not a simple thing to fix. We've put fixes for a lot of potential ones into the upcoming release so hopefully we'll manage to hit whatever one is causing the problem for you, but I can't guarantee it since I've no way of knowing which specific one caught you.

A coworker of mine had a good car analogy for this; consider the "unable to connect to database" error to be like the "service needed" light on a car's dashboard. If the light goes on it means something's wrong, but there's no way a mechanic could tell you what needs fixing without looking much more deeply into the issue.

[BryanDerksen]

FalloutBoy wrote...
I did get the compile error in sys_traps_h. I looked at the code and couldn't figure out why it would be failing there. The code looks right to me.

Interesting, I'm getting that too. I'll look into it more deeply on Monday and see if I can figure it out, I can't find the error it's complaining about in the code either.

[BryanDerksen]

Proleric1 wrote...
Good job, Bryan!

(Or should I say... Packrat? Any truth in the rumour that you're doing a Simpsons cameo next season?).

Heh. My playing style is why I was so vocal in insisting that a storage chest for the player be included in Warden's Keep.

Seems like the big bad bug is fixed, and the string editor looks OK now, too. Just some minor stuff...

Standalone custom modules still show up in the client as Installed under Downloadable Content. If you save the OC then disable the custom module, you have to force the OC to load.

I think having standalones appear under the Downloadable Content tab is how it's intended to work. Standalones can include changes to core contents that affect other modules, so it's important to be able to disable them.

I'm not sure how the system is supposed to interact with savegames. Check the "Extended Module" property of your module to ensure that it's set to "(None)", but it could be that standalones are supposed to be considered required like this on account of how their core resources could potentially impact other nominally independant modules. For example, you could have a standalone module that adds new core spells to the mage class and your OC mage would be able to add those spells without an explicit dependancy existing between the two.

Exporting areas with dependent resources works, but in every case I'm getting a compilation error on placeable_core (no right bracket in sys_traps_h at line 1521) even though I haven't touched any core scripts.

I'm getting this on a local test machine too. Curious, I'll have to wait until Monday to delve into it though.

Export also seems to create a lot of core scripts in documents > bioware > packages > core > override > toolset export. May be benign, but possibily unintended?

Works as designed, I believe - it's always worked that way for me on our developer toolset and I assume it's with good cause. When you #include something in a script it gets exported even when you've selected "export without dependancies."

Inventories created during beta testing now contain different OC items e.g. a leather helmet is now an apprentice cowl. Items belonging to my module are unaffected. My guess is that the GUIDs for OC items have changed since beta - if so this is not a big deal.

Interesting. I guess that's possible; the databases we released during beta testing were a bit more chaotic than the ones we're including now. Regrettably, as this plot GUID bug shows, only a bit more. I'll do a few tests of this on Monday as well and make sure there isn't something more fundamentally weird going on.

Modifié par BryanDerksen, 05 décembre 2009 - 02:29 .

[Proleric]

Bryan - at risk of being a dog with a bone - I really have a bad feeling about those "working as designed" issues - not showstoppers for 1.02 but maybe worth a second look once the immediate problem is fixed?

If a module is explicitly not an extension to anything else, it shouldn't be necessary to switch it off when playing other modules or the OC. Even if there were changes to core resources (which there aren't), surely they should only affect the module, not the whole game?

I suspect a thorough review of how [module v add-in] works would pay dividends in reducing support queries over time. Either builders and players need a much better understanding, or there's a design principle that needs to be fixed.

[Adaram]

Just a quick note, the community came through for me with a fix to my Shale problem. I'll link it here, but basically, they have us going into the console and resetting Shale's plot id that way using zz_shl_debug or some such thing!



So I trhink I am moving fwd with a fixed Shale as well.



Thanks



Link to Shale plot bug fix:



http://social.biowar...331250/1#382593

[Kaldir II]

BryanDerksen wrote...
When you #include something in a script it gets exported even when you've selected "export without dependancies."

Since these included scripts are core scripts that are available in the original game, can they be deleted without trouble? Or does the addin/module that included these scripts really need them to be available in the directory where they got exported?

BTW, good job on the plenty and lengthy responses from Bioware here. Gives a good feeling of how hard you guys are working to get all issues fixed.

[TimelordDC]

+1 for Proleric's post.

While the design may have worked without issues for the development team, keep in mind that pretty much everyone was working on one module and the play-testers had one build/game to test. With multiple modules overriding core resources in a variety of ways, enabling/disabling specific modules can become very cumbersome.

If core resources are always exported as part of a B2P module package, there is no reason why a module's overrides should affect the main campaign or any other module.
Similarly, add-ins that extend a particular module (or OC) should affect only that module or OC -> or the whole purpose of an add-in is defeated.
Again, core resource modification that are required to be applied to all modules/campaigns should have a different method => perhaps placing them in the install directory core override and re-releasing them for each patch version so that they are up-to-date (since they can affect the OC as well, such add-ins must be up-to-date on the patch side too)

BryanDerksen wrote...

stuntpope wrote...
...

"Leaving
core resources alone" in this case would require not #including them
into any of the scripts that you export, which would be nigh impossible
for any meaningful mod. The problem is that when you #include a script
(or a plot) you are telling the toolset to pretend that you've
cut-and-pasted the contents of the #included resource into the script
you're working with. So as I understand it there isn't really a way to
not export an #included resource along with the original.

...

Well,
all I can say is that it was a good design decision for us while we
were developing the game internally with this toolset. And if we hadn't
made that one mistake with how B2B handled plots, it would have been
fine for end users too - you'd have been exporting core resources that
were completely compatible with the existing game resources and no
problems like this would have occurred.

It does mean we'll have
to patch the toolset's core resources whenever we patch the main game's
core resources, but that would be desireable to do in any event.

How exactly would this work for released modules? Do we have to then release updated versions of modules for each patch that touches the game's core resources as otherwise there is a possibility that the resources included in the module and the game are out-of-sync (which could possibly mean similar issues as with the Plot GUID bug)? 

[ladydesire]

TimelordDC wrote...



How exactly would this work for released modules? Do we have to then release updated versions of modules for each patch that touches the game's core resources as otherwise there is a possibility that the resources included in the module and the game are out-of-sync (which could possibly mean similar issues as with the Plot GUID bug)? 

You should always do that; I know that in NWN2 whenever Obsidian updated anything one of the first things that Reeron and rpgplayer1 would do was compare their fixed scripts to what was in the patched version of the game, and alter their stuff accordingly. When Obsidian started using rpgplayer1's fixes, he would remove any of the fixed spells that now matched what was included in the game. It was less important in NWN and NWN2 for playable modules, since they didn't always include core scripts, but it's a good habit to start for DA.

[TimelordDC]

ladydesire wrote...

TimelordDC wrote...



How exactly would this work for released modules? Do we have to then release updated versions of modules for each patch that touches the game's core resources as otherwise there is a possibility that the resources included in the module and the game are out-of-sync (which could possibly mean similar issues as with the Plot GUID bug)? 

You should always do that; I know that in NWN2 whenever Obsidian updated anything one of the first things that Reeron and rpgplayer1 would do was compare their fixed scripts to what was in the patched version of the game, and alter their stuff accordingly. When Obsidian started using rpgplayer1's fixes, he would remove any of the fixed spells that now matched what was included in the game. It was less important in NWN and NWN2 for playable modules, since they didn't always include core scripts, but it's a good habit to start for DA.

Dang. I wrote a reply earlier but it didn't register
Here I go again...

Lady, I think we are talking about 2 different things here -> a module (not an add-in to the OC) that uses core resources (like chargen, event handlers, etc) but doesn't change them (override them, yes, but no changes) VS an add-in that changes core resources (Reeron's work on the spell fixes falls in this area since that fix is applicable to all modules in play -> unless the builder has overriden a specific spell in his module too)

I would not expect to update and re-release my module for every patch Bioware releases for DA; that would be a mod-maintenance nightmare. Secondly, a re-release, as you say, is a good thing since it keeps mods up-to-date. BUT, if forced to do so because of the resource database changing for every patch, can you imagine the save-game issues people will have?

Anyway, all this is speculation at this point...with way too many bracketed comments

[stuntpope]

Excellent posts from Proleric1 and TimelordDC above. I'm glad to see I'm not the only one that feels this way.

Bryan - thanks for your response.

BryanDerksen wrote...

"Leaving core resources alone" in this case would require not #including them into any of the scripts that you export, which would be nigh impossible for any meaningful mod. The problem is that when you #include a script (or a plot) you are telling the toolset to pretend that you've cut-and-pasted the contents of the #included resource into the script you're working with. So as I understand it there isn't really a way to not export an #included resource along with the original.

There is still something that doesn't seem right here. Surely those includes are added at runtime - so it shouldn't matter whether I am getting them from the override directory or the original game resources.

As proof of this, I can create a module with my own scripts that include core scripts. After I export my scripts to my module's override and the toolset exports the core scripts to packages\\core\\override I can delete those resources from the packages\\core\\override directory and my scripts still run fine. So there is really no need to export these resources. The only point to exporting them would be if I changed them.

EDIT - ok I just realised these includes are added at compile time - but that doesn't change my point, since they are included in my compiled code that goes into my module's own directory why do any original scripts need to be exported to the packages\\core\\override directory?

Modifié par stuntpope, 06 décembre 2009 - 12:37 .

[giskard44]

Thanks Bryan



I have 1 concern about the backup system that leads me to believe we will be bitten by this again and again and again.



All systems I have seen backup the entire database in 1 go, so what happens when I backup a database for (just as an example) Toolset 1.1 and you release and update for Toolset 1.2 in the future.



If to get my mods back i have to restore the whole database, that means 1.1 would completely replace 1.2. Effectivily giving me outdated GUIDs again.



And if I do not back up the database, when I upgrade the toolkit, I will lose my mods.



If your aware of this and already have a solution, can you post some links please Bryan, of if I am way of base here and have it completely wrong, just let me know



Thanks.

[BryanDerksen]

If we get it right this time, we shouldn't need to do another update that outright _replaces_ a database like this again. Future updates to core resources should be possible using conventional builder-to-builder files.



The solution for keeping your mods is to do a builder-to-builder export of them from your old database and then, once the new database is in place, builder-to-builder load them in. In this particular case there's going to be a bit of a trick to that as well since we're changing the B2B format (it was a flaw in the B2B process that created the bad plot GUIDs in the first place). So you'll have to do the operation in a very particular order.



First backup your existing database with its mods, just to be on the safe side. Then:



1- update your toolset to the new version but KEEP the existing database with your mods and the bad GUIDs

2- do a B2B export of your mods. This will produce a DADBDATA file in the new format.

3- restore the new database with corrected plot GUIDs. This will eliminate the bad core resources, but also wipe your mods.

4- do a B2B import of your mods. At this point you've now got your old mods in your new database, and all should be well.

[BryanDerksen]

Proleric1 wrote...
If a module is explicitly not an extension to anything else, it shouldn't be necessary to switch it off when playing other modules or the OC. Even if there were changes to core resources (which there aren't), surely they should only affect the module, not the whole game?

I suspect a thorough review of how [module v add-in] works would pay dividends in reducing support queries over time. Either builders and players need a much better understanding, or there's a design principle that needs to be fixed.

Yeah, we've definitely been continuing to work over the addin system internally as the PRC team has been testing its limits and finding problems with it. If the end user community is finding problems with it too then by all means report them and we'll see what can be done.

Also don't take my word as gospel on how the system currently works, I haven't had much first-hand experience with it. It's possible I've misinterpreted something.