Pelinor

Yes. I was preparing to make a post with details about it. There are a number of roadblocks for the project, with the most significant being F4SE and its current lack of functionality. They're getting close with the Papyrus support but it's not quite there.

That's right, you won't need to learn anything outside of Papyrus to make a menu with MCM. I'm basing it on an unpublished (and unfinished :ermm:) evolution to FNV's MCM from about 2 years ago, which is way easier to work with than the original. The script will be in essentially two sections - one for defining the menu and the other for managing values returned from the user. There's a bit more information to input when defining the menu, but it ends up being much easier to read and alter. Still waiting on F4SE to bridge the UI and Papyrus before it really gets going, though. Then there's the mess of Flash and the decompiled UI to fully understand...

I don't have anything to add to the holotape naming topic, but I wanted to let you all know that work on MCM is progressing. It's still very much in the initial stages, so I'm open to any requests or requirements you folks might have. No ETA unfortunately, but the menu building and managing is going to be much more streamlined than previous versions. Not a fan of Flash/Scaleform, though. :dry:

Although it's fairly simple once you know what's going on, it's a really complex thing to dive into or explain to someone. Fortunately, there's some good documentation on Oblivion XML. (Unfortunately, I only found that a few weeks ago... I had to learn the hard way.) Since that's for Oblivion XML and not Fallout XML, there have been some additions from what's written there. You can find the new stuff if you browse through master_menu_file.txt, though. You'll also need to learn how to use menu input, which isn't covered there. One way is to detect a hotrect element's <mouseover> value and have your script run IsKeyPressed to detect a click. Another way, which also works for controllers, is to have a custom tag (one with a _ prefix, or user#) that adds the hotrect's <clicked> value and then gets cleared when another value is set via script. You'll find this method used by most interactive menus.

There was a problem with the download. It looks like it's all been sorted now, though.

It's now official: The Weapon Mod Menu. I spent my whole morning wrapping things up and giving it the final pre-release bashing. Thank you all for the assistance, especially since "beta" tends to scare away most people. I sincerely appreciate it. :) I haven't tested the functions on NPCs yet. It should be possible, though.

Do you mean there's a bug with the new menu or the old one? The condition check in beta 5 should keep it the same as it was before the mod was attached/removed. My original says 0.5, as does the one I downloaded, so I'm not sure what's going on.

Oops. It looks like I needed to recompile one of the quest stage scripts. Please download again if you got beta 5 before this was posted. (Edit: :pinch: I just noticed it was the same file. OK... it's really the new one now.)

Thanks again for all of the feedback, folks. It should be ready for official upload now that I was able to fix that odd bug with HoldKey. I'll let it sit for another day or two to make sure no other bugs pop up, though. I need to come up with a logo, too... :confused: Added check to keep condition percentage after modifying Fixed bug with not equipping new weapon Removed debug code

Good catch. :thumbsup: It's virtually nothing to add, so I'll have it keep the condition percentage. I actually like that better than the vanilla behavior for those mods, which seems to be to "repair" the weapon after modding.

It's been designed to work with any weapon that can be modified. I've not specifically tested those, except WMX, but it shouldn't have a problem with them.

Thanks for all of the feedback, folks. It's been very helpful. Fonger: The weapon has to be equipped before the script can see if it has any mods or not, so unfortunately it won't be possible to hide the X prompt beforehand. As for X not working if the mod isn't in the list is due to the hijacked input of the inventory menu. Removing the XML includes returns it to normal. Does schlangster's updated dll help the initial problem, though? jonnyeah: I've changed it to read as "Telescopic sight. Aim zoom + X%" as a compromise. I think it's important to keep the percentage, but I agree that it should be more indicative of the mod's use. (Although the mods usually have "scope" in the name.) antistar: Thanks for letting me know. I never noticed the two "None" types. (Mostly because I never paid much attention to the list in the Mod Info tab...) :blush: Added new wmod_ext.dll provided by schlangster Fixed mod description for "None" type Updated description for several mod types Added message for "X cannot be modified." Added a few debug globals For those of you having problems with the selected weapon not being equipped before opening the menu, I've added some debug globals. "WMMDebug" will print out info to the console regarding the equipping section of the script. "WMMDelay1" and "WMMDelay2" can be used to add delays, in frames, to the equipping process. Try changing these to different values to see if a delay helps guarantee the force equip. The format is just like any other global, e.g.: set WMMDelay1 to 1

Well folks, I'm looking for some volunteers to test out my new mod. Thanks to a few new NVSE functions made by schlangster, it's essentially a new menu for adding/removing weapon mods. Feel free to download and try it out; feedback is appreciated. The readme:

GetPlayerCurrentAmmo from NVSE is what you're looking for.

I've been working on a Notepad-type text editor for the Pipboy. I have it where you press the N key while in the "Notes" section to open up the notepad. Writing in books is a neat idea, but I don't think I'll be doing that to start with.

NVSE's BuildRef function would allow you to set a reference variable to a known ID. You can then use that variable to manipulate the object however you want. An example of using it would be: short iIndex reference rRef begin OnTriggerEnter set iIndex to GetModIndex "The Other Mod.esp" set rRef to BuildRef iIndex [RefID] rRef.MoveTo [someOtherRef] 0 0 100 end The drawbacks to BuildRef are: You have to know the FormID of the reference. You have to convert the ID from hexadecimal to decimal for use in your script. (Ignoring the first 2 hex digits.)

Beta 10 is now Version 1.1 for the public. It's safe to release any menus using the new multi-menu feature now. I forgot to mention earlier, but there's a "StartMenu/MCM/_MCM" that has the file version, 1.1 right now; your mods can check against _MCM and give a warning to the user if they're using an MCM older than needed for your menu.

That's pretty close to my first attempt; I just didn't have a grid visible. The problem is it's very difficult to put the element exactly where you want it with smaller grid units. You'd have to use either a larger grid unit, which loses precision, or the grid area would have to cover most/all of the screen. Perhaps a "precision" selector beside the grid for the user to change the grid unit size and how easily the X,Y value changes. Or arrow buttons to move it 1, 5, or 10 of the smallest unit in each direction... I'll have to think on it when it's not so loud around here. :confused:

Fixed freezing if start_menu.xml edit is removed after saving That one was reported by a user. The current fix should have been the way I did it for beta 3. :blush:

Fixed list width padding Reduced highlight alpha Fixed freeze with scale when using higher script delays If nobody finds anything wrong with this beta, it'll become the official version 1.1. I don't want to hold up anyone waiting on the next version any longer. I expected to already have the X,Y coordinate option type finished but every time it ends up either looking bad, working poorly, or not user-friendly enough. I'll have to figure out a better way to implement it... Any ideas?

Oh, I missed that when it started a new page. I'm almost finished with the X,Y coordinate option type, so I'll include that fix along with it. I just wanted to get beta 8 out with the multi-menus so Gopher could wouldn't have to wait to finish his menu right. Something else I'll fix is the highlight alpha. (It should be 30 alpha.) I normally have the brightness turned down on my monitor to avoid too much eye strain, so I missed it being too bright.

Added capability of multiple menus per mod Added Multiple Menus section under Advanced Uses Fixed example esp scripts to use ListAddForm instead of AddFormToFormList (how did this happen...?) The new "multiple menus per mod" feature allows one mod to have multiple top-level menus, each with its own sub-menus. Gopher was having some trouble with the sub-menu limit, so I added this feature to help out. Details are given in the MCM Guide. As long as each successive menu has a higher value than the previous, it'll list them in the order of value with lowest at the top. (This should have the potential for an unlimited number of top-level menus per mod, although I only tested with three.)

Oooooh. That's really good looking with the Project Nevada graphics there. It's great that you were able to finish all of those menus with success, too. That must be well over a thousand lines to code, so bravo! :thumbsup: There wasn't any pestering, but I'll be adding two more option types for UI mods; one for X,Y coordinates and one for RGB values.

Now that's it's fixed, I've uploaded it for the public now: Link. Let me know if/when any of you upload files with menus for MCM so I can provide a link to it for other users. I'll continue to give support for modders here, so don't let its release discourage any of you from requesting new features.:)

Now 10 sub-menus are available Fixed the other mod list resizing issue Mod names are now shifted up if sub-menus extend below the list Improved mod list scrolling up/down All better now. I hope... :whistling: I think the problem you were having with the mod list was from using a bit higher of a script processing delay than I was testing with. It now waits for _Reset == 0, then has a 0.1 second period to check and adjust the width, so it'll work with fast and slower scripts just as well. I tried it from 0.01 up to 1 second delay and it worked fine. We'll just have to see if that was the issue, or if there's some other gremlin hiding in there, though.