55 réponses à ce sujet

[Werefox009]

Most of the TLKStrings are empty in that file (or at least the copy that I have of it anyway) but there are a couple that are not.



TLKString for plot name in the PLOT_PLOTS[0] structure has the value (in the DAO GFF Viewer) 5101:gen00pt_attributes. Its position in the file is at 0x01B0, with the first 4 bytes being the value 5101. The next four are the offset 0x0090 which when taken from the beginning of the raw data block (0x01A4) points to 0x0230.



The 4 bytes at 0x0230 are 0x0013 (19) followed by 2 byte chars for the payload gen00pt_attributes.



Now I exported the plt_gen00pt_attributes.plo file from the editor, so there is always the chance it has done something odd and decoupled it from files it would normally be linked to (and thus altered the file)

[tmp7704]

That's weird; the plot_name for "plt_gen00pt_attributes.plo" shows for me value of "21", both in GFF viewer and when reading the file directly. It's the one packed in ../packages/core/data/designerplots archive, i simply extracted it from there and didn't do anything to it. I'm not getting any note about any shared references when opening this one, either. 

I'll see if exporting it changes anything in the content for me but it'd be odd given the original process didn't do anything like that. Did you use any special way of exporting or just 'export with no dependant resources' or something like that?

Modifié par tmp7704, 28 décembre 2009 - 12:02 .

[Werefox009]

I've checked the version of plt_gen00pt_attributes.plo in the designerplots.erf and I get label = 21 and the next 4 byte reference as 0x0000.

I originally grabbed plt_gen00pt_attributes from within the toolset itself under the plot pallet window, in the directory _Global/Generic/ . Perhaps the second 0x0000 reference means to look in the .tlk file and a non-zero reference means to look elsewhere in the current file?

[tmp7704]

I imagine that would make sense. Although the talk tables are there to allow multiple versions for one string depending on the language selected by the user so i'm not sure how the local copy plays into it... Maybe if the string still kept the original StrRef of "21" it could be some kind of a cache, but you said it was a different value in the one you had. So honestly, it's confusing.

The alternative explanation could be maybe, if the file you checked was grabbed from the Toolset before the 1.01 patch, then maybe it was one of the instances of these messed up IDs in resources or whatever it was that the original Toolset had wrong, that'd lead to broken single player etc?

edit: on second thought, when you have that version with "5101" + reference in the *.plo file, does the generic viewer in the toolset show it as 5101, some other number or actual string which is potentially referenced by the other 4 bytes?

Modifié par tmp7704, 28 décembre 2009 - 02:16 .

[Werefox009]

It was shown in the toolset's generic viewer as 5101:gen00pt_attributes.



I've just done the 'Export without Dependent Resources' and got the exact same output as i did the first time. If I choose 'Export with Dependent Resources' I end up with a directory full of .nss, .plo and some.ncs files, and the PLOT_NAME TLKString still has "5101:gen00pt_attributes" as the value. (Both times the export is done via the plot pallet)



It is only when I open the containing .erf, load the plt_gen00pt_attributes.plo file, and then do a save as (not an export) that I get the results you are seeing (low id values).



Perhaps the tool set one I am looking at is for the demo project? Still very bizarre.

[tmp7704]

Yup it's pretty confusing. But seeing the generic toolset displays it as ID:Text leads me to believe your interpretation is correct and there can be (at least optional) "local" part of the string stored in the file, for whatever purposes. That'd mean the ID part which links to the talk tables is likely to be 4 bytes long rather than 8 like i thought.



Would be cool to get some official confimation one way or another, though.