Sorry, I wasn't actually trying to get praise for the mod really, more trying to persuade Hrnchamd

And I know what you mean, Rapidshare is a pain when you only get 44kbps down

Here is an alternative link from MegaUpload, it should be much faster:
http://www.megaupload.com/?d=UGD35CKJ

Ha, no its cos my internet is pants, not cos rapidshare is slow

RapidShare puts a cap on guest download speeds, and often makes non-premium users wait minutes to hours to download files ("all slots are full"), regardless of filesize. Their load time to download is also larger for larger links; sometimes you have to wait up to two minutes. With MU, you wait less than a minute (no wait times during happy hour) and have a much higher bandwidth allotment for downloading. 'Tis better than RS

Thanks for the tip Haplo

Man if anything's fixed in a next version, I hope it's the inventory bug.
Personally I have it so bad Morrowind has become unplayable.

If I so much as throw a dagger or fire an arrow it subtracts the encumbrance but the arrow/throwing weapon is still there. If I turn in an item for a quest it subtracts the encumbrance but the quest item is still there.
It's severity seems to be related to how long you've been playing, how many mods you have, and whether ot not the save is dirty. It still sometimes shows up as early as Fargoth's Ring.

Before, I've cleaned the save completely and had, like, a long break from the bug. But after a while it came back bad.

Mods that really make it noticable are Necessities of Morrowind, since it constantly removes food items, and any crafting mods.

Sometimes the item that bugs out has many numbers after it's name. Ff I do anything to the item the game crashes.

"- Hand to hand damage now varies with strength. It is equivalent to original Morrowind damage at 40 str and increases up to 2.5x at 100 str."

Does this also affect werevolves?

On a related question, does this also modify the fatigue drained per hit before the target goes unconscious, or does it only affect the actual physical damage?

About damage fatigue spell fix - I haven't tried it on NPC's yet, but PC's fatigue will not drop below 0 with it on.

I'm having trouble with the map expansion function. I tried it to see what it was like (I don't have TR, just wanted to see the map size change), played with it for a little bit, but decided I didnt' want it. Now I can't fully get rid of it. I tried unchecking its box, no go. I tried the "Uninstall All" button and manually reinstalled all the fixes I wanted to keep, but the problem still remains. Basically, the map appears to be the bigger map, but the game is treating my position and cells like it is using the smaller map. Here's a Screenshot:

http://img.photobucket.com/albums/v287/Telinome/MGEScreenshot1.jpg

What can I do to get the map back to the way it was?

IIRC, Wrye Mash can fix this by using it's 'Update Map' function for save games:

* Wrye Mash >> 'Saves' tab >> right-click on your save
* select 'Update Map'

It's also advisable to uncheck 'World Map Gridlines' from the context menu before updating >> right-click anywhere on the column bar for 'Saves' tab >> uncheck 'World Map Gridlines'.

I found another oddity. For some reason, a script is unable to do a getitemcount of a torch. Specifically, it's the light with the ID of "torch".

I was designing a torch-holder that a person can activate and place a torch from their inventory. However, I always got an expression error followed by a left-eval error whenever that one item was included. Taking out that one conditional check resolved the problem, and putting it back caused it to return, so it's definitely that item.

I also took out several other items to ensure it wasn't some fragility with the if-elseif structure. However, reducing the number of elseif's did nothing. Breaking it into several groups did nothing. The only solution was to remove the torch from the structure. Eventually, I ended up replacing every "torch" in the game with "torch_basic" and the script worked perfectly. However, as many people have found out, wholesale replacing of objects from the morrowind.esm file has ugly consequences, so I'd prefer to figure out why the script balks at that line so I can use it without having to replace several hundred default items.

If anyone has any idea why that one particularly object cannot be counted, I'd love to know why. If anyone can think of a solution which allows the torch to be compatible without wholesale replacement, I'd love to hear that, too.

Oh... and it seems that using itemcount with that object in the console doesn't cause any problems. Only when it's part of an actual script does it cause that error. I'm absolutely baffled.

By the way, here's a copy of the script in question:

begin FM_loadtorch1short DoOncefloat StartZfloat Dropdownshort stateif ( DoOnce == 0 )	set StartZ to ( Getpos z )	set Dropdown to ( StartZ - 12 )	set DoOnce to 1endifif ( OnActivate == 1 )	set state to 1endifif ( state == 0 )	returnendifif ( state == 1 )	if ( Player->GetItemCount "adm_torch_256" > 0 )		Player->RemoveItem "adm_torch_256" 1		set state to 2		return	elseif ( Player->GetItemCount "torch_256" > 0 )		Player->RemoveItem "torch_256" 1		set state to 2		return	elseif ( Player->GetItemCount "Torch_Basic" > 0 )		Player->RemoveItem "Torch_Basic" 1		set state to 2		return	elseif ( Player->GetItemCount "torch_157" > 0 )		Player->RemoveItem "torch_157" 1		set state to 2		return	elseif ( Player->GetItemCount "torch_128_off" > 0 )		Player->RemoveItem "torch_128_off" 1		set state to 2		return	elseif ( Player->GetItemCount "torch_128" > 0 )		Player->RemoveItem "torch_128" 1		set state to 2		return	elseif ( Player->GetItemCount "torch_77" > 0 )		Player->RemoveItem "torch_77" 1		set state to 2		return	elseif ( Player->GetItemCount "torch_64" > 0 )		Player->RemoveItem "torch_64" 1		set state to 2		return	elseif ( Player->GetItemCount "light_com_torch_01" > 0 )		Player->RemoveItem "light_com_torch_01" 1		set state to 2		return	elseif ( Player->GetItemCount "torch" > 0 )		Player->RemoveItem "torch" 1		set state to 2		return	endifendifif ( state == 1 )	if ( Player->GetItemCount "light_com_torch_01_off" > 0 )		Player->RemoveItem "light_com_torch_01_off" 1		set state to 2		return	elseif ( Player->GetItemCount "light_com_torch_02" > 0 )		Player->RemoveItem "light_com_torch_02" 1		set state to 2		return	elseif ( Player->GetItemCount "light_com_torch_01_256" > 0 )		Player->RemoveItem "light_com_torch_01_256" 1		set state to 2		return	elseif ( Player->GetItemCount "light_com_torch_01_200" > 0 )		Player->RemoveItem "light_com_torch_01_200" 1		set state to 2		return	elseif ( Player->GetItemCount "light_com_torch_01_128" > 0 )		Player->RemoveItem "light_com_torch_01_128" 1		set state to 2		return	elseif ( Player->GetItemCount "light_com_torch_01_77" > 0 )		Player->RemoveItem "light_com_torch_01_77" 1		set state to 2		return	elseif ( Player->GetItemCount "torch_infinite_time" > 0 )		Player->RemoveItem "torch_infinite_time" 1		set state to 2		return	elseif ( Player->GetItemCount "torch_infinite_time_unique" > 0 )		Player->RemoveItem "torch_infinite_time_unique" 1		set state to 2		return	endif	messagebox "If you had a torch, you could put one in this holder to light up the area."	set state to 0endifif ( state == 2 )	setpos z Dropdown	placeatme adm_torch_256 1,8,1	setpos z StartZ	playsound "item misc down"	messagebox "You put one of your torches into the holder."	set State to 0endifEnd

I've moved that one bit of code to various locations in the script and I'm absolutely convinced that it isn't a location issue. I've also tried isolating it in it's own private IF conditional, and I get the exact same error. It's the only object ID I've ever seen that the scripting language refuses to count, but if there's a bug in the way getitemcount works or some oddity with the pattern matching it uses on object IDs, it's something that maybe should be looked into.

[edit] I've also tried it with and without the surrounding quotation marks. That doesn't make any difference either.

@Toccatta
I did a very simple test to check this and had no problems with GetItemCount on object id "torch".

Here's the test script:

begin tetchy_torchtestshort stateif ( OnActivate == 1 )	set state to 1endifif ( state == 0 )	returnendifif ( state == 1 )	if ( Player->GetItemCount "torch" > 0 )		Player->RemoveItem "torch" 1		set state to 2		return	endif	messagebox "What's a torch ring without a torch? Please, give me a torch."	set state to 0endifif ( state == 2 )	messagebox "You give up your torch."	set state to 0endifEnd

No compile errors in CS and no expression errors and no left-eval errors on game load.
I'm using v1.6.1820; my test.esp is only dependent on Morrowind.esm. I'll try your complete script next to see if it works for me. <_<

I don't get the error on game load. I only get the error when I activate the object.

[edit] Oh, and I never get any compile errors either. That's what's so baffling and what took me so long to track the problem down. It only occurs when the script is actually run, not when it's compiled or loaded.

That test script I posted does not give errors when activating the scripted object - something else is going on in your script.

So I tired your script with some minor edits and also got the errors - will try commenting out some things next.

Just a suggestion: Comment out the offending lines which include "torch" and see if the error goes away. Then go back and find the section that looks for torch_64 and carefully remove the _64, making sure that all the rest of the syntax is unchanged and see if the problem returns.

Somehow, it's the ID itself. I know you said it worked on your script when it was by itself, and I'm not questioning you on that... but this is one of the most frustrating errors that I've never been able to track down, and I'm sure it somehow involves the name of the ID itself. It's like somehow the routine that getitemcount uses for pattern matching just gets confused and errors out.

[edit] Oh, and by the way... thank you for taking the time to help me troubleshoot this. Sometimes people who get help forget to say "thank you." I do appreciate your effort.

You're welcome. I also find it bizarre that just that id is causing issues and curiosity get the better of me here.

And this is quite bizarre - I copy / pasted your posted script into the CS, and have now stripped out everything from your script except the lines that matched my test script (kept your messagebox text the same tho), recompiled, saved, and the darned thing still throws the errors on activation. I went back and even deleted and retyped the getitemcount and removeitem lines for id "torch"... same errors.

If I switch over to the identical script I posted (hand-typed into the CS) it works. :blink:


[edit] Success!
If the esp is dependent on both expansions (Tribunal.esm & Bloodmoon.esm) then the errors occur - making the esp dependent on one or the other, or just Morrowind.esm solved it.

Looks like all the torch objects in your script (apart from 'adm_torch_256' and 'torch_basic') are accounted for using Morrowind and Tribunal .esms - Bloodmoon isn't necessary. I take it that 'torch_basic' is just the default 'torch' id object renamed for testing purposes, and 'adm_torch_256' you just added for the mod?

I'm going to see if this will still work with both expansions by also making it dependent on MPP which fixes the CS errors that usually occur when loading up MW+TB+BM on the first CS session.

[edit2] Yep, making the esp also dependent on MPP gets around the bug if dependency on both expansions is also needed. ^_^


Now that it's working... some comments:
* when the torch gets placed into the holder, it's lighted for an instant then goes out - doesn't seem to matter if it's day or night when activated; granted I tested in an exterior location.
* torches will continue to be placed in the holder after the first; each can be moved back into inventory as expected; would be better to limit one torch per holder.
* a slight exploit, partially spent torches will also get removed from inventory, so when taking the torch back will give player a pristine copy.

The fact that you've tracked down the problem is astounding. As to your concerns, the first is almost certainly due to the type of torch you used to replace adm_torch_256. That torch is not only set as constantly on, but has a script on it to fix issues associated with placing lights via script. The second is intentional, and the third is a necessary evil, given that there's no script function that will detect or modify the existing condition of a light.

That said, I'm still at a loss as to what has actually happened. Knowing the circumstances under which the error occurs isn't quite the same as understanding what's causing it.

I don't understand how having both Tribunal and Bloodmoon dependencies can cause GetItemCount to malfunction, and only with this one very specific object. I checked both Tribunal.esm and Bloodmoon.esm and neither one of them even includes an object ID "torch" so how could that cause a conflict, and how could it cause GetItemCount to fail with a left eval error? And I guess another important question which is part of why I posted it in this thread in the first place is: Is this an indication of a problem with GetItemCount that needs to be looked at from the perspective of adding a new patch?

And to make matters even more confused, if having both dependencies causes the error, how does having a third dependency fix it? I presume that MPP doesn't actually modify the torch object itself, and the only errors that I'm aware of from loading both Tribunal and Bloodmoon have to do with dialog indexing. I can see how those errors could be resolved, but I don't see how that would have any effect on GetItemCount.

I don't see adm_torch_256 in any of the stock esms - is it of your own device?

Yea, I knew that would be your answer to the third comment - MWSE might be able to track the torch state. Um, you don't have some aversion to MWSE, do you?


MPP does not change the 'torch' object id. Maybe quorn can weigh in with specifics regarding the CS error fix.

I'm wondering if the dialog indexing errors when loading together both expansions in the CS are just indicative of some hidden additional underlying problems with the CS. After all it is what's doing the compiling of the script which then gets misinterpreted in-game. It wouldn't be the first time an error result pointed to the symptom instead of the cause. Whether the anomaly is getting introduced by the CS or Morrowind.exe itself will need investigation by someone with understanding of MW's code.

Hrnchamd doesn't work with source code from bethesda, rather AFAIK he's reversed engineered it and pretty much is stabbing in the dark with some things. Here's hoping he's willing to tackle it.

I know that this is from a ways back, but it's the best technical answer about this phenomenon that I've seen, and it makes me think that you might also be able to answer my own related question: what is the largest dimension map that can be made for TESIII without encountering this? My guess, based on my limited reading of your post, is 122 x 122 cells (that's six digits - 999,999 divided by 8192 each direction). Is that correct, or am I way off-base? If so, what is your recommendation for a maximum area without encountering this problem?

I personally have noticed no problems past -200, -200 or 200, 200, your player gets a tiny bit jerky, but that's IT!

Taking a look at the furthest section of Tamriel Rebuilt, there's a menhir located at 401856,180576 so obviously the game is capable of remaining stable with only a single decimal place. However, you're forgetting that a signed number can go from -999,999 to 999,999 and still remain in the six digit range. That means the maximum map is actually about four times what you calculated. Also, don't forget that the location (0,0) is in the center of cell (0,0), which means that each cell address needs to take into account an extra 1/2 cell. A cell at grid reference 122 is actually 122.5 cells from the center, which exceeds six digits.

Without experimenting to confirm, I'd guess (and please remember that this IS just a guess based on the math) that you could have cells in a range from -121 to 121 without any risk of jittering caused by lack of floating point accuracy. That would allow a map with a size of 243 x 243 cells. Exceeding that risks errors caused by a lack of precision. How significant those errors might be is something that would have to be determined by experimentation. I imagine that at the very least, it may cause issues in building objects composed of multiple statics, as a variance of a single pixel can cause flickering.

Those people that have tested areas beyond that range using only integrated statics (like trees or boulders that don't need to be pieced together) aren't getting a complete picture of the potential difficulties. Only a test involving multi-static objects will give an accurate idea of the risks involved.

Thank you both for your input. Based upon Toccatta's calculations then, a map just over 2.5x the size of TR's Morrowind (85x90) should experience zero difficulties. That's a pretty decent sized playing field if you ask me.

I've tested all kinds of statics beyond -200, including statics that need to be pieced together and i can honestly say i have experienced no problems what so ever.


Does this mean there will be a very special edition Morrowind Code Patch with an extra large map ????

FYI checking this issue out right now since you've narrowed it down so well.

As for the larger map you really need to test dynamic things, like enemy navigation, shooting arrows, collision detection for spells/projectiles, picking up small items etc. Errors can build up over several calculations, specifically collision detection because it involves intermediate calculations.