There's a way?
OnStoreClosed Script
#1
Posté 07 septembre 2010 - 01:51
There's a way?
#2
Posté 07 septembre 2010 - 02:35
#3
Posté 07 septembre 2010 - 02:37
#4
Posté 07 septembre 2010 - 02:44
#5
Posté 07 septembre 2010 - 02:56
http://nwvault.ign.c...s.Detail&id=991
This one from the same guy I like a little better as you can make it so the store cleans itself after every 3rd opening so it looks like its inventory is changing.
http://nwvault.ign.c...s.Detail&id=990
#6
Posté 07 septembre 2010 - 02:57
Modifié par TSMDude, 07 septembre 2010 - 02:57 .
#7
Posté 07 septembre 2010 - 02:59
Let me know if any of this does not make sense...
Hmmm... Now how did it work to put stuff in a code box again? *takes a guess*
/*-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
* File Name: m_recreate_shop
*
* Purpose: Goes in the onClose event of a shop. It will destroy the shop object
* and drop a new one. The shop object must have a blueprint in the
* palette for this to work.
*
* Used to clean up inventory of shops that a player is not likely to
* want to purchase items that other player's have sold.
*
* Example: Bijou's gem shop in Genesia.
*
* Created By: Mistress
* Created On: 7-22-09
*
* Modeled after and adapted from:
*
* Change Log:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/
void main()
{
// Save off the tag so we can recreate it later
string sStoreTag = GetTag(OBJECT_SELF);
// Save off the location of the shop
location lStoreLoc = GetLocation(OBJECT_SELF);
// See if the shop has a counter.
int nCounterMax = GetLocalInt(OBJECT_SELF, "MYTHOS_SHOP_NUKE_MAX");
int nCounterCur = GetLocalInt(OBJECT_SELF, "MYTHOS_SHOP_NUKE_CURRENT");
// Increase the counter for the close we just did.
nCounterCur++;
// Nuke the shop if there is no counter or we have reached the max number of
// closes
if(0 == nCounterMax || nCounterCur >= nCounterMax)
{
// Destroy the shop
DestroyObject(OBJECT_SELF);
// Now drop a new copy of the shop on the map
object oMerchant = CreateObject(OBJECT_TYPE_STORE, sStoreTag, lStoreLoc, FALSE);
if(oMerchant == OBJECT_INVALID)
{
WriteTimestampedLogEntry("ERROR: " + sStoreTag + " failed to recreate in script m_recreate_shop.");
}
}
// If we aren't nuking the shop, then see if we need to update the counter
else if(0 != nCounterMax)
{
SetLocalInt(OBJECT_SELF, "MYTHOS_SHOP_NUKE_CURRENT", nCounterCur);
}
} // END of void main()
#8
Posté 07 septembre 2010 - 03:02
#9
Posté 07 septembre 2010 - 03:27
#10
Posté 07 septembre 2010 - 05:29
#11
Posté 07 septembre 2010 - 05:38
The reason we use OnOpenStore, rather than OnCloseStore, is because a PC could be viewing the store, other than the one closing it, and by doing so, they would wipe the store.. This can still happen if a PC opens the store while another PC is viewing it, but the benefit is, the PC cannot see what the PC just sold the store, so no spying..
// This script goes into OnOpenStore.
// Made by Darvin Kezar.
void main()
{
object oItem = GetFirstItemInInventory();
int nCount = GetLocalInt(OBJECT_SELF, "Count")+1;
SetLocalInt(OBJECT_SELF, "Count", nCount);
if (nCount == 1)
{
while(oItem != OBJECT_INVALID)
{
SetLocalInt(oItem, "Default", 1);
oItem = GetNextItemInInventory();
}
}
else
{
while(oItem != OBJECT_INVALID)
{
if(GetLocalInt(oItem, "Default") == 0)
DestroyObject(oItem);
oItem = GetNextItemInInventory();
}
}
}
Modifié par Genisys, 07 septembre 2010 - 05:40 .
#12
Posté 07 septembre 2010 - 06:10
So much complication:
Step1> Make the store.
Step2> Let player browse buy/sell.
Step3> Close and destroy the store when they finish.
Step4> There is no step 4, it repeats every time you open or close the store.
My base module does this already. (Look at my projects)
It has it's pros and cons.
pro: It won't build much lag due to the store being opened or closed especially if cashe`.
con: It does not save any inventory that has been sold, and reopens a new each time the store opens.
#13
Posté 07 septembre 2010 - 09:02
#14
Posté 07 septembre 2010 - 09:17
Mephisto Gladius wrote...
Is there any way to remove all the merchant inventory items after PC closes store? This merchant only buy stuff, and it's causing lag by having lots of items, so I want to remove them.
There's a way?
Put this on close for the store. If a PC can not buy from the store, it does not matter if the Items vanish before his eyes or not.
void main()
{
float fDelay;
object oItem = GetFirstItemInInventory();
while(GetIsObjectValid(oItem))
{
DestroyObject(oItem,fDelay += 0.1);
oItem = GetNextItemInInventory();
}
}
#15
Posté 07 septembre 2010 - 10:38
Xovian wrote...
It has it's pros and cons.
pro: It won't build much lag due to the store being opened or closed especially if cashe`.
con: It does not save any inventory that has been sold, and reopens a new each time the store opens.
Con: You must have it on your pallette which when you have a large server this becomes noteworthy as it takes up valuable resources.
If you add the little extra of it cleaning every now and then like the systems I linked then what happens after the third player who opens the store it gets cleaned when that player leaves the area. It is nice and works like a charm and causes very little fuss.
In a "SP Module" though yours does indeed work much better.
Did the OP who is the VIP specfiy if for MP or SP or just go MIA on the DL?
#16
Posté 08 septembre 2010 - 10:48
TSMDude wrote...
Con: You must have it on your pallette
which when you have a large server this becomes noteworthy as it takes
up valuable resources.
Not a con:
Even if you put a store in that isn't on the pallette, you will be required to script the onopen and onclose, also taking resources, so it is a nil argument to say it uses resources. Anything in the game will use some form of
resource. Pallette or not. The other way around this is of course limiting the total amount of stores, every barkeep, and every seperate "type" of store just adds to such resource use. If they are narrowed down to only a couple or so for each module (even if different areas) this problem becomes a non-issue as well.
It's easy to set how often you want something to clean, I prefer it be cleaned on every onclose (also prevents unintended trading...yes it does happen), but that's just my personal preference as a builder. To each their own, there is no "wrong" answer here.If you add the little extra of it cleaning every now and then like the systems I linked then what happens after the third player who opens the store it gets cleaned when that player leaves the area. It is nice and works like a charm and causes very little fuss.
In a "SP Module" though yours does indeed work much better.
I do prefer building single player, however my scripting resources i did for pw's also used this method, as playinga gm you could see (view triggers ect) the excess tags from it not being cleaned (depending on time limit, or if pc's are in the area ...ect). I also noted that players could run into these "dead" tags and it could forcefully switch their direction of movement, it also has a bad side effect for guards using WalkWayPoints. They can/will hit them, and stop walking their way points unless you are using an onheartbeat script to keep them going.
Good question, no idea.Did the OP who is the VIP specfiy if for MP or SP or just go MIA on the DL?
Either way this thread has shown several viable ways of overcoming the OP's questions/comments.
Modifié par Xovian, 08 septembre 2010 - 10:50 .
#17
Posté 09 septembre 2010 - 12:15
Xovian wrote...
Not a con:
Even if you put a store in that isn't on the pallette, you will be required to script the onopen and onclose, also taking resources, so it is a nil argument to say it uses resources. Anything in the game will use some form of
resource. Pallette or not. The other way around this is of course limiting the total amount of stores, every barkeep, and every seperate "type" of store just adds to such resource use. If they are narrowed down to only a couple or so for each module (even if different areas) this problem becomes a non-issue as well.
I stand corrected as I can see how you could do it via On Open and On Close so I guess it is just a matter of preference as both use/save resources in different ways.





Retour en haut






