Jump to content

Recommended Posts

Posted

Personally I still like qsa's idea to write one(or three) classes for loot, but afaik a multi-heritage OOP design throws a few problems (C-casts everywhere) - and I didn't understand why he didn't implement these classes as member variables of the creatures, corpses, or whatever ;)

As long as you do not cast to lootable, you are safe. As I see it, there's no principle problem using multiple inheritance here.

There reasons I don't use it as member variable is that it fits much better to OOP idea. Object (GO/creature/whatever) "is a" lootable. It differs from Object "contains/ has a" lootable.

Besides, it saves you access : obj->loot->something to obj-> something :)

You can always say "object has a loot" but, meh...

You are right in general, that its exactly the same thing. The only difference is approach. The way you look at things. Bottom line, C++ is level 1 language, therefore, classes and their relationships exist only in source code.

You can call this patch "proof of concept". It offers no functionality over other idea, beside arranging things differently.

I totally forgot about recent changes in item loot. Guess patch has to be revised a little bit. Don't have the time right now, but I'll get to it eventually.

Best regards.

  • 1 month later...
Posted

There is a similiar bug for conditional loot in scripted instances (i.e. loot from Sartharion hard modes) where additional items are always free for all and normal loot can be group/master etc. looted. Maybe similiar patch could be wrote for such cases?;)

  • 4 weeks later...
  • 10 months later...
  • 2 weeks later...
Posted

If Schmoozerd or someone else could reply to this I would appreciate it. With your patch listed in post #30 that is a full patch? Lootable.cpp and .h would no longer be needed or is that an upgrade to the first patch listed?

Posted

Schmooz's patch in post #30 is a full patch, but, if I understand correctly, his last post stated that he feels it's ready to be committed to the core once he's polished it a bit, so this may not be the final version.

  • 2 weeks later...
Posted

Ore veins are chests too. With this pacth, the vein that was opened by someone and not fully looted, will appear as empty to other ones. And will not be able to despawn.

Why won't it be able to despawn? Because veins don't despawn before they're fully looted.

Posted

Also there is an issue in instanced maps, one can leave from group just after killing a boss and loot a chest, thereby is will not be available to raid.

But in this case group recipient and recipient guids can be manually set by map script, for example to the guid of party's leader, whose member has done a killing blow.

On official servers one can't loot a chest, when it is being looted by another player (if he's viewing it's contents). I guess it is simply because chest in that GO state is not clickable.

Maybe there is a rule that not allows looting a chest to third person, when it has group loot in progress?

Posted

how would normal chests (or veins) work on retail?

is there a delay from when the first user looks into it, until the next user can mine/loot?

or is it the last looter/ miner get's the stuff inside?

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy Terms of Use