21 réponses à ce sujet

[Lance Botelle]

Hi All,

This question is related to my question about loot drops in this post, but is different enough to warrant a new topic.

I have noticed that some items collected from a loot are sometimes "identifed" or not, subject to whether they come from a creature that was placed in the area at build time or if they were spawned by an encounter trigger.

NB: The creature is otherwise identicle (i.e. It is the same creature with the identicle items on the template.) I place one in the area directly and set a trigger to spawn a second one next to it.

PLACED CREATURE: When I loot it, all items are identified, including some Arrows (Acid).
ENCOUNTER CREATURE (USING SPAWN TRIGGER): All items, except the Arrows (Acid) are identified.

At first, I thought it was due to different amounts of arrows, but I tested by placing different amounts in the area, and my test PC could not even identify a stack of 1 when picked up.

1) The arrows start off NOT identifed on the creature, but become identified if I use the placed creature.
2) If I use the SetIdentifed function to make all the items NOT identified on the creature. This does indeed, set them all as NOT identified. HOWEVER, I cannot then identify even the most basic of items!

I tried looking up the information about HOW a PC identifies an item. (i.e. I know it used to be based on the price of an item. Is this still the case?) Where can I find out which items I PC can identify when they pick them up  ... or go to take them from a loot?

I found the skillvsitemscost.2da ..... I thought this was the 2da that determines what a PC can identify when they pick it up? BUT, if this is thecorrect 2da, it does not seem to work because why would my PC be unable to identify the most basic simple/cheap weapons that were turned to NOT identified on the dead corpse?

Any help regarding this peculiarity of the identified function/lore skill with respect to looting corpses would be appreciated.

Many Thanks,
Lance.

Modifié par Lance Botelle, 17 octobre 2012 - 03:00 .

[kamal_]

Objects must be identified for the creature to use them (be equipped). Inventory objects do not need to be identified. Proper "unidentified item" behavior is a side benefit of having duplicate droppable items unequipped in inventory.

[Lance Botelle]

kamal_ wrote...

Objects must be identified for the creature to use them (be equipped). Inventory objects do not need to be identified. Proper "unidentified item" behavior is a side benefit of having duplicate droppable items unequipped in inventory.

Hi Kamal,

The arrows that are being identifed are in the creatures inventory and NOT in their equipped space (in both instances).

Yet, the "placed" creature identifes it and the "encounter trigger" creature does not.

Lance.

Modifié par Lance Botelle, 15 octobre 2012 - 03:26 .

[Lugaid of the Red Stripes]

Maybe the dead and looted NPC is supposed to identify the item, not the PC picking it up. I guess one could do a test with high lore-skill NPCs to make sure.

[Lance Botelle]

Lugaid of the Red Stripes wrote...

Maybe the dead and looted NPC is supposed to identify the item, not the PC picking it up. I guess one could do a test with high lore-skill NPCs to make sure.

Hi LotRS,

I would like to know how the "corpse" system works with respect to identification ... or even how identification works with the lore skill. I reckon if I understood that, I may have a little more understanding how to (perhaps) rectify the issue.

I thought the fact that I can turn items as NOT identified and then have the PC identify those they were able to would solve the issue, but as I say in teh first post, if I do that, the PC canot even identify the most basic items.

Still not sure what's going in here.

Lance.

[kamal_]

My understanding is that a pc that aquires unidentified loot makes a lore check to identify with a dc based on the level of magic on the item (in some mysterious formula). They either identify it, or it's marked as unidentifiable by them until their base lore score changes, at which time they will check again if they re-aquire the item.

Generally, a character that puts a point in lore at every level up should be able to identify most everything the party runs across, at least using the magic levels of the official campaigns.

[kamal_]

That also applies to npcs, my understanding is they try to identify things put in their inventory, based on their lore scores.

/ sorry, on mobile so I couldn't edit the previous post.

[Dann-J]

An OnAcquire event is triggered for every item in an inventory when a creature is spawned (or when reloading a saved game). It's as if that creature (or PC) picked up all those items at once. This is something you have to be careful of with tag-based OnAcquire scripts, since if you don't filter out who can trigger the script, and it's set to only run once, then the creature who will drop the item is the one who runs it, and it doesn't run again when the player acquires the item.

I suspect that OnAcquire event is also checking to see if the creature has enough lore to identify anything in it's inventory (but not anything equipped). Giving all your creatures lore skills of zero might prevent inventory items being identified. It may be that placed creatures and encounter-spawned creatures have subtlely different OnSpawn events.

[Lance Botelle]

kamal_ wrote...

My understanding is that a pc that aquires unidentified loot makes a lore check to identify with a dc based on the level of magic on the item (in some mysterious formula). They either identify it, or it's marked as unidentifiable by them until their base lore score changes, at which time they will check again if they re-aquire the item.

Generally, a character that puts a point in lore at every level up should be able to identify most everything the party runs across, at least using the magic levels of the official campaigns.

Hi Kamal,

That was my understanding. However, the way the loot drops work with PLACED creatures when they die, makes me think ther emay be some other system at work. (See next.)

DannJ wrote...

An OnAcquire event is triggered for every item in an inventory when a creature is spawned (or when reloading a saved game). It's as if that creature (or PC) picked up all those items at once. This is something you have to be careful of with tag-based OnAcquire scripts, since if you don't filter out who can trigger the script, and it's set to only run once, then the creature who will drop the item is the one who runs it, and it doesn't run again when the player acquires the item.

I suspect that OnAcquire event is also checking to see if the creature has enough lore to identify anything in it's inventory (but not anything equipped). Giving all your creatures lore skills of zero might prevent inventory items being identified. It may be that placed creatures and encounter-spawned creatures have subtlely different OnSpawn events.

Hi DannJ,

To me, it looks like there might be a connection (somehow) between what a creature has on them when spawned and the player's LORE skill when related to a SPAWNED creature (not a placed one). I only say this because if you attach a script to a creature's ON SPAWN that does the following, the player cannot identify even basic items the creature drops:-

1) Cycle through the creatures equipment. (Not equipped.)
2) Make a new copy of each item found (and ensure each item is not identifed).
3) Destroy the original item on the creature so that only the unidentifed copy remains.

Now, when the PC kills this creature, I originally thought this would happen: That the PC would now identify all those items they can according to their LORE skill.

BUT THIS HAPPENS INSTEAD: The PC cannot identify *any* of the new items we created! Even the basic (non magic) morningstar that is worth only a few gold! It's as if NWN2 checks what a PC will be able to identify on this creature at the time it is spawned into the game. By me then making a copy that is unidentified the moment after the creature spawns, means the PC can no longer have *another* identify check (until lore increased), because their chance has already been made at the time the creature was spawned.

Somehow, my turning all items (copies) unidentified when the creature is SPAWNED, stops the player from identifying them when they loot then from the dead creature.

EDIT: I can hand these items to a higher level companion and they can ID them.

DannJ, you also say "An OnAcquire event is triggered". Do you know what On Event script is fired? Is it hard coded or accessible?

Thanks for helping.
Lance.

Modifié par Lance Botelle, 16 octobre 2012 - 12:57 .

[Morbane]

on acquired is something that would be designed or assigned by the builder?

[kamal_]

Strange, because you can easily give a creature an item via standard scripts.

[Lance Botelle]

Hi All,

At some point I am going to test my theory about the loot being IDd according to my PC prior to my changing it in the creature's OnSpawn.

Furthermore, I am reasonably confident now that the PC Lore check against whether they can ID something is based upon the last column of the skillsvsitemcost.2da.

So, what I am going to do is:-

A) Change some settings in the 2da to what I want a PCs lore ability to cost to be. (This is because my items cost a lot less in my campaign and so this column needs to be decreaced by about a factor of ten.)

Do a gold piece value check of the creatures items versus the PCs ability to ID the item (based on the new 2da above) and then only turn the items ID on or off according to this check.

This way an item is rightly turned as unidentified instead of assuming the PC wil be able to identify one from their loot (after it has had the weird unidentify problem occur).

If anybody can shed any more light, do let me know. If not, I wil post again if and when I succeed in sorting this particulr problem out.

Cheers,
Lance

[Dann-J]

Lance Botelle wrote...
DannJ, you also say "An OnAcquire event is triggered". Do you know what On Event script is fired? Is it hard coded or accessible?

There should be a default OnAcquire script assigned in the module properties, which handles all acquisitions in the module for all creatures. I suspect that's the script that also checks whether an individual item has its own tag-based OnAcquire script, and runs it accordingly.

You can probably assign companions individual OnAcquire scripts as well, just as you can with HB or user-defined event scripts. It's not something I've ever tried to do though.

[Lance Botelle]

Hi All,

Great news!

I was able to make use of an edited examine GUI to make use of what I have learned about ID items. Now, I can take any item that is unidentified, and it becomes identified if the player examines the item and it is within their lore skill limit! Yeh!

This is actually better than I wanted, as it means I can make items remain unidentified until the player examines them! So, it means a player won't know if they truly recognise an item or not, until they have examined it. Thereafter, they get the true identification status!

I worked out I could make this an automatic process (as I first considered), but having items from a monster (especially) start off unidentified even after collection is quite a good way of showing th eplayer what items they have not yet looked at (as they are marked unidentified). Now, when the player examines the item in question, if they have the skill, they get the identified text and the item changes to identified seamlessly!

It looks really good!

Lance.

EDIT: Found a workaround for ID items to get gold value. It did not work in my original function, but does work outside of it! Weird.

Modifié par Lance Botelle, 17 octobre 2012 - 11:43 .

[Lance Botelle]

DannJ wrote...

Lance Botelle wrote...
DannJ, you also say "An OnAcquire event is triggered". Do you know what On Event script is fired? Is it hard coded or accessible?

There should be a default OnAcquire script assigned in the module properties, which handles all acquisitions in the module for all creatures. I suspect that's the script that also checks whether an individual item has its own tag-based OnAcquire script, and runs it accordingly.

You can probably assign companions individual OnAcquire scripts as well, just as you can with HB or user-defined event scripts. It's not something I've ever tried to do though.

Hi DannJ,

Ah, those scipts. I thought you meant some other "hidden"  acquire script. All those scripts appear fine. I have rewritten ALL of those ones, and nothing in them interferes with the identifying aspect of loot acquisition. There is definitely something else going on somewhere else, but thankfully, I have a solution I am working to now. (See last post.)

Thanks for all your help.
Lance.

[Lance Botelle]

Hi All,

I have found the answers I was looking for!  Yeh!

Here is the information for all those interested in the procedure:
======================================

1) When a creature is placed or spawned into an area without a dedicated AI script placed on it by the builder, then the creature is assigned a default AI Script called, "hench_o0_ai". This is done whenever the function HenchDetermineCombatRound is called.

2) HenchDetermineCombatRound is called (in my scripts and most likely the defaults) from a number of hooks, and so the timing of when all the items are identified for the creature varies depending upon whether the creature is spawned or already placed.

3) When this script fires, and if the creature does not have the variable "HenchAutoIdentify" set to one on them, then (at some point) it fires a function called HenchIdentifyWeapons, which does what it says and identifes everything the creature has on them. (It then sets the variable to 1 as all done.)

4) Therefore, depending when HenchDetermineCombatRound calls HenchIdentifyWeapons determines when items carried are made all identified. In a PLACED creature, the function is not called until quite some time after my own SPAWN script has made everything unidentifiable. Therefore, items are changed back to identified by the time I loot the corpse. A SPAWNED creature fires this function immediately, which meant my own SPAWN script was contesting for the ID of items at the moment of SPAWN. TIMING determined wether my own SPAWN code fired before or after the ID of some items that the HenchIdentifyWeapons did as my own code was firing. This is why some items remained identified and others were unidentified.

So, if you need to stop the creature from auto-identifying the items they carry, make sure you set the "HenchAutoIdentify" variable to one on them. Although it does do a couple of other minor things. (See script excerpt below from "hench_o0_ai") Alternatively, make sure the call to change identified objects comes after the creature has done the following script, which, at the latest, will most likely be when they are attacked.

if (!GetLocalInt(OBJECT_SELF, "HenchAutoIdentify"))
    {
 
  SetLocalInt(OBJECT_SELF, "HenchAutoIdentify", TRUE);
        if (iAmMonster || (GetAssociateType(OBJECT_SELF) != ASSOCIATE_TYPE_NONE))
        {
      
           HenchIdentifyWeapons();  // < THE OFFENDING FUNCTION
   
            if (GetHenchOption(HENCH_OPTION_ENABLE_AUTO_BUFF) &&
                (GetAssociateType(OBJECT_SELF) == ASSOCIATE_TYPE_NONE) &&
                !GetHasEffect(EFFECT_TYPE_SPELL_FAILURE) && !GetHasEffect(EFFECT_TYPE_SILENCE))
            {
 //               HenchQuickCastBuffs(GetHenchOption(HENCH_OPTION_ENABLE_AUTO_MEDIUM_BUFF));
            }
                      if (GetHenchOption(HENCH_OPTION_ENABLE_EQUIPPED_ITEM_USE))
            {
                HenchAllowUseofEquippedItemSpells();
            }
              if (GetHenchOption(HENCH_OPTION_ENABLE_ITEM_CREATION) &&
                (GetRacialType(OBJECT_SELF) != RACIAL_TYPE_UNDEAD) &&
                (GetAbilityScore(OBJECT_SELF, ABILITY_INTELLIGENCE) >= 6) &&
                GetCreatureUseItems(OBJECT_SELF))
            {
                HenchCreateItemsToUse();
            }
               HenchDetermineCombatRound(oIntruder, TRUE); // redo combat round
            return;
        }
    }

Modifié par Lance Botelle, 17 octobre 2012 - 03:03 .

[Lugaid of the Red Stripes]

Interesting stuff, I just love NWN archaeology.

Could an on-death script re-set everything to unidentified?

[Lance Botelle]

Lugaid of the Red Stripes wrote...

Interesting stuff, I just love NWN archaeology.

Could an on-death script re-set everything to unidentified?

Hi LotRS,

Yes, that would certainly work.

However, I wanted to make sure that the items I placed in the "equipment area" would definitely have a chance of dropping and not be used by the creature as part of an AI routine I may not be aware of. Of course, I may be giving the engine too much credit (or possibly not enough) and as long as the items in that region are marked "droppable", then they will still drop regardless, whether "used" by the creature in question or not. I am not sure about this.

My main reason for the "investigation" was to ascertain why this was happening - and understand a little more about what was going on. At least now I do understand what happens with respect to items placed inside the "equippable" area of a creature. And know how to make sure they stay unidentfied to prevent creature usage.

If the "droppable" section had worked like I first hoped, then I would never have done this.

I have only just started work on creature loots/drops as that is the section of my module that I am currently looking at. My creatures also have a number of other potential drops happen at death time, which is another reason I wanted to avoid doing loops to turn stuff unidentified at that time. (Although it should be easy enough still if I simply do the loop prior to the other drops.)

That's some of the reasoning anyway, but as I first said, "Yes, a loop in the creature's on death would certainly work!" And unless you have any concerns like I do, it would be the easiest method.

Many Thanks for all the help with this,
Lance.


EDIT: By the way, something very important to remember: If you do decide to turn everything unidentified on death, then you must also script a way for the player to be able to identify the items again, as even the simplest items made unidentified CANNOT be identified again until the player uses a PC with a higher lore skill.

Modifié par Lance Botelle, 17 octobre 2012 - 06:27 .

[kamal_]

Looking at Lance's point one. Why would a builder place or spawn a creature the builder intends people to fight without an ai on it?

[Lance Botelle]

kamal_ wrote...

Looking at Lance's point one. Why would a builder place or spawn a creature the builder intends people to fight without an ai on it?

Hi Kamal,

I don't think every creature needs an "special" AI script and so the default one works fine (mostly). I mean, I have written an AI script that I would like some of my creatures to use, but I imagine most creatures will still use the default one simply because they do not need any more than that.

The only "downside" I can see is (like I have now discovered) the default AI may be doing stuff that I did not necessarily want it to do. I suppose (like this time and incident) I will learn more as I test my monster "placement" setups and "encounter" setups.

Are there any other potential "issues" you think might be worth mentioning ... to save me time?

Cheers,
Lance.

[kamal_]

Issue: if you set the CR of a creature or creature blueprint to zero, you can't change it via the creature properties tab (at least it does not work for me).

[Dann-J]

kamal_ wrote...

Issue: if you set the CR of a creature or creature blueprint to zero, you can't change it via the creature properties tab (at least it does not work for me).

You can't change it on the 'Basics' tab, but you can change it on the 'Properties' tab. The CR is duplicated there (somewhere in the block of stats that includes the deity name).