Thanks for the report- I've put it on the to-do list!

This is being looked and currently and will most likely be fixed in the next patch!

@vinicity Thanks, I'll take a look! And yeeessss... deltaTime... that sounds exactly along the lines of what I was thinking...

In the interest of time, I'm tempted to just forge ahead with my game as-is, then make a "2.0 engine revision" with improvements like this, and which I (and others if they want) could also use for future projects...

@Willpowered thanks, luckily it's not easily triggerable unless you pressed accidently F5 in that location in the image selector (like i did).

There is also an issue with not all memory being returned when restarting the game.

In F4NS 3.0.0, the interpreter uses a pool for some internal resources, which are around 32MB each. These aren't cleaned up at the end of program execution, but rather reused on the next run. They're also reused during program execution. You may notice a lower available memory while running your games due to this, but it also increases speed. This system may change in a future version.

These two issues eventually causes an memory allocation error when I start my program (after a long Fuze session with lots of program restarts).

Possibly related to this issue: https://fuzearena.com/forum/topic/1598/actual-code-size-in-editor-is-affecting-available-memory-program-has-to-start-with-until-fuze-restart

Thanks for the report! I'm looking into the memory issues.

@Z-Mann First I thought its how the parser interprets plain numbers, but because it works for int() it must be the implementation of the operator =. - Well, I guess everyone got bored to sleep after "First I thought". 😶

i know the example might seem weird but i actually had this problem in my competetion entry i'm making it's there that i first noticed it. I'll probably have to split it up in multiple writetext calls to go around the issue currently. Good to know it's going to be addressed though

I think it means that you would be able to do something like this:

function increase(ref data) data.value += 1 return void example = [ .member = [ .value = 1 ] ] print(example.member.value, "\n") increase(example.member) print(example.member.value) // currently this value is not updated update() sleep(10)

nice thanks, thats good to know

Thanks for the report- I've put it on the to-do list.

Thanks for the report! A fix will be coming with the next patch.

Thanks for the report! A fix will be coming with the next patch.

hmm PlayAudio has the same the problem. If you set volume to 0 in playaudio and then call setvolume(0,1) later its not being played anymore either.

this does not work either
c36bbb46-7800-49f7-8d14-41767f2b7bec-image.png

It seems everywhere in fuze a volume of 0 is considered the same as do not play audio (anymore) or stop playing audio. To me this is not the same an audio file can perfectly play / start with a volume of 0 and later the volume can be increased or changed on that channel to make it audible.

The same workaround as before does work here also
bf2ee31a-65a0-45b5-a277-a6e2038a8e49-image.png

ah did not see that it existed already

@faz808 if you create a new map and don't scroll or click existing one's it will be fine. It's a workaround but it works. I think it happens if you remove images that are placed in maps or if a map gets copied it gets curupted sometimes.

@LinkCraft That's unfortunate. :(

At least I hadn't started making the collision zones for each tile I was going to work with.

Maybe I can downscale.

Thanks for looking into this.
Jason

@Chronos oh I see wish I could help

ok thats good to know :)

Thanks for reporting. I believe this is fixed on the upcoming patch