Talk:2DA

From Dragon Age Toolset Wiki
Jump to: navigation, search

Objection to some of the article changes

I'm writing this here so I don't start getting into the habit of mashing the undo button on changes I disagree with, but I think some of the recent ones are losing important information in the process of trying to make it more understandable.

I'll outline here what I'm taking issue with... not as a point-by-point nitpick, but just the sort of changes that make my undo-button-finger twitch.

Extending the game via M2DAs

  • I think the original was much clearer, and stressed the fact that BioWare might change the 2DA file itself, which would make your modifications to it out of sync. The latest revision makes it sounds like BioWare might have conflicting changes, maybe because of the row IDs chosen - which probably won't be the case unless you've ignored the reserved 2DA range to begin with.
  • Leaving out how 2DAs in the 10000-10999 range are treated exactly. The more explicit, the better - if somebody's reading this article for the first time, what are they to assume they're treated as if not M2DAs?
  • I think it's clearer if we keep referring to "worksheet" rather than "name".
  • I've read this statement a few times, but I don't know what it's supposed to mean: "References must then be made aware of the M2DA_base, instead of the single 2DA."

Guidelines

  • I thought it was clear enough saying "an integer row ID" instead of "a row ID"... it tells you the column type at least, even though you could see it in 2DA examples anyway.
  • Changing "that is unique to that row across all files (unless creating an M2DA override)." to "that is unique to that worksheet and therefore 2DA (including any added M2DA)" loses the information about creating an override this way.

Excel file formatting

  • The previous line "When extending a 2DA, new ID's have to be given, and Columns have to be exactly the same." seems succinct and understandable to me. But the last part of the latest edit makes no sense to me: "When extending a 2DA, new ID's have to be given, and Columns have to be exactly the same as the game references its name vs the row ID."

--FollowTheGourd 00:44, 29 January 2010 (UTC)

    • Objection. I had following reasons. Sometimes it is better to remove explicity, sometimes better to add.
    • I think that "Integer Row ID" is too much, row ID's are just numbers, and if you say a "number row ID" it makes more sense to say "a row ID number". At least "Number" isnt such a strange word which everyone knows. Integer makes it sound like there is hidden ID's to me.
      • Proposal: remove "Integer"
Maybe. I suppose it's a matter of taste, but I'd prefer "integer row ID" to "row ID number" or "integer row ID number" if we went the simplifying route. I don't understand how integer could make it sound "hidden", though. If somebody is altering 2DAs, I'd assume they know what an integer is. --FollowTheGourd 06:15, 30 January 2010 (UTC)
Eshme Hmm this is a language thing by part. You know how "Integer" sounds with my german roots? Like a word from outerspace. Integer in my language is somewhat tied to the latin meaning of being sober. Thus i assumed there are ID's which are "different". Perhaps that explains. I assume this is different for someone from england. My take is that someone who is experienced enough to know what "Integer" means, will probably already know what Numered IDs are. If your taste allows, then.. ;)
    • "that is unique to that row across all files (unless creating an M2DA override)"
      Isnt that wrong? The ID is unique, but its not unique across all files. For example almost every 2DA has a "ID 1" So it is just unique across the single 2DA isnt it? And it is also unique across an M2DA, and "unless" makes it sound like unique doesnt matter for M2DA. Who knows.. but this is my experience.
      • Proposal: undo conflicting change, perhaps find better explicity than worksheet and therefore
Good point; it's easy to overlook that by "reading the right thing" and interpret that as all the M2DAs that comprise the 2DA instead of all M2DAs everywhere. But the previous change still didn't seem quite right to me either. Perhaps simply change all files to be more precise instead of rewording the rest? --FollowTheGourd 06:09, 30 January 2010 (UTC)
Eshme I know... but its still wrong. Perhaps: "...that is unique to that 2DA (including M2DAs).." Or just "..that is unique to that 2DA or M2DA.." without the brackets. Either is right to me. Being unique to the row is a given. "The ID is unique to that row.." how does that sound! thats like "the first line is unique to Line 1". hehee.. The ID is unique only to the 2DA.
Or "2DA row ID numbers need to be unique across all currently active addins for any given 2DA". this is taken from Scripts, which sounds more accurate than i could say it. However remove the italized text. How about the latter?
    • "since BioWare might release an update to a core table at a later date that would overwrite any changes third parties had made to it"
      The problem here is that Bioware doesnt overwrite things. It is a conflict, that actually the modder overwrites with the override folder. And Bioware isnt the only one who adds things, so. M2DA's purpose as i understand it, is to use a blank sheet, and then conflicts are cut irrelevant in the first place. It can however be noted that Bioware reserves edits the existing M2DA. There is no "might" to it thou because M2DA's purpose is also to destinct from other modders, and should find a better word for it than "Coretable" thou, if that is what it means.
      • Proposal: undo conflicting change, and remove explicity "for modders only", and only explain why M2DA are made from a unique worksheet or something like that.
Couldn't they, though? What if there's a patch that updates the GDA files or they create a "patch erf" with another complete copy of M2DA_base instead of just extending it. Maybe there's a better phrase than "core table", but it sounds good to me. If anything, perhaps we need to also stress the need to extend M2DAs properly so modders won't have conflicting changes with each other - not just with BioWare. --FollowTheGourd 06:09, 30 January 2010 (UTC)
Eshme They could. But likely there are more user mods than Bioware to release patches. Funnily user mods take precedence over Biowares patches. It should thus not be onesided, that is correct. (You see many things are onesided here on the wiki, because they are made prior to release.) Or perhaps rephrasing the whole paragraph is needed to accompany any changes. Perhaps noting properties of the table that is displayed so that readers get the picture. May you find words for it? I have difficulties with it.
    • " References must then be made aware of the M2DA_base, instead of the single 2DA."
      The purpose was to destinct entries in the M2DA base, with the parts of the game that is responsible for handling M2DAs. An entry there doesnt automatically make a 2DA an M2DA, if other parts dont take reference of it. For example the Script or whatever handling the BITMbase will take reference to the M2DAbase since it is programmed that way. A script handling a normal 2DA will be programmed to only reference that 2DA. If you put this 2DA in the M2da base, nothing will change. Therefore ,and if my english wasnt good enough, someone else should explain that, or at least note in short words which is all i tried.
      • Proposal, undo conflicting change.
I still don't understand to be honest. Can you give a more complete example of what you mean? I've extended M2DA_base in a working mod, and I didn't have to do anything special to read the new rows. --FollowTheGourd 06:09, 30 January 2010 (UTC)
Eshme I had assumed by reading the rest of the article, that for example the 2DA "attributes", cannot be extended. Because its not listed in the M2DAbase. I know that Scripts read from the 2DA directly with some orders i havent a clue about scripts really. When you add "attributes" to the list, will additional M2DAs work or not? I mean without writing Scripts or doing something fancy, like i do with M2DAs that are already in the list?
Well in the end i see few 2DAs, so perhaps it doesnt matter to a modder. o)
    • Eshme 16:13, 29 January 2010 (UTC)
Well no opinions anymore? Gona change 1 and 2 again as proposed, and someone needs to do something bout point 3 Eshme 00:27, 5 February 2010 (UTC)

M2DA_base

Reminder to check, but is the base name of M2DA_base actually just M2DA, so instead of extending it with M2DA_base_MySuffix you could instead do M2DA_MySuffix (or even just M2DAMySuffix but less clearly.)? It's just when looking at other mods for compatibily, I happened upon this, so it would appear so at first glance. --FollowTheGourd 06:47, 28 January 2010 (UTC)

Page split

Undid the latest change since I think a lot of that information needs to go in a separate subsection instead of how to simply convert an XLS to a GDA. Also, the title made it sound like dragging GDAs into the toolset itself in order to somehow convert them. Anyway, I think it's just adding to the confusion of the article if the edits are more incomplete and questioning sentences that would be better asked in the article's talk page instead. --FollowTheGourd 00:31, 27 January 2010 (UTC)

Well i would have prefered the convert stuff in a seperate page anyway, since this page is rather long for a somewhat title page for 2DAs. It should be enough to know there is a excelprocessor here. What i would rather see here is examples, and links further into the topic. Right now it mainly links to other XLS's ,and that are pretty hardcore pages he he and just plain data. Eshme 00:49, 27 January 2010 (UTC)
Maybe a "Converting 2DAs to GDAs" page (or something better named)? --FollowTheGourd 00:55, 27 January 2010 (UTC)
Hmm yup. Perhaps it can also explain how to get them recognized, and precautions to do when creating builder to player stuff. But i do not know how big topic that is. I assume that either is ok. But my reason is thst is because I have only yet made one GDA which works when i copy it to the games directory. But it doesnt get included into builder to player. So i assume i still did something wrong sniff i dont know Eshme 01:18, 27 January 2010 (UTC)
I've created compiling 2DAs, which seemed like a nice succinct way of labeling the process. I also pulled that old list of XLS files out of here, it was a bit of a space-waster now that there's categories to keep track of stuff. Perhaps the list can be rewritten as more of a guide on how to find the 2DAs you need to edit for specific tasks, or something along those lines. BryanDerksen 17:23, 28 January 2010 (UTC)

Overview section

I would have prefered to have the Overview Section describing what 2DA's do and how they fit into this seemigly big topic, rather than describing what 2DA's can do and that they are made of Rows. Obviously i failed with that with the bloomy texting. I am trying to figure out this stuff myself, so may not have been correct anyway. But i would really like someone to explain so i can understand. Eshme 17:41, 25 January 2010 (UTC)

If you're wanting to know what 2DAs do as in what role they play in the game I think it may be too big a topic to fit comfortably into an "overview". 2DAs are used to define creature appearances, worldmap destinations, spell effects, achievement values, talents, shapeshift properties, item properties, placeable appearances, etc., etc., etc.. - there's nothing inherent in the nature of 2DAs that make them do any one particular type of thing. The only thing that they all have in common is that the 2DA contains rows of data with a uniform pattern of columns.
The 2DA#2DA_XLS_files_used_in_Dragon_Age section of the page could perhaps be rewritten into something more like what you're talking about, I think. Instead of simply listing 2DAs it could describe how some of the more important ones are used in the game. Is that more what you were after? BryanDerksen 01:00, 27 January 2010 (UTC)
Yep this would be great. What i initially had in mind with the overview was clear up the topic. When i first read 2DA i had the impression that whenever i create something i have to conjure a rabbit out of a hat. But i hadnt realized that the game already knows what columns to look for, and every 2da looks so different but in the end it only matters for the script or whatever that reads them, and that those are having the specific task to read the 2da in the way as they are ,and that is the reason they all look different. And that editting 2DA only means extending rows, and not columns. And that the existing 2DAs and the XLS to it are actually part of the running game! Which is actually the part that had questioned me the most. Many people just take the XLS and adjust it with their needs, without realizing they actually broke the source. And that M2DA are no magic and receive the most attention to modders, not a sidetopic. That is what i initially had in mind. Albeit i dont know too much more about them. Eshme 01:39, 27 January 2010 (UTC)

Adding strings?

Adding Strings?? How is this useful? Do you need to enter Strings into the Toolset String editor somewhere? I had made a 2DA now with a few "strings" and i entered them with Openoffice just like i think, and it worked seemingly. At least this part i think. I would rather move this somewhere else if it doesnt include any normal 2DA stuff Eshme 22:33, 24 January 2010 (UTC)

To be honest, I have no idea what that section is on about either. There is no "StringID" column in ABI_base.xls, so were they talking about those *strref columns and maybe if you make them **** then it uses the label instead? I'd second moving it out of the 2DA section and maybe the original author clarifying it. It's just confusing otherwise. --FollowTheGourd 02:22, 26 January 2010 (UTC)

Column case sensitivity

This section doesn't seem very accurate: "Column names are case sensitive. This is because of the CRC32 algorithm used to generate the hash key. Changing the case of a column name after it is in use will break the game. White space before and after a column name will be removed before hashing." It's confirmed that the GDA file's CRC32 is based on the lower-case form of the label, but perhaps it's still case sensitive for other tools while still in 2DA form? I'm just not sure if my changing that line would be inaccurate for something else -FollowTheGourd 01:23, 9 January 2010 (UTC)

As a noobie i wouldnt mind if this were part of guidelines, if all it wouldnt create troubles when doing so. I havent checked mind u and would be a wast of time lol Eshme 22:35, 24 January 2010 (UTC)


Page needs editing - lots of questions need answering

This is a rather poor page as stands. I think we need two sections. The most prominent section has to address Josh's questions in layman's terms, especially considering the role and importance of these .2DA files when creating modules. The second section shouldn't be too different from what we currently have, but should in no way have prominence on the 2DA page. I do feel parts of this section would be better served in tabular or bulleted form, a kind of technical sheet.

Deadrockstar 01:01, 7 December 2009 (UTC)


Some more information on the usage of these files would be great.

Questions:

-- What todo with these files?

-- Where to put them?

-- Do you need to copy them or modify the original? (why is there only one set of these?, should not every module have it's own set?)

-- Where to find them? (tools\source)

-- How do they fit in the whole toolset thing?

-- Meaning and usage in your own mod.

-- Best practices?


For all the people coming from the NWN Toolsets, that should be straight forward.

But for newcomers, this can be a bit confusing.


Thanks Josh


also -- where the heck ARE these files?