The editor currently does not support expanded cartridges and will provide an unexpected error in their advent. Instead, the editor should parse the header of the cartridge to enable a dynamic size acceptance.

You might think about adding two limit display functions to simply help out SMB3 editors.
There is already the option to display the jump zones to change the level, seeing the zones with a plane hatch, with minuscule oblique lines nearby to make a hatch, what I propose is to simply make horizontal lines throughout the level from 1 pixel with a green color, a line with a linear hatch ("_ _ _ _") to help visualize the exit points of the pipes set, a simple system to visualize the mandatory heights to be respected to position the pipes "can 't go "where Mario will come out from.

Another linear function could help is that limit with two simple lines, I would do it in blue but always with a linear hatch, to highlight the upper limit if starting from the level from the bottom, and low limit, if starting from the top , they are in height "11 Y" starting from the top (zero including therefore 12) and the same from the bottom up.

Another useful limit could be the one to respect if you don't want to cause a display error, a sudden video shift, when you want to put the "Double-ended Vertical Pipe" tube object in the layer.
Often when used if it is not set to respect certain start heights in the high pipe part, and only if they are not set in the level within the GUI options in the "Edit Level Header" options in the "Scroll Directin" part the options :
[1] "Loked 'By Start Coordinates'?";
[2] "Shouldn't Appear In Game, Do Not Use." It happens that if the high part of the tube does not reach height "7 Y" but for example "11 Y" you see the video move up to bring the video to hook that high pipe point ("pipe mouth") up to a number of "Vertical Y Blocks equal to 5" this causes a sudden and fast movement of the game video frame, it is a problem it does not happen only if one of those two options.
So this functionality could only be available if one of those two options in the GUI, by placing a simple yellow line help a in the level "7 Y",
Another black hatch could be useful only if one of those two options are active and you want to highlight the part where Mario falls over and dies, this line would be dashed in black.

Since in this case, if you want to take this development path, it would be right to put another distinct menu in Foundry but only so as not to make the list of items appear exaggeratedly long in the "View" menu.

An interesting name idea as a new menu alongside the current "View" menu could be "Guidelines"

Inner windows when detaching show docking dots for selection with pointer on left side of each small window, it's a wrong way to view this part, it should be on top this part.

There are scroll bars that do not show the attachment point to be able to move them, they need to be visible, and possibly larger because they are difficult to attach with the point, you must be very precise and given the point where it is not immediately detected you can hook it with the mouse pointer wastes time.

You need a simple way to view each editable level long before loading it, this would waste less time searching or simply if the purpose you want is to visualize how a level is internally, without having to enter the level to see it, therefore you need a preview both when there is no level list of the main window of choice, and when we are in one of the other tabs of this window, that is those dedicated to maps, with a part for both that acts as a detector, a kind of monitor window that in the first tab it works with the selection of the layers in the list with the selected items, in the other parts it should appear only if the mouse pointer passes over a working map layer, currently if you stay on a layer it shows the object code near the arrow and the enemies code, in the same way a window with the image of the level should appear (it would be good positioned in par low te), how those object and enemy codes appear, and then disappear when you go out of the level area, as happens with those codes.

When selecting an object from the object toolbar it disappears. This is not the intended functionality of this bar. Instead it should remain present.

Unfortunately it happens that the window on the right that contains the list of objects and enemies expands according to the name of the objects or enemies added, for example, if there is nothing and I put the enemy "white mushroom" (which is needed in the game to be able to make the mushroom house of toad appear and open a chest with safe the P-Wing), this object in Foundry has a long name, this unfortunately enormously widens the list horizontally and damages the visibility of the level, you need a stable size, small and adapted to the new skin, because it still takes up a lot of space. It seems good the size of the list in width that appears when opening level 1 of world 1 of the game.

Currently the Version is displayed independently in multiple places. This is inefficient and results in versioning anomalies. There are three known locations for the version inside the editor.

• The Poetry toml file
• The Conf Sphinx documentation file
• The about menu for the editor.

What I propose to fix this is standardizing this to use only a single instance of a version, most likely from the toml file.

Currently, the only way to edit the size of a given level is through the level header dialog. This is quite tedious and cumbersome. Instead, it would be much more beneficial to enable expanding the level similarly to the generators inside the game inside the level editor itself. This would allow for quick and easy adjustments at any time.

Since many people use other software to edit SMB3, there should be a good way to reload the ROM safely inside the editor. My proposal is to add an additional menu option inside File. This will allow people to save a few clicks when needing to refresh the ROM. It also can be used to resolve weird glitches if they arise.

idk what to put here

When selecting using the object list it raises an error stating that it cannot use a floating value to select objects inside the list. This should be resolved by using a QPoint of integers instead.

When trying to delete a Jump it creates an Attribute Error rather than deleting a Jump. To fix this, no attribute error should be raised and the jump should be deleted.

The problem is very simple, in practice it does not set the modified and open level in Foundry to be able to play it as always in level 1 of any set world, so opening we will find what has always been there, what it does in practice is turns out to be the same action is also done by the emulator outside Foundry with the open function, it just lets you play by opening the file.

Demonstration video:

You need a simple function of assigning X and Y coordinates inside the level for each object or enemy, the idea would be to add a feature that can be activated from the menu opened with the right button when you are above an object or an enemy, this should open a window asking for the coordinates and, once confirmed, move that object or enemies to the chosen location.

For some reason, I'm sometimes unable to open levels in the world map.

When each object is superimposed on another, it sticks and becomes a single indivisible object, this fact only happens when an object has the same size as the other both in length and height (with the same perimeter), I have not verified if it is incorporated even with different measures but this happens only with absolute certainty only if at the moment that two objects of equal size with the top selected object are joined by dragging in the layer, it is deselected.
The moment you exit that selection they cannot be split, the only thing you can do is just delete to add again.
This does not happen with sprite enemies.

I noticed that in the new version it is possible to detach every single internal Foundry window, this is a good thing, but there are things that should be corrected in this specific area, for example, the only window is currently not possible to detach and that of left.

Then I noticed that for example if a window is docked and extended in height (widened in height) it shrinks to its minimum extension when we try to dock a window above or below an already docked one on one side of the main window, this is wrong, I believe that the right thing should be that when the window is hooked the one already connected on one side should not retract resulting to be after the hooking of the smaller extension, it should remain the same and retract as much as it requires the new window, and when it is undocked it will return to its state of maximum extension if only one side of the main window is docked.

Another thing I noticed that the hook points for the windows pointer are strangely detached and are always on the left instead of at the top like normal windows, it is not very "familiar".

I noticed that the bars indicate the number of objects and enemies are detached and therefore not rendered in a single block, in a single window to be detached, this in my opinion is a bit wrong, that is, it's a bit stupid to put an object layer in North Korea and the other in South Africa just to understand, they should be together so if I look for quantities I will only have a place to look for them.

I noticed that only in this new version the color window expands the color squares one on top of the other for the whole window in columned groups, it seems a right way if this could allow a tiling of an equal window with another palette resulting to be as it was before with at most a single central space as a separé between two palettes, I say this because I had advised in another publication that it would be good to have another palette, the one dedicated to sprites, if it existed you could change the colors of the enemies making it quite comfortable do it a bit like the simple current color changer.

One other thing that I noticed in unhooking and re-hooking the interior windows is that you cannot expect one of them to be hooked in the lower side, this is not good because I could think, to widen the view of the level, to put some windows in low since there is still a lot of space at the bottom and on the side the space is preferable to have a lot of it to see the level well.

I would be of the opinion that they have two functions in the way of docking, either in the actual way where multiple windows can integrate as a single window on one side or otherwise snap together as blocks side by side, using a way in which the sides of individual windows are attracted by the other sides of the other windows as if they had a magnet, then fictioning so that by approaching the sides they hook together like lego bricks otherwise if they are pushed into other large windows on the sides they are incorporated but in the way I mentioned before .

Perhaps you could make sure that the part of the level is inside an internal window and that this can be detached afterwards to expand it on more screens if you have it, in practice it should be able to detach but still have its own real window in its perimeter, so that you also have the possibility to expand to everything with the arrow of the pointer if you are in the sides after the window is detached, if this window could be made it could have the effect if the window were a square with a side half the size of the game level, show half of the level in the upper part of the window and continuously below as if it were a text to continue in the line below an already full one and in cases of quantities where there are remains of non-workable areas there could be a highlighted area as empty.

UPDATE:

There is however that lower left part of the left window that shows the selected objects as a choice to add to the layer that could detach to conveniently place it where it pleases you most.

Here's what it looks like now with version 0.2.7 and what happens when you move windows:

1

2

3

4

Here's what it should look like:

5

6

Here's what more specifics should look like on the inside:

7

When changing the level pointer of a level an exception is raised, preventing the setting of the level pointer.

Add hooks to automatically check formatting prior to commiting to the repository. This will reduce the number of secondary+ commits.

It happens that if you have the level set in vertical mode and you put some enemies that appear at infinity, or the fine presence of another (I don't say the names because I don't remember them all) the level breaks under certain conditions, if you enters any pipe, if Mario gets hurt or with objects or enemies, I made a video illustrating what happens, the enemies are the four all close together that you will see in the video.
In one part I left Mario the big one as a test, when he is hit he manages to stay, he still manages to work the game, but what the video does not reveal, I reveal it by writing it.
In the part where it is touched you do not see why I have increased the speed of the emulator but if I had left it at the standard speed we would have seen a repetition on and off in the process of shrinking Mario after all fine until a situation like I happened described above.

The "lackytu" cloud (I think it's called that) does not create this problem if Mario gets hurt but he stays at that height we intended;
I think he should always get up while maintaining that height once the vertical level is set and he exists inside the level and approach Mario because he is Mario he would only approach when he reaches the top because mon, being able to climb more, at a certain point he should remain at the most high, otherwise disappear above, maybe if it is possible as Mario disappears in the sides in the horizontal way and reappears on the other side, so should the cloud but in the vertical way, so that after being far away it would no longer be activated and the effect would disappear .

Sorry if maybe I say impossible things but I make assumptions.

As far as the functioning of the fish is concerned, instead of working for more length in width and therefore horizontally, they could work like the hypothesis made for the "lackytu" cloud, they could follow Mario and the effect would be perfect if they kept the trajectory established in the exit. moment before where Mario was for the various areas in height, and the same goes for the other fish.

More I can not devise.

Video:

1/2

2/2

There is a compatibility problem with the enemy auto scroll, it depends which auto scroll you choose, it can make the auto scroll move in some, below the level size and this causes error and breaking of the game, to solve this situation I noticed that it is enough to change the basic position of Mario at the beginning of the level, knowing this only needs to put limitations when choosing the automatic scrolling.
A typical limitation could be to obscure the positions of Mario that are not compatible for some positions. Currently you can choose as Mario's starting heights otherwise he needs to automatically position himself in the ideal height.
Then there are scrolls dedicated to the vertical levels, so it is necessary that when they are chosen the level is automatically set in the vertical direction, otherwise you need two scrolling lists that are activated according to the chosen level, whether vertical or horizontal, allowing only to choose those movements suitable for that vertical or horizontal level.

If the dependence of the correct position of the automatic scrolling can be disconnected from the height of Mario's position at the beginning of the game, it could work with the custom height together with the personalized and particular automatic scrolling because in any case it would not depend on Mario's height at the beginning of the game however, it certainly needs two distinct lists of types of automatic scrolling, where those dedicated to vertical levels cannot be chosen if the level is set as horizontal and the same for the opposite solution, where scrolling for horizontal levels would be impossible to choose. for vertical levels.

It must be said, however, that the feature that allows you to reveal the path dirty the visibility too much, the visible part should not be colored darker, the non-visible part should be dark and the blue and red line with the dots should be able to be activated. and disable separately in options.

You need the function add Scift + arrow (down or up) which allows you to select one by one in a list list, such as the list in the right window, scrolling the objects in the list one after the other, keeping all those hooked in the selection from which we started, if for example I click on the first label of the list in the right window, and keep Scift taking the text of the "down arrow" one step at a time, I would see the first label hooked into the selection and then the second, then the third and all the others if I would continue to press the "down arrow" key the same should be done in the opposite direction starting from the bottom not necessarily from the last, as in the opposite version not necessarily from the first if down.
This function is typical in a Windows environment inside folders when the view is list or detailed, even in a writing software this function allows you to select a word letter by letter until you select an entire word or phrase or more, it just doesn't work in Foundry on that list and it should work like that.

When saving with excess objects and generators the LevelView creates an error which prevents saving. To fix this, this issue should be resolved or removed.

As you can understand from the title, there is a need to add an internal file update feature to Foundry when outside you are already sure that the file you are working on has changed, this should work so that it updates the file as it is out when it is changed but at the same time keeps the changes on a layer you are editing without needing to open it, then enter the layer selection window to start that change over.

If it is possible, this functionality could be in two places, one in the GUI with an icon that globally recognizes itself as "refresh" (two arrows follow each other attract to an invisible circle) and the other could be in the menu in
"Level > Update file Nes "
which could therefore be close to "Select Level" and "Reload Level", I would put it under "Reload Level".

Yep

PySide6 is an upgraded version of PySide2. To continue to receive continuous updates we should move to PySide6.

It would be useful to let you choose an object to apply to the treasure chest simply by providing a drop-down menu and a tip to select placed in the right window, if you want, this menu or it could contain one by one the names of the objects, a bad choice since someone could change some objects externally, or have only the figures in the menu as in the left window one by one, a little awkward choice, otherwise a drop-down menu shows more objects for the same row and going down it adds others , in order to have more choices between the lines but also on various heights, obviously all this if it is possible otherwise even the first option with labels is fine.
This idea helps less experienced people who want to use this object and want to make it work easily without going to look for the position interested by somebody and go and look for the position in the level, this new function would help him, it would be enough just to select the treasure chest to activate this area of ​​modification, to make it available for use, then using the menu the functionality will only have to see the position of the treasure chest object and establish which is the right position for the chosen object, with the choice tip positioned on the side "[✓]" you could simply choose whether to add a feature enemy for level exit or not always if the treasure chest is selected.

Different worlds in SMB3 cause different effects. The user should be able to select a specific world to enable experiencing these effects. This should be located inside the emulator tab inside the settings dialog.

The last screen corrupts the game and often results in a crash. It is known that there is not enough memory inside the game for this screen. To help prevent this, the editor should limit this from happening. This can be achieved by stopping the screens at the 14th instead opposed to the 15th.

The first new possible new feature connected to the zoom could be one that allows instead of enlarging or reducing the level with the usual and single lens controlled by the two zoom buttons "zoom -" and "zoom +", thus using already preset fixed zoom levels,
it could be a more refined additional functionality with, instead of having a new button in the GUI icons, having a switch, one that, upon activation, functions more refined in managing the zoom, a magnifying glass that associates with the mouse pointer as a lens instead of an arrow (possibly during the active switch) and which can decide the size of the level as follows:
If I click and hold the left mouse button down and scroll down the mouse he zooms in on the layer, if I do the opposite (up) he shrinks it.
This system is used in other technical graphics software so it is possible to build it in the software.

This idea would be of little use if there wasn't the second idea I'm about to write, because anyway This idea of ​​zoom was born to facilitate the view, and better set the level in the Foundry window, to fill the empty space there could be in the window immediately below the game level open when in landscape level mode.

The other idea is that the level, with a button that can change the display of the level, could also do so to split the level into several parts on a single video screen of the monitor, for example I have a 4/3 monitor quite large, this function, which could be activated with a new button in the GUI, could divide that part of a game level along many video screens (which forces you to use the horizontal scroll bar of the window) in order to position all that part not manageable and not immediately visible on the same video screen and along the empty space below the current level within the Foundry window, in pieces, with still "another layer strip" below,

so that with that zoom functionality I have suggested together with this one you can balance the zoom of the level well to make the whole level coincide better in a single screen frame, in a video screen in a suitable size, without the need to move the entire level to view it with the horizontal scroll bar.
Obviously I want to point out that I don't say it has to work so excluding the former display "with only one level strip at the top" for this I mean there should be two new distinct functions, to help get a better display of all the level simultaneously intended without many difficulty to see what's ahead at the same time.
Often, for example, in the errors of incompatible enemies, an error that exists in the versions of TheJoeSmo, one of the two enemies is often seen in error and not the other because it often happens that it is positioned in a long level much further ahead and is not understood "on the fly" who is precisely in error together with that other on the right or left placed more towards the end or the beginning of the level, but obviously this display would not only serve this purpose, but also to act on the whole level, in case it is necessary move one or more objects of the layer further away from the screen you are viewing by dragging, then realizing what is ahead and how you are moving it while dragging, making everything easier in the way of use but also in the way to view it if you have availability of a large enough screen or a good video resolution set adequate.
It often happened to me that I had to move all the objects and all the enemies, everything that was in the level or more to the right or more to the left, for this reason I had to leave the zoom to the minimum seeing the level miniaturized and difficult to control. , and I had to manage it like this because I needed to see what was happening in the whole level at the same time.

I don't know if it's intended as it should work but these layer strips placed one on top of the other should work more or less like a digital text, a "Word" (Office) text document, depending on how long the text is at the beginning of writing. , which for us would be the entire level, would take one or more staves, in Foundry it would be the same, via a button to change the view or it would be like "notepad" that always writes without going down (unless you press "enter ") or as" Word "which automatically moves to the next line.
For the vertical levels it is obviously not complicated to understand how it should work, instead of one on top of the other for the horizontal level, one side to the other for the vertical level, where the lower part and the beginning of the second level strip placed at right side.

So summing up
it would be necessary:

A switch to change the use of the pointer so the left click can work as a more precise lens

(if it is possible by changing the image of the pointer at that moment it is inside the working area of ​​the layer);

A simple button to vary the level display, from single that can be viewed via scroll bars or to pieces connected one above the other (or sideways),
functionality that makes the above (1) very useful.

To follow below there
I leave a video showing the result what the result of the magnifying glass would be if it were made, obviously the magnification differently from the video would make use of wider or narrower level strips to match the maximum space of the Foundry window with the maximum size of the level by plugging the vacuum as much as possible using the variable tractor of the magnifying glass and the static factor that is represented by the level that follows it.
I also leave two photos of how much space I have available on my screen to give an idea.

Images:

Video:

Given that to avoid errors it was chosen to decrease the space blocks of the level from 256 to 240, also the maximum settable jump areas must decrease, if with 256 the areas were 15 now obviously they are maximum 14 but currently they are 15 and this recognition of the fifteenth area therefore represents an error.

The version checker checks mchlnix's version of Foundry not our own. This should be redirected to our own repository now.

The user can select jumps methods that are known to cause crashes. Some of these include the ? options and the vertical positions for horizontal levels. This can be confusing and counterintuitive for the user. Instead, these should be hidden if they crash the game.

When I open the "Open ROM" dialog and then click cancel, this error shows up:

When selecting a level the title of the MainWindow is not updating.

When selecting an item and when creating an item from the middle mouse button an error is created. Specifically an error that states that the byte must be between 0 and 256. This should not occur during item creation.

Currently, if it is desired to reload the ROM in its entirety, the best method is to select the Open ROM menu and manually select your ROM again. This is rather tedious as it takes multiple clicks to reach a desired input. Instead, a button should be added inside the File menu to enable such action quickly.

I have repeatedly reported this error some time ago but it still has not been fixed, the problem is simple, opening the Foundry error list in these new versions of TheJoeSmo there is an autoselection system when the mouse pointer hovers over the objects in error inside the list, this selection we are talking about is both a selection of the linked objects inside the right list of the right window which contains all the objects and enemies, and a selection in the working area (all open level).

What I want to point out is that it needs, given this system of auto-selection in the error list, that when you are on an error and you click the left button of the mouse this has the effect as if we were going to click the button to open the list, this to allow you to close the list of errors and keep the selection of the fixed error, something that is currently impossible to do since during the act of closing the list by scrolling it is impossible not to change the selection (not keeping the desired one).

Moreover, to close the list I also just had to click 3 times ago so not even once as it should be.

The only way to keep the currently desired selection is to scroll the pointer to the right or left of the error line to exit the list area to click on the Foundry window which is not dedicated to anything, it is empty to click there , this method only manages to keep the selection and close the list, but it doesn't have to be.

I leave a video demonstrating the problem.

The rendering of underground and hilly tilesets are completely broken in the latest version. All four byte objects are incorrectly sized and levels appears corrupted.

The two problems are different, the first, the most important concerns the placement in the game when the level is installed and made playable in memory, essentially as you can see in the video below many of these are repeated with fixed cycles, I think every 16X of length, the other problem that can always be seen in a dedicated video is that put this in a left corner of the "Blue X-Blocks" object with 4 bytes it ceases to extend to a condition, as you can see I made three attempts , if for X-Blocks I select put in foreground or background level it remains as before, but if I do the same thing by putting something in front of X-Blocks and selecting put to background level it starts working.

A good idea is to be able to hook different objects or enemies in the selection both inside the workspace, meaning the open game level, and inside the objects and enemies list of the right window, the new functionality should work simply as this happens in the environment Windows inside the folders, if you want to select specific folders when the icons are of medium size (not in the list) the method is to press "CTRL" on the keyboard and click on the folders, in the same way it should happen to hook objects and / or enemies that you want to add to the selection, for example to delete them.
The same way should happen then also inside the window on the right shows the list with the labels representing the objects inside the level, to do the same way.

I made a video showing some problems of the right window.

The first problem is evident is that the items and enemies list appears excessively short compared to other previous versions, this cannot be descended compared to the old versions, it is blocked.
In the part below where that the part dedicated to the settings of the tubes, that part seems to have a new coupling for sliding downwards, this unlike the other coupling that already existed slides everything downwards, but as you can see the second new coupling , which works only with the pointer stationary in the lower part of the sheet (the one that contains the settings of the tubes), starts from a high and detached position between this point and the base part of the main Foundry window but the two buttons are not always located close to the bottom edge of the sheet but in the center of this void and when I narrow this space it always stays in the center during scrolling.
This should not happen because if you want to get a good way of setting the windows in the meantime we should divide the parts by forming subordinate windows and then give the possibility to move them individually to go and place them where it suits you being able to enlarge them while keeping, in case of that setting functionality of the tubes, that things work together remain together like the two buttons below and closed making a window block repositionable and modifiable in some measure length or width, it depends on what should be left free.

Another problem is a usual one that has never changed over time and that I have tried to change it but without success, this problem is represented by the fact that if for example I click to select the first object in the list of the right window that contains the names of the objects and enemies of the level, he selects, but if I try to scroll with the arrows on the keyboard the system does not work, I left a video demonstrating everything and a photo of the old window.

It is useless to explain what happens, to be able to see it in the video.

Video:

Old right window setting in TheJoeSmo versions:

Currently, there is no way to identify the starting powerup Mario will take inside the editor. This can lead to confusion when running this through the emulator. Instead, the Mario's powerup should dynamically change based on the settings that determine his powerups.

Unfortunately the right window containing the labels that can be selected with the mouse pointer and connected to the objects and enemies linked and existing of the open level, has a problem, once you have selected the first of a list you cannot scroll down one by one the selection of the list simply with the "down arrow", it hasn't worked for a long time.

A little while ago I tried to change some colors in the level but when I tried to put "level reload" action that I often do to delete the last actions done, the colors there in the window have remained, they have not updated returning to what they were before in memory.
It needs to be resolved.
However, I noticed that that part is large enough to accommodate a second palette, since this is the telative one, the one dedicated to enemies could be added to the background.

Opening with a click of the pointer in one of the colors opens a window for the color change, for the choice, it would be more useful to see a preview while scrolling the pointer over the colors so that it is not essential, if you are very undecided, to set for then return if you are not sure, it would be enough just to scroll over the pointer to see the color applied and when you have decided on the result you can already see there (during the window open for the change) click a color to confirm and close the small window , this would save you the hassle of opening and closing multiple times.

Another thing that could avoid the hassle of returning would be to enter a color and select others from them as if you already had the window out there, the only difference would be that from there you could think of adding labels to immediately understand what a color to avoid understanding it by making comparisons with what you see out of necessity, moreover if you decide to put the palette of the enemy sprites you could think of adding a card, then allocate two to switch to the other always for each color the title that makes it clear what it is dedicated to and under all the colors to choose from.

One thing I forgot to add even in the speech (I'm updating now) is that I have not at all advised to leave two buttons, one for the background palette and one for the sprite palette because I wanted to recommend another nice and simple function, the I change color with the mouse pointer and mouse wheel, I mean that even if there is no label and you already know where the color will act, you could make it so that when the mouse pointer points to one of the colors, without clicking to enter the internal window, it could scroll the colors in succession one after the other by making up and down with the wheel, and with each click of the wheel set the color, and if you right click in that color just canbiato returns to how it was originally.

It would not be bad to be able to see the color value inside the window, because at least if you look for value also as a form of reminder when using FCEUX it can be displayed, it can also serve because some monitors can deceive the eye but what is written you cannot be fooled.

Currently there is no way to edit the palette for a given level inside Foundry. This is a desired function by the user. There should be a bar on the side panel to allow this function.

The MainWindow keeps over-expanding without a good reason. Many toolbars keep going over the side of the editor. Both of these need to be fixed to make the editor run correctly.

Every time you go into the level select window, it jumps back to World 1 Level 1.

When clicking on exit inside File menu it raises an error inside Foundry and fails to exit the program.

There is a conflict when opening an M3I file and we click in the Floppy logo in the GUI to save the progress, obviously if we click there we mean we want to save the progress and we should be able to do it without the need to attach it in the NES file.
For this I would recommend, if you open an M3I file that the save function acts only on the same M3I file, if you choose to apply the modified level you should do it inside the menu with a dedicated command active, and disabled at the moment you act on layers in the NES file, adding a button in the GUI, if opening an M3I file, with this function available or leaving it always present as in the menu but disabled if not opening an M3I file.
Then, since each M3I file does not have in memory the maximum quantity of a level it was modifying, it needs a function that opens the level selection window to search for the maximum quantities in case they are needed to update the open M3I file with a retouch. .
The functionality should be called like "search level limits" and should be placed in the menu under "file"