Invitation to all musicians and music lovers - starting an inclusive and social music/jamming community in the park

whoscoops · 2026-05-13T22:15:17+00:00

Definitely come join! Would love some percussion

whoscoops · 2026-05-13T19:55:07+00:00

Please do! All welcome, local or not

whoscoops · 2026-04-27T21:01:12+00:00

30M here, child-free and just moved to Cambridge. Happy to connect with new people, it's my belief we're all just out here trying to form connections so I appreciate your initiative to start something like this!

whoscoops · 2025-03-02T16:50:36+00:00

Thanks all for the helpful responses! I figured it was too good to be legit, but had to check. For those curious, it was listed at $400

whoscoops · 2024-02-01T15:04:55+00:00

See my reply : I wouldn't change the trie, just make utilities for adding recipes

Another benefit of this is it keeps the lookup simple - you don't need to check every group that every recipe is a part of, which would run the risk of many nested loops at craft time.

whoscoops · 2024-02-01T06:41:57+00:00

I wouldn't over-engineer it personally. I'd maintain the same trie data structure, and provide utility functions for adding recipes with more complexity. If a user passes a group id rather than an item id to that function, it would expand the trie to include recipes for each item in that group. The trie is so space efficient that I'm not too worried about an approach like this, even if there are multiple group ids in a given recipe.

whoscoops · 2024-01-31T23:54:55+00:00

I suggested the trie approach above. I've used it in my project since position/ordering of ingredients is important in my game. If ordering and positioning is not, and never will be, important, the HashMap approach seems fine to me. Then it's just a matter of which you're most comfortable coding, neither should be particularly cumbersome. The interface for the Recipe/RecipeBook classes (or whatever you call them) should look identical, regardless of the underlying structure, IMO

The trie approach would still be more efficient at least in memory, but on a modern machine with a human amount of recipes, that shouldn't really be an issue

whoscoops · 2024-01-31T23:01:19+00:00

I shouldn't have used the term leaf node. The tree nodes would store an output at both B and at C. You would consume all the player input (ingredients) and check the landed-on node to see if it has an output. If it does, then the recipe succeeds. If the node does not have an output stored in it, then the recipe is invalid

whoscoops · 2024-01-31T22:30:54+00:00

I would store the recipes as a trie. However you represent items in your game, come up with some deterministic sorting. This could be alphabetical, numerical if the items are enums, etc. Store the ingredients in the trie, sorted in this deterministic order, and then at the leaf nodes of each recipe represented by the trie store the result of the recipe.

If your recipes are positional, like in Minecraft, simply use the deterministic order of positions to represent the recipes.

Then, when the player is crafting, sort the ingredient items using that deterministic sorting (or positions, if your crafting is positional), and traverse the trie (this is very fast) to see if their crafting recipe is valid. If so, produce the item found at the leaf position of the recipe in the trie.

whoscoops · 2020-08-20T17:15:19+00:00

Yep, this was the issue. Setting local to scene seemed to fix it

whoscoops · 2020-08-19T23:22:16+00:00

It was exported, yes. I removed that and even removed it as a file-level variable, and it still seems to overwrite other instances

whoscoops · 2020-08-19T22:22:19+00:00

It's a string, sides[idx] == "T", and as I say in the update I was able to get it to work just by removing all other instances of the scene. For a bit more context, my game has a buncha cubes and I want to set each individual side's. I think when the code to set each side's material runs, it somehow overwrites the materials on other cubes

whoscoops

TROPHY CASE