51 réponses à ce sujet

[Chronovore]

I've been comparing the DLC talk tables to the talk tables exported by the toolset. Things SEEM to be in order with just a quick skim with a HEX editor. We can access the entries in the talk tables with scripting using the StringIDs spat out by the string editor, but using the same IDs in the 2DAs doesn't seem to work properly. Perhaps it's not an error in the talk tables at all, but in the way 2DA and string tables are related under the hood?

And thank you VERY much for looking into it!

Modifié par Chronovore, 19 novembre 2009 - 08:53 .

[BryanDerksen]

Okay, it looks like it isn't really a case of "extending the core talk table". All of the talk tables loaded by the game go into one big talk table, so when you're creating a module with new abilities in it you should put the ability names into the module's talk table. I'm just looking at some of the abilities added by the Grey Warden Base 2DA and their strings are in the Grey Warden Base talk table. They're set to string type "Talent", that might be something to look at - as far as I'm aware the string type is for organizational purposes only, but perhaps GUI-related stuff is special and actually cares about that.



The core talk table's stringIDs match up when I compare the end user toolset's core talk table and the development talk table, and with the 2DA entries, at least at a quick glance. Chronovore and andyr1986 (or anyone else for that matter), when you say that the string table and 2DA stringIDs don't match up, could you give me an example?

[Chronovore]

Sure, in an earlier post in this thread, I showed this:

class Name NameStrref TalktableID

SHAPESHIFTER 238071 38

SPIRITHEALER 238072 39

CHAMPION 238073 40

TEMPLAR 238074 41

BERSERKER 238075 42

REAVER 238076 43

The first column is the class name, the second column is the NameStrref field from the class_BASE.xls and the 3rd column is the ID of the string in the Core Talktable that is associated with the entry.

[BryanDerksen]

Hm. As far as I'm aware, there's nothing special about string references in 2DAs. They're just integers like any other integer, it's how you use them that counts. These ability names and descriptions are a GUI thing, not a script thing, so perhaps it's not really a 2DA problem at all; perhaps the GUI isn't able to handle being fed string IDs outside of a certain range. Maybe try creating your ability names with string IDs down closer to the 500,000 range that we've been using so far? (you can change the string ID range used by a module in the module properties table)

[Chronovore]

I'll try it out as soon as I get home.

[dan_upright]

I'm sure I saw something about adding some large number to the string reference before you used it in a 2da - I'll see if I can find the wiki page again.

http://social.biowar...#Adding_Strings

Adding 16777216 to the talktable id as that suggests doesn't match up with the numbers you posted but it at least shows there's something wonky about strings in 2das. If adding 16777216 to your talktable id doesn't work, try 238033, since that seems to be what they've done in class_base.xls.

Modifié par dan_upright, 19 novembre 2009 - 09:22 .

[Chronovore]

The large number trick doesn't work either. The offsets of the strings from 2DA to String Editor vary from various blocks. In other words, it may have worked for whatever the writer of the wiki entry was trying to do, but it isn't a cure all offset.

[BryanDerksen]

I'm not sure where you're getting string IDs 38 through 43 from, in my core talk table they're all just blank strings that are associated with some core plots (such as gen00pt_combos and gen00pt_class_race_gend).



I'm going to reinstall the currently-released version of the toolset and see if we somehow managed to screw up the talk tables along with the plot GUIDs.

[BryanDerksen]

Okay, just got a reinstall of the original end user toolset up. Looks like the talk table that went out with the original release of the toolset has messed-up string IDs. I have no idea how that happened. On the plus side, the new version that we're going to be releasing Real Soon Now has correct string IDs, so the problem is already fixed (hence some of my earlier confusion in this thread). So whatever we did the second time around we did better than the first time around.

[Adaram]

For those of us still learning about all this stuff, can anyone confirm that this has no impact on our current single player campaign so I won't worry about using the toolset prior to the patch?



Thanks.

[Chronovore]

Yeah, I figured something like that was the most likely culprit since when you export the talk table, all the GUI strings disappear. :-D Good to know what it is and good to know that it's fixed, even if we don't have the fix yet. Thanks so much Bryan!



Adaram, it doesn't affect the base single player at all unless you export the string table. (but that's easily fixed by deleting the exported string table from the override directory.

[BryanDerksen]

Adaram> As Chronovore says, however bear in mind that the plot GUID bug is still in full flaming effect right now and that could mess up your single player game quite thoroughly if you're not careful. See http://social.biowar...p/Plot_GUID_bug for more details.



Since this is now the second major thing wrong with the core database released with the first version of the toolset, we're looking into the possibility of a pre-patch release of a corrected database. Stay tuned. If all else fails, though, new toolset should come out next week on or shortly after the game's patch release.

[elys]

BryanDerksen wrote...

Okay, just got a reinstall of the original end user toolset up. Looks like the talk table that went out with the original release of the toolset has messed-up string IDs. I have no idea how that happened. On the plus side, the new version that we're going to be releasing Real Soon Now has correct string IDs, so the problem is already fixed (hence some of my earlier confusion in this thread). So whatever we did the second time around we did better than the first time around.

While working on my GDA editor, I noticed the ExcelProcessor provided with the toolset does not convert properly high integer values.

Basically the INT from the GDA is slightly different from the INT in the XLS, which as you can guess will mess things up when using such integer values.

So I've looked at it and noticed the ExcelProcessor somehow handle INT32 as FLOAT(32b) during at least one phase of the conversion process.

Float can only store precisely integers between -8388608 .. 8388607.

So as soon as you add 16777216 to your strref in the  XLS, you are already way pass that limit, resulting of an integer approximation in the GDA.

For example: 50001 + 16777216 = 16827217, but once converted with the ResourceBuilder, if will be resulting to 16827218

Until this is fixed, modders should load their produced GDA files into the toolset, and verify that values are correct. You can correct the values in the toolset, unlike the converter, it works with integers correctly.

Modifié par elys, 19 novembre 2009 - 11:19 .

[BryanDerksen]

Fantastic catch, elys. I'm going to be copying and pasting this pretty much unchanged directly into our internal bug tracking system.



Needless to say, we never had 2DAs with row IDs above eight million during internal development.

[Proleric]

Will the patch address the visibility of Core and Single Player text in the string editor? Right now, I can't see most of those strings - it's as though the objects in question were never checked in to the data base. For example, try finding the codex entry for Hurlock.

[AnTeevY]

So with the correct string IDs, we just will to use the exact string ID of our text in our M2DA and it works? No offset or the like?

[Chronovore]

Well, I tried it and got it to work last night once, and then I promptly broke it again.

Right now the process is:

Alter the 2DA with StringIDFromEditor
Run the 2DA processor on that file
Open the GDA in the toolset
Find the row of the 2DA that you altered and make sure the stringID is StringIDFromEditor

Edit:  Got back home and discovered that it was the strings that DIDN'T have the offset added to them that displayed in-game.  I apologize for the confusion.

Modifié par Chronovore, 20 novembre 2009 - 11:14 .

[stuntpope]

I tried your process Chronovore and it didn't work for me. Not that it would be a satisfactory way to work anyway as you would have to re-edit the whole GDA every time you made a change to the 2DA.

[AND04]

nice nice nice gona tray that asap

[Lieutenant08]

I tried Chronovore's method using Talents within ABI_base.xls and it did not work for me either. Here's what I have:
String Editor:

• type = Talent,
• stringid = 2076000847 (Blessed Heal)

Module Properties:

• StringStartID = 2076000847
• StringEndID = 2076000861
• LastStringID = 2076000861

Processed ABI_base_mymod.gda:

• Row0 Col3= 2076000847 (This did not work)

tried again with:
Processed ABI_base_mymod.gda:

• Row0 Col3 = 2092778063 (2076000847 + 16777216 This did not work)

If I add a higher starting StringID the String Editor starts at that value. Chronovore can you list out the complete process you used to get it to work?

[Chronovore]

Unfortunately I'm not at home right now, so I can't create a full step-by-step with pictures and such.
Unless someone else can post a walkthru of it  before I get home (about 5:30PM EST) I'll whip one up as soon as I am home.

For now, here are the basic steps with a bit more detail than I showed before.

• Open the 2DA you wish to edit.  Edit the stringID to equal the stringID given by the String Editor
• Run the Excel Processor on the 2DA
• Open the resutling GDA in the toolset
• Find the row of the StringID and replace it with the stringID you originally put into the 2DA
• Save the file
• I threw the final GDA into the Module/Override directory to test mine.

I'm not able to reproduce these steps here at work to verify them since they frown upon games while working, but I'll definitely work on it when I get home.

By the way, here's an image showing the results of my changes.
http://social.biowar...ums/299413/9365
Edit:  I got home and discovered it was actually the strings that didn't have the offset that worked in game.  Sorry about the confusion.

Modifié par Chronovore, 20 novembre 2009 - 11:16 .

[Chronovore]

stuntpope wrote...

I tried your process Chronovore and it didn't work for me. Not that it would be a satisfactory way to work anyway as you would have to re-edit the whole GDA every time you made a change to the 2DA.

I agree.  Elys' editor sounds very promising to me.  For now though, until they correct the Excel Processor's large integer handling, this is what we have to work with.

I suppose a way to save time would be to just create your 2DA entries, process the file, and then edit the StringIDs in the toolset without entering them in the 2DA first since we KNOW they'll be wrong after processing.

[AND04]

@BryanDerksen:

Another thing i encountered is, if you edit a existing talk-table (.tlk File) with the Toolset and save it everything works fine - but if you add or "copy/paste" an entry it screws the whole thing up - I guess it has something todo with the fact that all the most outer entrys are numbered - but we can't apply numbers to them ourself - if i edit it to a numeric Value the toolset instantly adds "Label" in front of it.

[elys]

For those who wanna verify the StrRef value once converted into the GDA, I've uploaded an early version of GDApp, the GDA editor I'm working on when I'm not being lazy

While GDApp is not currently in a state to be used happily as editor due to its crappy GUI, it can however for now be used to verify values quickly, instead of browsing thru the GFF tree in the toolset.

Modifié par elys, 20 novembre 2009 - 07:02 .