Maybe you only need one value to save, the number of unlocked cars or you can do this

https://fuzearena.com/help/view/struct

I personally use gwidth() and gheight() a lot and they are very useful, but setdrawtarget() opens up a lot of fun possibilities.

@waldron Just a heads-up, I tried the map entity initialization outside of my game loop, and it still caused Fuze to crash-- figured I'd let you know.

I have something but it's brute force. I use a working copy of the items to shuffle. I use random to grab an index into the items then copy that to the first available position of the result array. The items in the working array are then shifted down to replace the used value and the number of indices given to random is reduce by 1. Once that value gets down to 1 you just copy it and you're done. I did a test one 10 number and it looked like the worst-case scenario would be a total of 30 shifts. Logically, the lower the random result (index) the more shifts have to occur in that iteration of the main loop. It's enough code that I couldn't bring myself to copy it here tonight. All the logic fits nicely into a function so it keeps all these extra variables out of the scope of the main processing, which I have done. I, too, knew that I might need this and had done it this way in another language, so decided to recreate it in Fuze tonight.

EDIT: Wouldn't it be nice to send a code file to yourself in an email from the Switch so you could just drop a snippet in here! : )

items = [123456789] function shuffle(ref options ) itemCnt = len( options ) array workItems[itemCnt] array shuffle[itemCnt] // Make the working copy... for i = 0 to len( options ) loop workItems[i] = options[i] repeat shufleLimit = itemCnt for i = 0 to itemCnt loop // If last item, just move it... if shuffleLimit == 1 then shuffle[i] = workItems[0] else // Use random index to get working item // into shuffled result array... pickIdx = random( shuffleLimit ) shuffle[i] = workItems[pickIdx] // Shift values down in workingItems // the item was not the last... if pickIdx != shuffleLimit-1 then for j = pickIdx to shuffleLimit-1 loop workItems[j] = workItems[j+1] repeat endif shuffleLimit-=1 endif repeat return shuffle result = shuffle( items ) loop clear() print( "Original: ", items, "\n" ) print( "Shuffled: ", result ) update() repeat

Also you have your ’left’ image half the screen width, but the right one the full screen width.

thanks so much this will be useful!

I recorded something with sound once and didn’t notice anything unusual. Volume about 0.7, using a sampled soundtrack not the synth though..

That's correct, this is being worked on for the next patch. The code below:

function toto(ref a) a = a + 1 return void toto(a)

...Does not affect the value of a in version 2.15.0 but will work correctly in the next patch. In the meantime, consider returning a value from the function or using a structure or list (ref works correctly for these).

For the second answer, whene we coding, we can write the different function on different file. Is more easy to read and understande. We can make this on fuze ?

Finaly, can we write my document on my PC and put the file on my switch for execute the program ?

FUZE does not currently support multiple code files in one project. We're exploring options that can help organize code better, but for now the best option for organizing code is using code bookmarks (R3).

Unfortunately there is not currently a way to transfer code or other text from the PC to the Switch. If you have a USB keyboard, you can plug it into the Switch or the dock to write code easier on the Switch.

Good to know. Maybe remove that parameter from the Help pages for now? Or change the wording...

It definitely would not be good for me to remove the ability to share the save file. I feel like there’s workarounds for most of this stuff at the moment, and imagine that the savefile functionality may be tweaked or added to in the future. For now though, I’d encourage new users to check out pianofire’s ‘persistent data’ functions (search in the forum for it), and/or gothon’s file system stuff, and/or spikey’s persistent high score table.

The way to get my collision map working undocked and docked and making use of 1920x1080 on TV was by applying setMode(1920,1080). In my past projects, this decreased the performance when undocked, so I did not use setMode() but scaled the coordinates. And for my current project the performance does not seem to be an issue. But is there another way to achieve this? I mean @Willpowered already answered this clearly, just want to make sure, I understand the application of the info.

@toxibunny
Will do! Tbh might drop the full code as the puzzle is getting stranger and stranger and with lowering the res to avoid stack overflows I can’t read error messages anymore!

@SteveZX81 ?

@spt-games Okay so yeah i can let it empty thanks

@thedos

guess my head wasn't quite out of c++ syntax

That's why I thought it would be interesting to have this discussion. Since there will be a variety of backgrounds and thus expectations to how things behave. But I also think it will help to improve acceptance to the new language feature.

The natural response when you are confronted with something that looks familiar by association, but does not behave as expected, is disgust. It's a defensive response for situations where something is off, but you're not sure what. Of course "disgust" is a strong word, and we don't normally value by one indicator. I just think it helps to have an open mind towards the update :)

++ operator discussion
I think this is an interesting discussion, especially since FUZE does not have this operator. I do feel that this discussion is off topic, but it seems most natural to respond in here anyway.

My argument regarding this operator was indeed within the context of FUZE, that is loosely typed. I absolutely agree that the ++ operator works perfectly well in C++. But FUZE is an entirely different animal.

A problem I see with throwing an error for incorrect types, is that the debugging capabilities in FUZE are not the best in the industry yet. One could also wonder similar questions about floats and even vectors I guess.

Also because FUZE is loosely typed, a mismatch in type could occur in very specific scenarios that might not occur during play testing. Since FUZE in general is used for entertainment, not business applications, it would be more fun if the game would continue with an unforeseen bug, rather than crash with an error. However, during development, you'd want to know that something is wrong.

In JavaScript var value2 = value1++ would be equivalent to:

value1 = Number(value1) var value2 = value1 value1 = value1 + 1

So here the ++ operator would first cast value1 to a Number, before assigning it to value2. Then after assigning to value2, value1 is modified again for the increment. As I said, this feels dirty, but as an expectation by a developer, not invalid.

I guess the scenario value2 = ++value1 is more simple in any case. Because, after the fact, both value1 and value2 should be equal, both by type and by value.

For these reasons, I am, mildly, opposed to introducing the ++/-- operators at all. But if the operators would be introduced to FUZE, I'd probably use them. But I don't need them.

But at this point, I do feel like I'm rambling on and am off topic.

EDIT: I've edited this post a couple of times, but mostly to improve how the message comes across. The message itself generally stayed the same.

I would also like to add, that although I say I am opposed to introducing ++, I would be happy to use it at the same time :-)

@waldron the good thing is that fuze gives you freedom in your style

@PB____ Ok thanks for the answer and yes it goes in to an endless trigerring if you return the function

Great, that's nice to know, I wasn't aware of that :)