candlepin

Not sure what I'm doing wrong, but I still can't get the perk script to compile without errors. It seems to be stemming from the CK not recognizing the property for the other script: unknown type cp_ingredientswap (I get this error from the "CP_IngredientSwap Property PlayerAlias Auto" line) cp_ingredientswap is not a known user-defined type (I get this error twice, once for each time the SwapInventory() function is called)

If you want to use this value during a battle, for example, why not do this: 1) Use FrankFamily's nice function and store the Max Health value as a global variable. Do this intermittently; perhaps on equipping items, leveling up, or just every so often (or some combination thereof). 2) Instead of calling this function every time you want to get the max health, use the stored global variable. It may not be 100% accurate but it will be faster and, depending upon how often you update the global (#1 above), should be accurate enough for most situations. Just spitballing here..

Unfortunately, I was not able to test this out yet. Due to an unexpected family obligation this weekend, I was unable to work on my mod as much as I was planning to. I did start to implement this though, and ran into a snag. While compiling the player alias script was relatively easy, I ran into issues with the perk fragment script. In particular, I kept getting compilation errors. One of the things the CK didn't seem to like was: CP_IngredientSwap Property PlayerAlias Auto It also didn't like the function. I haven't done much with script fragments, so I have the feeling I might be doing something wrong. Could you perhaps explain in simple terms how this should be implemented (e.g. where exactly do I add the script and when)? A Skyrim scripting/CK use for dummies version? And thanks again for all your help! It really is appreciated!

I don't know about others, but the CK is pretty unstable for me. Always has been. Depending on what I'm doing it might crash every 10-15 minutes or every hour. Rarely can I get more out of it than that. I have found that it does depend on what I'm doing. My only advice would be this: save very often. Like stupid, crazy often. Not only will you lose less work when the CK eventually does crash, but for some unknown reason the CK seems to like this and crashes less often with frequent saves.

Wow. That is incredibly kind of you, foamyesque. :thumbsup: I will look into implementing your script into my mod this weekend (have a big work presentation on Friday). SKSE functionality isn't a problem; other components of my mod require it.

Hmm... random thought. Instead of having the alternative version in a chest somewhere, why not just add it directly to the player's inventory (or remove it) using the same OnItemAdded/OnItemRemoved approach? That way, both versions of the item are always accessible with no delay. The only issue I see with this approach would be the inventory weight. Maybe make one of them weightless? Or update the player's carry weight? I might need to think about this possibility some more.

Interesting. My testing with my first method slowly updated the player's inventory while in the crafting menu without the need to craft anything. I've been looking at this a bit too and here is what I came up with for a function to reset the container inventory: I figured it would be quicker and probably cleaner to clear the container contents and then restock it than to compare the container contents to the player's inventory and then adjust. But maybe I'm wrong about that? So this would go in a script attached to the player via ReferenceAlias. I'm thinking that this function would be called upon OnInit(). Maybe also OnPlayerLoadGame()? Not sure when else. Perhaps after exiting the crafting station menu? And here is what I've come up with so far for adjusting the container contents on the fly: I'd put this in the same script attached to the player via ReferenceAlias. To speed things up, I figure I'll also need to add InventoryEventFilters: This can also be called OnInit() and whenever the global variable is swapped. And finally, here is the actual swap function. That's what I've put together so far. I have to do some more thinking about when to add and remove the InventoryEventFilters, but I think this is a pretty good start.

This belongs in Skyrim - Mod Detectives Threadhttps://forums.nexusmods.com/index.php?/topic/485981-skyrim-mod-detectives-thread/page-789

Yeah, I got this aspect of my mod working a while ago. Unfortunately I was initially only testing with a few items and everything seemed fine so I set it aside while I got other aspects of my mod to work. But recently I went back to update the formlists with all my items and tested the swap effect with pretty poor results; it worked but took way too long. Any thoughts on whether it is worth trying to split my formlists and script into ~20 pieces and run those ~20 scripts off the same magic effect/separate magic effects? I think I read somewhere that someone was recommending limiting scripts to 10 threads. Either way I will also definitely try the method you recommended; making a container that adds and removes the swap version of items as the player adds and removes items from their inventory and then swapping the items when called upon.

For my mod, I want to do the following: 1) Swap upon entering crafting menus, swap back upon leaving crafting menus to allow full utilization of the items. This may or may not be necessary based on the version the items are in upon entering the crafting menu (i.e. ingredient or not). This should be done automatically. 2) Swap whenever the player desires. Again, this is about utilizing the items. Maybe the player would like to eat the food version of a particular item. Or maybe they would like to eat the ingredient version to learn its alchemy effects. This should be triggered by casting a spell. All the swapping events will be governed by a global variable. For the crafting menu swaps, the global will be changed and the items swapped upon entering the menu. When the menu is closed the global will be changed and the swap function will be called again. Since the global has been toggled, the swap will be back to the original version. Do you get what I'm going for now?

It does, but it'll have to do the same thing even if you split it, and because the internal execution of the function isn't frame-linked (but the original calls are), splitting it into multiple form lists would tend to slow things down. I'm honestly surprised you say you saw a speed increase by dividing it in two -- my best guess for the cause there is that two separate RemoveItem calls allows the OnItemAdded events that're firing on the chest more time to complete and reduces the total number of suspended stacks. I'll see about working up some full scripts for you to try out, but the total time required for the RemoveItem(formlist) / RemoveAllItems() shouldn't be more than a second or two. Just to check, though: Do you want to restore the originals or not? Because if you don't this is a much simpler problem. I should have been more explicit in saying that not only did I split the formlist, but I also put them in separate scripts that I attached to a separate magic effects (although I guess I could have attached them to the same magic effect with similar results). I attached both magic effects to the same spell and cast the spell. I assume that it cut the swap time in half since the two scripts were run simultaneously. Thus my comment about poor man's threading; by splitting the scripts and running them simultaneously it's effectively doing the same thing as threading.

"PlayerRef.RemoveItem(ListA, 999, true, SwapContainer)" --> I assume for this to execute the engine goes through each item in ListA, one by one, and transfers up to 999 of that item the SwapContainer. That's what I meant by scrolling through the formlist. And that is where I thought the bottleneck was. I've been waffling back and forth about whether I want to split the formlists into tiny chunks and do the swaps that way. But it seems really tedious and I'm a little worried that if I try to run 40+ scripts from a single spell/magic effect that I may create a singularity in Skyrim and implode my laptop :tongue: But maybe I'm overreacting and the simplicity of these scripts would negate any chances of script-burst catastrophes? I would love to hear if this is a valid concern. Normally I would just try both approaches and see what is better but splitting the lists would be a crap ton of work and I really, really don't want to do all that work, have it fail miserably, and have someone turn around and say it was crazy/stupid to try it in the first place.

Thanks for adding this information. My post wasn't that helpful in hindsight.

Interesting results. Splitting the list in half reduced the swap time by 50%. That was what I was hoping for. That still puts me in a pickle though: Assuming this reduction scales, I'd have to split my list into 45 different lists to get my swap down to 1 second (I'd consider a 1 second swap acceptable). That seems like a lot of tedious work, but I could grab another coffee (or forty) and brute force it if necessary. Or I should I try foamyesque's approach but potentially at the cost of a little (perhaps not noticeable on it's own?) lag here and there. Other than it being a stupid amount of tedious work for myself, is there any downside to the first of those approaches (splitting my list into a ton of smaller lists)? Is there a saturation point where too many scripts running at once, even simple ones, doesn't increase the speed? Or potentially even makes things worse?

Well I tested this approach using a persistent container and it really didn't make any huge improvement on the speed. Maybe it's a second faster? Next on the testing block: 1) Split the script in two scripts and split the swap formlist into 2 formlist sets, each with half the items to swap. See if this improves performance noticeably. 2) Try foamyesque's suggestion of pre-loading the swap chest. This should definitely make the swap faster (it seems scrolling through the formlist is the slow part of what I'm trying to do), but if splitting the script into pieces makes it acceptably fast I might go that way so that there isn't a continuously running script on the player checking every time an item is added or removed from their inventory. But if splitting the formlists doesn't work, this approach seems promising.

Instead of spawned containers, could I use specific placed containers (maybe called via an alias)? Dedicate one container per formlist pair?

No, it is not.

I don't have access to the full script right now, but can post it later. This is how I have things set up: Spell, magic effect, and attached script. This script does the actual switching of ingredients. This can either be done manually (casting the spell) or called in response to opening a crafting station (see below). There really isn't much more to the script than the function, although I can post it later. Quest with optional aliases for crafting stations. Activation of these aliases calls a script in the player alias (via state change). Quest with player alias. Script attached. When state change happens (upon activation of a crafting station), this script calls the swap spell on the player depending upon a global variable check (no need to swap items if they are already in the correct form).

So that could be something like this? script applied to player: PlayerRef.RemoveItem(ListA, 999, true, SwapContainer)script on SwapContainer: Event OnItemAdded(Form akBaseItem, int aiItemCount, ObjectReference akItemReference, ObjectReference akSourceContainer) Int FormNumber ListA.Find(akBaseItem) ItemB = ListB.GetAt(FormNumber) PlayerRef.AddItem(ItemB, aiItemCount, true) SwapContainer.RemoveItem(akBaseItem, aiItemCount, true) EndEvent

I have a script that searches through the player's inventory and swaps out one set of items for another. It works properly but unfortunately is unacceptably slow. Here is the portion of my script that does the swapping: When the player doesn't have many items, this works fine. But if you have a lot of items (say 500+) in your inventory it is unbearably slow. I have a lot of items I'd like to swap (a little over 200) and since I have this swapping triggered when a crafting menu is opened I need it to happen as quickly as possible. In my current testing where I convert all 200+ items it takes approximately 45 seconds, which is obviously too long. Nobody will use my mod if they have to wait that long every time they open a crafting menu. Hell, I wouldn't even use it. I have a few thoughts on how I could make this faster and would really appreciate input (including other suggestions) on how to do this faster. My initial thoughts: 1) Use a brute force approach. Define all 200+ items from ListA and the corresponding 200+ items from ListB. Then use a more targeted search and replace for each item set. Maybe something like this: But, I'm not sure that this would actually be any faster than my original approach. 2) Threading? I don't quite understand the coding, but basically it allows multiple parts of the code to be performed at once. I've read that this is especially helpful in increasing the speed of scripts that use a lot of repetitive latent functions, which my script certainly does. 3) Poor man's threading? Could I achieve similar results to threading by just splitting up my lists and having multiple effects that call scripts that each convert smaller chunks of my original list? For example have Script1 attached to Effect1. Script 1 encodes the conversion of the first 25 items in my original list. Script 2, attached to Effect 2, encodes the conversion of the next 25 items in my original list. Since these are separate scripts, they should be run at the same time and thus achieve the goal faster. Any input would be greatly appreciated!

Beyond RND 2.0 and iNeed, are there any other popular eating/drinking needs mods? I'm making a mod with new food and drinks and would like to make it as compatible as possible. Thanks.

Use both enchantments on the same weapon. Set your enchantment conditions based on a new global variable (very easy). E.g. left hand enchantment condition of global == 0, right hand enchantment only if global == 1. Add both enchantments to the weapon. Then add a script to the weapon that changes the global variable depending on the hand in which it is equipped (global = 0 if left, = 1 if right).

I'm making a mod that adds some new food and drink items to Skyrim and would like to make it compatible with some of the popular needs mods out there. Question 1: Beyond RND 2.0 and iNeed are there any other popular needs mods I should be on the lookout for? Question 2: Does anyone know off hand how an RND 2.0 patch would work? From what I gather, I would need to attach an "eating" script to foods and a "drinking" script to beverages. Is this done directly, or via a scripted Magic Effect? Also, does anyone know if there is a value attached to these scripts (i.e. level of satiety that a particular food would imbue you with)?

I'm looking to make a few new crimes. I'm making a new mod that allows you to harvest body parts from NPCs and I would like to give the option of having it be a crime to do so. I'm having some trouble getting good information on the topic, so I'm here asking for advice. Right now, I'm thinking of making the crime be known via Actor.SendAssaultAlarm(). Since the dead don't speak, I was thinking of checking the area around the corpse when you harvest such items for other NPCs and have them send the alert (hopefully this wouldn't cause them to attack!). When such an NPC is found, I would Actor.GetCrimeFaction() on them to get their crime faction and then Faction.SetCrimeGold() to set the bounty. Does this sound reasonable? Has anyone tried something similar? Any pitfalls I should avoid? Other options I should try? Any feedback would be appreciated!

A few ideas: Addiction with included major withdrawal effects: serious imod effects (blurry, maybe purple tint?) plus effects like possibly random frenzy-like effects. Cure of withdrawal effects requires a special potion. Maybe require a quest to get the recipe for the withdrawal cure.