I don't mind doing a bit extra if it makes it easier/more customizable. I'll add it to my list

LE, what is the weight of getting "location_id" to be evaluated in regards to groundspawn entries? Meaning... if it's a huge task, we can live without it for now

An example case we're looking to solve are the ? spawns on the Queen's Colony where if they are on the beach areas, they give a "____ shell" for the shell collections, and if they are on the grass areas, they give "_____ feather" for the feather collections.

I started thinking about what the groundspawn_items table might start looking like if we had to have 1 item entry for each physical game grid location where that ? might spawn... that could be dozens. We would have to have

Entry 1, Item 1, Location 1
Entry 1, Item 2, Location 1
Entry 1, Item 3, Location 1
Entry 1, Item 4, Location 1

Then the next ? over down the beach, again:

Entry 1, Item 1, Location 2
Entry 1, Item 2, Location 2
Entry 1, Item 3, Location 2
Entry 1, Item 4, Location 2

That could get cumbersome. Unless you had something craftier in mind. Any ideas? For now, we'll just set up all possible collection items in the zone on each ? to get the items to the players. But I'd like to nail down a design concept before it slips off my radar

For collections I don't think the standard groundspawn items table will work. I think we will need 2 new tables. One defining the collection (id, zone_id, location_id) and the other containing the items that can be found in each collection (id, collection_id, item_id). I hate adding new tables as we have a ton already, but I don't see a better solution.

Sounds good LE. I do not mind more tables - in fact, I love data in the DB. /dance

Sorry, I think I missed the post from you right above mine that said you were adding it to your list. Didn't mean to make this sound urgent, just talking the talk.

Thanks!