TheJoeSmo
commented
3 years ago I like your ideas, but I find it integral that we separate these ideas into their own respective issues. In your post you mention real time color selection, a search bar for objects, translations, emulator stuff, better identification of generators. Each of these topics are deserving of their own issue and I fear if we let this continue all of these suggestions will be rejected due to the merits of only a single point. For that reason, I believe we should close the issue on principle and allow you to write each point separately. In the same token, I will not judge any of the points stated in this issue, as I would be forced to judge them as one point, which would not do justice to the points here.
Dariosky-01
1) Changes regarding how Foundry works there in the new tool for color change.
I noticed that in Foundry regarding the new tool for changing the colors of the layer, you must necessarily choose the color before seeing it in the project as it is.
So I thought: Isn't it better to see it in real time as you switch between the colors inside the window?
Then I thought of another solution to another problem:
Given that it is not possible to immediately understand which object a color is linked to, unless you already know by heart which object on the level it is associated with:
Isn't it easier to change one color at a time with each mouse wheel movement when the pointer is over a color to then return to the original set once out of the square?
This would be useful to see and understand, without opening the window and changing color, which object a color refers to, it could also be useful for a quick color scroll without having the window in front of your eyes which could be annoying.
Obviously then to set a color because you are sure of what you want you could open the window and set the color, but even in this case something should change, in the window containing all the colors, you should not see how a color looks for. need only if you choose it, you should be able to move the mouse pointer between the colors of the window and see in real time the color applied in the project.
Why should I waste time changing one at a time to see how a color looks? As it is in the current version it wastes time.
If the mouse wheel were missing from the operator there could be another easy way to view the colors without registering them in the set but only to test them if the pointer was over a color box, the problem of the lack of the mouse wheel could be overcome with function keys, for example the numeric keyboard keys "+" and "-". Obviously it is not necessarily necessary to use "+" and "-", also "page up" and "page down" would be fine or the arrows "up" and "down" if these already do not have other functional attributes. ("page up" and "page down" are much more interesting, I would prefer them)
2) Added a bar for quickly searching for objects or enemies / items.
There could be, as written in the title, a search bar located where it is more convenient to see and use it, preferably at the bottom. The bar should, in real time, discard all objects, enemies and functional elements that do not begin with a letter that we could start typing to start the search, (a bit like searching on Windows windows) and making sure the Foundry left internal tool window, the one that shows all objects, enemies and other elements, remove all icons with the name attributed that do not begin with that letter written in the search bar, thus facilitating the visual search.
The search, however, could refer to the left tab chosen previously, thus eliminating many of the a priori results and then showing, during the search, much fewer icons than there would have been if they had been searched in a list without a category attribute. With this idea the operator would surely find what he needed during the design without wasting a lot of time.
Finding what you need takes less time to design, and time is effort if you work and money to spend if attributed to current flows and wastes.
3) Small tricks
The functional elements of the levels, for example like the ones that get you out of the levels after choosing the treasure chest or, the element that decides which object will be inside these chests, these types of things elements of functional logic, could be very well in another tab on that window on the left, maybe they represent enemies for the game system, but they will never be enemies with whom Mario will interact and therefore, for those who are planning the level then from this deduction I think he deserves a tab to part, also to increase the chances that you will immediately find the icons you are looking for with your eyes.
The search could in any case take place having everything in a group through in that tool near the colors, so that for the choice of the elements to add to the project there, through this means it is made so that this tool instead of changing itself in the name by pressing a letter or the "delete" key on the keyboard, may not vary in the internal string but the name of each object, enemy or functional element may remain blocked, on the other hand, by keeping the name blocked, and pressing a letter, search for a first object, coming from a list sorted alphabetically in memory, so that writing a letter deletes me an object closer to that letter.
It should therefore work so that, if I write two letters quickly there, inside I select the object with those two letters always originally according to an alphabetical ranking instead if I write two letters slowly I do two searches, looking only for the beginning of the letter.
In practice it should be as I have used until now this tool that has everything inside it can be applied to the project with the annoyance that if I write it does not behave as I wrote but writes, without an important reason, without a real usefulness causing only annoyance. I often happened to search there, and I could only do it after having deleted the whole name, because writing a letter still writes not research by typed letter.
Obviously if the software had translations it could be easier to do a search, people remember the words of their mother tongue better, in the case of a foreign person, for example I don't speak English because I'm neither American nor British and I don't have never studied english in school but i'm learning by myself, that's why you might see errors, it's google translator's fault.
Very often the files that I tried to run inside the emulator, through a command given with the button at the top of the Foundry window directed to the emulator, gave me an error, but not because it didn't work or was set wrong in the Foundry options but simply because it cannot understand the modified file if it is not structured like the original, then it would be much more useful to just give a command that opens the emulator and opens the file as it is currently, without bringing the project to the first available level , at the limit this very simple function (it would save time), it could be another function button at the top more, in practice it would be a button that would have the task of saving the file in ram memory by compiling the .nes file in RAM memory as if it were inside the hard disk and make it available for the emulator. Someone might think: "but this is what it does", but I would reply: "it's not like that, I've already tried how it really works, and what it does is transfer the project to the first level that Mario in his map path is obliged to to play".
I always messed up in the left window with the many identical icons but with different functions, like with the many images of bricks that cannot be recognized quickly with a half glance, so why not add a signal that makes them immediately distinguish as a number inside, or image, or still a dotted image?