I still think that having a way to force a merchant to buy something at its TES:CS value would be very useful. Something that could be added to an item be it a script or whatever.

Is this not possible already? The creeper will pay the nominal value for many items, as does the Crab Merchant.

These two are not bugs or problems, they are feature requests, which I think lies outside the remit of the Code Patch. I have no idea, but mightn't MWSE already cater for both these things? In any event, that would be the more appropriate tool to request these features from.

Glad to see you back Hrnchamd.

I understand that stolen items are recorded by their bade ID. Fliggerty suggested storing the reference ID instead. Is that Possible?

And just to clarify, I don't want to remove curses or anything. I was wondering if it was possible to make curses only react to the unused Remove Curse effect. This makes more sense to me than Restore Strength fixing a curse that lowers your strength.

Just for the record, NoM is the only mod I have used that I know put me under curses. I suspect other realism mods would do the same.

I guess you could try to fix the problem with abilities, like a Drain or Damage Strength ability will lower it until 0, even if its magnitude is only 20 points. That seems like it would be a lot of work to cover every effect, which is why I thought about fixing curses in the first place.

Oh, and please do visit Mournhold. It's not looking good over there, and they could use the tourism.

References don't exist for inventory items, so there's nothing to reference.

I've fixed the bug with drain effects not restoring the attribute properly when the effect expires, and mercantile is looking a bit better balanced now. Creature damage is still confusing though. I may just move onto the map zooming.

Speaking of magic effects, Dispel works strangely. I haven't tested this exhaustively but as best I can tell the strength never gets reset. In other words, if you haven't used it before and cast a 80% Dispel on yourself, it works as expected. But is some time later use a weak 5% Dispel it would act as though were magnitude 85. Assume this is per actor, but I haven't checked. Anyway, the net result is that after playing for a while, the Dispel percent (of the PC) is inevitable stuck at 100+, so all Dispels succeed all the time. Actually what reminded me is that Remove Curse works the same way. So if you fix Dispel, it would be good to do the same for Remove Curse for completeness sake, but obviously it's not high priority in itself.

Ah I see. That's unfortunate.

I am not exactly certain what you need to know, but then your business is quite the mystery to me. If 1-based numbering means numbering the first month of the year as 1 rather than 0, then I am optimistic since the first month in un-patch Morrowind is numbered 1.

Most script operations that have anything to do with time and date are going to be reading the global variables Gamehour, Day, Month and Year, not setting them. The only occasion for setting their value is to affect the passage of time, something I have long thought of as a little risky mostly because I was uncertain of how the engine would handle some situations.**

One thing already understood is that if a date 'outside the calendar' is set by a script (and presumably dialog results and console as well) it would revert to the next 'supportable date' whenever the gamehour crosses midnight by natural causes (normal passage of time, waiting/sleeping and probably fast travel as well). It is for this reason that earlier attempts to fix the calendar bug through scripting have failed.

I have done some testing both with and without the Morrowind Code Patch calendar fix installed. This was an installation with Morrowind and both expansions.

To allow the normal passage of time from one day to the next, I either waited/slept or set Gamehour to 23.99 through the console and allowed the game clock to take it from there. The results are a little erratic when you work outside coded days and months, but there are some patterns that may be useful.


If Day is set to -4 (through console) and then the day advances normally (any month real or imaginary), the behavior is the same w/ or w/o patch: the month stays the same and the day increases to -3.
This continues to advance the day (to -2 and -1) until a legitimate day is reached and normal behavior takes over.


If Month is set to -3 (through console) and then the day advances normally (from any day real or imaginary)...
w/ patch: Month = -3 (same month), Day = next day
w/o patch: Month = -3 (same month), Day = next day
This behavior appears to be consistent for any Month <= -3.

If Month is set to -2 (through console) and then the day advances normally (from any day in the month or greater than 31)...
w/ patch: Month = -1 (advanced but not legitimate), Day = 1
w/o patch: Month = -2 (same month), Day = next day

If Month is set to -1 (either by script or through console) and then the day advances normally (from any day in the month or greater than 31)...
w/ patch: Month = 0 (first month), Day = 1
w/o patch: Month = 0 (advanced but not legitimate), Day = 1

Advance a second day in the same fashion?
w/ patch: Month = 1 (first month), Day = 2
w/o patch: Month = 0 (first month), Day = 1

If Month is set to 12 (either by script or through console) and then the day advances normally (from any day in the month or greater than 31)...
w/ patch: Month = 0 (first month), Day = 1
w/o patch: Month = 1 (first month), Day = 1

If Month is set to 13 (through console) and then the day advances normally (from any day in the month or greater than 31)...
w/ patch: Month = 13 (same month), Day = next day*
w/o patch: Month = 1 (first month), Day = 1
*If Day >= 31 (w/ patch), then Month = 0 (first month), Day = 1

If Month is set to 14 (through console) and then the day advances normally (from any day in the month or greater than 31)...
w/ patch: Month = 14 (same month), Day = next day
w/o patch: Month = 14 (same month), Day = next day*
*If Day >= 31 (w/o patch), then Month = 1 (first month), Day = 1

If the month is set to 15 (through console) and then the day advances normally (from any day in the month or greater than 31)...
w/ patch: Month = 15 (same month), Day = next day
w/o patch: Month = 15 (same month), Day = next day
This behavior appears consistent for any Month >= 15.


There appears to be a range of somewhat normal behavior depending on Month. Exceed that range and any advancement of the day does not advance the month:
w/ patch: if Month <= -3 or Month >= 14, then Month does not advance
w/o patch: if Month <= -2 or Month >= 15, then Month does not advance

At first glance there may appear to be a pattern: a shift of the range by one unit because of the difference in the index of the first month. But something is amiss. The normal range of months is...
w/ patch: 0 <= Month <= 11
w/o patch: 1 <= Month <= 11
So erratic behavior begins three units below the first month in each case, but three and four units above the last month (patched and un-patched, respectively). I could double check my tests for the latter, but both are far enough outside any value of Month that would reasonably be encountered that I don't think it will matter.


Scripts seem to resist (if I am using the term correctly here) any set of conditions whether within or outside the normal range of legitimate dates. My test results:

If the day is advance by script [set Day to ( Day + 1 )], the month is not changed (regardless of the Day) the month is not changed and the day increases by one (apparently without an upper limit) regardless if the calendar fix is installed or not. Of course, once the day advances normally (game clock, wait/sleep and possibly fast travel), then the calendar will be correctly following the behavior outlined earlier in this post.

As I wrote at the beginning of this post, it is rare for scripts to write values to these globals - and ill-advised.


For the sake of my own curiosity I tested scripting set Gamehour to ( Gamehour + 2 ) when Gamehour = 23.000. The result is the next 'legitimate' day (by previously examined Month conditions) or if Day is less than zero, Day will increase by 1. Regardless of how Day changes Gamehour will have a value of 0.000 not 1.000.


I hope this information is useful in clarifying how the game engine will manage the date under a variety of conditions. If further data is required, just let me know what circumstances you would like me to test and I will do my best to provide it.


Edit: **To say nothing about how such changes would affect other scripts keeping track of time.

edit:nvm, realized the obvious

The same thing happens if you get an NPC to wear a Negative fortify fatigue item.

Instant superhero that can't die. Unless you use spells.
Yeah, it's an overflow because the NPCs have according to the console, about 2 million fatigue.

On the month problem, wouldn't it be best to switch scripts to a different method of counting days? Either DaysPassed, or your own counter in a global script. Or are there many scripts that actually need to know how many days are in a month as such? I'm having a hard time thinking of any reason you would need that.

Referencing the global variable daysPassed can be unreliable, but certainly a global script can be used to count off days as they pass. The problem would be with existing local scripts that cannot be assured of running each time midnight is passed. Such scripts store the day and month to compare at a later date to see if the necessary duration of time has elapsed to trigger some event. These local scripts were considered more efficient since they would not be running continuously. With today's higher powered systems we might not have to worry about dozens of global scripts running all the time, but years ago it was considered responsible modding to utilize local scripts were possible. Many of those older mods are still in use even after their authors have moved on to other things. So it is unlikely that those local scripts will be updated.

To understand why the number of days in a month might be important to know consider the following scenario. Five days need pass from one event to the next, and the beginning of that interval occurs near the end of a month. It may be necessary to know if the month is 30 or 31 days long (to say nothing of First Seed/Sun's Dawn) in order to know when the interval of five days has passed. E.g., if the interval is started on 28 Second Seed, five days will have elapsed by 3 Mid Year on the un-patched calendar, but on 2 Mid Year on the patched calendar.

Need modder's put so fine a point on something like this? Perhaps not, but if they have there will be problems whose cause is very difficult to detect. As a modder, I like to know that what I create will work reliably on any configuration. In its present form the calendar patch does not provide that assurance, but my proposed change would - if it is feasible.

Well, the Creeper and the Mudcrab merchant buy things at their nominal value because they have no Mercantile skill, as they are a creature and creatures can't have skills, IIRC.


I agree about the MWSE, but I would hate to force people to play a mod using that, as there are people that have an aversion to it. But I agree, it isn't more of a bug than it is an oversight.

Is remove (or extend to 200) the attribute/skill cap is in the scope of this project.

no. It can, and has been done by other mods already - the engine does not restrict attributes or skills to 100.

Yes I known for other mods, I use myself GCD.
But that would be simplier if attributes and skills can go further 100 without scripts (GCD) or fortifications (MaddLeveler)...

AFAIK, Yes, you ca only put up to 100 points in a stat in the level up screen, but the Bittercup can push it above 100, and the Corpus, etc.

Even after you remove Corpus, the bonus still can be above 100.

So, there's not really a limit per se unless you mean only on the Level up screen? In fact, the limit for each stat is possibly about 32767, if not higher.

Maybe the bug with abilities could be fixable. Some birthsign abilities give you fortify attribute bonuses at a set number, so maybe it's possible to make the damage/drain attribute effect in an ability only do a set number, instead of subtracting until you are at 0.

I did a little testing with the Dispel bug ManaUser mentioned. I used a 5% Dispel with a 100 point Levitate. The more I cast it, the more often it succeeded, as if it were stacking 5% each time. At "100%", it almost never failed. However after saving, exiting, and relaunching the game, I couldn't get it to work anymore.

another strange thing...

has it occured to anyone that the blindness effect actually increases the chance to hit instead of decreasing it?

noticed it when using tenjon's fatigue mod, and more recently having aquired the boots of blinding speed, the effect is equivalent to having fortify attack :S (with the exception of a black overlay)

The ability bug may be applicable to constant effect drain/damage items also. So maybe it's just a problem with the way these effects are handled when used other than a normal spell. Maybe it's not a problem either, but it makes more sense in most cases for the effect to be applied once, and not every second.

Does this mod have an esm/esp in the Data Files? I have Code patch installed but it seems the only esm I have for it is the showcase, which I don't use.

No, if you use it it will change the executable itself (Morrowind.exe).

New release at http://www.tesnexus.com/downloads/file.php?id=19510 and http://www.fliggerty.com/phpBB3/viewtopic.php?f=53&t=1008.

Version 1.3 changes:
- Restore attributes fix. Now also fixes the attribute change when a drain attribute spell expires.

- Mercantile bug. The effect of disposition on price is reduced to 10% of its original effect. This should make the fix usuable without breaking the economy. With this patch, mercantile skill is the dominant factor in determining prices.

- Disposition bug. When talking to someone while under the effect of a personality increase that would push disposition over 100, extra disposition could be lost when the effect expired. This should no longer happen.

- Calender fix. It seems backwards compatibility is better served by using months numbered 1-12, as the original game uses 1-11. Months are still named properly and have the correct number of days.

- Spell magnitude fix. Spells with a variable magnitude (eg. 5-10pts) which affect an attribute, skill or rating would rarely ever acheive the highest (eg. 10pts) magnitude when cast. Now the highest magnitude should have an equal chance to appear.

- Map expansion. With the map expansion, it is now possible to zoom in (2x) the world map to get a better view using PgUp/PgDn. It uses magnification of the map texture, so texture quality is affected.

If you're upgrading from a previous version and you care about this kind of thing you might want to bump your Month variable up by 1.

Please test the new fixes thoroughly. I would also like feedback from any Polish or Russian edition players on how the patch is working.

And before you mention it, the map zoom will just zoom in wherever it feels like. I spent days trying to get it to centre on the player's location; all it left me with is bitter thoughts about touching UI code again.

Excellent news on the release.

Some issues here. I can't get the Map Zoom working, for some reason I can't really determine. I'm pretty sure the Patch has updated correctly (there were some issues at first when it claimed it was 'unable to find the correct version of Morrowind', but these were resolved by restoring the Morrowind.Original.exe and patching that), but I am not sure if there's any way to check; and the most obvious way (using PageUp/PageDown on the map page) to check is not functioning. Perhaps it's because I have a British keyboard that the keystrokes aren't recognised? Or maybe the patch has not installed itself correctly?

I have no real way of checking, as far as I know, but it definitely is not functioning for some reason at my end.