issues with setBlend

PB____

Since Jon mentioned on the forum that FUZE will have a big performance improvement, that motivated me to start a new project. I'm not sure if I'll ever finish it and I don't put any commitments on it, but rather it's something I can put a few hours in whenever I feel like it.

I've mentioned on Discord before that I had some issues with setBlend and that was with this project. To demonstrate some of the issues I run into, I've shared the project now with code nxkh21kb1z (note that this is a work in progress, it's neither stable nor complete).

The main issue that I wanted to report is the folowing:

Write on line 132: setBlend(0) (this originally was a commented line, but I accidentally shared an update without the comment)
Start the game
In the menu, select "Level editor"
quit the game using + or F5

You'll now notice that the blend mode of FUZE itself is set to 0.

I've tried to create a simple reproduction scenario, but didn't manage to do that yet. And I figured that this wasn't a project worth setting up an NDA for, so I just shared it anyway :)

However, even if you leave line 130 commented, you'll notice some weird rendering issues with setBlend as it is.

Some handy controls to know:

L and R to change the selected terrain (selected terrain is displayed in the bar at the top)
up/down/left/right change selected location to place terrain
A to place terrain at the location of the cursor (sometimes crashes the game, probably my fault, but I'm not sure yet of the cause)
sticks to move the view (but the selected location will always scroll into view)

TLDR:

bug in fuze: uncomment setBlend(0) to change the blend mode in fuze itself
As I understood from our discussion on Discord, this would be a new discovery. So far I didn't manage to create a more simple reproduction scenario than this game, but hope this helps in tackling this one.
bug in fuze: setBlend bleeds to regions even outside of the draw target where it was used
I suspect this bug was already known. So I'd like to know if this is something that would be fixed in the upcoming update? Any information on that?
bug in game: game may crash when placing terrain sometimes
I think this is something I need to figure out myself :) but if someone happens to spot the cause anyway, I'd like to know of course! :)

PB____

Big thanks @Martin for your help on Discord!
So far I've found out that:

Bug 1: should be fixed in the 2.15 update
Bug 2: this still occurs in the 2.15 build
Bug 3: Looks like this was a Fuze bug after all (crash wasn't reproducible in the build he was using)

It is also a known issue that the performance is bad, but I have some ideas to improve that.

EDIT:
I'm not sure anymore if bug 3 really was a Fuze bug. I had nested arrays, and I think Fuze does not like it if the types in an array are not consistent, and it seems to sometimes also define the type of an array based on the types that it contains (so an array that contains numbers is of a different type than an array that contains structs). So when I was using the type Array< Array<int> | Array<chunkStruct> > (an array of arrays that contained two different type of arrays) Fuze did not like that.

That in it self could be a design choice (I hope not), but the prominent issue is, that type checking occurred sometimes (not all of the times) and only when calling len, but not when setting a value. That makes it hard to figure out what's going on.

PB____

Because I continue to work on this project, I've shared a newer version (currently at v0.0.4) to back-up my progress, so this overrides the original reproduction scenario.;

I've managed to refactor my program to avoid bug 3 (so it seems up till now), in stead of arrays with arrays, I now use arrays with structs with arrays. So in stead of:

[
    [ [1,2,3],[1,2,3],[1,2,3] ], 
    [ [1,2,3],[1,2,3],[1,2,3] ], 
    [ [1,2,3],[1,2,3],[1,2,3] ]
]

I now use

[
    [
        .values = [
            [
                .values = [
                    [ .values = [1,2,3], .count = 3 ],
                    [ .values = [1,2,3], .count = 3 ],
                    [ .values = [1,2,3], .count = 3 ]
                ],
                .count = 3
            ], [
                .values = [
                    [ .values = [1,2,3], .count = 3 ],
                    [ .values = [1,2,3], .count = 3 ],
                    [ .values = [1,2,3], .count = 3 ]
                ],
                .count = 3
            ], [
                .values = [
                    [ .values = [1,2,3], .count = 3 ],
                    [ .values = [1,2,3], .count = 3 ],
                    [ .values = [1,2,3], .count = 3 ]
                ],
                .count = 3
            ]
        ],
        .count = 3
    ]
]

The struct also has a count property where I manually keep track of the length. Of course I wouldn't have done that if I didn't run into issues using len, but this work around seems to work for me so far, so for now I'm going with it...

If you want to reproduce bug 2 with the current version, that's still possible, but then you need to go to Options => Optimizations => Scale and change the value of that setting to 85 (you can see the value in the description on the left side of the screen while you have the Scale option selected...

EDIT:
I have now unshared the program (so the code nxkh21kb1z should not be usable anymore), because I want to often back-up updates of the program that do not need to be reviewed.