14 réponses à ce sujet

[FollowTheGourd]

Hi,

Maybe it's well-hidden on the wiki, but has anybody started carving up the 2DA space yet? Maybe it's too early to even know which values are safe to use and which might be taken for DLC and the like, but I'm interested in M2DA_base in particular.

I've created a separate M2DA file to extend it with some of my own custom 2DA files (that have nothing to do with adding to the game's pre-existing 2DAs), but I can see that causing conflicts if we don't reserve ranges as was done in NWN2. We might want to reserve M2DA prefixes, but I'm assuming that's easier to manage informally.

Maybe I should just stake a claim on the toolset wiki, but I'd be interested to hear what more experienced people have to say on it, or even better what BioWare's future plans are. Right now the best I could do is just choose a high number outside of any special ranges and cross my fingers.

It could be I'm missing something fundamental about M2DAs, but my understanding is that you still need to worry about the IDs, just not about having to keep creating monolithic 2DA files.

Modifié par FollowTheGourd, 04 décembre 2009 - 02:58 .

[FollowTheGourd]

This probably belonged in the custom content subforum, but now I'm thinking it might be safer to start with the highest working ID and work down from that... assuming BioWare would expand their range upwards.

At least with M2DAs, I'm hoping that won't mean lots of intermediate padding (internally, once assembled that is).

Modifié par FollowTheGourd, 03 décembre 2009 - 12:34 .

[EvilEdison]

Do we have to reserve ranges? I was under the impression that the toolset dealt with custom content dynamically, creating a unique M2DA for each module. Maybe I just dreamt that

[Ambaryerno]

EE,



If two active mods are both trying to use the same IDs, then it will cause a conflict if you try to use them both.

[ladydesire]

EvilEdison: We will still need to reserve space; all an M2DA does is handle merging any changes that Bioware might make to the core 2da files so that modders that build around the core 2da's don't need to touch the core files themselves.



FollowTheGourd: There is a page on the wiki for 2DA reservations; I don't know why it isn't linked to a more noticeable place, though.

[Phaenan]

Yes, this will become an issue in the long term. Those convenient M2DA tables help a lot, but we still have to make sure not to trend on each other toes. Rows.

Do we have to reserve ranges? I was under the impression that the toolset dealt with custom content dynamically, creating a unique M2DA for each module. Maybe I just dreamt that

Nah, it doesn't do that, and couldn't do that anyway since the toolset can't possibly know what IDs are being used by some modder on the other side of the planet. Plus, the toolset doesn't have to be involved in 2DA editing.
What the toolset do, is trying to randomize the talktable ranges for each module, hoping that nothing bad will happen when two modules meet. But that's just that : trying, and hoping. The random ranges may not be unique between modules, and when bigger fat quests-driven campaigns will start to appear, with lots of dialogs and hefty talktables, problems will arise sooner or later.

So yeah, we should at least have a community accepted "reserved list" containing modules talktable ranges, and ID ranges per 2DA.

Modifié par Phaenan, 03 décembre 2009 - 01:31 .

[sillyrobot]

One of the thing I plan to do is include the original .xls files in the download and use ini setting to control the ranges in use in my mods. That way, if there is a conflict, the user has the tools necessary to correct the problem. Change the ini file entriies to point to an unused block of IDs and make new GDAs that match.

[FollowTheGourd]

ladydesire wrote...
FollowTheGourd: There is a page on the wiki for 2DA reservations; I don't know why it isn't linked to a more noticeable place, though.

Thanks, I missed that in my searches. I updated the wiki's 2DA page to link to it now.

sillyrobot wrote...
One of the thing I plan to do is include the original .xls files in the
download and use ini setting to control the ranges in use in my mods.
That way, if there is a conflict, the user has the tools necessary to
correct the problem. Change the ini file entriies to point to an unused
block of IDs and make new GDAs that match.

While that might work for some things, I'd be at the mercy of people trying to play nice with the 2DAs I plan to use in my GUI mod. I can only read the INI settings that the game has already parsed, since I can't use DAScript from the GUI. While I could always go and update the values after the fact, I wouldn't want to deal with bug reports only to find out it was some rogue mod that messed things up - it's inevitable, but I'd like to lessen that chance.

It would also seem like a smaller thing to us, but I'm sure most users won't want to touch the .xls files - opting rather to just complain. Fixing the ranges might be easier than merging 2DA files like in NWN2, but even there I saw some modders not being comfortable with that.

Modifié par FollowTheGourd, 03 décembre 2009 - 02:30 .

[Phaenan]

FollowTheGourd: There is a page on the wiki for 2DA reservations; I don't know why it isn't linked to a more noticeable place, though.

Well.
I guess it wouldn't hurt to give that wiki page a nudge and watch if others follow. So when I'll be releasing the next version of my addon, some time before the end of the week, I'll simply put my 2DAs "reserved" ranges in that page. And prolly create her twin for the talktable "reserved" refs. Worst case scenario, I'll be the only one doing it, will look a like a fool (which I'm actually used to, no biggie >.>) for a while, and will ultimately remove the entries later. 

Modifié par Phaenan, 03 décembre 2009 - 10:32 .

[FollowTheGourd]

I'm still not entirely sure which ranges we should be taking, though. For M2DA_base, if we started at 8 million (or around that, until ExcelProcessor.exe's problem with higher values is fixed) and allocated downwards from there, then it would seem like a semi-safe way to avoid clashes with BioWare's future use... still assuming there wouldn't be any performance issues with doing that.

Oh, and Phaenan, I don't think anybody would look foolish for marking the ranges they used on the wiki page. If anything, I think the reverse would sooner be true if they knew about it but decided to plough ahead without letting anybody know. I don't see why it shouldn't take off other than people not knowing that it'd be beneficial to do so. We might want to have the starting range automatically reserved for "individual projects" (like self-contained campaigns vs. general addons). Maybe reserve that "indvidual projects" space on the high and low end, at least on the low-end, since I'm assuming (right or wrong) that they might be used by campaign-authors anyway. 

I look at it this way: it'll help avoid situations like having to say "Avoid using mods x, y, and z with my mod. While we could have easily avoided this mess, they're incompatible and it's too much bother on both our sides to make them work together now."

For an example: nwn2.wikia.com/wiki/Reserved_2da_ranges

Modifié par FollowTheGourd, 03 décembre 2009 - 01:43 .

[Phaenan]

The only guidance I found was about the talktable, as the toolset states entries bellow 631 million are to be reserved for Bioware and Bioware certified content. So for pretty much any other 2DA, I just came up with a random range. Obviously I'll change them if I hear they may cause problems somehow. In the meantime, here is :
- http://social.biowar...A_ranges_in_use
It's my first time ever editing a wikithingy page so bear with me. I'll add the others Bioware's OC ranges sometimes in the evening, can't right now. (That was supposed to be my lunch break. Oh well, looking slim is in those days. ">_>)

Modifié par Phaenan, 03 décembre 2009 - 01:41 .

[BryanDerksen]

Note also that (at least as far as I'm aware) 2DAs in an addin's override directory are only loaded into memory when the addin is actually in use. So if two different builders are working on stand-alone adventures that will only ever be played one at a time they could overlap their 2DA IDs without causing any confusion. The situation where care needs to be taken is with addins that extend core (and thus are always loaded into memory), or are otherwise used alongside multiple different addins (for example every addin that added new content to the Single Player module would need to take care not to reuse each others' 2DA IDs). So not all modders will need to worry about these ranges in all situations.

[Phaenan]

Makes sense. 
Thanks for the clarification.

Modifié par Phaenan, 03 décembre 2009 - 10:27 .

[FollowTheGourd]

If I understand right, it would still be prudent for every modder to keep the ranges in mind, even if they ultimately choose to ignore them. It doesn't seem like you still have carte blanche to take whatever range you want if you want your stand-alone adventure to stay compatible with mods in general (versus those that just affect specific campaigns or other stand-alone adventures).

It's hardly my original idea, but that's why I was thinking we ought to reserve a block for stand-alone mods, which don't have to worry about staying compatible with each other, but using that range helps ensure that they're compatible with addon-type mods. It would defeat the purpose of reserving that range if stand-alone mod makers reserved chunks of it.

Modifié par FollowTheGourd, 04 décembre 2009 - 12:38 .

[ITSSEXYTIME]

FollowTheGourd wrote...

If I understand right, it would still be prudent for every modder to keep the ranges in mind, even if they ultimately choose to ignore them. It doesn't seem like you still have carte blanche to take whatever range you want if you want your stand-alone adventure to stay compatible with mods in general (versus those that just affect specific campaigns or other stand-alone adventures).

It's hardly my original idea, but that's why I was thinking we ought to reserve a block for stand-alone mods, which don't have to worry about staying compatible with each other, but using that range helps ensure that they're compatible with addon-type mods. It would defeat the purpose of reserving that range if stand-alone mod makers reserved chunks of it.

That sounds like the best option overall.