I made a prototype of an auto tiler and it should work fine but there seems to be a bug.
In some of my blocks it won’t give a value output and just keeps a number at 0 making it play the wrong animation.
Basically if you look at the samples that kind of look like an L the caps of them only have a value of 0, causing them to play one type of animation.
I think it’s a bug but if it’s not and I’m being stupid then could some one point it out? Here’s a link to the game.
Note that not all of the animations have been uploaded but the ones that I’m having an issue with have been uploaded.
Also probably should have mentioned this but the issue happens inside of the bundle labeled as “Filter”. There’s an input number behavior and an out put number behavior, the output doesn’t receive a number from the list so it stays at zero although the number that should be filtered through is there but it won’t accept it and outputs the number 0.
Edit: so this is still kinda true but I think the problem has spread, to be honest I don’t think I know where the problem is anymore, but I’m pretty sure it’s something to do with the "shrink "“ray cast” and “filter” bundles.
Gosh I need to read the behavior hand book more closely, or really actually read it, I just spent 3 hours staring at everything that had to do with text and lists.
Thanks for doing that, it’s now a lot cleaner than before although it still seams to have the same problem.
I was actually able to fix most of it by using another timer, if it sent out a ray cast to early the blocks wouldn’t have enough time to shrink and accidentally clip one of the corner.
Maybe all I needed was a good nights rest cause these problems are starting to seem to be really obvious now.
Now the original problem that I made this post for, I now realize that the blocks will send a ray cast and detect a block vertically or horizontally and diagonally from it. This causes a problem when you try to make those L shaped pieces.
For example in a regular L shaped piece the top cap will detect a block south and south east from itself.
This is a problem because it adds the numbers 64 and 128 (=192) but 192 isn’t in the filter list.
I’m going to try to use some sort of way to detect if the number sent by that is not in the list and re cast the ray raycasts in the North, South, West and East directions only.
Well @glowbug, the first part is still in the system, I was just saying that using a “List Each” behavior would be faster (and will work and be instant if set to 0) (you can test the List Each behavior by input + to a text behavior).
Outside that bundle, you still have a timer set to 60 (6 seconds) and it takes 6 seconds for the filter input to come in. This huge 6 second delay is why it takes so long for the number to change.
By looking at all the bundles, I think you could really cut out a lot of the time with those timers.
These operations like raycasts, size, lists, expressions, ect. can all be done within a few frames.
Here’s the changes I would make for the filter bundle, but you should really shrink the time in all the other bundles:
Yes, I will do that, but the reason for them being so slow is due to the ray casts, I want to be able to see each step so I have some way to see what’s going on.
Once I get everything in place I’ll definitely shorten all of the timings.
Raycasts works in 1 frame, but I understand you want to see each step.
None the less, the screenshots I sent should still work after the raycast (though you could increase the timer on the bottom image to see when the number is sent to “Find”).
But as far as I see (after 6 seconds), the number does change and outputs the index and changes that 0 to something else.
Wo hooo I fixed it, now it should be all working!
Now I just have to upload the rest of the sprites.
Thanks JR_01 for the insight, I’ll definitely take your advice.
