Strange problem with random names and LBR models

[Datus]

Earlier today I was trying to give one of my NPCs a new LBR graphic. in npcdesc I left the "ObjType 0x190" intact and just added "Graphic 124" as the next line in the template. Somehow this causes random name generation to fail. If I remove "Graphic 124" then it works fine. Why would adding a "Graphic" ID to a template cause the random name generation to fail even though the ObjType is still the same? Doesn't randNameUtil.inc just reference the ObjType?

Thanks.

[Yukiko]

My randomName.inc seems to define graphic numbers. I created a troll and assigned it the number defined in randomName.inc for an OBJ_ORC_CLUB and the troll turned to a club carrying orc. Might have to rewrite the random name generator to handle LBR critters.

[MuadDib]

If you read the file, it checks mob.graphic for it. I personally would recommend ignoring the objtype on npcdesc, and just go graphic based. Then you don't get things mismatched/confused like this.

[Datus]

Unless you're me, then you're confused no matter what...

I actually found a fix to my problem... and I stress that this may in no way be the proper way to go about it at all because I can't understand how this is working, but it does.

Yukiko, you introduced me to NPCKeeper.src ... this holds the key to many of my recent dilemas. Incredibly it solved this problem too. By adding my particular LBR NPC desc "title" to NPCKeeper.src as well as creating new lines in randname.inc and randnameutil.inc, my LBR model now works with random name generation. What's even more odd is that randomnameutil.inc currently defines my OBJ_NPC within by it's graphic number 125 when in npcdesc.cfg , the particular NPC is using an ObjType of 0x190 (every other constant in randomnameutil.inc uses objtype references)... and it's even using the proper name index in names.cfg like i wanted it to...

Anyway it works, but I would be happier if it made sense!

[Yukiko]

Just curious Maud, what was the reason for objtypes on NPCs anyway?Makes more sense to use graphics for the NPC "type".

[MuadDib]

Beats me, that was long before I joined the team. And right now, not looking into why, hehe.

[Yukiko]

OK FYI ya need an objtype element in NPCDesc or you get an assertion failure I believe is what was reported in the game window. Assigning the graphic for ice fiend from your list to the objtype for ice fiend in the cfg file rendered the proper creature InGame but I recall some NPCs not working as expected, ie. not giving you the right animation, if you assign the ID to the objtype from your list. So the IDs need to be added as a Graphic element in the NPC cfg file.

So I assume you meant "Leave the objtype in the npcdesc.cfg file and modify the scripts to use the graphic number" and not to remove objtype from the cfg file since that doesn't work.

ANyway, thought I'd make this post so folks don't assume that they can do without the objtype in the definition of NPCs.

*grins*

I have to admit that was what I thought you meant at first but upon rereading your post that isn't exactly what you said.

[Datus]

Well, I've always left my objtype ID's intact to be safe. Like I said originally. So that wasn't / isn't the problem for my case. Interesting points though.

Anyone care to shed their light of wisdom on the NPCKeeper thing? I guess what I'm wondering now is why a template using ONLY ObjType 0x190 works for random names (if objtype is assigned to constants in randname and randnameutil), but anything with a Graphic tag (or at least LBR models) ALSO needs to be entered in NPCKeeper.src to work? Sadly I've spent a few days on this problem so I'd kill for some clarification.

Possible reasons it works below. (Please tell me if I'm wrong)

NPCKeeper.src:
Line 132: SetObjProperty(who, "Graphic", cint(who.graphic));

randname.inc:
Line 15: case( character.graphic )

[Yukiko]

Looks like it's in the "case" statement in randomName.inc.

I'll play with that and see if I can offer some help Datus.

[Yukiko]

It appears that the scripts use the "UOBJ" constant interchangeably as the graphic. Those UOBJ constants are defined in randomNameUtil.inc. That would be the place to add more definitions for new NPC graphics. It is somewhat confusing because the const is defined as "UOBJ". It would be more appropriate to have it defined as UOGRAPHIC" since the case statement in randomName uses it as if it is the graphic number rather than the objtype number.

In that case statement you need to define, for each new graphic you are using, the number and the index of names from which you want the script to draw upon for selection of the random name. The index consts are defined in randomNameUtil.inc.

If you look in names.cfg in \pol\config you will see the lists of index numbers and names associated with that index. The constants for each index number are defined in randomNameUtil.inc. That would be the place to add new index numbers for each graphic if you wish to create more name lists.

Hope this sheds some light on things. If you need more clarification Datus you have my number.

*grins*

[Datus]

[Marilla]

Hmm... not sure what's confusing about this... maybe another wording by way of explanation?


First: Random names are generated based on the graphic of the NPC, by all scripts I have seen. In fact, as a totally separate issue, I think it's best to do it by objtype. I might explain that below... but the fact is, that's not how it's done.

The reason for the constants defined inside RandomNameUtil.inc is as a list of the graphics that random names are needed for. Why is it in a separate file from the code that does the random names? I don't know. (I don't use that code, myself). Why, also, does it not just use constants from client.inc? Perhaps simply so as not to have to include client.inc. Then again, the naming convention of OBJ_* suggests the writer of that include MEANT for it to be used along with client.inc. (at any rate, I -never- duplicate global variable or constant names, nor function names, anywhere in my files, so as to prevent problems with include changes).

But the code that does the actual selecting of the random names, from RandomName.inc, clearly uses the mob.graphic property. It chooses an 'index' of types of names based on what the graphic is, and then chooses a random name from among the names that have that index in the names configuration file.

So, to add a new graphic to an existing list, you just need to find the code that selects the 'index' based on the graphic, and be sure to include a constant value for the new graphic you are using, that needs a name.



As for the objtype member. I can't even guess why this is so, but the reason it exists and is separate from the graphic property is answered by a look at the POL Object Reference: Both mobiles and items inherit from UOBject, which defines both objtype and graphic members. It's that simple. Further, definitions for both items and mobiles follow a similar pattern: You -must- define an objtype for the item, but the graphic is optional. If you do not define the graphic, it takes the same value as objtype.


This makes graphic and objtype members related, much of the time. However, 'related' does not at all mean 'the same'. items have a separate requirement, in that each objtype must be uniquely defined. mobiles do NOT have that requirement (you can define as many NPCs of objtype 0x1 (the first ogre graphic) as you like, and you can give them each whatever graphic you like. On the other hand, you can only have one item with objtype 0x1, though you can have any number of items with graphic 0x1.

Because both item and mobile inherit both graphic and objtype from UObject, they also treat the properties the same in most other ways; You can change the graphic all you want on an existing instance of the object, and the objtype always remains the same. The objtype also is read-only; you can't change it if you wanted to.



I think most scripters know how to use this fact for items - you can always check an item's objtype to be 100% sure that an item is of a certain type, no matter what might have been done to the graphic, name or CProps. Well, what many don't seem to realize is the objtype member of mobiles serves exactly the same purpose, basically (because it is read-only), but because objtype's can be duplicated among mobiles, there's an extra thing that it can be used for: For 'classing' or 'grouping' NPCs.


That is; You could make all your Daemons have the same objtype of, say, 0x9... but then give them each their own graphic. So each daemon will have the appearance you wish for it, and will generate the appropriate corpse, etc... but now, you have an easy-to-use way to tell monster 'classes', without having to package your NPCs and read the package name from the npctemplate. (though I still do recommend packaging classes of NPCs anyway - this just offers a better way, IMO, of discerning which monster is in which 'class', as it seems to me testing for equality among integer values is certainly better performing than testing a portion of a variable length string for a certain variable length string:

[Datus]

Marilla,

Thanks for the reply. I really do appreciate everyones replies here. Although again I have to stress that I am not confused with how randname.inc and randnameutil.inc function. I never had a problem with that... but you did make some solid points that will help me in the future.

My main source of confusion was with NPCKeeper. Like I said I needed to edit NPCKeeper (along with the randname includes) in order to get random names working for my LBR model. I just wanted to know why... Yukiko actually explained it to me earlier so I'm good now.

"ObjType" and "Graphic" being different but the same is what made it confusing I guess.

Again everyone thanks for your patience.