I do not mean to make yet-another-priorities-thread, but they all seem to get lost in the haze anyway. LE asked me the other night for my list of priorities - and this time, rather than drown him in a sea of wishes, I am asking for one thing at a time til we get it done.

We've been looking for this since August, so hopefully harvesting/gathering can be implemented now that Items are taking shape. If there is still some work that needs to be done to the emulator BEFORE harvesting/gathering can be implemented, please let me know so I can try to help or push things along.
This is the brick wall we hit with nearly every script we write.

Haha, that looks like mine. Depending on how LE wants to do harvesting, we may be able to use the obtain item function for those quests but I didn't want to make any assumptions. However, a lot of quests that require you to harvest do not actually put an item in your inventory so we would need some kind of special support for that.

Good to see you, Scat. I thought I'd lost ya

OK, it will be done. I am thinking about adding the following two tables: Anything that I am missing? I figured that it would be nice to allow the server admin to customize how many times a particular ground spawn could be harvested. The probability system will work like loot items - the numbers don't matter it is the ratio to the total that determines the percentage. I am going to be creating a GroundSpawn class in the code as well.

In doing some of the newbie harvesting quests I notice that sometimes you'll get between 1 and max_number items per gather cycle, with each node offering 3 "successes" before it poofs. I could harvest 5 times, get 2 failures and 3 successes - each success having at least 1 item, and sometimes up to 5(? not sure about that total).
Will this be covered in this design? Also, could we just use spawn_loot and the loot tables to assign lootable items to these nodes?

Yes, also don't forget the chance to get a rare. Unless they changed this, when you harvest a rare from a non-quest harvestable, you'll automatically get 10 of the raw harvest with the rare harvest (or maybe when you get lucky and harvest 10 raw harvest, they reward you with a rare?). 10 seems to be the max for non-quest nodes and I think quest nodes can go over 10 but that would be a good thing to let be customized as well.

Forget what GU changed harvested nodes, but in the beginning all you got was 1 item each pull. You still get 3 successful pulls before the node vanishes, but now you either get 1, 3 or 5 items each pull.
Now for the rare portion, you get a chance at a rare each pull, sometimes you will get just the rare, or you might get a rare and 10 harvestable items on the one pull.
So the only time time you can get the 10 items is with the rare event, otherwise it's 1, 3 or 5.

I thought of a couple more scenarios here.
Books: What about items you inspect that offer book/page reading? While the books may be 10 pages, only 1 shows during a particular quest step - and some steps throughout reading pages offer quests (or further steps).
Collections: When you find an item that is in a collection, does it automatically go into your collection now? Or still into your bag, then you have to add it to your collection manually? Would finding collectable items need to update anything, or just the adding-to-collection step of the item?
entity_commands: how do we govern what right-click menus are allowed on a given item? Examine, Equip (Unequip if equipped), Destroy, ... ? We will need to tie an entity_commands list to the items, too.

John Adams wrote:In doing some of the newbie harvesting quests I notice that sometimes you'll get between 1 and max_number items per gather cycle, with each node offering 3 "successes" before it poofs. I could harvest 5 times, get 2 failures and 3 successes - each success having at least 1 item, and sometimes up to 5(? not sure about that total).

Good point, I'll have to add that.

John Adams wrote: Will this be covered in this design? Also, could we just use spawn_loot and the loot tables to assign lootable items to these nodes?

We *could* use the loot tables, but I wanted to keep them separate to avoid confusion. If you are fine with it using the loot tables I could handle most of the complexities behind the scenes.

Scatman wrote:Yes, also don't forget the chance to get a rare. Unless they changed this, when you harvest a rare from a non-quest harvestable, you'll automatically get 10 of the raw harvest with the rare harvest (or maybe when you get lucky and harvest 10 raw harvest, they reward you with a rare?). 10 seems to be the max for non-quest nodes and I think quest nodes can go over 10 but that would be a good thing to let be customized as well.

That is a good point, I'll have to add the rare item support into this somehow. If I end up using the loot tables for these groundspawn items, I was thinking about adding secondary_item_id and secondary_item_charges fields to the lootdrop table. If the secondary_item* fields are given and the loot happens to be the item_id it will give the item_id AND the secondary item. This allows it to be pretty customizable. Any thoughts?

Zcoretri wrote:Forget what GU changed harvested nodes, but in the beginning all you got was 1 item each pull. You still get 3 successful pulls before the node vanishes, but now you either get 1, 3 or 5 items each pull.
Now for the rare portion, you get a chance at a rare each pull, sometimes you will get just the rare, or you might get a rare and 10 harvestable items on the one pull.
So the only time time you can get the 10 items is with the rare event, otherwise it's 1, 3 or 5.

Hmm, assuming I use the loot tables for this I guess I could implement it by adding a is_rare (0 or 1, default 0) and rare_multiplier fields to the lootdrop table. If the player gets a rare item, it multiplies the max number of charges for another item by the multiplier. So if the max charge received was a 5 before, it would be 10 if the multiplier was 2. Which solution would you guys prefer, this one or the one above?

John Adams wrote:I thought of a couple more scenarios here.
Books: What about items you inspect that offer book/page reading? While the books may be 10 pages, only 1 shows during a particular quest step - and some steps throughout reading pages offer quests (or further steps).

That will have to be handled separately whenever I implement books.

John Adams wrote: Collections: When you find an item that is in a collection, does it automatically go into your collection now? Or still into your bag, then you have to add it to your collection manually? Would finding collectable items need to update anything, or just the adding-to-collection step of the item?

You still have to examine it before it asks you to add it to a collection.

John Adams wrote: entity_commands: how do we govern what right-click menus are allowed on a given item? Examine, Equip (Unequip if equipped), Destroy, ... ? We will need to tie an entity_commands list to the items, too.

As of right now I don't believe that the text is customizable beyond the standard ones. Those fields are the menu_type, sub_type in the Items table. I haven't explored all the scenarios with these fields.

Ahh, so right-clicking on an item is not considered an "entity_command" like with everything else you can interact with? Regardless, as long as we can build the proper right-clickies (or if they are hard-coded/assumed), I think we're good there.
As for using loot tables, really it comes back to whatever is easiest for you to implement. The loot tables are there, we know how they work. These are still "loot" sorta, just not off a killed mob. If you think it'll be too confusing, we can separate them. My angle was that I am now basically building loot tables in two different places.
Your call, whatever is easier for/makes more sense to you.

What is the alternative to using the loot tables, scripts? I guess my vision of these nodes has always been the loot table.

No, the alternative was to build new tables for ground spawn loot only. It does make sense to separate them since they are a different subsystem, I was only suggesting using the existing tables if it's easier.