Greetings to everyone. I would like to congratulate everyone involved in the making of the Code Patch. I'm writing this message to confirm Eevv's observations in http://www.gamesas.com/bgsforums/index.php?showtopic=978076&view=findpost&p=14570469 post about the Boots Of Blinding Speed and share some research that I have done concerning the oddity. What I have been able to find out so far is that when the Blind effect is imposed on the player by an object that contains it as an enchantment, the effect and one of its side effects(i.e. the attack penalty) are applied in reverse; the Boots for example bestow a -100(MINUS hundred) point blindness effect on the player and a -100 point attack penalty(which is equal to a +100 point attack bonus), provided the player has no magicka resistance. Somehow the player's vision is not affected by this reversal bug and gets darkened as expected; I don't know why. I believe most people haven't noticed this bug so far since they tend to boost their magicka resistance to 100% before putting on the boots, thus receiving no unexpected attack bonus. I have tried with my limited scripting skills to create a workaround for this issue, without success. I believe that this bug can only be fixed by such a project as the Code Patch, and submit my vote for its inclusion in the to-do list of the Code Patch as soon as convenient. A little more information and a somewhat more permanent venue for the discussion of this bug are available at the http://www.uesp.net/wiki/Morrowind_talk%3a%50emenie_and_the_Boots_of_Blinding_Speed.

About the Reflect Fix, if absorbing spells get reflected, shouldn't they be absorbed by spell absorbtion as well, e.g. Atronachs?

Except the year rolls around after Morning Star now; and the month lengths don't match the month names again. It's pretty compatible, though.


Reflect has a no second roll policy. You can't reflect reflected spells, neither can you absorb them.

I think I've run out of good stuff to fix, so I'm going to release 1.4 once I get the Russian edition working.

Nevermind I can't read.

Oh yeah, huh? The lengths aren't too important, but making Morning Star the last month would be pretty strange. Who would have thought this would be so hard? :ahhh: I think I'll just stick with the current fix. It seems to be the only version that's really correct.

I understand the first bit, because that's what's expected to happen, and only makes a 'problem' if you can see the month number, which the player never can, but I'm sure the second bit shouldn't be happening.

Literally, I'm just gonna write up a grid of my own here.

Here is the current system (of the release version), am I right?

Month   # of Days   # of Days  Name		  Name		 (Beth)	   (MCP)   (Beth)		 (MCP)  1		31		  31	 Sun's Dawn	 Morning Star  2		28		  28	 First Seed	 Sun's Dawn  3		31		  31	 Rain's Hand	First Seed  4		30		  30	 Second Seed	Rain's Hand  5		31		  31	 Mid Year	   Second Seed  6		30		  30	 Sun's Height   Mid Year  7		31		  31	 Last Seed	  Sun's Height  8		31		  31	 Heartfire	  Last Seed  9		30		  30	 Frostfall	  Heartfire  10	   31		  31	 Sun's Dusk	 Frostfall  11	   30		  30	 Evening Star   Sun's Dusk  12	  N/A		  31	 N/A			Evening Star

Look at the month numbers. They correspond to the month days in both vanilla and patched, excellent! Look at the month names. They are all out of sync! Let's change those strings then, and create a new grid.

Month   # of Days   # of Days  Name		  Name		 (Beth)	   (MCP)   (Beth)		 (MCP)  1		31		  31	 Sun's Dawn	 Sun's Dawn  2		28		  28	 First Seed	 First Seed  3		31		  31	 Rain's Hand	Rain's Hand  4		30		  30	 Second Seed	Second Seed  5		31		  31	 Mid Year	   Mid Year  6		30		  30	 Sun's Height   Sun's Height  7		31		  31	 Last Seed	  Last Seed  8		31		  31	 Heartfire	  Heartfire  9		30		  30	 Frostfall	  Frostfall  10	   31		  31	 Sun's Dusk	 Sun's Dusk  11	   30		  30	 Evening Star   Evening Star  12	  N/A		  31	 N/A			Morning Star

I've got it so that the month number corresponds to both number of days and name string.

So month 3, in both patched and unpatched games, has 31 days, unlike the previous patch, where the days were messed up, so therefore Cyrano's scripts are happy.

And now, month 3 also keeps the name Rain's Hand.


In your current version, the month Rain's Hand is month 4 (but that's not right!) and has 30 days (but that's not right!). By switching them around like this, we get the right number, days, and name.

Unless somehow the strings are integrally linked to the number of the days and month number (which they can't be, because both do not correspond in the current version) you can very easily have everything correspond, and just add in the extra month 12. (As you already do, but rather than call it Evening Star for no other reason than that it corresponds to December, month 12 in our calendar, and have thus felt obliged to make it (for no necessity at all) month 12 in the game's inner clock calendar (although it remains the '12th month' for all other intents and purposes), call it Morning Star.

This is surely that simple. You've not said anything that makes me believe it is not so.

But!

If this really is impossible, it will be very easy to make a patching .esp to fix the Patch. So if I'm not making sense (which clearly I haven't been in the past), just stick with the current fix, and I'll patch it. Simple.

The only problem, is that Evening Star is supposed to be the last month and Morning Star the first. It has always been that way, and the names are a pretty good clue that it's not an accident. Although it would be marginally better than having a month missing completely, putting them in the wrong order would rather defeat the purpose of a calendar fix, don't you think?

Will using NOM's "triple duration" day length script conflict with anything MCP has done? I'm thinking because of the changes to the calendar. Is it possible?

No, because the number is irrelevant.

That's just how the game knows how to link the two values of number days and name, and what order to put those values in in-game.

In-game, the months will go Morning-Evening Star, and the player will see the months progress as you'd expect. (And remember, in the vanilla game, the month of Morning Star is skipped and the year goes from Sun's Dawn to Evening Star)

As long as in the endless cycle of 1234567891011121234567... the months proceed in the correct order, the player is never the wiser. Any scripts that rely on knowing 'is it Last Seed' will say 'is it Month 7'. In my version, it is. In the current version, it is in fact Sun's Height, because although the 'seventh month' in terms of order is Sun's Height, the 'seventh month' according to the game is Last Seed.

In addition, the month of First Seed, for example, is meant to be February and have 28 days. In the current patched version, it becomes March with 31! By sticking to the implicit 'Earth order' you in fact pull things out of the 'explicit' Earth order.

The game is told to begin in Month 7, so it starts in Last Seed (the eighth month). However, in the current patched version, it starts on Sun's Height (the 'seventh' month). In order to get the months to remain as the game thinks they are (so that scripts and the journal remain correct), they need to be one 'out of sync'.

The player never knows that it's 'month 12', they just know that it's 'Morning Star' (which is the first month, even though it would be the twelth in the game's stock list of months under my system).

Please tell me this makes sense now?

Seriously, that grid I provided will work. Just please use it. If not, as I said, and as I say, I will patch it, so don't worry.

Hrnchamd, I feel terrible for stirring up this mess. Perhaps a few broken scripts would be a small price to pay for the serenity this thread once enjoyed. Few people would have figured out what was causing the problem - most players would have shrugged it off as just another bugged mod and moved on. I think I could live with that.

Because ignorance is bliss I wasn't going to say anything about the problem with the year ending on Morningstar (the first month of the Tamrielic calendar) as Crustacean suggests. I know I would never have noticed the discrepancy in the month on the documents that Sellus Gravius hands the player - I can readily believe that few players will notice the year advancing after Morningstar.


The naming of months, their sequencing and the number of days per month are not arbitrary to Morrowind. With the exception of the number of days these details had been establish with Arena. Rain's Hand is not the third month of the year just because it had been assigned an index of 3 by Morrowind's developers. According to the http://www.imperial-library.info/calendar/ it is the fourth month of the year and it has 30 days.

The sad part it this is merely a cosmetic fix - the game is not broken because one month out of the year is not included. It is to satisfy lore that players have wanted a calendar fix. For that reason I would be surprised if those who really feel strongly about a calendar fix will be satisfied by having Morningstar the last month of the year. Of course, that is only an issue in the unlikely event they would have noticed the year changing after that, but I quest that secret is out now.

So how much more effort are we willing to put into making a calendar fix that still breaks lore? What we know with certainty was it worked before any attempt was made to 'fix it', and all documents and scripts would reference the date accurately (if not 'correctly').

Okay, last post. I am wrong on one point, which is that I'd forgotten the year changes as well. So in my version, the year changes after Morning Star, not on it.

The apparent solution to this is to make Morning Star month 0 (as Hrnchamd had it originally), but then to ensure the other values are changed to accomodate (as per my grid). Problem solved. Or to make the year turn over at month 12, not month 1. Either solution works. If these are impossible, it would still be better to use my grid because any mods based on 'annual events' (like Princess Stompers' Holidays one) would work properly, and the only bug would be the delayed year turn over. That is a cosmetic bug, not a practical one, however. In any case, I am sure one of the two solutions offered just now would be practical.

This will be my last post here. I have asked for deletion of my other posts, so that will hopefully happen sometime tomorrow if I'm obliged by the mods.

Apologies if I've disturbed the tranquility here. That was truly not my intention, and I apologise if I've come across bady, or annoyed anyone.

The Crustacean, I appreciate a heartfelt argument and there are no hard feelings from me. My intention was and still is to make a lore correct version of the calendar in Morrowind, but of course with the selective fixes I can add a Crustacean certified compability option with ease.


Thank you for testing this, and you may be pleased to know it's already fixed and will be released in the next version.


It won't conflict.


This is same hardness as any other software improvement process. If a third party software has to rely on a buggy assumption (either code or data), then that becomes part of the software ecosystem.. and when you patch it, stuff breaks. Bugs just keep on giving far into the future, but how often are these costs accounted for?

I've reviewed this thread with interest and, though I may be missing something here, I honestly do not see anything amiss.

It appears to me to be a friendly - if animated - discussion between seasoned modders who happen not to agree on everything. That is fine! Everyone is being polite, respectful and generally nice about it.

It is always a great pleasure to spend time in Morrowind Mods and this thread just reinforces my pride in both the talent of the modders in this community and the wonderful people you all are.

Whichever grid is used, it's still better than one with a month missing, and I'm sure that between everyone we can come up with something compatible with the majority of mods. Besides - as we all know - if you're not 100% happy with something, you can always mod it to fit your own tastes.

Yes, I know. Maybe Morrowind behaves like that already, but what I mean is, are absorbing effects (not reflected ones) absorbed by spell absorption?

Do not be alarmed - I just want to apologize for my previous post. I wrote carelessly and upset some people. Of all the people who have posted to this thread the only one I am annoyed with is myself. I was the only person to raise an objection to the calendar fix in the first patch so I felt that Hrnchamd made the change at my urging. I feel responsible for all of the dissatisfaction that has been voiced and regret for having Hrnchamd waste his valuable time. I appreciate (as I am certain other do) his tremendous effort in making the Morrowind Code Patch possible and all of the valuable fixes it provides.

I do not blame Crustacean, Manauser or anyone else who has posted very reasonable concerns about the current version of the calendar fix. My comment about having upset the tranquility here was out of frustration with myself for having pushed for the change when most people appeared satisfied with the original fix.


I see Princess Stomper has joined us and I am pleased to see that she has not deleted Crustacean's posts. As much as I mourn the loss of ideas as the deletion of those posts would represent, I regret even more that anyone should feel that his or her ideas are without value and are not respected. Crustacean, I hope that you will withdraw you request to delete your posts. Even if they do upset the tranquility of the community a little bit ( ), they enrich it much more. Ideas can be exciting without hurting anyone. And I hope you can be persuaded to continue to post to this thread on this issue and others. We cannot afford to lose good ideas or people with the willingness to try and make things better.

Perhaps we should settle that there is no quick fix for the calendar as we first supposed, and adopt an approach like that for valuing filled soul gems. Let us decide what is most important to achieve in case it is impossible to satisfy every need. And if there can be no consensus then we should reconsider just how bad it was before there was no fix at all.

@cyran0
I probably should of chimed in when you first posted in the previous thread about your concerns with the implemented calendar fix in v1.2, but your post was very thorough and stated exactly my like concerns. I'm sure others read that, agreed and chose not to elaborate as well. -_-

In any case, I thank you for first bringing it to everyone's attention!


@The Crustacean
I would find it a great loss if your posts regarding the discussions about the calendar fix were removed - please keep them. Good explanations like yours and cyran0's really help those of us better understand what is involved in how things like the calendar operate in MW and let us make better informed decisions when arguing or agreeing for or against implementing such changes in a project like MCP. I find it more confusing when trying to follow back on a running discussion only to find integral posts fully edited out or culled. <_<

Thank you for furthering the discussion and offering a sound solution!

I was going to point out the problem about the year changing after Morning Star, but see that you noticed it too. This might not be that big of a deal tho, since resting and journal entries never give the year AFAIK. Unless it would somehow break scripts, name order as you suggest should work fine.


So, I agree with what ever calendar fix is the easiest to implement and best satisfies lore without causing too much havoc with existing mod's scripts reliant on date indexing.

I don't really see the problem with the original Calender fix. Can't scripts just reference month 0 and rely on the MCP? I understand not wanting to force people to use it; but it's simple, safe, and problem free. I apologize if I am simply not understanding something.

Something I forgot to mention before, relating to bartering. You can sell a stack of any stackable item and get gold, or you could sell each one individually (Without even needing to exit the bartering screen. It's at least understandable if the transactions are made in different "sessions".) and end up with more gold than selling everything at once. I'm sure it's not supposed to work like that. I don't suppose that it's fixable?

I guess you could just look at it as a trade-off for the convenience of unloading everything at once.

Okay, I apologise one final time for the rather large detour this thread has now taken, but I'm sure we can be done with this soon. Thank you all for your comments, anyway.

This approach is best.

Firstly, the key thing is to have a month of Morning Star at all. Secondly, we want the number of the month to correspond to its number of days, so that scripts like Cyrano's can function properly. Thirdly, we want the name of the month to correspond to its index number (according to Morrowind, not it's actual place in the order) and day number, so that 'annual events' and the journal can function properly.

In an incremental order, these desires correspond to the options we've been shown. Hrnchamd's initial solution covered the first objective. Cyrano's solution then covered both the first and the second objectives. Mine then covered the first, second and third. There was, however, one problem with mine, which was that the year would turn over at the wrong time. This brings us to the fourth objective, that the year turns over correctly.

The first objective is rather simple: it's been achieved by all the patches so far. The second is just a matter of ensuring that the correct days number is assigned to the correct month index number. Very simple. The third is again just a matter of ensuring the correct string variable is applied to the appropriate days number and month index number. Very simple. These can be achieved with little to no effort at all.

The fourth objective is similarly simple. I think it is relatively obvious to presume that the year number turns over each time the month index number list reaches its end. In Hrnchamd's first solution, then, the year progressed when Evening Star (Month 11) changed into Morning Star (Month 0). In Cyrano's solution, the year progressed when Evening Star (Month 12) changed into Morning Star (Month 1). So clearly there is no fixed turnover point.

So, in order to get everything working in a simple manner, I present to you one last grid of excellentness:

Month   # of Days   # of Days  Name		  Name		 (Beth)	   (MCP)   (Beth)		 (MCP)  0		N/A		 31	N/A				Morning Star  1		31		  31	 Sun's Dawn	 Sun's Dawn  2		28		  28	 First Seed	 First Seed  3		31		  31	 Rain's Hand	Rain's Hand  4		30		  30	 Second Seed	Second Seed  5		31		  31	 Mid Year	   Mid Year  6		30		  30	 Sun's Height   Sun's Height  7		31		  31	 Last Seed	  Last Seed  8		31		  31	 Heartfire	  Heartfire  9		30		  30	 Frostfall	  Frostfall  10	   31		  31	 Sun's Dusk	 Sun's Dusk  11	   30		  30	 Evening Star   Evening Star

The new month of Morning Star has been added. Objective 1 is fulfilled.

All the vanilla Bethesda months remain unchanged. No scripts or events can be affected. So that is perfect, exactly as we want, fulfilling objectives 2 and 3.

The year, presuming it worked in Hrnchamd's first patch, will turn over at the end of Evening Star. Objective 4 is fulfilled. Everything is perfect!

Except! Damn, I have just realised exactly what everyone else may have been saying (though never explicitly, which isn't very helpful ). Which is that in the truest 'lore' sense, the entire original Morrowind calendar was broken. Because Sun's Dawn (the second month, February) should have 28 days, not First Seed. So in the absolutely truest sense of 'lore', the number of days should be shifted up one place on the grid each, with Morning Star's 31 then being cycled round to the end to Evening Star.

However, in this way, by following in the absolutely strictest sense of lore (and ignoring the fact that Morrowind itself screwed this up entirely), we break the rather important objective 2. Ultimately, it comes down to how imperative it is that Cyrano's scripts function as they do (personally, I've always used the GameHour variable to see how many days have changed, not the Day variable itself), and whether there are any other scripts that rely on knowing the number of days in a given month (I personally cannot think of any).

If it is imperative these scripts function, we use my grid above. If it is not imperative, we shift the number of days up by one place each, giving an entirely lore correct calendar that is able to still run yearly events, have 12 months, and turn the year over correctly (objectives 1, 3 and 4). (EDIT:Oh, just checked and that was the original fix: oh dear! )

Phew. I think that covers everything. I apologise again for any distraction I have caused.

BTW, my Holiday Mod does actually integrate the old MonthFix script - do I need to install some sort of check to toggle this off in my mod if people are using the patch, or will it be OK?

begin a1jw_thm_Monthfix		;based on Month Bugfix Script v2.0 - Zennorious	;thanks, rougetet, for the mercantile stuff		short LastMonth	short Yesterday	short ShorterMonth	short LongerMonth	short Leap	short doOnce		if ( Day == Yesterday )		return	endif	if ( CharGenState > 0 )		return	endif		if ( Month == 1 )		if ( LastMonth == 11 )			if ( Yesterday == 30 )				set Year to ( Year - 1 )				set Month to 11				set Day to 31			else				set Month to 0			endif		elseif ( LastMonth == 0 )			if ( Yesterday < 31 )				if ( GameHour < 1 )					set Month to 0					set Day to ( Yesterday + 1 )				endif			endif		elseif ( LastMonth == 1 )			if ( Day >= 29 )				set Leap to ( Year / 4 )				set Leap to ( Year - ( Leap * 4 ) )				if ( Leap == 0 )					if ( Day == 30 )						set Month to 2						set Day to 1					endif				else					if ( Day == 29 )						set Month to 2						set Day to 1					endif				endif			endif		endif	elseif ( Month == 3 )		set ShorterMonth to 1		set LongerMonth to 1	elseif ( Month == 5 )		set ShorterMonth to 1		set LongerMonth to 1	elseif ( Month == 7 )		set ShorterMonth to 1	elseif ( Month == 8 )		set LongerMonth to 1	elseif ( Month == 10 )		set ShorterMonth to 1		set LongerMonth to 1	endif		if ( LongerMonth == 1 )		set LongerMonth to 0		if ( Day == 31 )			set Month to ( Month + 1 )			set Day to 1			set Yesterday to 31		endif	endif		if ( ShorterMonth == 1 )		set ShorterMonth to 0		if ( Day == 1 )			if ( Yesterday < 31 )				if ( Yesterday != 1 )					set Month to LastMonth					set Day to ( Yesterday + 1 )				endif			endif		endif	endifif ( doOnce == 0 )	if ( Random100 > 90 )		set ajw_thm_assign to 1		Journal "1jw_thm_birthdayjnl" 10	elseif ( Random100 > 80 )		set ajw_thm_assign to 2		Journal "1jw_thm_birthdayjnl" 20	elseif ( Random100 > 70 )		set ajw_thm_assign to 3		Journal "1jw_thm_birthdayjnl" 30	elseif ( Random100 > 60 )		set ajw_thm_assign to 4		Journal "1jw_thm_birthdayjnl" 40	elseif ( Random100 > 50 )		set ajw_thm_assign to 5		Journal "1jw_thm_birthdayjnl" 50	elseif ( Random100 > 44 )		set ajw_thm_assign to 6		Journal "1jw_thm_birthdayjnl" 60	elseif ( Random100 > 36 )		set ajw_thm_assign to 7		Journal "1jw_thm_birthdayjnl" 70	elseif ( Random100 > 30 )		set ajw_thm_assign to 8		Journal "1jw_thm_birthdayjnl" 80	elseif ( Random100 > 23 )		set ajw_thm_assign to 9		Journal "1jw_thm_birthdayjnl" 90	elseif ( Random100 > 16 )		set ajw_thm_assign to 10		Journal "1jw_thm_birthdayjnl" 100	elseif ( Random100 > 10 )		set ajw_thm_assign to 11		Journal "1jw_thm_birthdayjnl" 110	elseif ( Random100 >= 0 )		set ajw_thm_assign to 12		Journal "1jw_thm_birthdayjnl" 120	endif	Addtopic "New Life"	Addtopic "Birthday Celebration"	Addtopic "--Celebration"	set doOnce to 1endif		set LastMonth to Month	set Yesterday to Day	startscript "a1jw_thm_celebratescript";	Messagebox "starting main startscript"	end

Also, it seems to have a dummy script but I can't for the life of me remember what this is referencing

begin _spzYearPatchActivatorScriptend

I already posted this in the http://www.gamesas.com/bgsforums/index.php?showtopic=1009286&view=findpost&p=14603204 thread where it apparently got ignored. So I repost here because maybe it fits better into this topic anyway:


Could that be the same issue causing meshes with alpha channel textures (e.g. some hair meshes, transparent glass weapons, etc.) to disappear when underwater when looking from above? I'd really like to set this on the to-do list for this great project.

An old saying fits:

"Some idiot threw a stone into some well, forty geniuses couldn't get it out."

I am indeed pleased, as I believe are many other people. Thank you for your attention and your prompt response.

Perhaps if there was some way scripts could detect this patch, I'm not sure how, I'm just brainstorming here. But both the orginal fix and cyran0's have the drawback that they aren't completely backwards compatible with scripts, depending on exactly what the script is trying to do (e.g. get the month's name, or number of days). This would be mitigated if there was at least some way to make a script "calendar fix aware", so it will work properly whether or not the fix is applied.

Perhaps the patch could use an unused variable and set it to true? And codes could detect this?

I actually was thinking about ways to detect the original Code Patch fix when it was looking like that was what we were going to have to live with. I envisioned a script that would store the current time and date, remove player control, fade the screen, set the date to Month = 3 and Day = 30 and the time to 23.99. Then check a moment later to see what day it was. If Day = 31 then the game is not patched and if it is Day = 1 (next month) it is patched. The script toggles a global flag so this kludge never has to be repeated, set the time and date back to the stored value and returning control back to the player (maybe ). It would still not be backward compatible so every script would have to be re-written to both check a variable and then manipulate the calendar depending on the outcome. If I was going to do all that work then I might as well replace every timer with global scripts. I suspect if Hrnchamd embedded a flag to indicate if the Code Patch fix is installed we would still have to update any affected script to detect it - again not backward compatible.


I think there is enough creativity in this community to get the stone out of the well. The problem is Bethesda dropped two rocks in there.

When people discuss the calendar bug it is usually to mention that there is a month missing (Morningstar). However, they also have the wrong number of days in each month. They gave us the number of days for the first eleven months, but they gave us the names for the last eleven months. I do not thing lore can be reconciled without breaking something in return.

There is really only one reason for changing the calendar since in every other respect the existing calendar works and that is to observe lore. There should be twelve months, so we and Morningstar, but Morningstar is 31 days long and Sun's Dawn should have only 28 days. The year should end on 31 Evening Star (Bethesda only gave Evening Star 30 days). Hrnchamd's first fix achieved all that, but at the price of changing the number of days in a month as referenced by its index. Perhaps it is the price we will have to pay.

My solution also preserves lore by changing the index associated with each month so the number of days assigned to that index would not have to change. But came at a different price that I did not recognize until Crustacean pointed it out. Time in Morrowind is mostly relative (how many day have passed). Rarely is there a fixed day, but the player's released documents write out the date that the player is dropped on the docks and that will be one month out of phase with the current calendar fix. If that was the only instance, the problem could be solved by changing the starting month (by index) to agree with the document. For that matter, the document could be patched. However the Holiday mod certainly has to reference specific dates on the Tamrielic calendar, and it may not be the only other example of this problem. Any such mod would be broken.

I appreciate Crustacean's attempt to preserve the number of days associated with the index of a month, but it breaks lore by having the wrong number of days associated with the named month. If lore is not important enough to protect in that instance then I don't understand why we should bother patching the calendar at all. An un-patched calendar assures every modder of how their scripts, documents and dialog filters will perform and eliminate bugs.

Unless I have missed something here (and we all know that is possible) I think these are our four choices:

1. Hrnchamd' first calendar patch (faithful to lore, but potentially breaks scripts)
2. Hrnchamd's current calendar patch (faithful to lore, but creates contradictions between named month and coded month)
3. Add Morningstar to end of year (does not break scripts or dialog, but is not lore correct for days in a month and when year changes)
4. No patch (does not bread scripts or dialog, but is not lore correct for the number of days in a month and missing Morningstar)

At this point, I favor no patch. If lore must be preserved then I suppose I could live Hrnchamd's first attempt at a fix. Since I recognize the need I can rewrite my own scripts. The rest is someone else's problem. As for my suggestion (the current fix) I do not like to think I am responsible for breaking someone else's work so I might sleep easier without it.