192 réponses à ce sujet

[Apolyon6k]

Malcroix wrote...
Are you saying that on your machine you can edit DA2 save games with pyGFF without any problems, and load them in the game?

I changed the inventory size (and it worked fine) and made my Hawkette immortal to get by one boss(that option is not persistant, on next save it is deactivated).
I have no DLC active and it works without any problem.

[Mephales]

Malcroix wrote...

How can I swap the player morph, if I can't edit the savegame?

In the savegame, the player character morph data is stored not as a reference to a pre-existing MOR (this is true only to chargen presets and all the other characters), but as a block of some kind of raw data. The line used to reference the headmorph for all other characters is simply blank for the player character. So without a working savegame editor, I don't see how we can change the player headmorph (aside from trying to override the tints/textures/etc, which doesn't seem to 100% work now). 

I'm not sure why it shows up as blank while other binary data has a preview, but it there. If you click on it, the edit section does show data. In an older version, you can just copy and paste the text, in the latest version you can export to and import back from a file, and in any version you can click the item in the tree, Ctrl+C copy it, go to the other savegame, click on the player morph in the tree there, and Ctrl+V paste it.

Not that that's useful to you, given your current issues. Given the way it throws up a random string for the DLC name, and can't find the DLC (which indicates the id in the savegame is the wrong string...) there's got to be something wrong with my code to serialize the string table. If you don't edit any ECStrings or TlkStrings while using the latest version in Fast Save mode, do you have that issue? If not, does it happen in both modes when you edit strings, just one mode, or even one mode when you don't edit anything at all?

[Malcroix]

Mephales wrote...

I'm not sure why it shows up as blank while other binary data has a preview, but it there.

I mean, there are two lines related to player character's headmorph in the savegame. There is 16328 (Savegame_Appearance_Morph) with an empty ECString (which is normally used to reference the headmorph for other characters), and 16950 (Savegame_Player_Morph), a UINT8 with the big chunk of data.

Not that that's useful to you, given your current issues. Given the way it throws up a random string for the DLC name, and can't find the DLC (which indicates the id in the savegame is the wrong string...) there's got to be something wrong with my code to serialize the string table.

It worked for Apolyon6K - BUT he didn't have any DLC installed, and I have the Black Emporium, which is what the error message references (in French for some reason) when it's not simply empty. So it's not random, but rather related to the DLC, which messes up the operation of the editor.

This is further supported by the fact that Oghier posted the same exact problem in your project's Discussion. Only his error message names the Black Emporium in Spanish, while mine does in French (probably because I'm located in France, even though both DA2 and the OS are English).

If you don't edit any ECStrings or TlkStrings while using the latest version in Fast Save mode, do you have that issue? If not, does it happen in both modes when you edit strings, just one mode, or even one mode when you don't edit anything at all?

Before I start listing experimental results, just wanted to ask - seeing how pyGFF doesn't come with a readme or help file  - how does one properly use the Fast Save mode? What I've been doing is turn on the mode in the menu, and then Save As, replacing the original save file. Am I doing it right?

Modifié par Malcroix, 11 mars 2011 - 07:20 .

[Mephales]

Malcroix wrote...
Before I start listing experimental results, just wanted to ask - seeing how pyGFF doesn't come with a readme or help file  - how does one properly use the Fast Save mode? What I've been doing is turn on the mode in the menu, and then Save As, replacing the original save file. Am I doing it right?

Yeah, I need to make that a bit clearer, maybe a warning message when you try to save a file in Fast Save mode that was loaded in Full Load mode, or make it so you can Fast Save a file loaded lazily or fully, split up the behaviour somehow...  At any rate the simplest thing to do is just leave it on Fast Save both when you load and save files. Lazy Load and Fast Save use the same load functions, but different save functions. Fast Save uses as much of the existing file as possible to keep it as similar as possible, while Lazy Load (and Full Load) build the file from scratch.

I regret choosing to have Gamestop mail me DA2 instead of doing instore pickup.

Also, I'm thinking I might need to make a google code project... I'm only a few hundred KiB from the filesize limit.

[Thought Process]

Testing with one of my saves, loading & saving in Full Load and Lazy Open seems to work correctly. Fast Save does not save strings correctly.

[Mephales]

Thought Process wrote...

Testing with one of my saves, loading & saving in Full Load and Lazy Open seems to work correctly. Fast Save does not save strings correctly.

Well. Hmm.
(15 minutes later)
I was going to say... well, I was going to put this down, play some Awakening, and start working on this tomorrow when I have an actual copy of DA2 in front of me to test with. I only have the save file you gave to test with, after all. But then a remembered, there was another GFF V4.1 file I used to test with. Before I wrote Fast Save... And I remembered. It had two empty strings in its string table, not just one. And I had been treating strings as unique.
Which is fine if I'm rebuilding the entire file, because apparently I'm better at actualling checking for uniqueness than Bioware ...But it's not good when I'm building off the original string table like I do in Fast Save mode. So...

I'll have a new version up tonight. It'll include the fix for this issue, along with a few tweaks. With luck, that's the issue. Easy way to check using the current version, if you open that file that doesn't load properly, are the strings in the addin section mismatched? Say... Off by one?

[Thought Process]

The off-by-one was the impression I got, yes.

[Mephales]

OK, new version uploaded. The issue I found that I think is the one Malcroix and many others are experiencing has been fixed. I also took away Full Load, and made Lazy Load and Fast Save independent options. Full Load would be Lazy Load and Fast Save disabled, while the old Lazy Load would be Lazy Load enabled and Fast Save disabled, and the old Fast Save would be both enabled. I also added a second edit field to 4- and 8-byte integers that lets you edit them as if they were floats/doubles, after the discovery that the elements of a ITEM_PROPERTY_POWERS list sometimes make more sense as floats. Perhaps I should add a checkbox to uint8, since they are so often booleans?

Anyway... I really hope that non-uniqueness issue was the problem.

[WuWeiWu]

I feel incredibly awkward for asking this question here - I have absolutely no idea about what has transpired within this thread. I'm able to follow the conversation a little bit, and I have a simply worded question:

Let's say I want to edit the damage done by Chain Lightning. How would I go about that?

Reading through the thread, I am to assume the game (or the editor?) doesn't reference filenames or anything directly but with a hash number? For reference... I tried to open the 2da.rim in your editor and select abi_base.gda; I then expanded 10003 and found the entry labeled 302030, MAGE_PRIMAL_2_CHAIN_LIGHTNING....

Expanding that gets me a slew of numbers that mean nothing to me. I don't really know what I'm doing, and feel badly asking a question this simple amongst a very informed thread. Is there a reference somewhere, where I could look and go, "Oh hey, changing this number corresponds to this effect within the game! Cool beans"?

Would appreciate it any help/information!

[Mephales]

Well, I'm definitely not as knowledgeable as many in that area... However, I do know that normally you'd want to learn about 2DA's in general and abi_base specifically. social.bioware.com/wiki/datoolset/index.php/2DA , social.bioware.com/wiki/datoolset/index.php/Ability, social.bioware.com/wiki/datoolset/index.php/ABI_base.xls would be informative in that regard. Something about using abi_base.xls as a template and making a xls with only the rows overriding whatever spells you want to override, however you want to override them, then compiling it with the tool included with the toolset, making it a mod, whatever.

However, last I knew, even the simplest attempts at modding were failing, like model swaps or simply extracting the abi_base.gda, editing in my editor or GDApp, and placing it in the override directory (or not even editing it).

And yeah, this thread has gone a bit beyond announcements of new releases.

[Malcroix]

IT WORKS!

Congratulations, Mephales, you're a master of modding!

This will probably make so many things so much easier, especially in light of what Bioware did to the override mechanic.

[Mephales]

Malcroix wrote...

IT WORKS!

Congratulations, Mephales, you're a master of modding!

This will probably make so many things so much easier, especially in light of what Bioware did to the override mechanic.

Thanks. I wouldn't even call myself a modder though

Looks like it's also been useful in the technical self-help arena: social.bioware.com/forums/forum/1/topic/300/index/6459070/1

[Malcroix]

I was tipped that pyGFF can be used to identify the full directory structure encoded in the erfs. As this seems to be necessary to properly override resources, can anyone explain how to make pyGFF do this?

EDIT: Okay, I guess I'll need the database that's a separate download.

Modifié par Malcroix, 13 mars 2011 - 04:27 .

[Mephales]

I uploaded 0.5.0.. No major changes. I changed the filenames I generate for nameless files in ERFs, I added a talktable downgrader tool shamelessly stolen from Thought Process, and I also added the ability to run arbitrary python scripts against the currently loaded GFF.

Edit: And 0.5.0a is up. Apparently editing any of the complex type (Vector3f, Vector4f, etc) was bugged, and someone finally reported it.

Modifié par Mephales, 14 mars 2011 - 12:36 .

[tazpn]

I have an update to your hash db.  Looks like it adds about 20000 more filenames. It also appears that you have not made the current db public so the database cannot be downloaded so these changes likely need to be merged in.
fnvhashes-20110313-tzupdate.7z

[Thought Process]

I would like to suggest having the zero-terminated checkbox checked as default, I imagine most things in DA/DA2 are going to treat these as c strings and not look at the length when using these values. I ran into this as an issue (didn't really notice) when adding new entries to item_variations -- they wern't showing up until I checked zero-terminated for all strings in the new entries.

[Mephales]

Thought Process wrote...

I would like to suggest having the zero-terminated checkbox checked as default, I imagine most things in DA/DA2 are going to treat these as c strings and not look at the length when using these values. I ran into this as an issue (didn't really notice) when adding new entries to item_variations -- they wern't showing up until I checked zero-terminated for all strings in the new entries.

Hmm... I'm not sure. If it's GFFV4.1, for instance, I actually make sure each string only has one null-byte, it's terminator. With V4.0... I suppose if they're treating them as wchar c-strings, though I've never heard the like before. I'll think about it.

[thestillwind]

Great work it's really appreciated !

[Mephales]

tazpn wrote...

I have an update to your hash db.  Looks like it adds about 20000 more filenames. It also appears that you have not made the current db public so the database cannot be downloaded so these changes likely need to be merged in.
fnvhashes-20110313-tzupdate.7z

Yeah, it was public, but then when I uploaded 0.5.0a it went back to group-only. I'll merge those in.

Edit: Yeah, merge, that's right... Given that the result of the merge has the same number of entries as your database, I'd say the answer is: No, they didn't need to be merged in.

Modifié par Mephales, 14 mars 2011 - 04:37 .

[Thought Process]

Mephales wrote...

Hmm... I'm not sure. If it's GFFV4.1, for instance, I actually make sure each string only has one null-byte, it's terminator. With V4.0... I suppose if they're treating them as wchar c-strings, though I've never heard the like before. I'll think about it.

By 'c string' I meant null terminated strings in memory, regardless of what encoding (wchar_t* etc). Lots of wchar_t*s get passed around assuming they have a null terminator from what I've seen. For example, the FNV implementation hashes up until a (wchar_t)0.

Edit: I believe the related files were all 4.0.

Modifié par Thought Process, 14 mars 2011 - 04:25 .

[Mephales]

Thought Process wrote...
By 'c string' I meant null terminated strings in memory, regardless of what encoding (wchar_t* etc). Lots of wchar_t*s get passed around assuming they have a null terminator from what I've seen. For example, the FNV implementation hashes up until a (wchar_t)0.

Edit: I believe the related files were all 4.0.

Alright, I've made the change, next version it'll be default... But not tonight, I'm going to bed.

[Thought Process]

That's fine, was just pointing it out.

[Mephales]

Thought Process wrote...

That's fine, was just pointing it out.

And it'll be the next-next version after all... I whipped up a big-endian version for a xbox 360 owner who has the perma-slow Hawke bug, and technically it is a new version

Edit: And now 0.5.1 is out, with new strings being zero-terminated by default, and the editor now supports both little- and big-endian files at once. Don't know which PS3 files are, but I'm assuming big-endian because the PS3 is PowerPC...

Modifié par Mephales, 14 mars 2011 - 04:43 .

[tazpn]

Another tool to help with the gathering of hashes, not that anyone asked for one.  Place this together with the sqlite database into the bin_ship folder of the game.  The winmm file will intercept the hash requests and compare them against the unknown hashes in the unkhashes database provided here.  It will add found matches to the normal database as it goes. It will automatically remove them from the unknowns as it finds them and generates a log at the same time. 

It will cause stuttering and slowness in the game due to the sqlite database updates taking a relatively long time to update the db.  Turn off autocommit in the ini for slightly better times but db will only be updated when exiting the game.  It was only tested with the original shipping version of the game and would likely break with newer builds.  Delete the files to uninstall or set Enable to 0 in the ini file.

fnvhashes_gatherer.7z

[Thought Process]

Heh, I did something like that myself. That's where a majority of my list came from.