An update on Vortex development
Since our last news post back in May we have setup a focus group of around 30 individuals who have been given access to an early build alpha of Vortex using a rudimentary design and UX flow. Tannin has been working with these users, taking on their feedback and patching up bugs that have been found over the past couple of months. At this stage, the core functionality is all done and now it's a matter of rounding off any rough edges and patching up any holes the focus group can find.
While Tannin has been working on the overall functionality of the application, our new UX/UI designer, Kit, who officially began her work at the beginning of October has been working on the overall look and feel. Kit's first task has been to work on the design of Vortex, drawing up wireframes and now mock-ups that eventually Tannin will implement into Vortex. The first of these mock-ups were offered to the focus group for consultation and feedback last week while Kit worked on the rest of the screens that Vortex needs.
I've been reliably informed that, today, Kit has run out of screens to mock up, so these final screens will be in the hands of the focus group by the end of today. We will give the focus group most of a week to provide their feedback on these mock ups. Following that, Kit will spend a few days implementing any necessary changes based on this feedback before they are handed over to Tannin as "final".
From there, Tannin will need to spend some time implementing the new design into the current build of Vortex, which is no small task. The focus group will be provided with these builds as and when they're ready for feedback. After that, it's all touching and shoring things up ready for an official public Alpha release.
Tentatively, we're aiming for a January release date for the open Alpha of Vortex. Naturally, that's subject to change as with all development cycles, but we're quietly confident that we will hit that deadline.
While I've juggled with the idea of providing you all with mock up screens of Vortex to tide you over until then, I think without you being able to actually experience the user flow and experience the software fully, a lot of the context will be lost, which will ultimately mean any feedback you could provide would be superficial (and potentially, negative, without any context to back it up). As such, I think it would be better for all of us if we waited until it was actually possible for you to use it. Then the feedback you provide will be far more useful, and relevant, to us.
Not long now!
443 comments
Comments locked
A moderator has closed this comment topic for the time being?
gud sitePlease tell me whether I understand Vortex, or not, and let me know how it's progressing. Thanks ...
For a "group of mods to download to a vanilla game, all of which function well together," modding guides are still your best bet.
edit: by the way, the modpack feature talked about below isn't from devs, nor is my comment, so uh, don't take everything as gospel and try to get revenge if i'm wrong, lol.
this type of comment doesn't help nor is funny
what about switching back to NMM?
It started out to be, but it appears......is the term hijacked correct?
Comparing a beth game to Minecraft, is like comparing a model T to a Bugatti veyron. The games are similar only in superficial ways. There is FAR more going on under the hood in beth games. Pretty much apples vs. hand grenades.
That is why there is a part on the Mod page called Description. This tells what the mod is and what it is used for and some mods use this as to how to install the mod and where to place it the Load Order. They also tell you how to uninstall the mod as well.
It is always important to read the Description page before downloading the mod. Plus, it is also important to go to the Post page or even the Bug page to read if someone encounters any problem or problems with the mod. Because sometimes either the mod author or other mod authors can give helpful advice on how to resolve any issues.
Remember, always read the Description Page First and then go to either the Post page or Bug page in case there are any problem or problems other people have encountered.
@Jpwolf69
Plenty of mods in Minecraft require other mods. It's a mod pack, they include the mods the other mods need. It's not complicated. In fact, the curse/twitch client will download required mods automatically. If you install a mod that requires a library, it will also download that library.
Load order is also not a problem, it's just a file that tells the client what order to place mods in. It's literally a copy and paste sort of job. Not complicated. I can take all the information one one load order, and all the mods and copy it over to a different computer and it will work fine as long as I am not missing anything that is required.
There is a lot of ways one can do this and make it work. The biggest difference between Curse and Nexus is Curse keeps all old files, while Nexus allows the mod author to decide if they want to remove it or not. There are several ways to solve this problem.
1. You no longer allow mod authors to delete old files. This is not a way they want to go about it because it takes away a bit of control. However, it is a way that still exists.
2. The modpack just installs the latest version of the mod. This can work quite often, at least in the case of Skyrim and Fallout because most updates to mods don't typically break entire games. This is more of a problem with updating during an already existing game, which is something most people who use mod packs likely would not do. Only if there is a game breaking bug that an update is needed.
3. The best solution besides solution 1 is to use notifications and choices. If a mod authors delete a version of their mod, it will notify anyone who has included it in a mod pack that they made. This will help those who make mod packs keep things up to date, and aware of any possible issues. Then when a person downloads a pack with a version of a mod missing it will give two options. One, download the new version, or two, don't install the mod. In the case of option two the client would check to see if there are any required mods and also not include those unless they are needed for another mod. The load order will be the same just minus those mods. These two options would work the majority of the time for a game like Skyrim and Fallout.
The only other issue with modpacks is there are a lot of mods that generate unique files. The solution here would be to include those unique files in the mod pack. So the user does not have to generate it themselves. The exception being things like DynDOLOD. I would say that just can't be included in a modpack. Sacrifices will have to be made for those who want to go the modpack route, but to people who never modded before and are not very good at it, I think they wouldn't care all that much.