I’m building a map from hex tiles. Each hex has its type: one of five letters or ‘A’, which means it’s type will be chosen automatically in Blueprint - a mix of its nearest neighbours.
For debug purposes, currently I’m printing either the type (D,F,M,S,R) or (for A) an array of neighbours.
I encountered a problem. Everything works OK straight after compiling the Blueprint, but gives strange results while in Simulate mode or after opening the project again.
What could be the cause of the problem? Is it possible that the errors result from querying all members of hex’s own class?
I attach 3 screenshots and the project.
After lots of playing with your idea (which is great and i will steal it for my personal selfish gain in future):
I think culprit here may be “get distance to” you are comparing component distance from local root to world coordinates.
I recreated your idea in totally new network, same “feature” appears. but when i move all hexes together result varies, and should not because relative distance is same.
PS. Anyway this is a bug in blueprints. This may be reason i could not get my maze example to work correctly for last two weeks.
My network, same behavior, not using “distance to” because i was trying all methods to calculate distance i could think of:
Yesterday you wrote about a possibility that all blueprints in Simulate are constructed “at the same time”, so they don’t know about the ones still to be created.
So I did a simple check: “Hex, tell me how many hexes exist in the world?”. It seems that, actually, all of them:
So at least the unchanged parts of hexes - variables and world positions - should be available and the system should work. (If all blueprints are recreated from scratch on the beginning of Simulate/Play, then my system has no chances to work in a stable manner, but the screenshot above contradicts that).
But when the blueprint collects the neighbours’ types and distances into an array, the errors remain.
A more predictable option will be to write a plugin, but I’d like to avoid it for now.
Ok i found solution, there is something fishy going with determining neighbor location trough reference. And that is probably same thing that messed my maze generation.
But everything is fine and dandy when that neighbor gets self location and stores it in variable.
So to fix that whole problem make vector variable to store self location, then for distance use that variable for hex you are processing and for neighbor.
PS. investigated further.
In some cases get actor reference> cast to actor > get actor location or get world location returns 0,0,0 vector even if i can read variables from them (referenced actors) correctly
But when you simulate and drag actor it will update variables correctly. If you attach actor to actor (by dragging it in list of actors in level) parent actor cannot get locations of its child objects,
probably because parent is spawned first.
This indeed looks like some BPs at construction time do not have neighbors yet, so they set 0,0,0 there. Probably optimization thing or “feature” that is hard to fix.
Now, the farther the other hex is, the lower is its contribution to the automatic hex’s type. SearchDistance was increased to about 4 hexes.
Blueprint’s SearchPower variable defines how much are instant neighbours promoted.
For example, when power is 1, two distant Military terrains can overweigh a single adjacent Scientific terrain.
But with power of 2 (like on the picture below), Scientific wins (slightly).
Thanks. Still a bug probably, so I filed a 