No drop/ no trade flag rule

[bufferofnewbies]

I was wondering if someone better at coding than myself (read as: pretty much anyone in the world except Al Gore) would think about trying to set up a new rule_value for setting a flag to indicate what level of account status could ignore the no drop rule.

This way GMs can bypass the restrictions of it when needing to recompensate a player w/o having to go through such a silly series of events as makeing a killable npc with the item in it's loot list for them to kill.

With the rule system, different servers could set this access to balance for any special status accounts they have placed into their server without having to rewrite coding that might change in a future patch.

[John Adams]

That's a great plan. The fun side of it is then Emulator GMs can use the excuse "Sorry, only a lead GM can summon and hand out no-drop items. I will escalate your ticket to a lead"... and the player can feel like Live again.

:)

But seriously, good idea.

[Rogean]

That is currently not possible for us because the restriction to transfer no-drop items is handled client-side. If you try to trade a no-drop item your client will say "no" and won't even ask the server.

GM's On live can do it because they actually run a completely seperate compiled version of the client that we don't have access to.

[bufferofnewbies]

ahh rats. Was worth a shot. Thanks for the update. :)

Guess It's back to #spawn I_Have_Your_Stuff_Playername and equiping him.

[John Adams]

BoN, you might be able to make a clever quest script out of it. If someone needs a no-drop item, give them a tradeable "token" to turn in to a specific NPC (lost-n-found dept? heh) and when that NPC gets that token, that ND item is spawned for the player.

Imagine the exploits. ;)

[bufferofnewbies]

I was truely thinking about trying to fool the dbase into thinking the GM is on a FV regulation server. Since there is a flag for FV no drop. Not sure if that is still applicable if it's a client side lock, but I love to break things while I experiment. Actually, Im not even sure if I can figure out how to set that up/ if it is even possible.

But such is life.. You never know how far you can go, until you at least try to go there.

Thanks for the replies all. The bigger stuff I usually leave to people more experienced for now, as I still have so much small work to do here it is like walking through a swamp. But this I plan to make some time for, to at least try to figure out how the server is setting itself up in the coding. I'm like a kid in a candy store here, Oww. My tummy aches...

[LostZaphod]

I think you sould be able to change the summon item to use the target of the summoner. The problem is if the summoner inputs the wrong value you would never know.

in command.cpp is

void command_summonitem(Client *c, const Seperator *sep)

with in the if's it could be checked if a target is selected and then summon to their cursor.

this is some ruff UNTESTED code....

Mob *t;
if(c->GetTarget()){ // have target
t=c->GetTarget();
t->CastToClient()->SummonItem(itemid);
}
else
{
c->SummonItem(itemid);
}

[bufferofnewbies]

Now that is a very nice design fix. Simple, elegant.. and without the need of excessive delving into things best left untouched. Thanks for the insight. :)

[Rogean]

I was truely thinking about trying to fool the dbase into thinking the GM is on a FV regulation server. Since there is a flag for FV no drop. Not sure if that is still applicable if it's a client side lock, but I love to break things while I experiment.

That isn't a bad idea. The only problem is that we don't know how to tell the client that its on a FV Type server (Its probably among a lot of the unknown values in many structures). If we did know, we could send that variable specifically to characters with a certain status.

[fathernitwit]

Good idea, I put in a "giveitem" command to accomplish this.