Inventories on players were designed with large quantities of items in mind.
I have a script that processes player inventories on player join, and to maximize performance, I store a local int on the item itself to say whether it has been harvested.
When finished with the items - I set the local int on the player to say he has been processed.
Variables on players only persist until a server restart - but this is by design, it means that next time I process the player - it will only capture/process items that do NOT have the harvested int set.
Meaning it will capture new items that were collected between the last login of the player in the last server instance.
Granted - you are saying that you are getting poor performance just on player login -
Yes onAcquire definitely fires.
Its ony of those things that sorta follows an xml/tree diagram.
When a Player logs in, their creature object is created,
the inventory items are all created from the serialized data inside the bic file.
But creating the inventory items is not enough - they need to be 'given' to the creature, in order for them to be valid objects.
Player logs in
Creature Created
Creature Inventory Created
Items Loaded into Inventory - trigger on Acquired per item
Any items going into slots - trigger the onEquipped per item in live slot.
onClientJoin probably fires here or above.
Creature Added to area
Area Enter Script fires
Best example of this heirarcy is spawning a creature via DM Creator.
When you spawn the creature
it spawns the Creature, Fires the onSpawnEvent - you will probably see the onAcquired event fire too, as well as the onAreaEnter event
There is an idea - you could create a creature - give it customized event scripts to SpeakString the name of its event.
Spawn the creature, and you would get alot of spam chat telling you what scripts were fired, and in what order.
(Since only one script can ever run at one time - it would tell you which event fires first, and which scripts are children of other scripts etc)
Anyway - kinda rambling now
If you feel that your onAcquired event is indeed the source of your trouble
You can tell it to ignore the player, until a certain INT value has been set on the player.
eg
onClientEnter
DelayCommand(10.00,SetLocalInt(oPlayer,"FULLY_JOINED",1));
Then in the onAcquire
object oPC = GetModuleItemAcquiredBy(); // think thats it?
if(!GetLocalInt(oPC,"FULLY_JOINED")) { return; }
This will exit out of the script, and discount onAcquired events during the players initial join.
Note - even the Tag Based scripting method - calls a script somewhere else
I think its in one of the X1_ or X2_ include files somewhere - if you follow the X2_default module scripts back for onModuleAcquire back far enough, you can find the actual parent function that fires the tag based script for individual items.
Or at least - I think I saw that once upon a time - I might have been high - but who knows.
Modifié par Baaleos, 11 septembre 2012 - 04:04 .
