Oblivion Mod:Cobl/Projects/Alchemical Sorter

Cobl: Old Project Page: This is an old and now inactive discussion article for a Cobl project. If you have questions about this or other Cobl projects, do not edit this page, but instead discuss it at the official forums on Relz topic.

Old Discussion

What about a standard "alchemy sorter" script, that is a script which can remove all ingredients from the character's inventory and put them all in a container, or vice-versa? I think there are some pretty advanced scripts out there that also allow to remove from the container all ingredients with a specific effect. If we have a basic "skeleton" script for that, then the process of automatically updating it with all ingredients wouldn't be much more complicated than the update for the catalog books. (However, the problem is the script would then have to be compiled. This step would be more complicated.) --Gez 16:42, 21 December 2006 (EST)

I actually have never used alchemical sorters. I put all my ingredients in one big cabinet and just pull what I want out of it. Problems with alchemy sorting: 1) If you sort on the basis of effect, which of the (up to four effects) do you sort into? 2) If you sort into separate jars for each type of ingredient, then you need: a) to recompile sorting script(s), b) jars for each ingredient, c) placement of jars into the world. Now, OTOH, if you just had sorting scripts for all standard ingredients, that would probably be a "resource" type thing (doesn't have to be unique, but is convenient). There might be OBSE considerations here too, right? (I'm thinking that alchemy sorting is easier in OBSE.) --Wrye 18:33, 21 December 2006 (EST)

I use only one container, too; the script would simply take all the ingredients from the player's inventory and put them all to the container's own inventory (would be a local script, so that it can be placed on any container). The sorting part only comes if the script is more advanced and allow to retrieve ingredients by effects -- then it would remove from the container the ingredients that have the wanted effect, and add them to the player's inventory. --Gez 06:49, 22 December 2006 (EST)

The first part of this script I've got already, both a vanilla version and an OBSE version that can recognize mod-added ingredients. The second part I don't have but could produce. (kea's portable sorter does this) It would need to check what level your alchemy skill is at and what effect you want to produce and pull out the ingredients on which you can see that effect. --Daleth 18:30, 22 December 2006 (EST)

I do the same as Wrye. I find it easier to store ingredients in one container. I've release a mod that adds (OBSE) scripted containers that can automatically store your ingredients regardless of what mod they come from. It appears to have separate jars, but they're only decorative pieces of the mesh. Kea's still working on doing the same for the portable alchemy container. A mod like these is probably preferable to a unified sorter. --Daleth 18:56, 21 December 2006 (EST)

Daleth, how about taking the lead on this? What specifically would be useful to add to Cob main.esm? (Or maybe to a Cob Resources.esm). Whatever is added should be pretty universally useful (e.g. a standard alchemy sorter that modders can add to their houses). (If there's a way that Bash merge can help, then I'll try to help with that.) Run your implementation past folks either here or on ES Forums. If there's a consensus, I'll add it. --Wrye 23:55, 21 December 2006 (EST)

For alchemy sorting, I actually think it may be best left out or included in the OBSE module. There's no good way that I can think of to create a cross-mod alchemy sorter that does not involve OBSE or a great deal of backwards (and forwards and counter-clockwise) incompatibility. The 3 ways to make sorters are to script the individual ingredients and trigger them by another item, to write a long script with an "If" block for every ingredient, and to use OBSE to determine what objects are ingredients. The first one would be incompatible with many existing mods (some that will never be updated), the second not extensible, and the third requires OBSE. I wouldn't find a vanilla ingredients only script useful considering how many mods add them. In Morrowind I had only a couple of mods that added ingredients, but in Oblvion it's pretty common to add a few. --Daleth 00:54, 22 December 2006 (EST)

For Cob, I see two main possibilities: 1) Provide a non-OBSE if block script that grabs vanilla ingredients from the user and stores them in a single container. 2) Provide one or several standard sorter containers, which would have standard script on it. Modders could then: A) Use these standard containers in their house/wherever mod, B) Create new activators (different mesh) and use the standard script on it, and/or C) Override the default script with a different implementation. The overriding implementation could be an OBSE version of the script, or maybe Bash could build it (the main problem is I would need to make Bash also compile the script which would require, well... more work than I want to do. :) The OBSE version could be in Cob OBSE.esp (needs to be esp because it overrides an esm definition), or it could be in an a non-Cob mod. I would definitely lean against the script on every item approach (at least in Cob) because it changes so many items, and so will conflict with any other change to ingredients.--Wrye 01:21, 22 December 2006 (EST)

I'm also not in favor of scripting each ingredient. Carrying potentially hundreds of tiny scripted objects at once feels like a time bomb. :) I had Access spit out the vanilla "if" blocks for a friend a few weeks back, so I've got that part done, and I've got a working OBSE sorter as well. My storage shelves are already released as a resource and could be used in COB if they were wanted, but the scripts can be attached to any container. I'll work on the second part... sorting by a desired effect... and see wha happens. --Daleth 18:30, 22 December 2006 (EST)

Continued discussion: Because of UESP server difficulties, discussion moved to bethsoft forums. See COBL Alchemical Sorter. However, at this point further discussion should probably continue here.

OBSE Upgrade

Cobl 0.03 included the non-OBSE version of the Alchemical Sorter. Phoenix Amon (aka Daleth) also developed an OBSE version, but was waiting for the release of OBSE 10 before releasing it. That took a while, and during that period, she retired. She should be contacted to see if we can use her OBSE version. If not, it should be built from scratch. --Wrye 22:52, 24 October 2007 (EDT)

Haama 1

I'm working on the OBSE version. The sorter part shouldn't be a problem, but making it work for multiple containers might take a bit more thought. The current setup has a central storage container where ingredients are moved to when the player selects "Store ingredients" and that can be opened. There are two types of multiple containers - individual ingredients and specific effects. Ingredient containers grab the ingredient from the central container when they're activated and opened. However, there is no code to move the ingredients back to the central container afterwards (this can be done, but I'm curious why it was done this way in the first place). The Effects method uses several scripts to move any ingredients with the effect from the central container over to the effect container. Again, there's no code to move the ingredients back after the player has closed the container.

These present some difficulty, as a unique script is needed for each. Each script needs a couple of changes on it which takes time. Also, the effects version would not be very easy to do with the OBSE version.

I propose a slightly different method of dealing with the issue. Require mdders to set up 2 activators/result stages - one to move all of the contents of the multiple containers to a central container, and another to move all the contents from the central container to the multiple containers (they should already have this one for the most part, might need to change 'player' to 'CentralContainer'). Granted, this is still a lot of script work, but they will be simple (essentially 'RemoveAllItems blah'), and will still require fewer lines than the original method. These functions would be used before and after sorting, storing, or whenever necessary.

Would that be a general enough method? I think I would also like to propose the ability to link all of the central containers (for instance, from different houses) together to reduce player frustration. Still thinking about it though.

--Haama 19:19, 10 November 2007 (EST)

Before we go to a lot of trouble to support the separate containers approach, I suggest that we wait to see if anyone actually wants to use it. (I'm particularly dubious of having separate-ingredient-containers -- it's just a total pain in the butt given the ever increasing number of ingredients.)

Various Notes:

• I assume that you're familiar with this discussion. OBSE scripts should neither add nor remove variables to existing scripts.
• The editors ids for alchemical sorter objects changed in last release to start with cobAls.
• If there really is a need to produce multiple scripts with minor changes between them, I can do that relatively easily with Bash/bish. But again, I think that we should avoid doing this until support for such containers is clearly desired.

--Wrye 13:46, 12 November 2007 (EST)

wrt Multiple Containers: I like not worrying - that will work just fine.

wrt Overriding: Yes, I know enough to get me by. PhoenixAmon set it up so it's easy to modify. There's a trigger script that calls other scripts to do the real work. I'll modify it to start up different scripts - problem avoided.

wrt EditorIDs: Noted. I'm only looking at the latest release, actually. (Should I be aware of previous releases?)

wrt Bashing scripts: Ah, cool, didn't know that. However, I'm taking a dynamic approach to the problem. This will require waiting for OBSE v13. Would that be acceptable?

--Haama 16:14, 12 November 2007 (EST)

EditorIDs: No, you should not worry about previous releases. (They'll be compatible with your release anyway, since although I changed editor ids, I didn't change any formids.)

Bashing scripts: bish is the command line brother of bash (both built on top of the bosh and bush). If you poke around in bish.py, you'll see some various temporary functions that I've written to create and/or modify records in various ways. I haven't done template scripts yet, but it would be pretty easy.

Waiting until v13: I'd prefer that you used v12. It's been out for a long time and is stable. v13 still has another beta release coming out before the final release. After that, there's likely to be a shakeout period for bugs. But... It's up to you. Use your best judgement.

--Wrye 18:47, 12 November 2007 (EST)

I was going to create the functions myself, but upon looking at the source code... well, my brain melted a little (knowledge of C != knowledge of C++). Anyway, I need to ask 2 questions now:

1. What was that about the Bish stuff again? It will be pretty simple - there are some tokens that PA made that don't have a script (i.e., cobAlsTokAbsorbAcrobatics) that need a script. The script should be a copy of the tokens that do have a script - i.e., cobAlsTokBurden and the script

scn cobAlsTokBurdenOS

Begin OnAdd player
    set cobAlsSorter1.iBurden to 1
    set cobAlsCounterVars.iBurden to 0
    RemoveMe
    Return
End

but the scriptname needs to be the same name as the token with an OS tacked on, point to cobAlsSorter5.iXXX instead of cobAlsSorter1.iBurden where XXX is the unique name of the token (i.e., AbsorbAcrobatics), and leave out the 'set cobAlsCounterVars.iBurden to 0' line. Ok, so is all that remotely possible?

1. Easier question - I swear that either v1.2 or SI added new magic effects, but I can't find any info on it (no luck on the boards). Anywhere other than the patch release info on UESP or in the read-me that you can think of?

--Haama 21:16, 13 November 2007 (EST)

Not sure if it's what you're looking for, but did you check out Shivering:Magic. Or maybe this: Shivering:Ingredients. --GuildKnight (Talk) ^contribs 22:06, 13 November 2007 (EST)

New effects. I can find that out pretty easily. (There are least a bunch of new summons.) I'll have to add tokens to support the new effects, and add scripts for tokens that don't have effects. And add variables to handle new effects. I'm working on it. --Wrye 00:07, 14 November 2007 (EST)

---

Thanks - hopefully there aren't that many (and for the non-OBSE sorter I don't know that it will be an issue - can they be turned into a potion in vanilla Oblivion?).

wrt Multiple Containers: While I'm thinking of it - When it's released there should be a note that following PhoenixAmon's suggested code for Separate Containers by Effect will use the original sorter, not the OBSE one. I could overwrite the original with the OBSE one, but that would require one of two things: Add at least one variable (I need a reference, no way around it), or create and use a unique activator for each and every effect.

--Haama 00:26, 14 November 2007 (EST)

---

New Effects:

BW01 Bound Order Weapon 1
BW02 Bound Order Weapon 2
BW03 Bound Order Weapon 3
BW04 Bound Order Weapon 4
BW05 Bound Order Weapon 5
BW06 Bound Order Weapon 6
BW07 Summon Staff of Sheogorath
BW08 Bound Priest Dagger
Z006 Summon Gluttonous Hunger
Z007 Summon Ravenous Hunger
Z008 Summon Voracious Hunger
Z009 Summon Dark Seducer
Z010 Summon Golden Saint
Z011 Wabba Summon
Z012 Summon Decrepit Shambles
Z013 Summon Shambles
Z014 Summon Replete Shambles
Z015 Summon Hunger
Z016 Summon Mangled Flesh Atronach
Z017 Summon Torn Flesh Atronach
Z018 Summon Stitched Flesh Atronach
Z019 Summon Sewn Flesh Atronach

Looking over effects (old and new), it seems that PA defined tokens for all (or at least most) vanilla effects. However, the sorter scripts only have variabled defined for vanilla effects that are actually used by vanilla ingredients. --Wrye 00:31, 14 November 2007 (EST)

About half of those are special purpose, so I'm leaving them out. I've added in just the usable summons. And am reminded about PA's other strength modelling/textures -- each of her tokens has their own icon. Studette! Not a lot of people are good on both modelling and coding. Anyway... She had 43 effects scripted. The other 156 are new. In some ways, she has already coded these in (esp in the counter handling stuff -- but not for the new SI stuff, of course). I think that I'll add a new quest/quest script to hold all the new variables for the sorter (cobAlsSorterVarsQS).

But, I'm trying to keep more regular hours. So it will have to wait until tomorrow. --Wrye 01:46, 14 November 2007 (EST)

I can write up the extra sorting quest scripts. I need to set up the spacing for each anyway. I can figure out which ones are from the original Oblivion, but which effects from Shivering Isles would go in, exactly? (I've had it for months and never did play it) --Haama 09:21, 14 November 2007 (EST)

Download this: Cobl 1.11.zip. This doesn't have any of the resources -- just the mod and doc files, so just install it over previous installation. It includes the new tokens, the new cobAlsSorter quest and now includes scripts for all tokens. As I mentioned, I left off a few magic effects that should not be used. So, the new SI tokens are:

SummonFleshMangled
SummonFleshSewn
SummonFleshStitched
SummonFleshTorn
SummonHunger
SummonHungerGluttonous
SummonHungerRavenous
SummonHungerVoracious
SummonSaint
SummonSeducer
SummonShambles
SummonShamblesDecrepit
SummonShamblesReplete

Again, I've left some of the "internal" effects off. However, PA included a few such effects that probably should not be included (notably, the SummonMDArmor and SummonMDHelm effect).

BTW, keep in mind that anything that's new to Cobl Main (either a record or a variable in a script) has to be added to the master copy first -- i.e., it has to be added by me to my copy. Otherwise, CTDs are likely. --Wrye 00:21, 15 November 2007 (EST)

Got the file - everything seems to be in order. Should have it ready in a couple of days.--Haama 01:23, 15 November 2007 (EST)

Haama 2

Wrye, I noticed something that should be changed in the COBL.esm - the containers in the cobAlsCell are set to None for Ownership. To prevent NPCs from calling the player a thief, they should be set to Player.

Testing is going a bit slowly, but it is going. A few more days and it'll be ready (basics are working, just a lot of copy/paste/minor edits and making sure there aren't any typos).--Haama 14:24, 18 November 2007 (EST)

I thought that the cell was public. But, I'll double check when I get a chance. --Wrye 15:57, 18 November 2007 (EST)

Alright, done with the testing. Couple of minor things while I'm thinking about them (because I won't over the next few days ;):

• Checked the cell, it's not public and the owner of the cell is set to None as well. (Either way, did you mean the owner of the cell or the public area flag - would be good to know)
• I can inject the OBSE sorting in one of two places:
  • The Sorting scripts (and trigger script) - All mods that use the COBL sorter will use the OBSE version. This will probably include mods that modify/copy the Trigger script for their own use (as the Sorting scripts are at a deeper level).
  • The Trigger script - If anyone ever sets up a multiple effect container add-on, those containers can't/won't use the OBSE version. Then again, this allows the modder to know exactly what the container will do as it will continue to use the original/their scripts.
• The list of magic effects that won't be sorted: Bound Armor 1-10, Bound Weapon 1-10, Darkness, Disease Info, Dummy, Fortify Magicka Multiplier, Lock, Poison, Reanimate, Resist Water Damage, Script Effect, Summon Rufio's Ghost, Summon Ancestor Guardian, Summon Flesh Guardian, Wabba Summon, Extra Summon, Sun Damage
• How am I releasing this? I suppose I'll release it on my own?
• I have been unable to test this with an non-SI Oblivion.esm, mainly because I have a 1.2 Oblivion.esm instead of 1.1. Looking through the bosh.py code

    def setOblivionVersion(self,newVersion):
        """Swaps Oblivion.esm to to specified version."""
        #--Old info
        baseName = Path('Oblivion.esm')
        newSize = self.voSizeByVersion[newVersion]
        oldSize = self.data[baseName].size
        if newSize == oldSize: return
        if oldSize not in self.voVersionBySize: 
            raise StateError(_("Can't match current Oblivion.esm to known version."))
        oldName = Path('Oblivion_'+self.voVersionBySize[oldSize]+'.esm')
        if self.dir.join(oldName).exists(): 
            raise StateError(_("Can't swap: %s already exists.") % (oldName,))
        newName = Path('Oblivion_'+newVersion+'.esm')
        if not self.dir.join(newName).exists(): 
            raise StateError(_("Can't swap: %s doesn't exist.") % (newName,))
        #--Rename
        baseTime = self.data[baseName].mtime
        newTime  = self.data[newName].mtime
        basePath,newPath,oldPath = [self.dir.join(name) for name in (baseName,newName,oldName)]
        basePath.rename(oldPath)
        newPath.rename(basePath)
        #--Reset mtimes
        basePath.setmtime(baseTime)
        oldPath.setmtime(newTime)
        self.mtimes[oldName] = newTime
        self.voCurrent = newVersion
        #if oldName in self.data: self.data[oldName].mtime = oldPath.getmtime()

if I comment out the

        if oldSize not in self.voVersionBySize: 
            raise StateError(_("Can't match current Oblivion.esm to known version."))

lines I should be able to use any version, correct? That is, those are the lines that check the size of the Oblivion.esm file?

• Happy Thanksgiving everyone (and November 22nd to everyone else)!--Haama 11:12, 21 November 2007 (EST)

Sounds like the ownership isn't a problem (owner == None means no ownership). I pretty much figured that if there were a problem with ownership it would have shown up immediately in testing.

Design goal is that it will replace behavior for all regular alchemical sorters. (So sorting/triggers, sounds right.)

Release will be in regular Cobl distro. But feel free to do beta and/temp releases (it would be very useful to have some extended playtesting before it goes into Bash distro). The plan is to have a "Cobl OBSE.esp" which overrides select portions of Cobl Main.esm. So your modified scripts would be part of that (or more accurately, ALL of it until some other OBSE overrides are added).

Bash: Just manually swap the Oblivion.esm file around if you need to. The acutal core of bash's swapping feature is that it just renames the files. However, I don't know that will help you -- Oblivion.esm 1.1 and 1.2 are actually the same (at least in US english versions). Anyway, just do a manual swap and it will do the job.

--Wrye 00:03, 2 December 2007 (EST)

In my experience 'None' Ownership will make people call you a thief, but I haven't tried it with the Alchemical Sorter yet. I'll get back on that one.

Oblivion.esm - doh! Thought there'd be some difference between the .exe files. Thanks for the heads-up.

Part of the distro - that makes a bit more sense now. I'll keep my eye peeled on the official COBL v1.11 and release a beta shortly afterwards. So far, just need to add the Shivering Isles effects and it will be ready. I'll play with it a bit to see if I can't, somehow, combine the non-SI and SI version into the same plug-in (for that matter, I should be able to make the OBSE sorter part of COBL without the need for a separate .esp - however it requires waiting a frame so not all of the other COBL scripts may be able to do the same... that and I just thought of it so I still need to test it).

--Haama 00:18, 2 December 2007 (EST)

Oblivion.exe differs between 1.1 and 1.2 (I think), but Oblivion.esm does not. --Wrye 00:58, 2 December 2007 (EST)

Did some tests:

You aren't called a thief when you take items from containers in the Alchemy cell, so no need to change the Ownership data.

Standard .esp works with and without SI. As of now, these are broken into two files: one for SI and the other without.

I've been able to produce Test scripts that check whether the player has SI and/or OBSE installed. Essentially, this means that the mod can be directly incorporated into COBL.esm, without need of a separate .esp file. If this is the way to go, let me know so I can send it to you (and I guess I would create an .esp and the changes could be merged into COBL.esm with Gecko?).

--Haama 22:02, 2 December 2007 (EST)

Policy rule: Cobl.esm does not require OBSE. That's why all OBSE upgrades will go into a separate (optional) esp. However... If the override doesn't introduce any new formid's then it will be mergeable into a Bashed Patch, so it won't soak up an extra slot.

So go ahead and send the esp. (I'll PM the email to you.) Ohhh... And cool that it works correctly whether OBSE is installed or not! That makes things nicely simpler. --Wrye 23:39, 2 December 2007 (EST)

Completed

Pending some final review this has been accepted and will be included in an upcoming release of COBL. --Wrye 18:18, 10 January 2008 (EST)

OBSE sorter added in version 1.16. See Modding/Alchemical Sorter. --Wrye 22:13, 18 January 2008 (EST)