NMM2 - Update and recruitment

[Deleted1302561User]

In response to post #47600045. #47798955 is also a reply to the same post.

kriekit wrote: NMO - Nexus Mod Organizer, as a nod to Tannin's fantastic work.

mcdanielskh wrote: In my opinion NMO is the only name that accurately describes what I hope is being developed :)

+1

[JoruneSkyman]

1. Personally I prefer pgms/apps/whatever that have names which describe their functions, rather than the vogue for Ikea-style names which tell you nothing about functionality.

 

2. I assume the new mod organizer will have most of, or preferrably all, the features of the current version, on pain of screams from the community, but it will be x64 (but still 32bit compatible?)

 

3. It would be good if the new version indicates, in the main interface, whether a mod has scripts, and especially, if those scripts are continuing, such that they may cause complications if the mod is uninstalled without some special procedure. It would be a nice headsup to be reminded of this issue when contemplating removing a particular mod, to know that a simple uninstall won't do the job.. (I know MO indicates scripts now under 'content', but it doesn't show whether they are continuing, ie special uninstall procedure required).

 

4. I notice that many mods have installers with options depending on what other mods you have installed, either pre-requisites for the mod, and or compatibility patches for other related (?) mods. The potential problem here is that the installer may, for instance, have a compatibility patch as part of the overall install (ie not a separate DL patch) for a mod that is not installed at the initial time of installation, but which a player may later decide to install, the player forgetting that by installing this new mod, an older mod will also need to be reinstalled with a new option taken in the install procedure. Would it be possible to add flags, or something like that, so that ALL the options in a mod's installer are mapped internally in the new MO, and options not taken in the original install are still noted so some kind of notice (mod order line colour change ??) and when a future mod is installed, for which this original mod has options (taken or not) the user is prompted to reinstall the first mod.. ? A bit wordy - so an example: XPMSE has a number of compatibility options for belt-fastened quivers/dagger/sword at hip/at back in Archery Gameplay Overhaul, Pretty Combat Simulations, and Joy of Perspective. When I installed XPMSE, as a prereq to CBBE, I wasn't using any of these other mods so didn't take the compatibility options. However, if in future I decide to install say Archery Gameplay Overhaul, it would be good to be reminded (post-install for the new (Archery mod to register in MO's internal database) that XPMSE will need to be reinstalled as a result of installing Archery.. or maybe it won't NEED to be reinstalled but reinstallation could give better results..

 

Cheers! :)

 

Edited March 8, 2017 by JoruneSkyman

[Stiffon]

In response to post #47600045. #47798955, #48172257 are all replies on the same post.

kriekit wrote: NMO - Nexus Mod Organizer, as a nod to Tannin's fantastic work.

mcdanielskh wrote: In my opinion NMO is the only name that accurately describes what I hope is being developed :)

xama21 wrote: +1

+1

[varararak]

In response to post #47600045. #47798955, #48172257, #48266012 are all replies on the same post.

kriekit wrote: NMO - Nexus Mod Organizer, as a nod to Tannin's fantastic work.

mcdanielskh wrote: In my opinion NMO is the only name that accurately describes what I hope is being developed :)

xama21 wrote: +1

Stiffon wrote: +1

+1!

[Mikanoshi]

We did consider many alternatives but problems/limitations with each. Feel free to suggest other UI toolkits, I'm fairly confident I can justify why electron is better for our use case for anything you can come up with.

https://sciter.com/

 

 

I wouldn't worry too much about the memory footprint, the memory usage you see in the Task Manager is quite misleading. A smart application will use as much memory as it can reasonably use, for caches and such. It's not a design goal for modern PC software to avoid memory usage. But that doesn't mean that memory is unavailable to other applications: If you're running a game and uses most of your physical memory, windows will, quite efficiently, swap out the memory of idle background applications (like NMM) first. A demanding foreground application will be able to utilize almost all of your physical memory no matter what you're running in the background.

Empty page in Sciter consumes significantly less memory vs empty page in Chromium, which contains a lot of stuff you'll never ever use in a non-browser program.

Yes, memory should be used as much as possible, otherwise it's a wasted memory, but it doesn't mean you have to load unneeded data there.

Sciter is a single DLL (static linking is possible, but not in a free version), 4MB for 32-bit and 5.5MB for 64-bit version.

Chromium is... well, a lot of MB in a plethora of files :smile:

 

For one thing it gives us more power to style and theme the UI than any "regular" ui toolkit.

Sciter supports CSS/HTML, native drawing and DirectX, you can paint anything you want. Styling is as easy as loading different CSS styles.

It also has unique attributes: https://sciter.com/docs/content/css/cssmap.html

 

It is platform independent so we can support Linux and MacOS (not making a promise here, just saying from a technical standpoint we haven't burned any bridges).

https://sciter.com/sciter/crossplatform/

 

 

It's using a widely known, simple programming language and free tools making it the best option when hoping for user contributions.

Sciter uses TIScript, an extended version of JS:

https://sciter.com/developers/for-web-programmers/tiscript-vs-javascript/

https://sciter.com/docs/js-dart-tis.html

It is not compatible with JS frameworks, but it already has a lot of additional methods built-in that are similar to JQuery for example.

 

The v8 engine is the fastest (or close to) of any scripted language interpreter, several times faster than, say, python.

This is an UI, not a full featured app that requires all functionality to be implemented in scripts. Why do you care about JS speed, NMMv2 will have some heavy scripting on UI side?

Anyway, Sciter's script engine is fast enough, you can even precompile scripts to bytecode.

 

Electron and related tools are well supported and actively developed, giving us the trust that they won't be obsolete in two years.

Sciter (previously HTMLayout) is being developed for more than 10 years and counting:

https://sciter.com/sdk/logfile.htm

IMHO its main advantage is a close integration of UI and native code, you can easily control any element from native side and also call native functions directly from script.

Edited March 10, 2017 by Mikanoshi

[Dark0ne]

In response to post #48279552.

Mikanoshi wrote:

We did consider many alternatives but problems/limitations with each. Feel free to suggest other UI toolkits, I'm fairly confident I can justify why electron is better for our use case for anything you can come up with.

https://sciter.com/

I wouldn't worry too much about the memory footprint, the memory usage you see in the Task Manager is quite misleading. A smart application will use as much memory as it can reasonably use, for caches and such. It's not a design goal for modern PC software to avoid memory usage. But that doesn't mean that memory is unavailable to other applications: If you're running a game and uses most of your physical memory, windows will, quite efficiently, swap out the memory of idle background applications (like NMM) first. A demanding foreground application will be able to utilize almost all of your physical memory no matter what you're running in the background.

Empty page in Sciter consumes significantly less memory vs empty page in Chromium, which contains a lot of stuff you'll never ever use in a non-browser program.
Yes, memory should be used as much as possible, otherwise it's a wasted memory, but it doesn't mean you have to load unneeded data there.
Sciter is a single DLL (static linking is possible, but not in a free version), 4MB for 32-bit and 5.5MB for 64-bit version.
Chromium is... well, a lot of MB in a plethora of files :smile:

For one thing it gives us more power to style and theme the UI than any "regular" ui toolkit.

Sciter supports CSS/HTML, native drawing and DirectX, you can paint anything you want. Styling is as easy as loading different CSS styles.
It also has unique attributes: https://sciter.com/docs/content/css/cssmap.html

It is platform independent so we can support Linux and MacOS (not making a promise here, just saying from a technical standpoint we haven't burned any bridges).

https://sciter.com/sciter/crossplatform/

It's using a widely known, simple programming language and free tools making it the best option when hoping for user contributions.

Sciter uses TIScript, an extended version of JS:
https://sciter.com/developers/for-web-programmers/tiscript-vs-javascript/
https://sciter.com/docs/js-dart-tis.html
It is not compatible with JS frameworks, but it already has a lot of additional methods built-in that are similar to JQuery for example.

The v8 engine is the fastest (or close to) of any scripted language interpreter, several times faster than, say, python.

This is an UI, not a full featured app that requires all functionality to be implemented in scripts. Why do you care about JS speed, NMMv2 will have some heavy scripting on UI side?
Anyway, Sciter's script engine is fast enough, you can even precompile scripts to bytecode.

Electron and related tools are well supported and actively developed, giving us the trust that they won't be obsolete in two years.

Sciter (previously HTMLayout) is being developed for more than 10 years and counting:
https://sciter.com/sdk/logfile.htm
IMHO its main advantage is a close integration of UI and native code, you can easily control any element from native side and also call native functions directly from script.

You're entitled to your opinion and all, but we did all our own research and decided Electron was for us. You can argue the merits of your preferred platform, for sure, but we've already made our mind up.

It wasn't mentioned to gauge opinion, it was mentioned as a matter of fact :)

[Longcrossing]

 

In response to post #47600045. #47798955, #48172257 are all replies on the same post.

 

 

 

kriekit wrote: NMO - Nexus Mod Organizer, as a nod to Tannin's fantastic work.

mcdanielskh wrote: In my opinion NMO is the only name that accurately describes what I hope is being developed :smile:

xama21 wrote: +1

+1

 

 

I too have much respect for Tannin and his work and, in fact, am still overjoyed that he is working on this new version of nexus mod managing software.

BUT, the name option NMO was vetoed by the site owner a long time ago.

 

I personally like Vortex (suggested some time back). The alliterative nature of Nexus Vortex works.

 

Someone also suggested NUMI a while back. It's good too.

 

Some other suggestions (truly very plain but they would get the job done):

NMT - Nexus Mod Tool

NMH - Nexus Mod Handler

NMC - Nexus Mod Coordinator

NMW - Nexus Mod Wrangler (yes it's dopey but gets across the "herding cats" nature of trying to get mods to play nice together.)

 

Admittedly, these are all just synonyms But this IS Nexus, it DOES work with Mods and IS meant to manage.

Clearly, this project is an altogether new product and therefore keeping the name NMM would only cause confusion as some users will stay with the old NMM and not update...

[Longcrossing]

 

In response to post #47493580. #47500655, #47507910, #47533300, #47538495, #47549365, #47581735, #47582835, #47686910, #47688185, #47825835 are all replies on the same post.

 

 

 

Farvahar wrote: What I want to be able to do: have a person save their Skyrim configuration in toto and share it with other users as a file; the mod manager would then recreate that experience on my machine without all the hassle that goes with this currently. The manager would download the mods, set them up etc etc so as to create the same Skyrim experience as a mod master would be able to put together.

 

Their are guides that explain how to recreate an "ideal" Skyrim configuration, but they require far too much attention for novices and more casual players. For folks with little time to play around with all that, it deters from playing the game.

bubinga64 wrote: Im not saying it's impossible, but I wonder just how useful that feature would be unless it was only mods from this site and said configuration didn't have older mods that are now hidden or removed. Also keep in mind that many people tweak mods so you may not get the intended effect.

piperman123 wrote: I can't second this enough, making it so we can share modded games without depriving modders of their downloads would be sweet AF! Would also be a tremendous help with troubleshooting I imagine. Letting more experienced modders or mod authors tweak certain things or quickly produce patches, reproduce and narrow down user issues etc. As for people using tweaked esps, no reason why after the manager downloads that mod it can't copy (or the users can manually share) the tweaked versions or direct each other to mods downloaded from elsewhere which is probably far fewer than those used from here anyway.

 

Plus I spend weeks messing with mods and it would be great to be able to share some of my 'ultra modded' setups with friends who aren't as experienced or willing to put the time into learning or setting things up but have seen my version of Skyrim and would like to play it too or even help troubleshoot and test things as they play more than I do or while I continue to play about with modding further.

 

+1 for sure!

vogues wrote: game changer

phellen wrote: I could see automation like this working for mods using the simple "click the NMM button to install" but not for mods that require separate plugins, patches, mod requirements, ini edits, manual downloads, etc. Probably would end up creating more problems for people than it would solve. Then there is the issue of bypassing page views, and the advertisement and support that nexus, and potentially mod authors get (through donations) with those page views.

 

The only way I can imagine this working is if Nexus set up a file sharing system like dropbox that can also connect to the Skyrim data folders and the nexus mod manager, allowing players to share data/ save game files via the cloud. Interesting concept for sure, but sharing data like that could also mean monthly subscription charges to pay for storing all the data on the cloud.

tajetaje wrote: So one thing Most of the modding community (probably) and I would absolutely love/need in NMM2 would be some sort of import from MO2/NMM1 and a virtual file system.

P.S. love te work you guys do here, very much hyped for NMM2.

tajetaje wrote: bubinga64 it's called a backup. But what would be cool is having an exportable/importable mod list that auto downloads, if still on the nexus.

lued123 wrote: Taje, Nexus can't keep backups of old mods if the original authors don't allow it. The guy who made Wyrmstooth left because he wanted to completely erase his online presence. Nexus keeping a backup of that would have been in direct conflict with what he was trying to do, and probably insulting besides.

At any rate, modlists that make use of mods that no longer exist can just become obsolete like many mods themselves eventually do, so I don't think that's a huge problem. You could create a list in ModPicker or find one on the Nexus site and then feed that list into the mod manager and have it create that modlist as closely as possible, then notify you of what's missing.

The actual problem here is what Phellen said: bypassing page views and ad impressions, as well as the Nexus simply having to handle the traffic. The closest thing to a solution that I can think of would be restricting the feature to premium members, who don't contribute ad revenue anyway, and already paid for access to better servers.

In any case, I think the Nexus staff probably want to focus on the basic features of the new manager and the site redesign before moving on to hypothetical features like one-click overhauls.

tajetaje wrote: what I meant was very similar to what you just described, but the feature would not be hard at all to implement, and even easier with electron. The feature would basically have a .txt file that NMM2/vortex could read with the mod name, file version, and nexus ID. Of course this wouldn't work with manual downloads or old/deleted files, but that is the trade-off.

Kirk777 wrote: Yes please.

 

I'm the kind of player that like to experiment mods and different environments, and this'll let me switch from my desktop PC to my laptop much much easier.

 

And as OP said, it'll give mod authors a way to give players the experience they want to share, especially for ENB authors.

Limbic2Node wrote: I have several follower mods that I've edited visually and altered their esp. , unless the creator/author looks under the hood, I doubt they would recognize their own creation.

I;m willing to bet these mod creators would not be happy with me if I made their altered followers available, neither would the folks running The Nexus. So, even if it was practical to implement, I would suspect mod "ownership" would be enough of a reason to reflect upon, throw in the other wise points discussed above and that makes it a no go.

Having said that, +1 for a pretty good idea.

@Limbic

I think in general it would only support nexus-managed files. It wouldn't just internet your data folder into someone else's. There'd probably have to be a prerequisites text field where the creator of the modlist could put information like "requires SKSE" or "looks best with X ENB", but it wouldn't be able to transfer files from the list author's machine.

At best the list author could create add-on esps (by esmifying, then making those edits you talked about) and upload those on their own Nexus page, then include those in the list. With permission from the original mod author of course.

Edit: and what would also be great is that the modlist could include a file list (listception), so when the manager finished downloading, it could check the data folder against that list to make sure all the mods made it.

 

 

With absolutely no disrespect or snarky-ness intended to any poster on this sub issue:

The idea is interesting but... I, for one, hope the Developers do not put any time or energy into it for the time being.

Many of us are just holding on for 64 bit NMM/MO+ for all the previously stated reasons.

 

Coding algorithms that could cope with an export/import process of what every single Nexus user could potentially put together for all Nexus mods for all the games Nexus handles, install them in the correct sequence and then in some cases move the mod to a different position in the load order and then deal correctly with all the error conditions that result sounds something like playing chess with a stadium full of opponents and covering every single possibility with each of them 512 chess moves out.

That isn't even taking into account users with mod merges in their setup and mods that were on Nexus but have since been removed and every potential version of a given mod in the user's mod list.

 

Please, don't get sidetracked, and just give us the new NMM/MO for now?

[Tannin42]

In response to post #48279552. #48280237 is also a reply to the same post.

Mikanoshi wrote:

We did consider many alternatives but problems/limitations with each. Feel free to suggest other UI toolkits, I'm fairly confident I can justify why electron is better for our use case for anything you can come up with.

https://sciter.com/

I wouldn't worry too much about the memory footprint, the memory usage you see in the Task Manager is quite misleading. A smart application will use as much memory as it can reasonably use, for caches and such. It's not a design goal for modern PC software to avoid memory usage. But that doesn't mean that memory is unavailable to other applications: If you're running a game and uses most of your physical memory, windows will, quite efficiently, swap out the memory of idle background applications (like NMM) first. A demanding foreground application will be able to utilize almost all of your physical memory no matter what you're running in the background.

Empty page in Sciter consumes significantly less memory vs empty page in Chromium, which contains a lot of stuff you'll never ever use in a non-browser program.
Yes, memory should be used as much as possible, otherwise it's a wasted memory, but it doesn't mean you have to load unneeded data there.
Sciter is a single DLL (static linking is possible, but not in a free version), 4MB for 32-bit and 5.5MB for 64-bit version.
Chromium is... well, a lot of MB in a plethora of files :smile:

For one thing it gives us more power to style and theme the UI than any "regular" ui toolkit.

Sciter supports CSS/HTML, native drawing and DirectX, you can paint anything you want. Styling is as easy as loading different CSS styles.
It also has unique attributes: https://sciter.com/docs/content/css/cssmap.html

It is platform independent so we can support Linux and MacOS (not making a promise here, just saying from a technical standpoint we haven't burned any bridges).

https://sciter.com/sciter/crossplatform/

It's using a widely known, simple programming language and free tools making it the best option when hoping for user contributions.

Sciter uses TIScript, an extended version of JS:
https://sciter.com/developers/for-web-programmers/tiscript-vs-javascript/
https://sciter.com/docs/js-dart-tis.html
It is not compatible with JS frameworks, but it already has a lot of additional methods built-in that are similar to JQuery for example.

The v8 engine is the fastest (or close to) of any scripted language interpreter, several times faster than, say, python.

This is an UI, not a full featured app that requires all functionality to be implemented in scripts. Why do you care about JS speed, NMMv2 will have some heavy scripting on UI side?
Anyway, Sciter's script engine is fast enough, you can even precompile scripts to bytecode.

Electron and related tools are well supported and actively developed, giving us the trust that they won't be obsolete in two years.

Sciter (previously HTMLayout) is being developed for more than 10 years and counting:
https://sciter.com/sdk/logfile.htm
IMHO its main advantage is a close integration of UI and native code, you can easily control any element from native side and also call native functions directly from script.

Dark0ne wrote: You're entitled to your opinion and all, but we did all our own research and decided Electron was for us. You can argue the merits of your preferred platform, for sure, but we've already made our mind up.

It wasn't mentioned to gauge opinion, it was mentioned as a matter of fact :)

Sciter:
- uses it's own language for no good reason and apparenly only supports a subset of html which means you have to do more yourself than with a well established framework
- isn't open source
- is apparently developed by a single person who insists on talking about himself as "we".
- has this funny clause in the description: "NOTE: public version of the engine may send diagnostic messages to one of our servers." The alternative to exposing all our users to spying from a third party is paying thousands of dollars per year on a license for something that offers less than electron
- from my experiments does not use considerably less memory than electron, even an empty page took around 60MB.
- is !only! a ui framework. electron includes node which gives us cross platform file access, network, debugging, ipc, storage, installer + updating, ... Which also explains in part why sciter is so much smaller: It has a much narrower focus. We wouldn't be able to develop NMM2 with just sciter, we would need further libraries to provide that functionality like Qt or .net which also take memory and (except for .net) disk space.

There is sooo much speaking for picking electron over sciter and the only thing speaking for sciter is that it maybe takes a bit less disk space? Which isn't even sure because - again - we would require further libraries for functionality that is included with node.

Sciter supports CSS/HTML

That's the thing: It does not fully support html5 or current css standards. It may have useable equivalents but that still means you can't use libraries/frameworks based on modern standards. And there is absolutely no good reason for that.

Sciter uses TIScript, an extended version of JS

exactly, why is it using TIScript?

This is an UI, not a full featured app that requires all functionality to be implemented in scripts. Why do you care about JS speed, NMMv2 will have some heavy scripting on UI side?

Of course the majority of application logic will be written in JS because that's how you write electron/node applications. We use native code only for computing-intensive tasks.
I realize sciter forces you to write most of your application logic in another language through a c binding, I'd just like to know how that's supposed to be a good thing?
Node lets us use native code just fine whenever we want, it's just not something you want all the time.

Sciter (previously HTMLayout) is being developed for more than 10 years and counting

The fact it's taking forever is a good sign now? ;) Edited March 15, 2017 by Tannin42

[ErusPrime]

Would you consider adding a modpack functionality? The ability to export download links, load order, and maybe even configuration settings would be an amazing thing. Having to create and curate my own group of mods gets tedious after awhile. Especially for newly released games that are still being updated. Small groups creating and curating collections of mods would be a much more welcome experience.