I'm still looking for the relationships between the database tables that tell the programme what to use and what to print so we see text instead of the reference ID'.
It shouldn't be this difficult but darn it I really can't find the name for the base material, the tier level ect ect.
Any answers?
Text to reference ID's
Débuté par
Sidrat2009
, févr. 27 2010 07:14
Retour en haut
#2
Posté 27 février 2010 - 08:54
CID-78
-
- Members
- 1 124 messages
those are likely to be represented by a number in the database which is translated by reading a .2da that contain the extra information.
#3
Posté 28 février 2010 - 01:19
Sidrat2009
-
- Members
- 25 messages
Perhaps they could have made it easier by encrypting the files first.
There must surely be relationships in the existing database right?
There must surely be relationships in the existing database right?
#4
Posté 28 février 2010 - 03:41
TimelordDC
-
- Members
- 923 messages
The IDs reference the Single Player talk table which you can view using Tools -> String Editor and selecting the Single Player talk table.
Are you looking for database tables containing this information?
Are you looking for database tables containing this information?
#5
Posté 28 février 2010 - 07:59
nezroy
-
- Members
- 99 messages
You are still under the mistaken impression that everything is in the database, and it isn't. Most of the important relational content is stored in the 2da files. A lot of this stuff can be inferred from the database, and there are certainly duplicated instances of 2da data in the DB, but the canonical source for the majority of relational game data is in the 2das. Just like meshes and textures are stored externally as well. The database is used as a tool for organizing and exporting SOME of these things (i.e. I'm pretty sure item UTIs are generated entirely from DB content).
But anyway, more specifically to your question, as TimelordDC mentions, most of the strings are in the talk table. Which is in the DB, lucky you
From looking at it briefly, t_String connects string IDs with their string table IDs (which are defined in t_StringTable), and t_StringText contains the actual text for each string. So:
select * from t_String, t_StringText where StringTableID = 1 and ID = StringId
Gives you all the strings from string table #1 (I believe the core string table is 1 and the single player string table is 2). However t_StringText also has multiple versions of strings, with the "current" version being defined elsewhere (presumably t_StringVersion, but I didn't dig that far). I'd guess that you can somewhat safely assume that the highest version number is current.
Of course the game doesn't actually read strings from the DB, it reads them from a talk table that gets exported from the DB. This is important because the toolset DB is not guaranteed to be up-to-date with the actual talk table being used by the current game version. Though in practice I doubt you'd find many inconsistencies.
However if you want a guaranteed accurate representation of the data the game is using, the actual talk tables, etc. from the core/single player ERFs would be the thing to parse.
But anyway, more specifically to your question, as TimelordDC mentions, most of the strings are in the talk table. Which is in the DB, lucky you
From looking at it briefly, t_String connects string IDs with their string table IDs (which are defined in t_StringTable), and t_StringText contains the actual text for each string. So:
select * from t_String, t_StringText where StringTableID = 1 and ID = StringId
Gives you all the strings from string table #1 (I believe the core string table is 1 and the single player string table is 2). However t_StringText also has multiple versions of strings, with the "current" version being defined elsewhere (presumably t_StringVersion, but I didn't dig that far). I'd guess that you can somewhat safely assume that the highest version number is current.
Of course the game doesn't actually read strings from the DB, it reads them from a talk table that gets exported from the DB. This is important because the toolset DB is not guaranteed to be up-to-date with the actual talk table being used by the current game version. Though in practice I doubt you'd find many inconsistencies.
However if you want a guaranteed accurate representation of the data the game is using, the actual talk tables, etc. from the core/single player ERFs would be the thing to parse.
#6
Posté 28 février 2010 - 11:00
Sidrat2009
-
- Members
- 25 messages
Thanks for the replies I feel lucky in that there's another method to learn how to learn with.
I wonder why they chose the dual front system (database and spreadsheet) any ideas?
Oh yes also which version of the 2da' is the safest to use for generic purposes (to display not to edit)
I wonder why they chose the dual front system (database and spreadsheet) any ideas?
Oh yes also which version of the 2da' is the safest to use for generic purposes (to display not to edit)
Modifié par Sidrat2009, 28 février 2010 - 11:01 .
#7
Posté 01 mars 2010 - 01:35
Challseus
-
- Members
- 1 032 messages
Sidrat2009 wrote...
Thanks for the replies I feel lucky in that there's another method to learn how to learn with.
I wonder why they chose the dual front system (database and spreadsheet) any ideas?
Oh yes also which version of the 2da' is the safest to use for generic purposes (to display not to edit)
All the 2DA's under the Source/2DA directory should be fine. As far as I know, the only time a 2DA will change is with a patch (if Bioware so chooses to add to it). That note you saw on a few spreadsheets saying something like, "This 2DA is auto-generated", ignore that.
#8
Posté 01 mars 2010 - 09:36
Proleric
-
- Members
- 2 361 messages
To find a string's reference id, you can filter the string editor on that text.For example, filtering on "Hurlock" shows that the creature name string is 158146.
The owner tells you which object has the string as a property. The ones that are only in 2DA files tend to have owner=None, for example 395038.
To find the 2DA file, do a text search for 395038 on the contents of Source/2DA including sub-folders (if your OS doesn't do that, try FreeCommander).
This particular example illustrates that some strings don't even seem to be in the 2DA. Some might have been depecated, but I suspect there's more to this.
The owner tells you which object has the string as a property. The ones that are only in 2DA files tend to have owner=None, for example 395038.
To find the 2DA file, do a text search for 395038 on the contents of Source/2DA including sub-folders (if your OS doesn't do that, try FreeCommander).
This particular example illustrates that some strings don't even seem to be in the 2DA. Some might have been depecated, but I suspect there's more to this.
Modifié par Proleric1, 01 mars 2010 - 09:36 .
#9
Posté 01 mars 2010 - 11:38
Sidrat2009
-
- Members
- 25 messages
Woah holy organisation skills.
I've been playing the game and thinking about consolidating the 2da and sql database into one package, keep it semi or fully automated to help when patches/updates are released.
But even when that's done it'll be a nice process of making the relationship table do it's magic, in the meantime I'm still enjoying the game.
I've been playing the game and thinking about consolidating the 2da and sql database into one package, keep it semi or fully automated to help when patches/updates are released.
But even when that's done it'll be a nice process of making the relationship table do it's magic, in the meantime I'm still enjoying the game.
