Closed ZookaOnGit closed 2 months ago
How about another approach, mpkg upgrade
+ a better way right inside Mudlet to tell users their custom changes in a packages would be lost? And offer an easy solution such as copying the item out of a package so they keep changes?
how would one compare if there is anything that requires backing up?
Mudlet already knows what is part of a package, so if you start editing a trigger in the generic_mapper, it could notify you that the changes will be lost during a package upgrade, for example. The notification would mention that copying the trigger out of the package could be one way to keep your work.
However, once the trigger is saved and Mudlet is restarted, we lose track of what originally came with the package versus what was modified, so no warning would be issued at that point. I believe this is acceptable since it wouldn't be as relevant then.
What are your thoughts on this?
This has been an ongoing issue, so I figured now is the right time to address it.
Ah, outside of mpkg, I'm with you now.
Yes, this is a good idea. How about making the yellow box 'wall of text` in the script editor context specific?
Yep, that's the one!
I'll see about putting something together, and making it less of a wall so the message gets through better.
Give https://github.com/Mudlet/Mudlet/pull/7411 a try, how does it feel?
I've been debating whether to provide this command to give the ability to upgrade to a new version of an installed package.
Atm I have instructed the user to run
mpkg remove
first, thenmpkg install <pkg>
This is a way to let them know that the old package will be removed and thus remind them that any changes they have made to the package will be lost.
Thoughts?