Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some suggestions/feedback and either a bug or a communications issue in the ui #69

Closed
Alice-Cheshire opened this issue Jan 2, 2023 · 4 comments

Comments

@Alice-Cheshire
Copy link

Alice-Cheshire commented Jan 2, 2023

I didn't want to spam a bunch of new issues for all of these and many of them are inter-related so I figured I'd combine them unless it turns out to be necessary to spin any of them out into their own issues.

I'll start with the possible bug. When you're in the sprite editor (at least for Aria which is what I'm editing) there's a field labeled Frame Delay. If you play the animation then this value changes as the current frame changes. However if you're not playing the animation and change the frame you're currently viewing in the dropdown then that value doesn't change. After some testing, it seems that if you drag the slider next to the play button then it does change but the ui doesn't communicate that that's how you need to do this. In addition, on Windows 10 sliders are literally three pixels tall which makes it much more difficult to actually use them. This latter issue is less the fault of the program than Microsoft for making such a stupid design decision but it's still a problem. If at all possible on your end, it might be a good idea to change that up.

As for suggestions, the current documentation is far from comprehensive. That's probably the biggest issue. It'd be quite helpful if there were tutorials for doing specific things. For example I created a room and was rather confused about dealing with the multiple layers. Tiled just labels them layer n starting from 0 but in addition, when you create a new room it automatically creates three layers for it which can be confusing if you don't notice this at first. It took me awhile to figure out that I needed to resize each individual layer as well as needing to change the tileset, collision tileset, and tileset type values in the edit layers editor. I was able to eventually figure out these issues but having a small tutorial in the documentation that walks the user through these steps as well as what each entry in the relevant editors actually means would be extremely helpful.

Another change that would be rather helpful is to have the ui in the different editors update with the values that show up in the textbox at the bottom, for example the items editor. At the bottom you have a textbox that describes a bunch of relevant information. It's not always obvious what fields in the ui line up with the entries here. If feasible it'd probably be best to append the byte information associated with a given field to the field's label. (Ie: For weapons the Item ID label would have something like [00] appended to the end.)

One more change that would be quite helpful would be to change how the add entity dialogue works. The way it currently works, if you want to add a pickup you need to go get the local id from the item editor for that item. It'd be a lot more convenient if the Var B field when editing a pickup entity would just give a dropdown with the valid values and their names. The current way is kinda clunky and also not as clear as it could be since the local id isn't immediately obvious. In the item editor there's a listed id (0020 for a knife, for example) but this value isn't the value needed for the entity editor, that instead being the hex code to the left of the item's name in the list on the left.

The final suggestion would be if possible, extending the room zoom to other graphical editors such as the map editor for similar reasons as adding the room zoom.

I'm sure most of these would probably be quite a bit of work but the editor would really benefit from these changes in my opinion. The more clear things are in the editor and the easier it is to use, the more people will make romhacks for these games and there's really not enough of them currently, let alone ones that are all that great.

Edit: I just remembered another potential bug or communications issue. The test function bound to F7 states it will spawn you in the current room at your cursor's position but this doesn't seem to be the case. In all my tests it spawned me at exactly the same spot near the center of the room no matter where my cursor was.

Edit2: I also just realized I'd forgotten one suggestion. It'd be helpful to not display menu entries that aren't relevant to the current game. For example for Aria, there's a number of menus such as the player editor which can't be used. Rather than simply telling the player that it doesn't work for aria, it'd be better to not display the entry in the first place.

@LagoLunatic
Copy link
Owner

I'm not actually working on this editor much anymore now. I just fix major bugs that are easy to fix and update the docs with things other people find and send me. Only reason I added that zoom feature is because I already had that coded for a different project and it only took a few minutes to convert for DSVEdit.

A lot of what you've said makes sense and is likely how I'd have done things if I made the program nowadays, but DSVEdit's code is a big legacy mess and I don't feel like reworking the UI design decisions I made when I was first learning.

In addition, on Windows 10 sliders are literally three pixels tall which makes it much more difficult to actually use them. This latter issue is less the fault of the program than Microsoft for making such a stupid design decision but it's still a problem. If at all possible on your end, it might be a good idea to change that up.

I'm also on win10 and the slider is 21 pixels tall.

Edit: I just remembered another potential bug or communications issue. The test function bound to F7 states it will spawn you in the current room at your cursor's position but this doesn't seem to be the case. In all my tests it spawned me at exactly the same spot near the center of the room no matter where my cursor was.

It positions me correctly, even if I'm zoomed in. I have no idea why it wouldn't work. Make sure your cursor isn't outside the bounds of the room since you're not allowed to spawn there.

@Alice-Cheshire
Copy link
Author

Ah, I see. That's too bad then.

I'm also on win10 and the slider is 21 pixels tall.

Really? Sliders have been only three pixels tall for me since I first upgraded to Windows 10 years ago. That would explain why I've never seen anyone else complain about this issue, I guess. I wonder why they're so small for me though? How strange.

It positions me correctly, even if I'm zoomed in. I have no idea why it wouldn't work. Make sure your cursor isn't outside the bounds of the room since you're not allowed to spawn there.

I definitely wasn't outside the bounds of the room when I tested. That was one thing I specifically made sure to check. I'm not really sure what exactly is going on but it's always in exactly the same spot. At the very least it's not that huge of an issue since I can work around it easily enough.

@Alice-Cheshire Alice-Cheshire closed this as not planned Won't fix, can't repro, duplicate, stale Jan 2, 2023
@LagoLunatic
Copy link
Owner

This is what the slider looks like for me:
image
Maybe you have some custom windows theme installed.

@Alice-Cheshire
Copy link
Author


Strange, this is what it looks like for me. I've never installed any Windows themes so I'm not really sure why this might happen. What you have looks much closer to how they were for me back on Windows 7, albeit those ones were light gray with a darker border rather than blue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants