OFFICIAL 5.0 SUGGESTION THREAD!

RadJunk

Administrator
Staff member
Well, the time is nigh. We are beginning work on 5.0.

We would love to implement everyone's suggestions, but of course there are complications when it comes to some strict challenges of translating tool - to - NES sometimes. Occasionally, even what seems like the most simple or obvious suggestions are tied to complex things like bank switching or limited memory space when assembling.

That said, hopefully you've all come to realize that we take your suggestions seriously. Since we've launched, we've continually attempted to include any and all that we could. We are now beginning to work on 5.0, and with that comes a laundry list of things we need to tweak to make the tool a bit easier to use, a bit more cohesive, and add a handful more features. But this is a great opportunity for you to get your voice heard with what you want or need, too.

Keep in mind, what we're talking about in this thread is the TOOL, not necessarily the engine. We're not looking at suggestions for modules or to fix engine code or anything like this. This is a thread about suggestions for the front end itself.

We'd like to hear your ideas, and hopefully we'll be able to implement some of them!
 
I would like the ability to choose how my texture space is used up. For example, if I only have 2 paths I want to use, it would be great if I could use that freed up tile space for main tiles.
 

digit2600

Member
My suggestions:
-auto format button in script editor
-a quick way to set variables in objects Properties i.e. defeating specific monster causes either a custom script to run, or just sets a flag for specific variable
 

Retrobuster

New member
I'd like to see some more incremental zooming in the pixel editor. On the smaller tilesets like special screen tiles, it's either zoomed all the way out or it zooms in really far. So having more of a "slider" function so you can control the level of zoom would be awesome!
 

RadJunk

Administrator
Staff member
@Convoy_Avenger - good suggestion, but that memory space is regimented for a reason. What would end up happening is if you started to change those things, the regimented memory space would break down. That would lead to constant compilation issues. That's one thing we did to make NES development easier to a WYSIWYG type tool. It's possible that you could load existing screen specific tiles in that space or something like this, but then it's very difficult from screen to screen to control that, and it will wreak havoc on things like animated tiles and other specifics of tiles. Not impossible, but...that's pretty baked in, and it all has to do with memory management. :)

@digit - interesting on auto format. The second part - not quite as easy. That's just not how the engine works. But you could write that in custom ASM. There are simply too many places to try to tie in script access and not enough ROM space. You could do this on the ASM level though. But I'll look into it. Same problem with a drop in sound effect scenario. There are literally infinite places you could want to place a sound effect...but you don't have that much code space, obviously, to allot for it. Not sure how to solve that problem.
 

SuperNatetendo

New member
A few things in no particular order -

- duplicate script function in-tool and/or being able to switch defined scripts from the defined script menu. this would be helpful for if you unexpectedly wanted to change a bit of a script, you could quick make a duplicate, edit it and use it. Then switch back to the original if you did not like it.
- ability to export text/text groups
- painting tile collision types instead of having to right click to modify
- I don't really want to use Shiru's Screen Tool when I want to make a special screen
- Screen Flags / Object flags / Object Status Flags could be numbered in-tool for easier reference when coding
- Objects could be hex-numbered in-tool for easier reference when coding (00-10 for game objects, 11-FF for monsters)
- HUD Variables maybe could also be shown in the tabs where the User Variables are so one can more easily keep track of all the variables they're using in-game
- Dunno if this is an engine thing, but in the HUD editor do the elements HAVE to follow the variables sequentially? I'd love to be able to choose what variable each element links to.
- On objects larger than 16x16, the placement is off in-tool vs in-game
- A lot of the stuff in the System folder seems to be not in the defined scripts? Edge Reactions and some Handles one needs to manually open. Maybe put this in a separate part labeled "System Scripts" or "Core Scripts"??

Just a few ideas. Loved working with the tool thus far. Learning alot about NESdev in the process!!
 

n8bit

Member
-Undo option on screen editor.
-Mass select, paint, or hot-keys for all collision types when editing in screen editor.
 
Well i was sending a copy of my game to some of my relatives without a nes but a pc. And so i made a simple batch file using your game. But it still uses the name mystic origins. Could it be possible to have a option in nesmaker to modify the title and to make a easier way to make a distribution package and folder. One without the need for a batch file and combine the default emulator with the nes rom file together?
 

Bucket Mouse

Active member
Dear Santa Joe, for Christmas I want these things. I have been good all year.

A way to stitch all the text groups into one long text string
Lower-case text
Memory mapping, to make space for that lower-case text
In lieu of memory mapping, a way to assign any lower-case graphics I create to keyboard keys. I've been informed by the board there is actually a way to do this if I want to edit the data by hand, but it would be so much easier if it were built in. Did I mention I've been good all year?

In terms of bugs that need fixing:

If I make a monster group that uses any tileset other than 0 and go back to it later, the tile setting will have reverted to 0 and all the monsters will be gone. I have to either re-set them all up or never open that monster group again.

Worse yet: If I can't remember exactly what monsters were placed where, and I open an overworld screen with those monsters even slightly off, NESMaker crashes.
 

Mugi

Member
1) allow defining the number of bytes used by user variables (just like overflow ram and zeropage works) ((also add a counter to show available space for uservars, currently it silently overwrites other code if too many vars is set))
2) allow creating assets outside of bckchr/ssbckchr for people who do not wish to use paths (a toggle button for show/dont show paths in asset painter would be enough if all else fails, the assets already work, they just cant be created/displayed.)
3) restore the missing colors from the palette (i know why this was done but it is not your place to tell people they cannot use something the system actually does support. let them have the headache)
4) allow object placement on a 8x8 grid into the screens
5) allow all 4 palettes to be used for all object types (again, not someting that should be yours to decide that people cannot do.)
6) allow setting hud area in hud & boxes to 0x0 (it cannot be set off for sprite hud users which causes issues with current scroll.)

those are from the top of my mind some of the limitations of the tool itself that unnecesarily restrict the way it is used way too much for advanced use.

if you ever want to rubber duck this stuff with an outsider, you know where to find me, i'd love to have an in-depth discussion about things in the tool.

edit: one more, this is something which i specifically would love to have but it's not exactly important per-se.....
allow seamless display of the screens in the overworld view when "show large map" is checked, to allow screenshotting the world without having the white 1px grid on the screens to create pixel perfect maps of one's game world.
(alternatively, add a button for "export map as an image" button to automatically do so.)
 

jorotroid

Member
Mugi said:
(alternatively, add a button for "export map as an image" button to automatically do so.)
There is an Export Map Image in the Map menu, but this reminded me that it has a bug with this feature where it skips the top row of the screen. I'm guessing this has to do with assuming people are using a background HUD.
 

dale_coop

Moderator
Staff member
A lot of things has already been asked...
- Objects ID somewhere would be great (we all can count, but we are lazy. If the tool can show us their ID, a tooltip maybe? it would be appreciated).
- 8x8grid for object placements on screens (still annoying me, so I second that).
- In the Screen Editor, if all the display options could remain, when changing to another screen, map,... (like show grid, show collisions, ...)
- In the Screen Editor, I love the key shortcuts but would be great to have something more visual for that...? Something inspired by shiru's tools:
2019-03-26-10-58-17.png

(or a similar idea including the subpal selected)
- Still in the Screen Editor, maybe add the paths in the Asset list? we can just select the path1 icon and paint with that... easier for beginners (instead of using 1,2,3,4 keys).
- A screen should load the 1st path, by default, if at least 1 created. Or, like someone suggested (jorotroid maybe?), use pre-defined settings.
- In the Object Animations manager dialog, remove the "rename" button and just keep the name I type in the text box! (I really hate that "rename" button).
- In the "Project Settings > Scripts Settings", we don't need the full path of the scripts assigned. Just relative paths (from ROOT) would be better (Same for the "Input Editor"... so a general rule here).
- If all the Object Editor windows would look the same (a button to save, a button create new, same size buttons,...)...
2019-03-26-11-19-54.png

- In the Object Editor window, if I have my 2x2 object currently using the subPal#1 and want to change it for the subPal#2... I didn't find an easy way to do that. Currenlty I have to select each tile of each frame of each animation to set the subPal#2 ...for each >_< Maybe a button with actions with the selected suPal (set for the entire frame, set for the entire animation, set for all animations... )

...etc
 

BinaryLab

New member
Some things I felt the need for, from the top of head:

1) The animation preview is too small. In a high res monitor, I can't barely see it.

2) Some screen properties could either be set in the screen painter, or (and?) a way to set some defaults, like "use gravity" or the songs.
 

Mugi

Member
jorotroid said:
Mugi said:
(alternatively, add a button for "export map as an image" button to automatically do so.)
There is an Export Map Image in the Map menu, but this reminded me that it has a bug with this feature where it skips the top row of the screen. I'm guessing this has to do with assuming people are using a background HUD.

haha i never noticed that before. but yeah, it appears to skip the first metatile row of the screens.
so i second the notion of fixing this, or allowing this to be adjusted depending on what kind of hud people use (maybe bind it to the size of the play area ?)
 

RadJunk

Administrator
Staff member
Wow! Great suggestions here! The GOOD news is, about 75% of them are already on the list. Another handful will likely not be possible, but are great ideas. And still another few, I think should be possible, but will have to check with Josh about logistics. We have a LOT to do beyond all these changes too, but the input really, really helps. You guys rock. :)
 

WillElm

New member
Expanded/more complex input settings via the gui! So for example, "hold up, then press b" would initiate some script without having to code the button combo.
 

Kasumi

New member
Programmatically verify whether or not a sprite zero hit will actually happen to the extent that it's possible. The HUD is created in the tool. The HUD tiles are known, because they are loaded into the tool. The HUD layout is known because it is created in the tool. The position of sprite zero is known because it is placed in the tool.

So there's no reason the tool can't give an error if the chosen position for sprite zero does not overlap any non opaque pixel in the background. Yes, I understand it's technically possible for sprite zero to be set to a sprite tile that varies, but not being able to catch all cases is not a reason to catch none of them.

The default speed/acceleration for an object should not be zero. (User compiles game, object doesn't move. Program looks broken.)

The default module when starting a new project should not be none. (Similar to the above)

You might say, "Oh, but they should follow the tutorials." But really, any step you can remove for the user not only makes the program easier to use, but reduces support requests. These are off the top of my head from issues I've seen that people have, if I think of more I'll post. Any time you're making a video tutorial, and there is a step that must be done for the software to work, think about if you can make the software do it for the user. I think NES Maker has a lot of "bad defaults". A bad default is a default behavior that is not what most users would want. The sprite zero position is not defaulted such that it will hit for the default HUD. Edit: In the video for game objects, "Before I forget, I'm going to give him a speed..." is said. That's the kind of thing I mean. Don't allow forgetting to be an option.

I guess the way to think about it: You still need to explain sprite zero. You still need to explain object speeds. But only for users who want to change them. Currently almost everything has to be explained to everyone because so many of the defaults are not things the user would want. This information density even hits users who do closely follow the tutorials, because it's so much info all at once they're likely to miss some required things to do (that really could be defaults).
 

codingkid01

Member
(1 dither tool in sprite editor and abillity to have a primary and secondary color selected at once primary left mouse secondary right.
2) ability to move sprites and selections with arrow keys or mouse in sprite editor
3) Dpcm sampling without asm knowledge
4) easier level select screen creation
 

Raftronaut

Member
It would be amazing to be able to move to different screens when in screen settings. Working with the shooter module,
I will often forget set up the screen settings before constructing a row of screens. Having to go back and enter
each screen one-by-one and enter the screen settings is very tedious. It would be amazing when in screen settings
to be able to move to the next screen, or better yet, to be able to copy and paste the screen settings without
affecting the screen tiles.
 

RadJunk

Administrator
Staff member
@ Kasumi - good ideas, as expected :) I think I intentionally forced people into sprite 0 learning because of that exact reason...so when they resized the HUD, and it broke THEN, or didn't have any graphics loaded, they'd have to learn why. But I do see the point. And maybe the solution for starting module is that "none" is still some sort of functional base.

@CodingKid - 1 = interesting, but right click does a lot of other things so I'd have to look into that. 2 - planned, or at least already in the docs! 3 = not likely to happen, but when making the sound engine we'll look into it maybe. 4 = not sure what you mean. :)
 
Top Bottom