Sorry for another bump, but same problem here. I see no other way to upload it, so I’m waiting for a fix.
No need to be sorry. A problem to go unaddressed for this insanely long needs to be seriously taken care of given how often this feature is used. You’d almost think it’s getting ignored at this point, so the more attention the better.
Is there any update regarding this issue? I need to update an ‘old’ model of mine in order to properly update my game!
As far as I know… not in the slightest. Nearing 4 months of NOTHING.
I’m sorry, but is there any information regarding this bug? Many people are unable to upload the majority of their past models. Can we get some type of response from any staff members?
Do any Roblox Employees have an update on this issue?
As it’s getting critical for me…
Hello there. I’d hate to pester you, but it has been about 5 months since this bug has been reported and we’ve gotten nothing back. The bug is still present and affecting many users including myself. Has there been any updates regarding this problem? Is it still being looked into?
This issue is still in progress of being fixed, and our engineers have performed work on this as recently as last week. We’ll update the topic once a fix is live!
Yesterday, I was able to update an old model, but now I can’t update it anymore. There’s also another model that was created on the exact same day that I created the old model, but I am able to update it for some reason.
Despite all four models being made on the same day, I am unable to update any of them, except for the last one I made that day.
Why can’t we go back to the old asset configuration system? I don’t see what’s so wrong with that. It’s clear that a fix will probably never come for the problems that currently exist, so why can’t we go back to a system that had no problems to begin with?
There were no changes made to my model inventory yesterday other than me updating the model that I was able to update yesterday.
Hi there, as mentioned above our engineers are actively working on this issue. There is a fix going through the pipeline already at the moment.
I unfortunately cannot give an exact date for when the fix will ship due to the agile nature of our engineering processes, but it will definitely be shipped as soon as we are able to!
Hopefully this will be the final fix. I used to have a method for working around this bug, but a few updates later it stopped working.
Happy to learn that it’s being pushed through, I’ve been unable to update a module I rely on for quite a few things for a while now so
My entire community is stuck due to this isse. I posted about it months ago, please let the engineer team to have the option to revert to the older UI instead of having a developer stuck for over six months for a fix, this is critical at this point.
They can then be as agile as they like taking their time, and then publishing the new version again when it works.
I will follow up again on this issue – apologies for the inconvenience
Ah nice. We are now back to even more limited space. Why is that every time Roblox Studio has an update, a feature is either removed or broken? I’ve said it before and I’ll say it again, please don’t mess with something if it isn’t broken. How long has it been now? almost 6 months? I hate to say it but this is why Roblox Devs haven’t been on or have even quite Roblox entirely because they are sick of something always getting messed up behind their backs.
The fact that this is still an issue baffles me. The old UI worked fine, we didn’t need this new one, you simply fixed something that wasn’t broken. The only reason for this UI update was having everything written in Lua, like the toolbox (IIRC, I might be misremembering)
At this point I’ll just have to publish a new module (thus having another old-ish module unupdatable) and go through all of my code to update it to the new one, and then tell everyone else who uses it that I have contact with to use the new one instead of the old one.
It might be possible to find the endpoint that is used to update models and then use that directly to update the content on the back-end. That way you don’t need to keep pushing new models. Whatever is more convenient to you.
This new asset configuration is just a complete waste, no one wanted it, the old one was more than useable and was pretty good, the new one is worse, has a few bugs like the one you mentioned, and even freezes quite often(I have a beefy pc which nothing other than studio freezes on)
Four months from my last reply to this thread and this issue still isn’t fixed. I’m unable to update modules for groups I work for without re-uploading them and changing the required ID. This has gone on for way too long, but I wouldn’t even be surprised if it surpasses a year since this thread was created at this point. Currently, we are forced to upload them as new models, meaning more assets in our inventories, consequently making this problem worse!
How is it that you can justify this toolbox update when this is clearly a massive flaw? Not to mention the other issues with it, such as: "Search by User" option in Toolbox does not show assets for some users - #4 by un1ND3X.
This update should’ve been reverted the moment issues like these were discovered until a fix was implemented. Finding the endpoint and manually uploading the model through that is inconvenient and terrible UX. This shouldn’t just be downplayed because it only affects some users who have uploaded a larger amount of assets. I’d still much prefer that it’s reverted until a proper fix is put in place.
There has been a large number of requests for it to be reverted, but they have all been ignored without even a reason as to why. I understand that this update means all widgets are ported over to Lua (which is great). However, as with any update, it shouldn’t be pushed until it’s fit for use - and this clearly isn’t!
Please, give us one good reason why you won’t revert it. You have completely disregarded all requests for it to be without good reason.
The reason is likely going to be engineering-related. It may be too costly in terms of maintenance / testing to keep both the Lua and Qt versions of the functionality alive at the same time across many months. Just the fact of a feature being alive means it is eating up engineering time in some part of the process.
Other than that it’s very hard in engineering to predict how long something is going to take or how easy something is to fix. Judging from the responses above it seems like they have been investigating and trying to fix it from the week it was reported. Probably just unfortunate that the fix took way more tries / more effort than they thought.
Maybe they would have reverted it if they knew it was going to take this long, but that’s hindsight.