- Joined
- Aug 19, 2020
- RedCents
- 23,325¢
@nightsta69 thanks for the focus!
-
You've discovered RedGuides 📕 an EverQuest multi-boxing community 🛡️🧙🗡️. We want you to play several EQ characters at once, come join us and say hello! 👋 -
IS THIS SITE UGLY? Change the look. To dismiss this notice, click the X --->
Resource icon
- Thread starter Ionis
- Start date
- Joined
- Dec 1, 2006
- RedCents
- 278¢
I have been trying to use the RGManager beta for regular play. I did a timing check with the new RGManager versus the Older RedGuides Launcher, and I was able to install the test client (accidentally since I had it selected) and the Live server updates, including plugin updates and Lua and macro updates, while the RGManager was still running the Update All for the watched Resources. I am not sure what the difference in the code is, but it seems about a factor of 3 times slower on getting things updated.
I dont want to disparage everything you have done, and I do recognize it is still in Beta, and you probably have not done many optimizations yet. I just wanted to mention that so you can look at it eventually.
I dont want to disparage everything you have done, and I do recognize it is still in Beta, and you probably have not done many optimizations yet. I just wanted to mention that so you can look at it eventually.
Whenever you get the chance, if you could navigate to RGManager -> lib -> bin -> Resources -> Test and send me the ResourcesLog.json I can take a look at what may be slowing things down!
To note on the difference in code between the programs, there were a handful of things the old launcher couldn't handle/had issues with that were tackled when blueprinting out the new schema for downloading in RGManager. A big point of contention was elevation, we wanted to avoid having to force RGManager to run elevated to dodge issues with permissions and allow users to have tighter control over what parts of resources they wanted to manage. The solution was to create a shell application within the RGManager solution that handles downloads. This application talks to RGManager through a named pipe server allowing us to elevate, cancel, continue et. al. downloads via user-response driven prompts without having to change the UAC level(s) of RGManager in any capacity.
There are downsides to this though, every step taken can slow things down, establishing the named pipe server, launching the ResourceHandler, passing the appropriate authinfo, all of this stuff can add anywhere between 500ms-2000ms but there are solutions.
I have plans for optimizing the ResourceHandler (as well as other things) after the full MVVM implementation which should greatly decrease the load of each individual download and significantly increase download/update speeds.
Regardless, you are correct, optimization is not currently at the top of the list but will be performed during the squish phase prior to the programs full release.
As well, just so you know, Update All updates all existing resources, not just watched resources (regardless of which page you start Update All on)!
So if you have some resource that you're not watching that are also downloaded (in ExistingResources in the backend), those will be included in Update All.
As always, I greatly appreciate the feedback. No need to worry about the possibility of discouraging development. If you, as a user, feel there is a problem I want to solve it. Any constructive feedback is good feedback whether it be negative or positive. It's about bettering the application overall, the communities opinions and feedback are a indispensable tool to achieving that.
Whenever you get the chance, if you could shoot that file over to me I can check in on what we can do now to help speed things up for you specifically!
Last edited:
- Joined
- Oct 22, 2022
- RedCents
- 6,102¢
Alright, so this is what's happening here:
I put in my MQ path in the path field, it is saved. I go to the VV tab, it says "install" (not upgrade), I click install.
After install finishes, the default (RG Manager) path is back in the MQ path field, and MQ is updated there.
I put in my MQ path in the path field, it is saved. I go to the VV tab, it says "install" (not upgrade), I click install.
After install finishes, the default (RG Manager) path is back in the MQ path field, and MQ is updated there.
Attempted the same steps and couldn't recreate this myself, does the root you're assigning to have MQ2Main.dll in it's file tree?
When assigning the root folder for a MQ install, the folder must contain MQ2Main.dll in it's file tree.
If you're entering the root manually, attempt to instead navigate to it using the seek button for the MQ path:
Let me know if that works, the path should be detected on the TextChanged event but there may be some funkiness there with the view-model restructure.
I'll take a look in to the TextChanged event as I have a feeling that's the issue here but if nothing above works/applies, let me know and I can take a deeper dive in to it!
The TextChanged event is working as intended here but catching a lack of MQ2Main.dll isn't.
I'm going to push a fix up to resolve the issue with detection over MQ2Main.dll within the roots file tree when the textbox loses focus. This should remedy updating the MacroQuest page's controls and solve the lack of user-end feedback.
Ionis updated RGManager (beta) with a new update entry:
v1.6.0.4: MQ Path Assignment Modifications
Read the rest of this update entry...
v1.6.0.4: MQ Path Assignment Modifications
Read the rest of this update entry...
- Joined
- Dec 1, 2006
- RedCents
- 278¢
Just as a comment, I was actuially updating Live with teh RGManager, it was the oild program I ended up updating both Test and Live in while waiting on RGManager to update the live system. I am sending both Test and Live folders to you to loook at to see if that helps.
One thing I noticed that did seem a lot different. In the old systsm, if you bought a license for a plugin, it would put it on the plugin page and you would DL it from there, In the RGManager, you have to specifically watch the purchasd plugins to get the DL The first time I fired up the bot and tried to load the plugin, it bit me in the behind
No big deal, but definitely a difference in operation.
One thing I noticed that did seem a lot different. In the old systsm, if you bought a license for a plugin, it would put it on the plugin page and you would DL it from there, In the RGManager, you have to specifically watch the purchasd plugins to get the DL The first time I fired up the bot and tried to load the plugin, it bit me in the behind
No big deal, but definitely a difference in operation.Just as a comment, I was actuially updating Live with teh RGManager, it was the oild program I ended up updating both Test and Live in while waiting on RGManager to update the live system. I am sending both Test and Live folders to you to loook at to see if that helps.
One thing I noticed that did seem a lot different. In the old systsm, if you bought a license for a plugin, it would put it on the plugin page and you would DL it from there, In the RGManager, you have to specifically watch the purchasd plugins to get the DL The first time I fired up the bot and tried to load the plugin, it bit me in the behind
To the last point, this was something that's been discussed quite heavily and could change!
Currently, it was decided that purchased plugins should not be automatically added to the watched resources but it's definitely a point of contention that gets mentioned to me quite often. I'll make sure to bring it up again in discussions about further development just to see how the powers that be may feel about implementing identical functionality!
Been watching this thread for a bit and messed with the new RGManager a little but decided last night to take a more in depth look and see if I can offer additional feedback and perspective since this is going to be the latest and greatest very soon and it appears you're at a stage where feedback/testing is very important.
First off, thank you for your hard work on this Ionis! Tackling this and IonBC (while trying to have a life) must take quite a bit of your time. I read through several pages here and found answers to many quesitons/issues I encountered but I found one that I thought I would bring up since it appears many of us do modify things within resources others post.
Let me start by saying I never did a "first" install of MQ from RGManager so I am not sure if that changes things but thought it worth mentioning. I updated RGManager to the latest version, then copied my MQ directory and pointed it towards the copied directory so I could mess with it without affecting my "old" install. Assuming that's the right thing, might be something others want to know in case they want to test this as well. If not, please let me know.
I love the idea of the "resource files excludes" as if I understand it correctly, we can exclude certain files from being updated when one is posted in case we have modified it. Similar to making the file "read only" on the old launcher so it would not overwrite. One of the resources I watched was Task Hud and it does have it's own directory (previous post seemed to indicate stand alone files may not be listed) but it does not appear in the resource file excludes as I thought it would.
As you can see, it's watched and has it's own directory in the Lua directory within the MQ directory RGManager is pointing to. When I go to the list of resources of files to exclude, it's not there.
Where as a resource like RaidHUD is and allows me to exclude the file I do not want updated (please correct me if that is NOT what this is meant to do).
Is this a setting or something I need to change?
First off, thank you for your hard work on this Ionis! Tackling this and IonBC (while trying to have a life) must take quite a bit of your time. I read through several pages here and found answers to many quesitons/issues I encountered but I found one that I thought I would bring up since it appears many of us do modify things within resources others post.
Let me start by saying I never did a "first" install of MQ from RGManager so I am not sure if that changes things but thought it worth mentioning. I updated RGManager to the latest version, then copied my MQ directory and pointed it towards the copied directory so I could mess with it without affecting my "old" install. Assuming that's the right thing, might be something others want to know in case they want to test this as well. If not, please let me know.
I love the idea of the "resource files excludes" as if I understand it correctly, we can exclude certain files from being updated when one is posted in case we have modified it. Similar to making the file "read only" on the old launcher so it would not overwrite. One of the resources I watched was Task Hud and it does have it's own directory (previous post seemed to indicate stand alone files may not be listed) but it does not appear in the resource file excludes as I thought it would.
As you can see, it's watched and has it's own directory in the Lua directory within the MQ directory RGManager is pointing to. When I go to the list of resources of files to exclude, it's not there.
Where as a resource like RaidHUD is and allows me to exclude the file I do not want updated (please correct me if that is NOT what this is meant to do).
Is this a setting or something I need to change?
This is likely due to the TaskHUD resource only having a singular file.
When we originally created the Resource Excludes, it was theorized that anything with more than a single file would be all that was relevant since updating a single file resource would mean that the single file located would be all there was to update.
This was due to my understanding of single file resources and an assumption on my part but if that is not actually the case then I'd be happy to review the process and allow for single file excludes!
Alternatively, you can make the init.Lua (the single file) in the TaskHUD directory read-only and when RGManager attempts to update the resource it will prompt you first to determine whether or not you want to update it, as you can see here:
While this isn't a solution to the exclude issue if you find you'd prefer to have single file excludes, it will prevent RGManager from overwriting the file if you select the continue or cancel options (continue will act as if it's updated but ignore overwriting, cancel will cancel the download altogether and elevate will pass through UAC to force an overwrite).
I appreciate all of the kind words, when we started RGManager we didn't expect it to be as grand scale of a project as it turned out to be (your normal app dev experience!) but it has been a fantastic experience and I've adored working on the project!
This and IonBC do take up a great deal of my time but I have an absolute blast working on both projects, interacting with the community and creating something that folks enjoy using so it almost feels like a hobby rather than work most of the time!
Regardless, I appreciate the feedback and if you feel you'd prefer single file resources should be added to the excludes please don't hesitate to let me know your opinion! I am always open to making changes to further better the program and all constructive feedback is good feedback regardless of what it is!
- Joined
- Oct 22, 2022
- RedCents
- 6,102¢
Sorry for the delay, I figured out what was causing my confusion - the default setting was showing this:
so I figured not to include the Release folder. But...turns out, there was more hidden, when I made the window bigger:
so when I correctly set the path, it worked fine now
Not a problem! I thought I had instantiated a tooltip to allow the user to see text that wasn't entirely revealed. Alternatively, making the window bigger will also make the textbox bigger!Sorry for the delay, I figured out what was causing my confusion - the default setting was showing this:
View attachment 65132
so I figured not to include the Release folder. But...turns out, there was more hidden, when I made the window bigger:
View attachment 65133
so when I correctly set the path, it worked fine now
I'll check and see if something went funky with the tooltip!
Opened up RGManager today and it loaded fine. Installed 
and then opened the old launcher to put themside by side to compare some things (was looking to see how I would verify how something would show in the new launcher if it needed to be updated), then closed them both. Never launched MQ on either. Came back a short bit later and opened RGManager again and got this;
Sent you the dump file as requested in previous posts. Please let me know if you need anything else!
and then opened the old launcher to put themside by side to compare some things (was looking to see how I would verify how something would show in the new launcher if it needed to be updated), then closed them both. Never launched MQ on either. Came back a short bit later and opened RGManager again and got this;Sent you the dump file as requested in previous posts. Please let me know if you need anything else!
- Joined
- Dec 1, 2006
- RedCents
- 278¢
On the single file Lua's, if I want my own version I just make a copy of the Lua to a different name then keep that one as 'My Version'
Yup, I did the same or marked it as RO.
The new launcher allowing for the exclusion is very cool though.
Got a fix coming for a separate issue I caught myself, but I'll take a look in to this!
At first glance, it seems that it's having a problem with determining the state of a resource when applying it to the datagrid.
Whenever you get the chance, could you navigate to: RGManager -> lib -> bin and shoot me over all of the contents of the Resources folder located in there?
I can setup an identical environment that way and see what's going on!
As well, MQ VS Code Lua Autocomplete Definition Library has no files associated with it in the backend as it's repository is off-site. This means it cannot be downloaded through RGManager even though it shows up in the datagrid(s). I've gone back and fourth a lot on whether or not resources with external hosting should be fully ignored, but there's a couple of problems:
1. There's a massive limitation with the current XF API resource object which requires us to get the file list of a resource before we can actually see if there's any file associated with it. If we were to do this with every resource to check for no files it would be extremely time consuming and increase load times exponentially.
2. It may lead to confusion if users were looking to navigate to the resource on-site via the name (which you will soon be able to do via RGManager) and they couldn't find it within the resources list.
These are primarily why I chose to just handle it at time of download as opposed to bogging down the user experience, but there's likely better solutions I could explore.
We could potentially asynchronously remove resources that don't have files on a page-to-page basis. This way, it won't hang up the main UI thread and can be designated to something like a background worker to handle it as the pages turn over. That's just me spitballing ideas though
I'd really have to play around with solutions to see if I can come up with something that I'm comfortable with, but I went on a bit too much of a tangent here.
Shoot me over that resources folder whenever you get the chance and I'll take a deeper dive in to what's going on!
Ionis updated RGManager (beta) with a new update entry:
v1.6.0.5: No Files action history fix
Read the rest of this update entry...
v1.6.0.5: No Files action history fix
Read the rest of this update entry...
Ionis updated RGManager (beta) with a new update entry:
v1.6.0.6: Download column state bugfix
Read the rest of this update entry...
v1.6.0.6: Download column state bugfix
Read the rest of this update entry...
- Joined
- Dec 1, 2006
- RedCents
- 278¢
Doing the new update this morning, I decided to look through my watched resource list, and I found 3-4 items I had not yet downloaded because they were older resources that I had just recently seen and started watching. I think it would really help to have an option, or maybe a category filter for 'Watched, but not yet downloaded' to be able to find those easily.
I had a similar thought. We need to devise a better way to see "up to date", "needs update", "purchase", "download", etc. Also have a color system similar to the existing maybe? Red for update needed, green = up to date, blue= <purchase>, etc.
and sort, but I think that was mentioned already.
and sort, but I think that was mentioned already.
I had this planned for the advanced filtering functionality but, for the time being, adding new features for RGManager has been officially frozen.
The next patch released will hold the second half of the MVVM shenanigans and a lot of QoL/Optimization but after that development on new features would be solely when I can make the time to do so as of the current freeze to development.
I've been asked to put my time in to a different project by the powers that be (at least for the time being) so my standard workflow is mostly invested in to that project as opposed to RGManager.
I still plan to unofficially update RGManager as a personal project, as I really enjoy working on the project, a lot of folks seem to really enjoy using it and I feel it has a great deal of potential so I appreciate any/all feedback.
It will, more or less, be updated on my own personal time now as opposed to a consistent flow of updates.
With that being said, I think this would be best implemented as a form of filtering but I am open to suggestions! Statuses such as purchasable, downloadable, updatable, et. al. could be nested in a panel native to the Resources pages to allow for easy filtering. I'll blueprint out a structure for it and see what I can come up with, but I am open to any suggestions for tackling implementation that may make more sense.
Missing as in they're not in the resources lists what-so-ever or they're not showing up in the Watched Resources list?
Purchased plugins aren't automatically watched through the API (RedGuides site-side). I have a working solution for this that checks for purchased plugins using a system of structures but it won't be out until next patch. If you watch the plugin either through RG or RGManager, it should appear in the watched list (if this is the issue you're having).
If they're not showing up at all try searching for them in the All Resources list by name and let me know if they appear.
I, currently, can't recreate this as they're both showing in my instance:
If none of the above are the solutions to the issue it may be something more specific to your instance or potentially a change in the API I wasn't made aware of.
Let me know if you can see them in the All Resources list!
