I'm not sure if this is the best place to ask this, so please move it if I am wrong.
Our server has been crashing a lot lately. About once every one to three days. We believe it may be linked to character inventories. Is it possible that characters with too many filled magic bags can crash a server? also are there any known bugs that involve character inventories? Thank you for any help you may provide.
Inventories and Magic Bags
Débuté par
Sadira of Tyr
, sept. 08 2012 11:12
Retour en haut
#2
Posté 09 septembre 2012 - 01:57
acomputerdood
-
- Members
- 219 messages
enormous inventories can definitely drain the server's resources. i don't know exact numbers, and i'd imagine that the only study done on it would have been years ago. presumably one might this this wasn't an issue anymore with more modern computers, but you never know.
#3
Posté 09 septembre 2012 - 06:58
Shadooow
-
- Members
- 4 465 messages
nope i dont think so, definitely shouldnt crash because that, it fires one script for every item each time player log in this character but thats not really an issueSadira of Tyr wrote...
I'm not sure if this is the best place to ask this, so please move it if I am wrong.
Our server has been crashing a lot lately. About once every one to three days. We believe it may be linked to character inventories. Is it possible that characters with too many filled magic bags can crash a server? also are there any known bugs that involve character inventories? Thank you for any help you may provide.
Modifié par ShaDoOoW, 09 septembre 2012 - 07:08 .
#4
Posté 10 septembre 2012 - 04:16
Khuzadrepa
-
- Members
- 188 messages
It can definitely contribute. I've seen this on several PWs... a player logs in, and the server is brought to a grinding halt for some amount of time. Usually, the server recovers, and play continues... but not always. If this is what you are experiencing, then you might be on the right track.Sadira of Tyr wrote...
I'm not sure if this is the best place to ask this, so please move it if I am wrong.
Our server has been crashing a lot lately. About once every one to three days. We believe it may be linked to character inventories. Is it possible that characters with too many filled magic bags can crash a server? also are there any known bugs that involve character inventories? Thank you for any help you may provide.
Check your OnEnter and OnAcquire scripts for optimization. Also, are you using Creature Skins on your players?
It's also not a bad step to have players reduce their inventory, especially containers. If you don't have one already, maybe give them some kind of other persistent storage option?
#5
Posté 10 septembre 2012 - 05:05
The Amethyst Dragon
-
- Members
- 1 875 messages
My server has a small script on client enter that, if not run already after the last reset, counts a PC's inventory items and writes it to the server log. Many of my players are pack-rats. Most seem to carry an average of 75-150 items. A few carry over 800. And this is in addition to persistent storage chests.
In the servervault, I can see which player files belong to pack-rats. The .bic files of such characters tend to run in the 350-500 kb size range. Yup, loading in a 1/2 MB character file, before the server runs their entire inventory and associated on-acquire script checks.
I think I'm going to start having the script actually give this number to PCs in-game. It might influence some of them to clear their inventory of some things they never use.
In the servervault, I can see which player files belong to pack-rats. The .bic files of such characters tend to run in the 350-500 kb size range. Yup, loading in a 1/2 MB character file, before the server runs their entire inventory and associated on-acquire script checks.
I think I'm going to start having the script actually give this number to PCs in-game. It might influence some of them to clear their inventory of some things they never use.
Modifié par The Amethyst Dragon, 10 septembre 2012 - 05:07 .
#6
Posté 10 septembre 2012 - 09:36
MrZork
-
- Members
- 938 messages
AD, I suspect that would actually help somewhat, assuming they know that hauling around so much stuff causes problems. There is some psychology that indicates people will respond to feedback and metrics about possible misbehavior, even when the feedback is automated and otherwise unmonitored and carries no penalty. That's why there are so many of those "Your speed" radar signs on roads that show the speed of the car as it approaches. It turns out that, if you put one of those right near the speed limit sign, speeders do slow down.
Modifié par MrZork, 10 septembre 2012 - 09:37 .
#7
Posté 10 septembre 2012 - 11:04
Sadira of Tyr
-
- Members
- 172 messages
Thanks guys! I appreciate the help. 
We do have some players with a lot of bags, and crashes usually occur while players are selling items.
We do use creature skins for our undead subraces. Does that make it worse?
Our module on client enter script also excutes our subrace script, which adds properties to creature skins for undead characters.
We do have some players with a lot of bags, and crashes usually occur while players are selling items.
We do use creature skins for our undead subraces. Does that make it worse?
Our module on client enter script also excutes our subrace script, which adds properties to creature skins for undead characters.
Modifié par Sadira of Tyr, 10 septembre 2012 - 11:33 .
#8
Posté 10 septembre 2012 - 11:59
The Amethyst Dragon
-
- Members
- 1 875 messages
Creature skins on PCs shouldn't be that hard on a server. It's only one item on the PC. The game having to handle hundreds of items in PC and merchant inventories, that one's hard on the server.
#9
Posté 11 septembre 2012 - 04:08
henesua
-
- Members
- 3 858 messages
Would it be worth it to escape out of the OnAcquire script when a player is logging in?
I'd flag a player OnClient enter.
And then delay deletion of the flag by one second.
If the flag is set, OnAcquire immediately exits.
Make sense? Or is this a waste of code?
I'd flag a player OnClient enter.
And then delay deletion of the flag by one second.
If the flag is set, OnAcquire immediately exits.
Make sense? Or is this a waste of code?
#10
Posté 11 septembre 2012 - 04:18
Lightfoot8
-
- Members
- 2 535 messages
I guess it depends on how much you do in the OnAquire event And if you need the scripts to set thing up or not. Still if memory serves me correctly, All of the items are aquired before the OnEnter script ever fires. If they where not, there would be no way of stripping player of there items in that event.
#11
Posté 11 septembre 2012 - 04:27
henesua
-
- Members
- 3 858 messages
Well if a a PC has 500 items in inventory, it would be nice to avoid running OnAcquire 500 times when they are logging in. Or do I misunderstand how this event works?
#12
Posté 11 septembre 2012 - 04:41
Lightfoot8
-
- Members
- 2 535 messages
Yes, It would be nice, If it was not needed in the module. But the question is:
Would the check of the local, to stop the running, be that much quicker the the standard TagBased script. 99% of the items aquired will not have a TBS after all.
Now if the OnAquire is the old style. A bunch of chained if... else if... statments. then yes I can see it being quite a drain.
Would the check of the local, to stop the running, be that much quicker the the standard TagBased script. 99% of the items aquired will not have a TBS after all.
Now if the OnAquire is the old style. A bunch of chained if... else if... statments. then yes I can see it being quite a drain.
Modifié par Lightfoot8, 11 septembre 2012 - 04:43 .
#13
Posté 11 septembre 2012 - 11:51
Shadooow
-
- Members
- 4 465 messages
Yes the OnAcquire, possibly OnEquip runs before the OnClientEnter script.Lightfoot8 wrote...
I guess it depends on how much you do in the OnAquire event And if you need the scripts to set thing up or not. Still if memory serves me correctly, All of the items are aquired before the OnEnter script ever fires. If they where not, there would be no way of stripping player of there items in that event.
This is however easy to distinguish via local variable on module like this:
SetLocalInt(OBJECT_SELF,ObjectToString(oPC),1/0) in client enter/exit
there are also some other remarks such as that the oPC isnt valid object (but neither invalid), but im now not sure if that applies in all cases or just after first login atm
#14
Posté 11 septembre 2012 - 03:58
Baaleos
-
- Members
- 1 322 messages
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
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.
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 .
#15
Posté 11 septembre 2012 - 04:34
henesua
-
- Members
- 3 858 messages
I like that method, Baelos. Thanks.
Set an onAcquire flag on an item, next time exit the event if the flag is already set. Very simple.
Set an onAcquire flag on an item, next time exit the event if the flag is already set. Very simple.
#16
Posté 11 septembre 2012 - 05:11
Shadooow
-
- Members
- 4 465 messages
One futher clarification.
Again this is not problem with the way how it works by default. I am working on PW which is missing any persistent storage and so we encourage players to make mule characters. The ammount of items in there often exceeds 500. These players often relogging if they cant log in twice at once. There are no issues with that, our OnAcquire contains only few adjustions from the default.
This is fine, the problems arises when the OnAcquire script is poorly written and ineffective. Tagbased scripting might be cause. I certainly dont think that its okay to try to fire script for each items tag, when only total minority of items has such behavior scripted actually. Now I dont talking about the way how ExecuteScript works, its probably fast and probably handles the case of non-existant script, yet I wouldnt call it if its not really necessary.
The local variable to deal with items only once isnt good idea. You have to also remove this variable when the item is dropped, also what if you need to apply some sort of effect on character, something that must be repeated after relogging?
Anyway, my advice is to make the OnAcquire script as efficient as possible, because you cannot prevent the OnAcquire script to be fired.
Again this is not problem with the way how it works by default. I am working on PW which is missing any persistent storage and so we encourage players to make mule characters. The ammount of items in there often exceeds 500. These players often relogging if they cant log in twice at once. There are no issues with that, our OnAcquire contains only few adjustions from the default.
This is fine, the problems arises when the OnAcquire script is poorly written and ineffective. Tagbased scripting might be cause. I certainly dont think that its okay to try to fire script for each items tag, when only total minority of items has such behavior scripted actually. Now I dont talking about the way how ExecuteScript works, its probably fast and probably handles the case of non-existant script, yet I wouldnt call it if its not really necessary.
The local variable to deal with items only once isnt good idea. You have to also remove this variable when the item is dropped, also what if you need to apply some sort of effect on character, something that must be repeated after relogging?
Anyway, my advice is to make the OnAcquire script as efficient as possible, because you cannot prevent the OnAcquire script to be fired.
#17
Posté 11 septembre 2012 - 06:02
henesua
-
- Members
- 3 858 messages
Are you suggesting that no tagbased scripting be included in the onAcquire event?
#18
Posté 11 septembre 2012 - 07:05
Shadooow
-
- Members
- 4 465 messages
Yes, I tried to suggest this. After more closer look it looks tagbased scripting is ON by default so nvm. Anyway Im not claiming that tagbased scripting is wrong and it makes this. Im claiming that I dont have this ON (and I have very small and effective OnAcquire script) and there arent any lag issues even when char with 500+ items logs in.
Apparently just the fact that it fires OnAcquire script 500 times at once it probably the most extense.
Apparently just the fact that it fires OnAcquire script 500 times at once it probably the most extense.
Modifié par ShaDoOoW, 11 septembre 2012 - 07:08 .
#19
Posté 11 septembre 2012 - 09:00
henesua
-
- Members
- 3 858 messages
OK. I understand your perspective.
Since I do have a bit more than the tagbased hook in OnAcquire, I'll look into some optimizations.
In my experience once CNR is implemented you tend to get characters with huge inventories. I am leaning towards CNR now, and want to be ready for it.
Since I do have a bit more than the tagbased hook in OnAcquire, I'll look into some optimizations.
In my experience once CNR is implemented you tend to get characters with huge inventories. I am leaning towards CNR now, and want to be ready for it.
#20
Posté 13 septembre 2012 - 09:39
Lightfoot8
-
- Members
- 2 535 messages
If you do have a lot in your OnAquire script, You could mark the items that do not have an OnAquire event so that the event can skip them. Assuming that your OnAquire Event is a If.. else If.. statement you could do it something like this.
If ( GetLocalInt(oItem, "NO_AQUIRE_EVENT") )
{
if ( sTag == "tag') DO Stuf
else if ( sTag == "tag') DO Stuf
....
else SetLocalInt(oItem, "NO_AQUIRE_EVENT",1)
}
If done right "NO_AQUIRE_EVENT" local will only get set if none of the tags matched. Allowing the script to just skip over all the checks after the first time Aquired.
Where the above will run into problems is when you add items to your OnAquire Event. But it is not that hard to overcome. You basicly give the script a version number. The first time it is only checks to see if the local is set. To make sure that a new revision of the scrip(with Tag checks added) dosen's skip items PC already possess, just increase the local you are checking on the item. Agreed that the first time players log in again it will check every item in there inventory. But it will only be the first time they log in after a revision of the script.
So your second run of the script would end up looking like this.
If ( GetLocalInt(oItem, "NO_AQUIRE_EVENT")== 2 )
{
if ( sTag == "tag') DO Stuf
else if ( sTag == "tag') DO Stuf
....
else SetLocalInt(oItem, "NO_AQUIRE_EVENT",2)
}
and of cource the third revision just increase it to 3. Ect.
Hope that is helpfull
L8
If ( GetLocalInt(oItem, "NO_AQUIRE_EVENT") )
{
if ( sTag == "tag') DO Stuf
else if ( sTag == "tag') DO Stuf
....
else SetLocalInt(oItem, "NO_AQUIRE_EVENT",1)
}
If done right "NO_AQUIRE_EVENT" local will only get set if none of the tags matched. Allowing the script to just skip over all the checks after the first time Aquired.
Where the above will run into problems is when you add items to your OnAquire Event. But it is not that hard to overcome. You basicly give the script a version number. The first time it is only checks to see if the local is set. To make sure that a new revision of the scrip(with Tag checks added) dosen's skip items PC already possess, just increase the local you are checking on the item. Agreed that the first time players log in again it will check every item in there inventory. But it will only be the first time they log in after a revision of the script.
So your second run of the script would end up looking like this.
If ( GetLocalInt(oItem, "NO_AQUIRE_EVENT")== 2 )
{
if ( sTag == "tag') DO Stuf
else if ( sTag == "tag') DO Stuf
....
else SetLocalInt(oItem, "NO_AQUIRE_EVENT",2)
}
and of cource the third revision just increase it to 3. Ect.
Hope that is helpfull
L8
#21
Posté 30 septembre 2012 - 02:17
Validus II
-
- Members
- 1 messages
Magic bags, player file size, crafting included. Ok lets see here.
Managing magic bags can be a hugeissue IMHO. Screen after screen of bags with no labels and no way of being SURE what is in them until you actually open them. What a pain. A couple of fixes: create new bags/boxes with different looks and labels to help you visually sort them out. A box specifically for gems makes tons of sense, it would not even have to be magic (gems have no weight). Boxes for scrolls and potions make sense too.
Next, reduce the number of bags/boxes a PC can have on his person. To me one full screen should be enough, I would think this could be done by scripting using integers to restrict number of containers on a player?
We all know players log in and out with a lot of stuff they either will not use, do not have time to get back to town to sell or craft with or are simply being packrats, keeping that old sword for 'sentimental' reasons. Pfah! Looks like players need merchants who come to them. So give them some.
Create an item to use in summoning merchants, I have in mind two types. One normal merchie to sell the 'spoils' to and get gold for. The other merchant would be special, a 'storage' merchie, he would buy and sell items used in crafting, crafted items, reagents, maybe even excess scrolls and potions? The price would be one gold piece per item, both buying and selling. Each sell could be stored as an integer on the PC so he could only buy/sell however many he/she originally had. This store would only be used to BUY what it also SELLS so the player could get his stuff back.
If a store is too much to deal with script wise, conversations with an NPC merchant might be used, like Percy in Nordock used to be in buying reagents, I feel sure that could be done. Scripts checking integers on players could then be used to sell stuff back to the player. And with the right scripts this process can be done so ALL of a certain item are taken off the PC at the same time.
I use a script generator though I have managed to adapt or add to scripts in the past. All the above is off the top of my head without looking at any scripts. I hope this might help?
Managing magic bags can be a hugeissue IMHO. Screen after screen of bags with no labels and no way of being SURE what is in them until you actually open them. What a pain. A couple of fixes: create new bags/boxes with different looks and labels to help you visually sort them out. A box specifically for gems makes tons of sense, it would not even have to be magic (gems have no weight). Boxes for scrolls and potions make sense too.
Next, reduce the number of bags/boxes a PC can have on his person. To me one full screen should be enough, I would think this could be done by scripting using integers to restrict number of containers on a player?
We all know players log in and out with a lot of stuff they either will not use, do not have time to get back to town to sell or craft with or are simply being packrats, keeping that old sword for 'sentimental' reasons. Pfah! Looks like players need merchants who come to them. So give them some.
Create an item to use in summoning merchants, I have in mind two types. One normal merchie to sell the 'spoils' to and get gold for. The other merchant would be special, a 'storage' merchie, he would buy and sell items used in crafting, crafted items, reagents, maybe even excess scrolls and potions? The price would be one gold piece per item, both buying and selling. Each sell could be stored as an integer on the PC so he could only buy/sell however many he/she originally had. This store would only be used to BUY what it also SELLS so the player could get his stuff back.
If a store is too much to deal with script wise, conversations with an NPC merchant might be used, like Percy in Nordock used to be in buying reagents, I feel sure that could be done. Scripts checking integers on players could then be used to sell stuff back to the player. And with the right scripts this process can be done so ALL of a certain item are taken off the PC at the same time.
I use a script generator though I have managed to adapt or add to scripts in the past. All the above is off the top of my head without looking at any scripts. I hope this might help?
