Indeed, I think with a small combination of Ref Replacer user, NoM_Data.ESM Ingredient Integration, and Mild ESP Patch use we should be able to cover all area rather well for this area, and honestly think this is probably pretty well squared away in concept.


The more I see from this area, the happier I think I will be. If nothing else, if we can get a list of things that should not be included for whatever reason in NoM, or any lore they have worked up around any of their new foods and such would be great.


Little to say here as well, since I am not too worried about how much work I have to put into this either, and I am sure that on a technical standpoint, the route we take will be simplest.

Your license is intended to promote incorporation and adaptation of Necessities of Morrowind. The permissions of Morrowind Crafting really aren't all that different, since my only restriction is that the intellectual properties of MC are used in a manner intended to improve (adaptation) or coexist (incorporation) with Morrowind Crafting. My concern is that I would prefer that someone doesn't take all my hard work and effort to create a new crafting mod intended to compete with (and obsolete) my own, or plagiarize it (which, sadly, the internet community seems to see very little problem with) for completely unrelated mods. Originally, I did use Max's Complete Morrowind. It was a HIGHLY modified version of it, but at its core, it was still Max's work. When I finally decided that it wanted to release a crafting mod, instead of releasing his work with my modifications, I dumped it all and started over from scratch... not out of contempt for the original work, but out of respect for it and a belief that using someone else's efforts to compete with them is inappropriate - a viewpoint which it seems is hardly universal. The permissions that I've granted for MC reflect how I treat other modders and how I prefer to be treated.

So personally, I prefer to keep my permissions where they are. However, I've discussed the matter with Drac and we'll offer this compromise: Those portions of Morrowind Crafting which aren't applicable to Necessities of Morrowind will remain under the original permission. Any materials originally from Morrowind Crafting which are released in conjunction with NoM 3.0 will be subject to YOUR license restrictions.

That's great! Thank you

Ummm... What?!? Nevermind, it's not important. Suffice it to say taht I feel a degree of simplicity needs to be maintained, and in the interest of that, I think we should carefully ecamine what elements comprise a true improvement rather than a needless complication.

Like adding qualities of foods, or cliff racer meat thigh vs briast... that sort of thing. Does the added realism outweigh complications?

Re: Licensing


Very, very much appreciated, Toccatta (and Drac, if you are reading here as well). We'll work to come up with a license/statement of permissions that expresses both the concerns of open modding and of courtesy and respect for the time and labor of those whose work creates so much of the underlying value of the mod.

Re: Overcomplexity


(What I meant in that admittedly-obtuse bit of writing is that two or three people have expressed an all-other-things-equal preference to retain elements of NoM's current configurability that we have proposed abandoning.)

There are a lot of moving parts in discussion here, and a generalized expression of concern for overcomplexity is a bit too vague to be very constructive in itself, so specificity is very helpful here.

But yes, what you say here is in line with the more conservative sentiments contained in the consensus we've reached on those aspects (and in general).

For example, we already decided against superior and inferior versions of individual foods as a general rule, though there might be general categories of failed cooking and a short list of what we might call, in the parlance of other games, "prestige foods" that grant small temporary boons, that will have a marginally-successful counterpart. (Say, a "Cliff Racer Kiev" sort of thing, that would produce either another normal dish or some failed version if the cooking roll is failed.) This is still conceptual, and, like other issues, it will be subjected to consideration here for consensus as to overall acceptance or rejection once we have more concrete concept-examples worked up.

In regard to different cuts of meat, that question -- the balance between added value and increased complications -- is exactly the question in discussion. And that question involves a number of concerns that easily outweigh a few technical complexities that would not likely be passed on to modders trying to make their mods NoM-compatible. (For example, no one is going to be changing existing cooking scripts, so why would the implementation of two different kinds of this or that Ingredient in the cooking scripts make any difference at that level? If anyone chooses to make their own custom cooking recipe scripts for their mod, they need only examine, copy over and adjust relevant portions in the base scripts. In the end, if it only involves a bit of extra work that would not likely be passed on to NoM-compatible modders in terms of additional complexity, is it really that much of an additional cost, especially when weighed against other considerations expressed?)


EDIT: The usual corrections that could easily have been prevented with a quick preview.

If there's any potential for animosty over one item's art being used instead of another, I'd suggest including "alternate" graphics in a seperate folder, so you could overwrite the "default" icons or textures with ones from the other "included" mods, at your leisure. That way, there would be one form of Cliffracer meat, but whether you see the white "tastes like chicken" cut or the yellow "nasty flying lizardmeat" fillet would be up to you. That way, everyone who wants their mod's artwork included is accommodated, yet you only have one "in game".

Unrelated products from the same source: Racer Plumes and Racer Meat, for instance, or Guar Meat and Guar Hides would still be needed, where one mod uses the one item for alchemical and crafting purposes, and NoM uses the other as a food source. I still find it bizarre that a full-grown Guar only supplies enough meat for one meal at most, where a herder spends a year or more raising them for just that and a small square of hide.

Toccatta has been very reasonable with permissions so far: he was willing to let me tack on a rather impromptu small addition to MC without calling in the Ordinators. His participation on this, even if only as a "consultant", bodes well for the project.

TR is a "de facto" standard, whether we like it or not, and anything "we" do will need to take that into account (read that as "you" do, because you probably wouldn't want "me" mucking around with otherwise working code, unless you're really desperate). On the other hand, TR has also shown a tendency to change "everything" on short or no notice (witness their revised BSA file with drastically altered contents between the Map1 and Map2 releases), so anything NoM 3.0 does needs to be kept independent from TR and patched for compatibility as needed, with occasional patch updates based on their changes and additions.

I wouldn't say that the overall concensus is for a "reduced footprint" for NoM, rather for a "less obtrusive" footprint. The foodstations and food vendor tables were excellent at the time when NoM was first introduced, but have become "conspicuously out of place" as the overall quality of mods has progressed. Updating them cures the symptom; removing them and integrating their functions in other ways solves the underlying cause. The functionality is still there, either way, but the latter method is not as blatantly visible.

Yeah, the tiny amounts of meat provided by large animals is unrealistic, to say the least.

I tried raising the amount in a mod once, and things became somewhat unbalanced, but I think if the meat is not used as an ingredient it could be altered to something reasonable.

Re: How to Integrate Variant Meats



You know, though, if we do go with the "Choice Cuts" method, we may end up keeping your nomenclature, there.

Using only one object definition, but including the variant art resources, is definitely one of the options on the short-list.

Re: Other Animal Parts and Amount of Meat Yielded Per Animal


Good points, for sure -- I'd definitely like to incorporate those things as well.



On the amounts of ingredients yielded, I can't imagine it's universally-appealing enough to include in the main ESP/ESM, but I could include an add-on that modifies the leveled lists to make wildlife produce more meat (basically, my Creature Loot Mod, updated and revised). We just need to implement it in a way that respects both (1) the original alchemical-essence methodology conducive to game balance for alchemy, and (2) the additional functionality we add for non-alchemical substances. (Again, basically making sure not to cheapen alchemy by keeping the Ingredients worthless or very humble for alchemical purposes.)

Re: Incorporation of TR Elements


Good points. That sort of thing could be chalked up to developmental bell-curve (changes being less sweeping and fundamental as the project matures), but yeah, I definitely agree on keeping it independently functional and updated.

Re: NoM "Footprint"


Good point. I should clarify that, by "footprint," I mean it here in the literal sense taking up space in the gameworld, rather than in the other sense of overall pervasiveness/presence. Pervasiveness-wise, it's pretty clear the mod as currently conceived will definitely have a "larger" footprint than before. So your qualification better rounds off my earlier statement.

Havn't said much in here lately. But I remembered something someone said in the last thread about a gender variable added by the MCP?

Perhaps it was just not listed in the readme, but I can't seem to find when it was added. I know MWSE has a gender variable, but does the Morrowind Code Patch?

Also, about over-complication. As long as we decide to use a basic and advanced setup option I don't there should be too many issues gameplay-wise. Putting it all together shouldn't be too much of a problem if the mod is done by a group of people. Though, I may be thinking too positively.

Low-res vs. hi-res and Alt. artwork
I love the idea of including a low-res pack and a hi-res pack. I also love the idea of including alternate icons and the like.

Having just been reminded of a previous little tweak I did for my own games, I thought I'd bring up the subject:

Any chance of adding a fireplace and a cistern or well to each of the old Dunmer Strongholds? I stuck a rain barrel outside Hlormaren and Marandus, and fireplaces inside, so my characters wouldn't have to go all the way back to town for a drink of water or to cook a meal. I'm sure that the Strongholds would have had something better than a rain barrel, though. Any place that's designed to withstand a seige is going to have a secure water source, and some form of cooking is mandatory.

On a somewhat related note... No idea how other people would feel about this, but personally I'd like it if the checks to stop you sleeping or lighting fires in water and in towns and interiors were removed. Reason: they're not at all accurate (eg you can be technically in Ald'Ruhn but really on the other side of the hills, and nobody should notice or care if you slept there), plus they stop you from lighting fires on your own property and in your own fireplace, which is silly (also sleeping on the floor in your own house, which is even sillier - why would anyone bother stopping you from sleeping on your own floor?).

Another gripe (and the other reason I never use the existing sleep scripts): there is NO reason that sleeping on a bedroll should be less adequate in general than sleeping in a bed. The Ashlanders do it all their lives, and they don't seem to suffer from sleep deprivation, which makes it internally inconsistent. And it's not even remotely realistic for the player - unless you assume for some reason that Imperial prisons (and prison ships) have luxury accommodation for prisoners and that every player character was a well-to-do city dweller in their former life (in which case it might take a while to get used to sleeping on a bedroll but would still not lead to serious sleep deprivation for most people).

Being able to light a fire in a stronghold brazier would also be nice.

Not sure what you referring to here, I use the bedroll very often with NoM, and you only ever have to sleep 6 hours - regardless of what item is used (bed or bedroll). Obviously, one of these is needed for sleep effects, so just using the rest option does not work, but other than that there is no difference in what is used.

How strange... I was sure beds were required. Maybe it changed over different versions of NoM and I didn't notice? Or maybe I'm just confused

Sorry, nevermind that then!

Re: Fireplaces/Water Sources in Old Dunmer Strongholds


That makes a lot of sense to me. As far as I'm concerned, that's good material to work into it for the drawing board.

Re: Proposal: Removing Campfire and Bedroll Prohibition Against Use in Inhabited Areas


Yeah, that seems a bit strained to me. I personally wouldn't miss them, either. Any strong feelings one way or the other from others?


I know I was definitely under the same impression as you were, Melian, but it just kind of fell out of sight and out of mind. But thinking about it, I sure haven't noticed any such effects either.

Yea, I am pretty well on board with this too.


Considering the lack of aforementioned issues with the bedrolls, I don't think there is an issue with the city deals. Though it does provide some minor inconsistency in where you can place a bedroll (the Ald-ruhn example provided), these issues can be covered by lodging provided by Inns and Guildhalls if one is so close to a town already.

Perhaps an MC (I believe is the mod I saw this in) approach to the fires issue, where the mod provides "campfire kits" and "fire kits." The issue with it in NoM (I assume), is that the fire appears like a camp fire when placed in the world by the scripts, and thus looks out of place if used for such purposes as lighting a fireplace. In MC (again, I believe - Tocatta correct me if I am wrong), the difference in the kits lies exactly here, where a "campfire kit" provides an aesthetically pleasing camp fire, and the "fire kit" provides an aesthetically pleasing fireplace fire. Perhaps checks could then be used on both, so only the aesthetically correct one can actually be used in the prescribed areas (a la NoM scripting).

If such a method were taken, the best of both worlds could be achieved, and restrictions still applied as well in the case of all objects (simply providing a method of workaround).

Further, with account for some popular mods in the base functions of NoM, various things can be taken into account so that if a mod is used and an item is placed it can function as a NoM item should, further cutting down on any prescribed issues mentioned.

Actually, there's only the one kit called the "Flint and Tinder kit" and it allows you to select which type of fire you want to set. Both have the same requirements and difficulty, the difference being solely cosmetic. You place it on the ground where you want the fire and activate it, then select whether you want the campfire or the cook fire. Both give you access to the cooking menus, but the cook fire is more suited for fireplaces and Redoran hearths.

I should mention that there IS a difficulty with MC bedrolls. The intent of the bedroll was to allow a player to take it along instead of simply permanently installing it like a normal bed. Since NoM took over the normal bed script, and since I had to rewrite that script to allow the MC bedroll to remain mobile, I wasn't able to make it compatible with NoM. I tried several times to get permission from Taddeus and Nymeria to use their sleep script, but there was never a reply to my emails. If Gluby gets permission to go forward with the project, I'd recommend a modified sleep script to allow the mobile bedrolls to be used to fulfill NoM sleep requirements.

It's possible that those people that are remembering bedrolls that don't fulfill sleep requirements are using a mobile bedroll. I did point out in the readme that the bedrolls aren't compatible, but how often do people actually READ a readme file?

From the Morrowind Crafting 2.0 readme file:

Beds and Hammocks made with Morrowind Crafting will satisfy the sleep requirements of NoM, however the portable bedroll that you can make with MC will not, unless it is permanently installed. It cannot be used to satisfy sleep requirements for NoM if it is used as a portable device.

There was also Acheron's Camping Gear that provided a campfire, bedroll, and tent ( a guar hide lean-to ). I seem to recall he made the campfire (which worked as you describe) NoM compatible at some point, but the bedroll had the standard sleep script, aside from being place-able.

I do agree that the NoM fire and bedroll restrictions are unrealisitcally restrictive.

It always bothered me that trying to light a NoM campfire in one of the strongholds, or in some buildings and caves, would generate a warning that "You can't light a fire under water". Being able to make a "firepit", with a ring of stones surrounding it instead of just a pile of logs in the open, would be a big plus for wilderness encampments.

I recall that there were some bedrolls that were usable and others that weren't, and I eventually gave up on using them.

BTW, Toccatta, if you do any future patching to MC, I'm not sure why some of the sewing kits are usable and others aren't. Buy them from a Merchant, they work fine; buy one from a Woodcutter, and they generally don't activate when you "equip" them, they just pop back into inventory like any other item without a script.

That's not a problem with Morrowind Crafting. What you're describing is a mod conflict of some sort. I just confirmed that the sewing kits from woodcutters work just fine unless something else is screwing them up. I have seen a situation where scripted items for some reason lose their scripts. I have no idea WHY it happens, but it's always a mod conflict that causes it. In every case I've seen, you can just drop the item on the ground and pick it back up again. That causes the game engine to re-identify the item and attach the appropriate script.

I can think of several types of mod conflicts that could permanently strip the scripts from all sewing kits, but nothing that would arbitrarily strip the scripts from some, but not others. There's only ONE object ID for a sewing kit, and it has a script, so either they all should or none of them should. It would be a truly bizarre mod conflict that would allow some to have scripts and others to not have them. But as I said... I *have* actually seen that happen! Nevertheless, it isn't the original mod. It's something else messing with the mod.

Toccatta: I was talking about the NoM bedroll - nothing to do with MC in fact.

It is currently possible to make a modded bed (portable or otherwise) compatible with NoM but it's more inconvenient than it probably needs to be.

Nevertheless, it does point out an incompatibility with MC that I would like to have been able to resolve but couldn't because of permission issues. If Gluby does get permission to go forward with the project, it's something I'd like to see included in NoM 3.0

Also, if it's more inconvenient than it needs to be, that just means we need to work on making it more convenient. Once we have the appropriate individual's blessing to move on the project, I'm confident we'll be able to work out any problems.

Indeed, I agree 100% there.

I am still not really convinced the restrictions of item placements it too terrible. As previously stated, the fire issues should be able to be worked around in some manner (a few methods have been presented). The bedroll issues in the Dunmer Strongholds should certainly be addressed though (I see no real reason a person should not be able to do that if they have cleared the location already - no threats left).

To me, it seems the restrictions were designed primarily to make the player utilize other avenues that were made available in NoM, such as access to cooked foods when near a town (or Inns for beds). Further, not being able to set things up in water sources is also good as no one in their right mind would sleep partially exposed to a river or such (nor would most be able to successfully light a fire in water with wet materials).

Though, certainly, some revisions stand to be made so that it functions better than it currently stands.

The problem with the water detection is that IIRC it just uses getWaterLevel - and nothing else. This means if you're in an interior with NO WATER, you may well get stupid messages telling you "you can't set up a bedroll in water" and have to go outside to sleep. Because if the "cell has water" box isn't checked, the value returned by getWaterLevel could be 10000 units above the highest static in the cell. And there's no function to detect whether the cell has water at all.

So to correctly detect whether the player is in water is not as easy as it sounds. Firstly, you *have* to use getSoundPlaying, there's no other way to know if an interior has water (unless it's a fake exterior, then it does). And getSoundPlaying is extremely unreliable on some systems, so I'm assuming Gluby at least will want to avoid using it. So without getSoundPlaying, it's false alarms for people using the mod as intended, or dropping it and allowing people to do silly things if they want to, which frankly is just fine by me. Why bother stopping them? Most portable bedroll scripts don't have those checks. Or you could use the getSoundPlaying check and let some people sleep in water and some not, if you prefer (if it's not working on a particular system it just won't register when it should). Here's how to detect when the player is in water (so you know where I'm coming from with not wanting this running all the time - which it would have to, it couldn't be a local script!):

First you check for a sudden change in player position on one or both x,y axes.
If found, assume a cell change (because cellChanged isn't reliable, so can't use it for this) and reset water check.
If cell is an exterior, it has water. Otherwise:
If getWindSpeed returns values higher than 0, it's a fake exterior, and has water.
If the player has any one of three water-related sounds playing on them (FootWaterLeft, FootWaterRight, DefaultLandWater), the cell very probably has water, and you can use getWaterLevel to find the water level.
Once you know the cell has water and what the water level is, you can check the player's z-pos against it, and be reasonably confident you won't get it completely wrong very often.

Now I don't know about you, but if I'm going to go to all that trouble over something (and sacrifice game performance to it), I'd rather it was something important. If this is really that important to you then fine, I'm just saying it's not that important to me. :shrug:

If you do decide to do the full water check, btw:
IIRC, Wrye has some water check scripts in NoM already. I don't remember exactly how they worked but they were usable for any mod (ie the just checked for player in water, they weren't tied to NoM) - so more than one mod could use them even without a dependency. IMO this is a good idea: more efficient to have one global script checking this, since there are quite a few mods that want the info.


Personally, I'd really rather it didn't do that. Why make the player use the inns if they don't want to?

Odd, I have never encountered this issue before and thus had not taken it into consideration. How often do these instances occur in the game?


I sort of assumed that was the point of using the sleep scripts in the first place (to add restrictions to how the player will go about playing the game, and have them utilize otherwise unused locations in the game), and thus the ability to disable them from the configuration menu (assuming that the player did not want this aspect in their game). Certainly, imposing difficulties beyond the confines of the normal game is the entire goal of this mod.

As to the issues with making portable bedding work with NoM, I fail to see an issue considering if this project is able to move forward to development (barring Gluby being able to obtain the needed permissions) then it would lie in the hand of the Dev Team here who could then make that code readily available for modders to use freely in their released mods (as from the sounds of what Tocatta posted, this was previously an issue). As previously stated in regards to already existing mods, that would come down to the Dev Team to decide if they want to contact the various modders of some popular portable bedding mods to make patches (or just make them barring permissions in the readme files), leave it up to the mod creators to update their own mods to be compliant to NoM, or leave it to the individual players to upgrade mods to be complaint to NoM in their own games (we could even provide instructions on how to do this to make it easier). Simply put, it would stand as it does now and always had (by my perspective).

Now, on the other hand, since I have little experience with this glitch you mention, that COULD be a real problem for all of this by my book (and this I am very curious to hear more in regards to it if possible). I just think, like with all matters, all the pros and cons of the areas of this mod should be weighed to decide their usefulness and worth (much as we are doing now). In truth, I am impartial to any aspect of it, and simply want to see it polished up and improved for the current era of modding, but still I feel it bears some decision.

I guess I came over a bit strong before - sorry, I didn't really mean it like that. Just cranky again.

Hm, now I wish I could remember the cells that I had problems in... Basically after I had a few issues like that I just disabled the sleep scripts and never used them again. I like my bedrolls to be rather fancier than the default anyway IIRC it's an issue with cells that don't have water, and that have the statics placed below 0 on z.

What I actually meant about the water detection thing is: If you do keep it, I think it would be useful to keep Wrye's method there to the extent that it allows other mods to use the same script (ie my mod could add that script as well, and because it's identical it won't matter which overwrites, so my mod and NoM could both use the results without extra scripts running). That would mean more reliable detection on most systems (and won't cause major issues when it doesn't) and if you've got, say, 3 mods running that all use the results of that check it starts looking efficient and useful, not a waste of resources at all. Of course, that's just my opinion. And IMO the person who writes the thing in the end should be the one to have the final say on it.