Antono

Thank you! Although I dread the day when my code will be full of alternate functions, with progressively more complicated names, each one passing along default values to the next like a conveyor belt .

Ouch. Then it's a good thing I've already formatted my header for features I plan to add in the future! Thanks Min.

Hi xaz, Can I make a modder's request? I am trying to get all bindings that a slave was wearing, as they had been registered by zbfSlot. As it is now, since the form array zbfSlot.AllBindings is just a variable, I cannot access it from outside as I need to. There is no function to get it either. So, I have to call GetArmBindings(), GetLegBindings() etc but this only gets me the first 5 slots of the AllBindings array. Or, if I use a while loop to run zbfSlot.GetCurrentBinding() 10 times (let aside the inefficiency of the loop) to reconstruct the array, I will get the current bindings which may or may not be the ones that zbfSlot has registered in AllBindings[]. Could we have a function e.g. Form[] Function zbfSlot.GetAllBindings() that will return the zbfSlot.AllBindings array? Or, could we have this array made into a property so that we can access it? EDIT: GetCurrentBinding() will return the registered bindings first, otherwise it will guess what's on the actor.

Kimy, another thing: To keep things as they were previously, in v1.1.4 I restored the order of the arguments in the OnSerialStripStart() event as it was before (< v1.1.3). I promise I won't change it again, plus starting v1.1.5 it has default values, as I said. But, since you're sending the event directly, the correct order of push should be: ModEvent.PushForm(Handle, a) ModEvent.PushForm(Handle, a) ModEvent.PushBool(Handle, True) ; override and exception lists ModEvent.PushString(Handle, "") ModEvent.PushString(Handle, "") i.e. PushBool() is the 3rd argument.

Hi Slorm, The new version v1.1.4 just restores compatibility with mods that used to work with v1.1.2 but broke in v1.1.3. You don't need to update.

Ah, don't worry about it. But yes, you kept changing that particular function header lots. I think I had to adjust it pretty much every single time you updated SS. *giggles* I had to use functions marked as "internal" to get my integration done, so you probably didn't even know that people would be using your API the way I did. I needed to use the mod events directly instead of using the wrapper function in order to get a notification when the actor is actually done stripping. Otherwise I wouldn't be able to continue my scenes properly. Damn. Sorry about that. As WaxenFigure and CGi suggested, I will add default values for the arguments further down the code, not only in the top funcitons as it is now. If the event SS is listening for (OnSerialStripStart) has defaults, it shouldn't break anymore. In fact, I've already coded it this way in v1.1.5 and I my tests show it's backwards compatible with v1.1.4. In any case, don't hesitate to tell me if I do anything stupid again!

Did you know that when you add new arguments to an existing API call you can specify default values to use for those new arguments which will allow the older mods to keep using the API without needing to be updated? Function APICall(int Parm1, Int Parm2)... Function APICall(int Parm1, Int Parm2, Int Parm3 = 0, String Parm4 = None)... It is in fact a good habit for API calls to provide default values for as many parameters as possible. Yes, this is how this API function has been written, to minimize the risk of it breaking. But you're right! I think I have to provide default values for another level of the interface, the OnSerialStripStart() event that we're listening for. I had only provided defaults for the function that sends the event but obviously this is not enough.

Hi Kimy, I got some feedback today that, although you used to use SerialStrip with your mod, my recent update (v1.1.3) broke the API and it's not working for you anymore. Ooops, sorry about that. I don't have much of experience with API 's so I failed to foresee that my update would break it. Also, I didn't get any reports about any such issues in SerialStrip's thread, so I assumed all was fine. In any case, I just released a new version (v1.1.4) which restores compatibility without you having to edit your code. However, you need to re-compile any of your scripts that are accessing SerialStrip, because it's changed: the function SendSerialStripStartEvent() that starts it all now sends 5 arguments instead of 3 and, consequently, the event that SerialStrip is listening to has changed from 3 to 5 arguments. A re-compilation will allow your scripts to tap into the new function/event. For more info, have a look here. Also, I'd be happy to have a look at your code if you're still having problems with this. (Let's hope I don't break it again next time )

SerialStrip updated to v1.1.4 SerialStripper updated to v1.1.4 It was brought to my attention that my recent updates (probably v1.1.3) broke the API i.e. broke SerialStrip for other mods that depended on it. I apologize for not realizing it earlier but I didn't catch any bug report of that sort in this thread. As far as I can tell, this was due to v1.1.3 adding support for a custom array that determines exactly which slots the modder wants to strip, by-passing the user's preferences. This of course created the need for extra arguments (5 instead of 3) in the SendSerialStripStartEvent() that other mods use to start the stripping cascade, which in effect changed the function and broke the API. I also made the stupid mistake of changing the order of the arguments... I'm afraid I'm not that experienced with keeping an API backwards compatible. I should get better with practice, though! Anyway, v1.1.4 addresses that by restoring the original order of arguments in SendSerialStripStartEvent(). So, if you're a modder and your mod was working fine with SerialStrip v1.1.2 but broke with v1.1.3, then it will work fine with v1.1.4 again with no code edits on your part. However, you have to re-compile your scripts with v1.1.4 so that they use the new SendSerialStripStartEvent(), otherwise your mod will be sending the old Event to the new SerialStrip. You'll know you have this issue if you're getting a "wrong number of arguments, was expecting 5, got 3". Change log: SerialStrip v1.1.4 - Restores initial order of arguments in SendSerialStripStart() for backwards compatibility (API broke in v1.1.3). - Modders: if you used to use this plugin but the API broke for you in v.1.1.3, please re-compile your scripts with this v1.1.4. You shouldn't need to edit your code but a re-compilation is necessary as SerialStrip's code has changed (no of arguments in SendSerialStripStartEvent()). SerialStripper v1.1.4 - Updated to work with SerialStrip v.1.1.4.

Thank you for your kind words. As I've said before, I hadn't expected this little plugin to be liked by so many. I only created it as a tool for another thing. I guess this means CGi's idea (that sparked it) was brilliant. Now, about your issue: I can see that you're using v.1.1.2. I'm about to release v1.1.4, to address an issue with the API not working for mods that use it. Could you remove v1.1.2 and install v1.1.4? Then go into its MCM and turn "debug mode" on, so that it generates debug messages? Then attach a new log here and I'll have a look at it.

Need the promised multi-threaded version for those to use it. Indeed, WaxenFigure is correct. I have to create the multi-threaded version to be really useful for SexLab. Currently, I am too much absorbed in another mod that I'm building... It's gonna happen, because that mod also needs a multi-threaded SerialStrip.

Crashes right after the Bethesda logo are, almost without exception, the result of missing .esp or .esm. Double-check that everything is installed. I am not familiar with the Nexus Mod Manager but, if it works anything like Skyrim Mod Organizer, make sure that your .esp is also activated in the program.

Ah, yes, this update doesn't need a clean save. Nor does it need an uninstall (through the MCM) before the install. An easy update path, for a change. Thanks for the feedback!

OK, in that case, could you activate the "debug" option in SerialStrip's MCM and send me your papyrus log?

Ah, yes, it's happened to me a lot of times while testing this mod: you forgot to run FNIS after installing SerialStrip, didn't you? Since the mod adds new animations, FNIS_for_users has to be run after installing it, otherwise the animations will not play and, consequently, nothing will be stripped. BTW, try the v1.1.3 and see if you can spot any bugs there.