kryptopyr

Ironwood Tree. Generally, I've wanted to avoid adding anything as large as a new tree in CACO, but there are two reasons that I felt the Ironwood Trees were needed. First, Ironwood Nuts are an ingredient from Oblivion, and in that game it was explained that Ironwood Trees are native to Skyrim. I always felt that it was an oversight that the trees weren't actually included anywhere in Skyrim. Second, I really wanted to add at least one type of nut to the game (where do they get the nuts to make those honey-nut treats!). The Ironwood Trees seemed to fill both gaps. I'll take another look at the leaf texture. I certainly don't remember it looking cartoon green, but I'm pretty sure I didn't have SFO installed when I was working on the trees, so perhaps some color adjustment is in order. However, I don't know how to create a LODGen file, so would anyone be willing to help me with that?

As a kid we had several games on the family computer. They all came on floppy disks, and while I don't remember their names, my favorite was one that involved horse racing. My brother ended up with a Sega at one point so I played that occasionally, but I've always tended more toward computer games. Command & Conquer and Myst are the ones I remember specifically, and I enjoyed playing both of them a great deal. I don't really feel that they were ever a significant part of my childhood, though. I spent a lot more time with physical toys (Legos mostly) and books. I probably hadn't even glanced at a computer game or console game in 12+ years by the time I met the guy who would become my husband. I remember talking to him on the phone early in our relationship and he was trying to describe Oblivion to me and the concept of mods. I thought it sounded rather strange that other random users were creating content that was getting added to this computer game he was playing. I started playing Oblivion shortly after that and got hooked. Then after a while, I started playing around with the construction set and from that point on, all was lost. I spent months working on this massive castle mod (basically a highly modified version of the Griffin fortress). I think I was still working on that castle when Skyrim came out. My husband likes computer games quite a bit, so I've now had exposure to a number of different games over the past several years, but I don't play as much or often as he does. Though I might play more if modding didn't dominate so much of my spare time. I suspect that I'll probably always consider myself a modder first and a gamer second.

Here's the update: https://www.nexusmods.com/skyrim/mods/74045/? Almost everything is enabled by default. Like before, the Treasure Loot and Dawnguard Cache markers are still disabled by default (and have to be enabled via the old setup guides). The Gem Geodes, however, have been changed so that they are now enabled by default (this just made it easier to set up the MCM options consistently). The Flagon shortcut is now disabled by default. The initial map marker and compass presets that come with the new file are my personal preferences and the settings I generally like to use. The compass settings in particular, I find useful. As mentioned previously, I also like to disable most of the city markers and the POI markers to avoid excess clutter on the map. Obviously, you guys are more than welcome to provide different STEP-recommended presets if this mod is ever added to the guide.

Yep, I've added USLEEP support. I'm hoping to get the updated file finished and released this weekend, but I have a few more things I need to do yet so no guarantees. Question: the Legendary file changes the map icon used for Mines from the vanilla "pickaxe and hammer" to a "mine cart" icon that was added by one of the DLCs (but wasn't used anywhere). This mine cart icon is actually named "smelter" so I was considering changing the mod so that this icon represents only mines that have smelters nearby, while any other mines would use the default pickaxe icon. This would make the difference in the icons useful to players trying to locate smelters. On the other hand, using the mine cart for all mines is more consistent and distinguishes the mines from the blacksmith shops (which Atlas marks using the pickaxe icon). Anyone have any thoughts or opinions on this?

I just noticed that Kronixx recently updated the permissions for Atlas Map Markers to allow for modifications and updates to the mod. It looks like it might be time for me to finish up the MCM.

Another option, if this is something that really bothers you, is to turn off the option to rename the player-made potions. This will remove the issue altogether since it's the renaming script that introduces the issue. If you're interested (I know how much people around here love the technical details ;) ), the reason for the non-stacking potions is that the script that renames the player-made potions renames the individual references, not the base potion: using SetDisplayName() instead of SetName(). This allows the new names to persist when you save and reload your game. Unfortunately, it also means that the game initially treats each reference as a separate item. Originally, I was using SetName() which renames the base potion and allows the potions to immediately stack in the inventory. Unfortunately, that change does not persist across saves, and would require a tedious and resource-intensive maintenance script to run each and every time the player loads their game. It's a lesser-of-two-evils type of situation. I've tried a few work-arounds to force the game to stack the potions without reloading, but so far everything I've tried has been unsuccessful.

When I released SSR with the All Access perk, I expected that I would get some complaints about broken quests, even with the warnings I've provided in the description (as we know, most users don't bother with mod descriptions). Surprisingly, though, I've never received a single bug report or comment about SSR causing any broken quests. I've even personally tried to use the All Access perk to break a number of quests, and I've never managed to do it. Of course, I'm not trying to argue that it isn't possible; I still see this as a risk when using All Access, since the game is not designed around the player having this ability. However, I don't think you'd see a sudden flood of issues in the forums here, since I've never seen anything like that on the mod page. If STEP wanted to recommend the Full Version, there's actually an alternative to the All Access ability already built into the mod. You can either recommend the following changes or include them in the STEP extended patch: in the console enter: set AllAccessOff to 1 This will remove the All Access option and convert the All Access perk into a once-a-day power that will allow you to automatically open any Master lock (or lower). However, the perk name and description will remain the same. If STEP decides to include SSR and wants to use the Full Version minus the All Access perk, I could also put together a simple patch that would make the same change mentioned above (it's just a quick change to a global value), as well as editing the perk description to match this alternative version.

If you are using WAF, then stick with the WAF keywords. Do not combine them! All of these WAF keywords are correct and intentional.

I've never seen this problem with CCOR or had it reported by anyone else. CCOR only protects favorite items while at the Smelter, and shouldn't have any effect on them outside of that specific crafting menu. For example, it won't protect favorite items from being sold or dropped. It does this simply by adding a copy of the item to a hidden chest, so it really shouldn't have any effect whatsoever on the actual item in your inventory, the favorite tag, the item's equipped state, or any quest flags. Still, I'll review the script this evening and see if I can spot anything that could potentially be conflicting or interfering with another mod and causing this sort of behavior. If there are any more details you could provide, it might help narrow the problem down. Is there any pattern to the times and/or situations in which this problem occurs? Are you just favoriting the item or adding it to SkyUI's favorite groups? Does the problem happen with vanilla items or specific mod-added items?

Most of the factions used by NARC overlap with the ones I've covered in SSR. I think NARC adds all the individual creature and animal factions (Wolf Faction, Dragon Faction, etc), but all the actors in those factions are also part of the Predator, Prey, or Creature Faction and are, therefore, already covered by the changes SSR makes to those factions.

Yes, I'd be happy to upload a STEP preset to my mod page, or you can add it to the STEP page. I think it might be easier to add it to the STEP page, since that would make it slightly easier for STEP to update the settings in the future (should that become necessary for whatever reason). However, that's up to you guys; I'm fine with either option.

It's not particularly hard to implement, certainly no more so than creating an MCM. However, I feel like there isn't a great deal of documentation on it, and the first time I added FISS support, it did take me awhile to figure everything out. Once you have it figured out, it's relatively simple. Even so, I think I only have it on a few of my mods. It's just another thing that takes some time to do, and it generally ends up as lower priority than adding new game play features. I'm slowly trying to get it added to all my mods as I update (the new Disparity update includes fairly extensive use of FISS).

Here you go: https://forum.step-project.com/topic/1453-waterbreathing-breathless-emerge-by-alek/

https://www.nexusmods.com/skyrim/mods/72556/? This is a recently released mod that supposedly provides a partial fix to the inaccurate enchantment values. I've never done much enchanting, so I'm not really familiar with the bug described, but it looked interesting so I figured I'd make a topic for it. I wanted to at least bring this mod to the attention of others who might know more about this particular issue. STEP already includes Enchantment Reload Fix by egocarib, which isn't compatible with this mod, but is a very well regarded mod. One of the reasons that I found this new mod interesting is that it takes a very different, almost opposite, approach to addressing the same general bug. This is my understanding of the bug: When enchanting, as your enchantment skills increases and your enchantments become better and stronger, the value of the items you enchant actually decreases. Reloading the game changes the values to something other than their initially created value, at higher levels this causes a significant decrease in the value of enchanted items. The number of charges also changes after reloading. This is my understanding of the differences between the two mods: - Enchantment Reload Fix by egocarib: forces the game to reload enchanted items with the same value and number of charges as they had when first created. This has the benefit of complete consistency with what you're seeing in the game. The fix is also very well designed and doesn't modify any vanilla records. The only potential downside to this mod would be if those initial values are in themselves bugged, which happens to be what this new mod attempts to address... - Enchantment Value Fix by DrizztTheDrow: This mod assumes that the values displayed in the enchanting menu are the broken values and the modified values that are recalculated when the game reloads are in fact the correct values. It uses a sort of weird work-around to force the game to recalculate the enchantment values immediately rather than waiting until after a reload. The downsides of this mod are that the values shown in the enchanting menu will not match the actual value of the item, and I don't think this mod does anything to address the change in number of charges. It also has the standard compatibility concerns that come from editing vanilla records. If the values of player-made enchantments are indeed decreasing as the enchantment becomes stronger, then I tend to agree with Drizzt and see that as a bug. The correct value could probably be confirmed by looking at the auto-calculated value that the game assigns to generic enchanted items and comparing it with the value assigned to a player-enchanted item of the same strength. I like Egocarib's fix, but I also think that stronger enchantments should be more valuable than weak ones.

Shurah, I don't think any of those modders are trying to insult you. The way I read their comments, it simply sounds like they are very frustrated. Many people are interested in your mod and the work you've done. They like what they see and want to use it. However, when a great mod conflicts with a bunch of other great mods, people are naturally going to want to find a way to use them together. The reason that these people are spending hours and hours of their time trying to decipher your work in order to make patches for it is because they like your mod and they really want to use it. That's a compliment to you and what you've created. They just sound frustrated at the lack of specific information to help guide them in making those compatibility patches. I may be wrong since I've not dealt directly with any patches for ICAIO, but I feel like this is the sort of specific information that could be useful in improving the compatibility with other mods: This sort of list, no matter how brief, is infinitely more helpful than just stating that you saw a lot of bugs. This gives people an example of what to look for when making/improving compatibility. I know people have stated there's a language barrier, so I urge you to give these modders the benefit of the doubt and not judge their intentions so harshly. The best way to learn more about modding is by sharing information. This goes both ways. The Wiki is not always 100% correct and even the most knowledgeable mod authors tend to have areas of expertise and areas where they still have more to learn. No one knows everything about how the game works (probably not even any single individual at Bethesda). We're all just trying to figure things out as we go, while trying to make the game better and having fun.

The leveled list in question here is added by CRF, so the only changes that would get "bashed" would be possible changes from a patch designed for CRF. Removing the second cuirass from the CRF leveled list would not be the best way to fix this unless you want to remove the sleeved version entirely. A bashed patch won't combine edits to outfit records, so a file editing the outfit will win or lose based simply on load order. I agree that reporting this to Arthmoor would be best.

Ralof uses the MQ101StormcloakPrisonerOutfit [OTFT:000FE535], which is changed by CRF to use a leveled list (CRFArmorStormcloakCuirass [LVLI:0302D151]) in place of the regular ArmorStormcloakCuirass item. The CRFArmorStormcloakCuirass leveled list includes two items: ArmorStormcloakCuirass [ARMO:000A6D7B] and ArmorStormcloakCuirassSleeves [ARMO:000AD5A0]. This means that with CRF installed there will be a 50% chance that Ralof will be wearing the version with sleeves instead of the regular stormcloak cuirass. I am looking at just CRF, though. I did not compare the records on a full STEP install, so I'm not sure whether STEP is using another mod that might overwrite this change and therefore explain why Tech and Shariss haven't seen the sleeved version (other than perhaps they've just been extremely lucky?).

What 2-3 mods already make these exact changes? I have my own personal movement speed mod that I use, and before I created it, I compared a number of the available movement speed mods. None of the ones I looked at made the exact same changes, and I doubt that this one is exactly the same as any of those. The balance and feel is different among them, so they can hardly be called the same, and different ones will suit different players' preferences.

I think that recipe is probably from Campfire. It's not from CCO. Chesko has a few recipes like that which are intended to use DLC items (Vale hides, I think) to make Fur Plate. I'm guessing that in the rush to release the update, these didn't get hooked up correctly with the script that's suppose to change them.

No, I think the conflicts are okay. If I remember right, the USKP actually copied some of the changes from Timing is Everything several versions ago, but the placement of the conditions is slightly different so it shows up as a conflict.

Tech, it's not the responsibility of those mod authors to make patches either. They are under no obligation to do so and have probably already put hundreds, if not thousands, of hours into their respective mods. Let's not dismiss the significant amount of effort that those authors have already contributed to their mods for the sake of users. It's not always possible for a mod author to realize their vision and intention for a mod while also maintaining compatibility with other mods, or sometimes it's just simply not a priority for them. That is their right and prerogative. They have no responsibility to ensure their mods are inherently compatible with other mods. If two mods are not compatible with one another, then users must simply decide which one to use. Shurah, I agree wholeheartedly with your decision. It isn't your responsibility to create compatibility patches for other mods. As you said, other modders will almost certainly come along and create new city/village overhauls that are designed with your mod in mind, or the older mods will be adapted (like the new Lite version of JK's Cities). Personally, I'm really hoping that you'll decide to focus your efforts on expanding the amazing AI in your mod to the NPCs in other cities and towns. You've done an incredible job, and I wish you the best of luck with your project.

Wet & Cold has already been updated for CCO compatibility (back in version 2.0), so no issues there. CCO 1.7 will probably be released tomorrow.

Is Jaxonz Positioner needed in order to take full advantage of this mod?

Yeah, I just saw your comment on the mod page. I'll move your comment to the bug posts, even though it's really more just a different type of compatibility issue, and I'll see what I can do to address those issue. Please report any additional mesh/texture issues that you encounter. The bug reports are a really handy way for me to keep track of what things I need to look, so that's the best place to list stuff like this.

That's correct. Unless I've missed something, there shouldn't be any reason to use Clams Drop Pearls with CACO.