Hello. It would be great to have hash tables that have more than one column per key. For example, in my game I have 100 item prefabs, and an icon for each. Currently I must have a giant hash table containing all prefabs, and a second Icon Hash table containing all icons. Now that I'm splitting the prefab hash into 26 hashes, one for each letter, to make it less clunky to alphabetically add new items, it means I might want to do the same for icons, meaning I'll have twice the number of hash tables since each "type" will need its own.

But if I could have one giant grid (honestly like a SQL table that can store item prefabs, sprites, etc.) then my life would be glorious.

I currently use SimpleSQL to retrieve item strings from database files, and it makes my like SO much better, but unfortunately SQL tables are not "in Unity" so they can't contain Prefabs, sprites, etc.

What is the best way to currently handle this? When I said my game has 100 items, I lied. it actually has 400 and counting, and that's just for basic props; each quest will have its own unique puzzles, keys, etc., too. so anything to reduce duplicated storage, would be great.

I've considered using Scriptable Objects for each item to store this info, but that would mean a unique game object or script thing for each of 400 objects, which is way clunkier than having them all in one place. Not to mention that if I later update the Script for the Scriptable Object, I could lose A LOT of data if I do it wrong.

The big problem is, to quickly find Hash Table entries, they must be alphabetical because there is no search function in the hash table proxy thing. And making them alphabetical is a pain because you cannot "insert" new keys at various points, so new items must just be tacked onto the end. If there was a way to solve these problems, possibly by adding a search function to hash table proxies, this all might be less problematic.

An excel spreadsheet listing all actions along with their millisecond count, would be super handy for devs to decide which approach to script things with.

For example: when the player acquires a new item, I have a 26 hash tables named after each letter, where I store prefabs of each item. Should I have a parent AllPrefabs game object where I say, "find child named b" then get the entry from the b hash table, or should I have a SEPARATE hash table with 26 entries, where I just "hash table get" the one with a key of b?

In other words, which is more expensive: find child, has child, or hash table get?

A way for devs to rank the actions by expense would be very handy for optimizing the script profiler.

Hi,

 ArrayMaker is still very much required in my opinion.

ArrayMaker gives you access to a more flexible list, and hashtable, PlayMaker FsmArray is more constrained on that regards, with a fixed type. I sue both personnaly, switching to ArrayMaker when I need more power for my lists.

Bye,

 Jean

Okey cool! Thanks for they reply

Hi,

<Disclaimer: you might be a bot, but the question is interesting nonethless , please reply, and I'll remove the disclaimer />

 Unity 4 is totally outdated, unsupported by playmaker and almost all other assets you'll find.

 just get the latest Unity, there is a free tier, the only thing is a unity splash screen. So there is no need to hold back in using the latests.

PlayMaker is indeed the best visual scripting available for Unity, period. and it's been the case since day one ( back to 2011 !).

that's because it doesn't try to mimic what c# script is, instead it brings the concept of "Finite State Machine" FSM and custom actions, which encapsulate regular scripts to perform a given tasks. And this combination is the most powerful one so far.

1:)  yes, PlayMaker runs everywhere Unity can.
2:) yes, PLayMaker comes with a full api so that you can control it via script, access fsm, variables, events, so it's ok to mix regular script and playmaker in the same project, I do that on a regular basis.
3:) PlayMaker capabilities ends where your c# expertize ends, because custom actions are in regular c#, you can create your own and thus making PlayMaker flexible and provides just the nice FSM design pattern to develop faster than with just c#

Bye,

 Jean

Hi,

 uhm... how many enenmies do you have? lookat is expensive, so in your case, it might make sense that I create a custom actions so that you don't waiste perfs on that.

Bye,

 Jean