40 réponses à ce sujet

[Phaenan]

Craig Graff wrote...
Though it does make it significantly more difficult to ensure that there aren't conflicts, it is certainly not impossible

I guess it'd all come back to some kind of "reserved ID list" with the entries from various mods, and a comfy margin of "blank entries" assuring some place for Bioware right after the last official entry.
The official Wiki seems to be the perfect place to hold such a list but - first - it needs some kind of consensus between modders. Something we've yet to work on, unless I missed something.  (and another list for those strrefs wouldn't be such a luxury in the long run)

Modifié par Phaenan, 02 décembre 2009 - 04:50 .

[Joshua Raven]

The problem is that I could reserve 60-70 but if someone didn't install my mod and you use 71-80 then your mod won't work, right?



Though using the GetM2DAInt should work if you want to retrieve a value from the properties.xml, right?



GetM2DAInt(-1, "Max", 10181001, "properties_np_items"))

[Axe_Murderer]

Craig Graff wrote...
Though it does make it significantly more difficult to ensure that there aren't conflicts, it is certainly not impossible.

Not sure I follow or agree with this conclusion completely. If I install 3 independent packages that all have changes to this 2da then yes I can reallocate their numbers so they don't conflict with each other and the rows are all sequential. It will work as long as all the packages are all installed and active, but if I disable the first package it is gonna break all the others following it since the numbers are no longer sequential and that appears to be a requirement. There will be no conflicts, yet it won't work. This sequential requirement imposes a package ordering and a requirement to have all packages installed to ensure the sequence is not broken. Which ties all custom packages related to this 2DA together -- it is impossible to create a package that adds new stuff into the 2DA which is completely independent of all other packages that deal with this 2DA. If I am not the author of one or more of these packages then I am burdened with a maintenance nightmare every time one of these packages is updated by the author.

I believe this needs to be addressed, particularly if the 2DA is expected to be one that is likely to be commonly modified or appended to. Furthermore, I will argue that properties falls into this category.

Modifié par Axe_Murderer, 02 décembre 2009 - 05:28 .

[Phaenan]

The GetM2DAStuff() functions works on everything, even new custom tables so yeah, it'd work.

Still, all we would have to do (appart from sticking to a single "reserved id list") is something like
0             INVALID INVALID
1             Strength ATTRIBUTE
2             Dexterity ATTRIBUTE
(snip)
58           Nature_Damage_Bonus ATTRIBUTE
59           Electricity_Damage_Bonus ATTRIBUTE
60           ****
61           ****
(safe margin for Bioware's future stuff)
1000       Mod MyThing - PrpYada_yada1
1001       Mod MyThing - PrpYada_yada2
(let's say 50 IDs reserved here)
1047       ****
1048       ****
1049       ****
1050       Mod Bidule - PrpYada_yada1
1051       Mod Bidule - PrpYada_yada1

Etc etc etc.
No. I couldn't imagine something more cumbersome.

[Phaenan]

I believe this needs to be addressed, particularly if the 2DA is expected to be one that is likely to be commonly modified or appended to.

Agreed, unless there is some underlying... thing... preventing it, it'd be much simpler for everybody to simply have this properties table (and the BITM one, while I'm at it) correctly working within the boundaries of the M2DA system.

[Craig Graff]

Joshua Raven wrote...
Though using the GetM2DAInt should work if you want to retrieve a value from the properties.xml, right?

GetM2DAInt(-1, "Max", 10181001, "properties_np_items"))

As I said in my previous post, this will work if you use the base table name: "Properties".

[Joshua Raven]

Aren't M2DA's supposed to have some suffix after the required name? the M2DA name for properties is that, properties.

That's why I added _np_items as a suffix for my custom M2DA of the properties 2DA. The above code did return my values, unless I don't quite understand what you mean with your remark, Craig.

[Axe_Murderer]

Joshua Raven wrote...

Aren't M2DA's supposed to have some suffix after the required name? the M2DA name for properties is that, properties.
That's why I added _np_items as a suffix for my custom M2DA of the properties 2DA. The above code did return my values, unless I don't quite understand what you mean with your remark, Craig.

Yeah but those suffixes are a build-time deal. At runtime the M2DAs are all merged and converted into a single 2da (gda I think they call it) using the prefix only as the name of it (i.e. properties, without any suffixes).

[AND04]

Phaenan wrote...

The GetM2DAStuff() functions works on everything, even new custom tables so yeah, it'd work.

Still, all we would have to do (appart from sticking to a single "reserved id list") is something like
0             INVALID INVALID
1             Strength ATTRIBUTE
2             Dexterity ATTRIBUTE
(snip)
58           Nature_Damage_Bonus ATTRIBUTE
59           Electricity_Damage_Bonus ATTRIBUTE
60           ****
61           ****
(safe margin for Bioware's future stuff)
1000       Mod MyThing - PrpYada_yada1
1001       Mod MyThing - PrpYada_yada2
(let's say 50 IDs reserved here)
1047       ****
1048       ****
1049       ****
1050       Mod Bidule - PrpYada_yada1
1051       Mod Bidule - PrpYada_yada1

Etc etc etc.
No. I couldn't imagine something more cumbersome.

hmm, creating some kind of web-interface where a user can "draw-a number" and then subsequently use it for  his mod in the 2DA-System would be neat - and for such sequential ones we would "just" have to make a download availible with the complete list.

Its a simple thing (as in a couple of hours work + testing ofc) - if possible it should be included inside the Social-Site - but we can easily create that system ourself too - if its being used that is.

Modifié par AND04, 02 décembre 2009 - 06:37 .

[Axe_Murderer]

While that idea might be workable, it could also present some significant problems. Presumably the sequential restriction is there for performance reasons to keep the table as small as possible. What you're proposing would greatly enlarge the table and most of the new entries would be empty (reserved for whatever). This could be a very bad consequence performance-wise.

[Joshua Raven]

Well if you think about it, the properties table is applied to every creature (object?) in the world, so a single row added to that means several thousand times that row is called during the game.



Actually the wiki also warns for this:



-----------------------------------------------------------------

Words of Caution

Properties.xls is the most integral and powerful 2da in the game. Any changes to it have profound implications on the game and the chance of breaking existing savegames and introducing unwanted behavior.

Removing Rows It is referenced from many other rules and UI related 2das and removing existing data can have severe consequences, including the invalidation of existing characters. You can NEVER remove rows from this 2da!

Changing Rows Changing rows is not as dangerous as removing them, but still can have severe implications. The m2da system should be utilized to modify individual rows instead of overwriting the entire 2da. Especially the Min, Max and EngineLink columns hold a lot of rules relevant data that might not be obvious on the first glance (e.g. the Max value on 'Experience' defines the maximum XP the game will allow on a character. Any attempt to award more XP from script will silently fail.)

Adding rows: Every row added to this file will reserve several Float32 data fields on every combat capable creature in the game. While a few floats might not sound like a lot, the impact on runtime area memory, savegame size and associated load times can not be overstated. While these issues are more pressing for the console versions of the game, they still do affect the PC version and I strongly advise not to add to this file unless absolutely necessary

-----------------------------------------------------------------

[Phaenan]

AND04 wrote :
if its being used that is.

Yep, I'll say that's a concern here.
'Cause if putting that kind of system in place isn't that hard, as you said, it still puts some strain on the modders. Everytime one of the mod included in the list modify/add something, authors/groups managing every other mod in that list will have to get the new table and include it in their end-player package. Possibly between their own releases. Kinda glad I'm not forced to use any of those tables. (Yet. * crosses fingers *)
Better than nothing, that's a given, but quite the pain wherever you don't like pain.



// Edit :
And Axe_Murderer just made a very valid point while I was posting...

Modifié par Phaenan, 02 décembre 2009 - 07:13 .

[Axe_Murderer]

Huh...after reading that warning I must change my assessment that this 2da falls into the category likely to be modified.

[AnTeevY]

Why can't we create a M2DA for the var_creature.xls again?



And another thing: I think the easiest way would be just to always make sure that there is only one module which changes the properties enabled at a time and as a developer use IDs from 60 upwards.

[Georg Zoeller]

In general, leave a few thousand ids between your module and the bioware declared ranged, just to be safe for the next two years.

maximum row number is +MAX_INT, so you have plenty of space.

[Joshua Raven]

Georg, I'd love to, where it not that the properties 2da doesn't allow anything but sequentially ID's. But yeah, in general, thanks for the tip. Another tip is to use some kind of standard first 5 digits that you won't forget. Like for me, I use JRA in numbers: 10181xxx.