16 réponses à ce sujet

[BryanDerksen]

We're closing in on being able to release a new toolset update and it will include a new copy of the core resources that don't have bad plot GUIDs causing the main game to break. Considering the nasty effects that bug had when we first released the toolset we figured that to ensure we don't get bitten a second time we'd do a test release of just the database.

Note that this isn't really a 'beta' test or anything comprehensive like that, we're just putting out the new core database to allow it to be checked over and used a bit. Anyone who wants to take a stab at it should apply to join the "toolset core database" group (http://social.bioware.com/group/721/) and you'll get access to a project you can download the new database backup file from.

We're 'hiding' it this way simply to ensure that anyone who wants to test it comes to it with deliberate intent and full awareness of what they're going to be tinkering with. There's nothing really new or interesting here beyond that. If testing goes well and there's still a little while before the new toolset comes out we'll open it up to non-group members too.

http://social.biowar...kup_and_restore has information on how to back up and restore copies of your database, which can also be used to install the new database's backup file.

Modifié par BryanDerksen, 10 décembre 2009 - 11:06 .

[Allan Smith]

Just to clarify this a bit. This database has proper GUIDs in it, so if you export things from core, they no longer mess up your game. This will NOTclean up already corrupted save games, it just means that if you export from the toolset, subsequent savegames will not be corrupt, and the game should continue to work as it should.



As stated in other posts, we are waiting on game patch 1.02 before releasing another toolset patch, we are kind of tied to it. That patch is taking longer than expected, so this is an attempt to get you some help in the meantime.

[BryanDerksen]

The plot GUID bug only hits core plots that are already present in the retail version of the game. Basically, the database we sent out with the toolset had plot GUIDs that were different from those in the retail version, which meant that if you exported them you'd override the ones in the main game and the main game's scripts wouldn't recognize them any more.



Note that core resources can wind up being exported even if you're working on a stand-alone module, so if you're playing the main campaign at the same time you should take care to clear the core override directory whenever you play the main game. Other than that it shouldn't have an effect on your work.



See http://social.biowar...p/Plot_GUID_bug for more details about this bug.

[BryanDerksen]

This particular database release doesn't address any of the issues that could give rise to the "unable to connect to database" error, no. The upcoming toolset release will hopefully address many of them, however.

[BryanDerksen]

This database is intended to fix the known issue where the toolset corrupts the normal game via broken plot GUIDs in the core resources, so you should no longer have to clear the core override directory after exporting non-single-player-related resources.



Note that it's still quite possible to corrupt the normal game via stuff you do in the toolset, but it should no longer happen unintentionally. If you deliberately mess with core resources I can make no guarantees that they'll still work correctly with the existing main campaign.

[BryanDerksen]

Yes, unless you clicked on "export" at any point in that sequence of events I don't see how restoring the database could have any sort of direct impact on the game. The database is a toolset-only repository of information.



If this is a plot GUID issue my guess would be that you had exported something from the old database before switching to the new one and that exported stuff was still sitting in the core override directory. Check to see if there's anything in there, if there isn't then this might not even be related to the toolset in any way.



However, this sounds similar to a bug report we got a little while back with the same symptoms - Shale "forgot" it had been recruited and reverted to the original conversation. In that case it seemed to be a result of a transient decryption problem with the DLC and the best we've come up with for fixing it is to revert the last good savegame. I'll ask you for you to send us your savegames and maybe we can get a better handle on that one this time, if this really is another example of the same bug.

[BryanDerksen]

What's happening there is that, since the conversation is being triggered in the wrong area, the stage the conversation wants to use isn't present. So the game doesn't know where everyone's supposed to stand and defaults to putting them at 0,0,0. In the case of the Dead Trenches that puts you on the bridge. For an outdoor area, you'd wind up at one of the corners of the terrain mesh.

[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.

[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 .

[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.

[BryanDerksen]

Kaldir II wrote...

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?

Yeah, if you haven't tinkered with the core resources you can safely remove them. In fact, it's advisable when making builder-to-player packages to not include them in it - uncheck the "packages/core" directory when packaging stuff up. That way if some other mod changes the core resources your mod and the other mod won't fight over who gets to override core.

Of course it means that someone could release a mod that changes core in a way that isn't compatible with other mods. But that's a bigger problem that probably shouldn't be the responsibility of mods that use vanilla core to try to fix.

[BryanDerksen]

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)? 

If we patch or extend the core resources I imagine one of our main QA goals will be to ensure that they remain backward-compatible with existing content. Otherwise all our DLC, or even the main campaign, would be at risk of breaking. So you should in theory not need to release an updated version of the module if the module is just using vanilla core.

[BryanDerksen]

stuntpope wrote...
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?

I don't know the real answer to why that decision was made. It could be that it was simply a case of "well, the toolset had to retrieve and compile these resource anyway since they're #included, we might as well take the single last step of exporting them as well so that when the designer tests his work he'll be sure to have the latest guaranteed-compatible stuff on his system."