As you say, it’s pretty much the smallest bug in the beta, yet it ruins workflow the most.
I think if you look at end of video the second folder part is named “Part” instead of “Part2”. It looks like instances that are automatically renamed do not save the automatic name when copy and paste.
Why is it named “Part” when copy and paste but said “Part2” earlier?
Edit: I think it’s just that the name incremental rule starts at no number. Not that the name of instance is not saving, I was wrong about that maybe. But still doesn’t look good when copy pasting.
Even if this was “intended behavior” by having 1 instance with no number. The names were clearly different.
running v0.25 of the explorer, and ive noticed that the ‘Paste Into’ keybind does not seem to work at all; I have to manually right-click and click on the Paste Into button.
Also, if I have a service with a lot descendants in it, such as our game’s ServerStorage that has 471386 descendants, the explorer freezes up for a solid half-a-second before becoming responsive again. My device specs are AMD Ryzen 9 9550X 16 cores, and NVIDIA GeForce RTX 4070 Ti SUPER, so I’d imagine this isnt a device bottleneck.
Can confirm having this exact same issue.
This was the biggest issue with the new explorer: shortcuts didn’t work in the script editor, so you had to right click to perform actions manually.
Fixing this was absolutely essential - none of the other improvements would have mattered as much without it.
I just wanted to post this issue here so it doesn’t get lost as it’s a pretty big disruptor to my workflow, there is a pretty big discrepancy between old and new explorer behaviour when double clicking to expand/collapse instances, I can’t enable the new explorer for this reason.
Thanks for the feedback!
Will share this with the team.
I’ve been running into a headache all day and gaslit myself into thinking I simply had bad aim for parenting objects to models. Upon closer inspection, dragging an object just below a Model will count as a miss. This makes the target hit area for parenting an object even smaller than before.
The previous explorer did not have gaps between models for you to drag into. Pleeeeease restore original functionality here, I have yet to adjust.
(Otherwise loving a lot of these changes. It’s great that expanded models remember their state when moving their Parent around!)
I’ve noticed an issue where if you’re dragging an object, you can no longer scroll up/down with the mouse scroll wheel, forcing you to rely on moving the object all the way up/down of the UI.
Additionally, I feel the responsiveness & speed of the scroll when dragging the object downwards or upwards is too slow, having to wait on the ‘speed-up’ for too long for any meaningfully quick actions.
unsure if this is related, but opening the children of an object is similarly acting funky:
it seems like a non-issue at first, but I’ve ran into the case of opening the object below rather the one im hovering over more times than I’d have originally thought. The disconnect between the hover highlight, and the actual object that you end up interacting with, adds onto the issue.
This is a awesome feature but i feel like sometimes changing the names of items after copying them like that if the items are already numbered could break some scripts in the game if the developer doesn’t notice it. It should probably just continue from the current count if there are items with the same name
Unsure how to explain it without it all being confusing i think i rewrote this a few times and its still confusing
Just custom icons i got from an older version of studio with qtextract
I’d share it but there’s a lot of useless things in there i cant be bothered to go thru so the folder is massive
This reply worried me a bit, because in the current state, Qt’s context menus are quite powerful, and I think if Roblox re-implements them in Lua, they might miss a couple things. I was actually really worried that they would change the behavior at some time.
I am currently in the process of developing a big plugin, and it uses a lot of context menus. I take full advantage of the display and accessibility features that Qt’s menus have.
I think if Roblox were to redo context menus, I wish they would consider all the following factors of the current Qt context menu implementation, which are not widely known:
- If there is an
&
symbol before a letter, it will dedicate that letter to be a mnemonic, meaning you can press that key to trigger that option. This isn’t documented but is very useful, and as such I do use this extensively for micro speedups. - If there is a tab (
\t
) character in a context menu option, it will align the text afterwards to the right, which is useful if you want to display the key to press for that option (since it isn’t underlined for some odd reason). - Minor detail, but the context menu options are one of the last few things we have that are read aloud by screen readers and are fully keyboard navigable.