24 réponses à ce sujet

[OldTimeRadio]

Hey there, a question came up in the CC forum about customizing weapons with colors higher than 4 and I was hoping some of you might be able to help us with it.

I'm not actively working on a solution, but I wanted to know what the answer to the question was.  I did a little digging last night and it looks like with CEP, for instance, you can modify weapons like this.  Is that correct?  We're talking doing this via scripting, of course.  Looks like what they use was originally created by SartriX and then modified a bit from there.  This seems to be a slightly more updated version.

Anyway, for those of you with tailoring systems to change the appearance of weapons, is something like the system I link to above how you're getting around that 4 color limit?

Thanks.

[henesua]

Has anyone actually verified that this is indeed a problem? I didn't see any conclusive response in the first thread. While I haven't run into this yet, my plans for a custom crafting system could be stymied by it.

[OldTimeRadio]

henesua wrote...
Has anyone actually verified that this is indeed a problem?

It definitely appears that way, though I've never tried to implement such a system so I never ran into it personally.  You can pick up some hits searching for "CopyItemAndModify limit*" or "ITEM_APPR_TYPE_WEAPON_COLOR", for instance.

I didn't see any conclusive response in the first thread. While I haven't run into this yet, my plans for a custom crafting system could be stymied by it.

Bingo.  I'm in the same boat, more or less.  Meh, even if I don't get an answer I don't think it'll take too much digging to get to the bottom of the issue.  I'm just not too keen on throwing a few evening's worth of free time into it when (theoretically) there would be a number of regular readers here who would have some wisdom to share on the point.

Modifié par OldTimeRadio, 15 novembre 2012 - 08:47 .

[Lightfoot8]

OldTimeRadio wrote...

  ...We're talking doing this via scripting, of course.  

I hope you do not mean by scripting alone, You will still need the models and icons for each color variant.     
 
But I am in the same boat as you two,   I have never played with the function myself with values past the 4 colors, since I have never had the models installed.   
 
My impression on the linked topic that brought up the question, was that they where reading to much into the limit placed in the comments on the CopyItemAndModify item for the ITEM_APPR_TYPE_WEAPON_COLOR parameter.   I feel that Bioware placed the 1-4 limit in the comments simply because that is how many variants the made for every item,   Since there where no other variants the range for the parameter was 1-4.     

Modifié par Lightfoot8, 15 novembre 2012 - 10:06 .

[henesua]

This is piquing my curiosity. If I unearth anything I'll post the results.

[Lightfoot8]

Here is some info from the file format to help your quest.  


[quote] From BioWare Aurora Engine Item Format...


4.1.3. Composite

Model = <Itemclass>_<position>_<number>.mdl

(eg., waxbt_b_011.mdl, waxbt_m_011.mdl, waxbt_t_011.mdl)

Icon = i<Model ResRef>.tga

(eg., iwaxbt_b_011.tga, iwaxbt_m_011.tga, iwaxbt_t_011.tga)

The <position> is one of the following letters: b (bottom), m (middle), or t (top), usually corresponding to the pommel, hilt, or blade of a weapon.

For weapons, the 3-digit <number> field is broken up into two parts. The first 2 digits map to a physical shape variant, and the last digit is a color variant. For example, parts 011, 021, and 031 all have the same color, but different shapes. Parts 011, 012, and 013 all have the same shape, but
different colors.


To determine what colors are available for each of the b, m, and t portions of a composite item, do the following steps.
Scan for icons, incrementing the <number> from the baseitems.2da MinRange to MaxRange, and find first icon file that exists. Check the color code in the icon's resref (the last digit). This is the minimum available color. Increment the <number> from there until another icon is found that has the same color. Recall what color the icon was before that. That color is the maximum available color.


To determine what shapes are available, scan for TGA icons from <number> = (MinRange + minimum color) to <number> = [i MaxRange[/i], incrementing by 10 each time. If an icon exists, then assume that all the MDL file exists as well, and also assume that the shape variant exists in all the other colors as well. For example, suppose that the minimum color found earlier was 2, the maximum color was 4,
MinRange = 10, and MaxRange = 100. The icon scan would check for 012, 022, 032, ... 092. If 082 exists, for example, then assume that 083 and 084 also exist When drawing the Icon for a composite item, the 3 portions are painted one after the other in the order:
bottom, middle, top. The order is important because the icons overlap.

[henesua]

Wow... that is asinine. It really does clamp the color value between 1 and 4. I have tried values 5, 6, 7 and -1 the result is that the item doesn't change.

This was on a dagger model with colors from 1-7


I made a tag based script and tested this out on some weapons:

void main()
{
  if (GetUserDefinedItemEventNumber() ==X2_ITEM_EVENT_ACTIVATE)
  {
   object oUser = GetItemActivator();
   object oWeapon = GetItemActivatedTarget();

   int nColorTop = GetItemAppearance(oWeapon, ITEM_APPR_TYPE_WEAPON_COLOR, ITEM_APPR_WEAPON_COLOR_TOP);
   SendMessageToPC(oUser, "START Target("+GetName(oWeapon)+") Top("+IntToString(nColorTop) +")");

   object oCopy = CopyItemAndModify(oWeapon,ITEM_APPR_TYPE_WEAPON_COLOR, ITEM_APPR_WEAPON_COLOR_TOP, ++nColorTop, TRUE);

  nColorTop = GetItemAppearance(oCopy, ITEM_APPR_TYPE_WEAPON_COLOR, ITEM_APPR_WEAPON_COLOR_TOP);
  SendMessageToPC(oUser, "FINISH Target("+GetName(oCopy)+") Top("+IntToString(nColorTop)+")");
 }
}

Modifié par henesua, 16 novembre 2012 - 03:09 .

[henesua]

Well, I figured out what my solution will be: A store filled with items with special tags identifying model part numbers.

Let me know if you aren't sure how this would work.

[OldTimeRadio]

Thank you for the information, both of you!

@heneusa - I'd love a 25-cent rundown on how that would work.  I just wanted to be clear: That's not going to get you around the 4 color limit, is it?  Separate question: Do you recall if the dagger you tested had bottom, middle and top color 5's?  If it did have a color 5 for each of the models and it still didn't work...(makes sad face)

Lots more questions than answers now. I guess the biggest one is where is that 4 coming from.

Putting that aside for a second, if this is Unchangeable™ (cringe), it looks like there's a path out using this NWNX plugin.  The idea being one dupes the weapon base item types to cover for the 4-color limit and is still able to tie the duped weapon base item types to feats appropriate to the original weapon base item type.  This would be an escape hatch if you wind up with more weapon appearances than you can account for with you weapon model * weapon color variations.

Back to the issue.  I did more searching around and I found that apparently CEP doesn't have a way around this, the 4 color limit, in thier crafting or any crafting pack I could find so far.  So it's gone from something I assumed everyone was doing (but just didn't know how to do myself) to something that hardly anyone/nobody knows how to do.  Would love to be wrong about that.

About the most hopeful thing I can offer up is the thin possibility that ITEM_APPR_WEAPON_COLOR isn't hardcoded, per se, but a derived value, the result of some logic in the program.  Both ITEM_APPR_TYPE_WEAPON_MODEL and ITEM_APPR_TYPE_ARMOR_MODEL appear to work like this.  Anyone who's attempted to add a new 3-part model from scratch knows the circuitous hoop-jumping you have to do to get them to show up in the toolset.  I guess, retreating to my Happy Place, I'd hope that the reason the weapon color (at least) has been so elusive is that modders haven't been meeting whatever requirements to cause the CopyObjectAndModify to behave differently.

I don't have much faith in that, though.  It looks like both ITEM_APPR_TYPE_WEAPON_COLOR and ITEM_APPR_TYPE_ARMOR_COLOR are similar in how their values are static and I haven't yet found an answer to how to change armor color either.

Where those values actually come from...I dunno.  LOL, I just wanna change a damned four to a nine! 

Modifié par OldTimeRadio, 17 novembre 2012 - 12:19 .

[henesua]

This will get me around the four color limit in the crafting system I want to write. Whether it will benefit others, I don't know.

My thinking is that once a weapon is made, the model will not be modified further. So this will help crafters customize the look of a weapon that they make, but not players that want to adjust the look of a weapon they find. The later has never made any sense to me.

So for the above situation I will do the following:
(1) Create all the aesthetic variations of the various weapon types that I want players to be able to create.
(2) Each of these weapons will be put in a store and deleted from the palette.
(3) Most importantly each of these weapons will have a tag which identifies weapon type, and the model part numbers it uses.
(4) Create functions which enables the increment and decrement of a model part of a weapon. These functions generate a tag based on the specific change, and then get the weapon via tag from the store. Then it copies this weapon into the player's inventory, tags with something appropriate, and destroys the old weapon.

[OldTimeRadio]

Now I see what you mean- thanks for the explanation.

[henesua]

Do you see why this doesn't work for existing weapons in the PCs posession?

The problem is that you can't copy all the item properties and data from an old weapon to a new using the method I describe. So it isn't a full featured solution. Essentially I'll be adding the properties relevant to the crafting being done, and allow players to customize the look of the weapon, but... am not able to allow modification of the appearance of an existing weapon.

[OldTimeRadio]

Your reasoning and the solution make sense, I'm just still hung up on the limitation.  With issues like this, I tend not to advance very far on the "Five Stages of Grieving" scale, heh heh!

[OldTimeRadio]

Lightfoot8 wrote...
My impression on the linked topic that brought up the question, was that they where reading to much into the limit placed in the comments on the CopyItemAndModify item for the ITEM_APPR_TYPE_WEAPON_COLOR parameter.   I feel that Bioware placed the 1-4 limit in the comments simply because that is how many variants the made for every item,   Since there where no other variants the range for the parameter was 1-4.

I wound up following in Heneusa's testing footsteps and also found there's definitely something going on though, honestly, something like what you were describing is what I was thinking too.  I uploaded a little test kit project so you can check out the behavior, here.

LOL, and I think asinine is the perfect way to describe the behavior, as well! 

See, one of the interesting quirks I came across is that if you have a 5th color (for each top, middle & bottom) and have those new fifth colors set on a model (I used a dagger, too), when you carry out a CopyItemAndModify function to change the Top of the weapon to 5, the model copies fine.  It's changing the Top part from 5 to 5, so that sort of makes sense. As in, no change, so it leaves it alone.

But the bottom and middle parts also remain changed.  Which shows there's some sort of "gate" that CopyItemAndModify is using and if the parts of the model are not being touched, they don't even have to pass through it.  But the setting you want to use does, and that's when it runs into trouble.

There are two other tests whcih might yield useful information: Creating the 5th part for each of the other shapes for the dagger (so every shape has a 5th part) and (maybe) IPGetModifiedWeapon and whether that can be used to circumvent this in some way.  Lexicon says it eventually calls CopyItemAndModify, so I'm guessing not.  Still...

I'm probably not going to attempt the first test any time soon because that requires something like 100+ icons and model parts to test- this would be to see if having the fifth color available to all shapes was what CopyItemAndModify needed in order to consider "5" a valid value to use.

OnEdit: Oh, there may be some impact on this situation from baseitem.2da, but it seems as though it would impact the shapes more than anything else.  I.e. Not the colors.  Tried a number of minrange and maxrange changes, found nothing particularly interesting or helpful.

Modifié par OldTimeRadio, 17 novembre 2012 - 10:15 .

[henesua]

OTR, I believe you are over thinking this.

What you have is a function that you can't see inside, but will take some data.

We know that the function copies an item.
We also know that it can adjust a model/color part of the item.
These seem to work independently because of the following:

When you supply a color value outside the 1-4 range the color part of the model does not change yet at the same time it copies the model and gives it back to you. This occurs regardless of anything about the model, regardless of how many color parts it has, and regardless of what the value of its color part currently is.

I think it is a very safe assumption that the function simply checks to see if the color value supplied in the function call is within the 1-4 range, and if it is not, it ignores it.

Since we can't track down the function and modify it, nor can we find the code which sets a color or model part, we need a different kind of solution. If however we do find the code, then we are set. I would love to find a function which simply sets the color or model part of a weapon. That would be useful. I'm not going to hold my breath though.

Modifié par henesua, 17 novembre 2012 - 11:36 .

[OldTimeRadio]

henesua wrote...
OTR, I believe you are over thinking this.

Maybe. 

What you have is a function...

Understood.  I'm just wondering out loud where that "4" comes from.  It might simply be a hex value someplace.  The reason why I entertain the possibility of some more complex reason is purely because the toolset uses a convoluted test to determine how to show 3-part models and their shapes and colors.  That's all.  Just the hypothesis that the max value in CopyItemAndModify for 3-part weapons might be derived from something else.

Modifié par OldTimeRadio, 18 novembre 2012 - 12:31 .

[henesua]

OldTimeRadio wrote...

I'm just wondering out loud where that "4" comes from.  It might simply be a hex value someplace.  The reason why I entertain the possibility of some more complex reason is purely because the toolset uses a convoluted test to determine how to show 3-part models and their shapes and colors.  That's all.  Just the hypothesis that the max value in CopyItemAndModify for 3-part weapons might be derived from something else.

The solution I think really comes down to gaining access to that function. Once you have it you can make the changes you want. Otherwise, I don't see what we can do.

[henesua]

Went sleuthing and found the declaration for CopyItemAndModify in nwscript. But no function body. I suspect this means that the function is hardcoded. I'll await the experts to weigh in there. Is this true? Any function declaration found in the script "nwscript" which lacks an implementation is therefore hardcoded in the engine.

[Lightfoot8]

I found a little bit of time to look at this today.   

So far it looks like the 4 is hard coded.   It looked like if a value greater then 4 was passed the new modification was just concidered invalid and a straight copy of the old item was then created(  A guess I got a head ach trying to trace it out.)    

There is no dout though that the first check against the Arg is a hardcoded 4.      I guess you could try to simply hak the server and change that 4 to your 9.   I am not really sure what the results would be if an invalid number was passed though.   

If you wanted to try that on the windows version of the server,  I could pass you the location to edit.    I am not really sure what im looking at on the Mac version to find the location. 


 

[Pearls]

if you post or pm about the win version i can do the same for linux if needed, dont know anything about macs though

[henesua]

I've got the mac version.

Would I have to decompile it and look at binary?

Those are things that I don't know how to do.

[OldTimeRadio]

Lightfoot8 wrote...
There is no dout though that the first check against the Arg is a hardcoded 4.

If you're seeing it in the code, it's hard coded.  What's the location?  I have IDA Pro and I'd be interested to poke (or is it peek?) around there.

I believe Acaos already released a Linux plugin that does this, but I don't know if one was ever done for Windows. (?)

And thanks!

[Lightfoot8]

OldTimeRadio wrote...

...If you're seeing it in the code, it's hard coded.  What's the location?  I have IDA Pro and I'd be interested to poke (or is it peek?) around there.

 I wish it was that simple.   I do agree that I am 99% on it being hard coded.   the 1% is because of how little I have traced past it checking against 4.   If the code simply replaced the value over with a default value I would be 100%.  For All I know it may try to derive new Max values if the value is over 4.   My 1% uncertenty still remains. 




Back on track...

If you are changing the value in memory after the server is running the location is:   0x0058A872

If you are hacking the .exe the location is at :  0x0018A872 in the file.

and just incase I have done something to my copy of the exe that has offset the location in the file here is a hexstring with the needed value highlighted.

14 02 00 00 E9 6B 02 00 00 8B 45 0C 83 F8 31 BA 04 00 00 00 74 21 83 F8 65 74 1C 83 F8 68 74 17 83 F8 1A 75 0B 85 C9 75 22 BA 03 00 00 00 EB 24

[OldTimeRadio]

Thanks for taking the time, I appreciate it....a lot! 

[henesua]

I know we've moved on but I found an issue with CopyItemAndModify that I had not anticipated before.

Lets say you have a dagger, and want to change the top part. Currently the top part is Model_7 with Color_6, and you want to change this to Model_1 Color _4. If you lack Model_1 Color_6, and lack colors 1-4 for Model_7, you will likely be unable to change the object's appearance as desired. Changing the model part to 1 returns an error, and changing the color to anything at all returns an error.

Just FYI.

So, I'm definitely going with my method... along with a custom 2da or some other list to sort through all the potential forms.

Modifié par henesua, 21 novembre 2012 - 02:03 .