Wishlist
-
I've noticed that it would be convenient if the screen didn't scroll to the right when entering code so quickly. once you get to a certain amount of characters typed, the screen jumps far to the right and it can mess with my bearings. does that make sense? maybe just move with each character typed, but still show a majority of the left side of the screen rather than the right.
-
@Jonboy lambda expressions I can stick in variables and array slots, functional-style features for dealing with collections of things (so, closures.) Some way to break my code into multiple "files" (even if that's not what's going on under the hood; the whole thing could be a SQLite database or whatever else.) Regular expressions would be a huge win. ToyCon integration (particularly the piano and the VR goggles.)
-
I imagine the "File Handling" stuff is mainly for a project's "save" data (so it doesn't actually get shared), but maybe that could be expanded so we can store project relevant data that'll be shared, not limited to just one file, and maybe make them read-only when sharing (as they could be important and changing data in them could break the project). When I worked on my MM2 PTC project in Petit Computer, I utilized the program's use of graphic pages (GRP) to hold such both graphic and non-graphic data (like levels, music, etc) because I had no room within the program's line limit (9999 lines of code) to fit them there. As I understand it right now, if I were to use arrays and whatnot to hold levels, music, etc, that would actually take away from the memory allocated for variables. PTC provided the DATA and READ commands to hold the data as code like an array, but one had to read that data into variables and arrays to use them, thereby they didn't take up precious memory.
If having this expanded file handling is out of the question, then what about allowing us to read pixels in image buffers, and being able to save images from within our projects? That would allow us to utilize them like files that held project data like how I did it in Petit Computer.
-
This post is deleted! -
This post is deleted! -
What we need to get to OOP is mostly struct + lambda, and we're missing the lambda. Doing e.g. class-based message dispatch wouldn't be too hard with lambdas, and with multiple code files / IMPORT or whatever, we could write it once and use it whenever.
-
I would like to chime in and agree, as well as add an idea to hopefully implement write and open and both seq. and r.a. file operations perhaps ?
-
@MikeDX
Hi Mike,I want to be careful to avoid coming off as too negative on this, but respectfully, being forced to use one file is just painful. Code re-use is important: having to highlight a mountain of code and copy it into every program that uses it is not a good solution. Arguably it's even a bad habit.
I agree that the default workflow should expect that most users will be kids using just one file. But sometimes you get an ambitious kid who wants to do a bigger project; should we make that harder than it needs to be?
If this is about "Nintendo doesn't want us creating and deleting tons of files in the underlying Switch filesystem," there's a simple solution: use one (actual) file, and present it as though it were multiple files to the user. Let us have some kind of REQUIRE or INCLUDE command so we don't have to scroll through thousands of lines of copy-pasted "library" code.
Example underlying representation (actual file on Switch) for clarity:
<project name="foo"> <file name="scanner"> //big pile of code here </file> <file name="parser"> //metric ton of code here </file> <file name="fuzeInFuze"> require("scanner", "parser") // a ton more code, followed by an educational... metacircularityLesson() </file> </project> -
@Jonboy I almost forgot: when I get a syntax error, it helpfully tells me what column it happened in. Perhaps on the far right end of the bar at the bottom of the edit view there should be a column indicator?
-
@Zero-Division I had my own version of upper() and lower() posted in the Hints and Tips thread if you wanted to look at my versions.
-
While we can see the overall free memory for our projects, that includes space for images, music, models, etc. With all the recent "stack overflow" errors cropping up, maybe we could have the option to preview the amount of memory available to just code and variables? Would help when seeing if there's potential memory leaks, imo.
-
It would be nice to be able to collapse function definitions, structures, loops and the like. Extra wish: The ability to define one's own collapsable range of lines (something like "//<<" and "//>>" as start- and end-tags).
-
If not already mentioned:
-
Ability to read other character values such as backspace, tab etc. What standard is used I don’t care, so long as a I can read other keystrokes from the keyboard buffer.
-
Easy one: Press UP/DOWN arrow or joycon button while at the top/bottom of bookmark list jumps to opposite end of the list. I’m getting a lot of bookmarks now and it’s slow to simply scroll to the end even the bookmark list (albeit faster than in the code window).
-
-
-
When you have the help menu open, while coding, the screen will scroll to the right when you enter code, so most of your code isn't visible anymore. This only happens when the help menu is open. Does this make sense? :)
-
Maybe support for vertical screen orientation.? :)
-
Please make the code colored in the tutorial section of https://fuzearena.com/help/ like it is on the Switch itself.
-
I don't know what it's called, but in other coding languages, when you for instance change the name of a variable, the name will change everywhere in the code where you have used that variable
-
-
Id like to request ability to reuse your own assets in many projects. Ability to seperate code into different page tabs. Code wise it would be treated as one program but more visually appealing.
-
We're aware of the desire for splitting up the code into multiple files and / or tabs. We need to give the editor some additional work once we've got some of the initial bugs out of the way.
For asset reuse you can already do this. It may not be exactly how you are thinking but you certainly can. Create a project for your shared assets only and then when you create a new project you can copy any that you wish to re-use into your new project. It's not the same as referencing the assets directly of course but it has the advantage of allowing you to make small changes in the inheriting project.
-
@Martin yeah i knew about that but really that is a waste of space. That would be like copying the content of a function and pasting it several times whenever you call the function in your program. You also have the advantage of making changes to an image and it would apply to all programs that use the image. Would be nice to have the option but i do see an issue of sharing as fuze would have to copy any images that were linked this way before that project can be shared.
-
Going back to the roots of Fuze, and teaching kids to code... I've been thinking about how I first started and it was all about typing in the code (starting from the Spectrum manual, and swiftly moving on to magazines)..... Sharing programs with friend codes, and even the possibility of some future curated server based content is all well and good.. but what about having a page of simple games listings to type in?
-
what about having a page of simple games listings to type in?
I definitely like this idea, but I do fear that the patience for typing in 1000 lines of code or more (10,893?) might be long gone. And then that will lead us straight back to "would be great if we could copy / paste from PC" - which has all sorts of problems and restrictions.
I'm sure we'll definitely give this one some thought however.
-
@Myddrak I like the idea, perhaps a section on the forum where we can share small but useful functions? I know the hardest thing i struggled with initially was jump mechanics and collision detection, would be great to see "Tiny Demos" where we can share how we tackle these challenges
