http://www.tesnexus.com/downloads/file.php?id=26348 release. There's still a lot people need to look at, please contribute.

Changes:

• Fog of war fix, a few more changes. Check if it's working.
  
• Enchant value item increase covers throwing weapons and ammo properly. Test new prices.
  
• Improved animation support. Should cause banners to behave properly now.

Still needs testing:

• Larger windows now covers birthsign menu and race menu tooltip. Test with different birthsign mods that aren't BAMF. Still no reports.
  
• Bound weapons expiry fix. Unconfirmed weirdness reported, please check if it works for you.
  
• AI casts zero cost spells. Check for zero cost offensive spells in Tribunal/Bloodmoon/any mods.
  
• Random spell deselection while wandering around still needs testing.
  
• Area effect multiplier. Zero radius multiplier fix needs checking. Still no reports.

Information on PlayGroup / LoopGroup:

PlayGroup and LoopGroup both play animations. There are three key differences:
- PlayGroup waits until the current animation is complete before starting the given animation. LoopGroup plays it immediately.
- Both loop the animation, but differently. PlayGroup plays the whole animation and ignores any Loop Start/End text keys. LoopGroup respects the Loop text keys.
- AI controllers depend on animation keys to know when the chosen action is finished. Since PlayGroup plays forever, it can freeze NPC AI. LoopGroup returns control back to the AI after it has played the animation. If you use PlayGroup for it's waiting behaviour, then PlayGroup idle will usually return the control to the AI.

There are a lot of things that don't work as you would expect, where the name or documentation is wrong or outdated. I will try to research some of these for you, as I'm waiting on test results.


You can make spells consume fatigue with these. It's best if you ignore the names but look at the equation:
fatigue loss = encumberance % * fFatigueSpellBase * fFatigueSpellMult * spell magicka cost


This is correct, these are not used in the game, but could be added with little problems.


These are rarely used as part of a quest line, so they haven't been tested much. I think iDispKilling only works on the one NPC that reports you for a crime, it looks like they are in the same function. I'm not sure of the exact conditions that should trigger these, it seems difficult.


Someone asked me in the last thread too. You can read my reply there, but in short, it would be easy to repeatedly use bartering to increase disposition. Some extra mechanic is required to make it work well.


It is a good idea. The current patches replace existing functions with new ones. What you propose requires a lot more code to read attribute X and skill Y depending on config Z, which means new code paths that will no longer fit in the existing space in the program. Regarding the soulgem value, it's not a simple X*Y+Z equation and so can't be configured easily, if you require a new formula, you have to write code. Then you need another program outside to set all the new data required; it's not efficient for the time I spend working on all that infrastructure. What I can do is researching where to add back unused GMSTs.

My fog of war does not always paint in visited areas correctly. Here's a screenshot showing my little compass arrow surrounded by black: http://yfrog.com/0afowpj
Also, if I open console and do "fixme", my local map goes black, like it's an entirely new area without any visited areas painted in.
Sometimes going from interior -> exterior, the visited areas are (temporarily?) forgotten and I have to travel around before I start seeing previously visited areas correctly painted in.
Not sure if maybe running on Linux has anything to do with it.

Bound weapon expiry works for me. When the bound weapon expires and if it has been put away, my most recent weapon no longer pops up like it used to.

Still testing.

Thank you.



My apologies for the misinformation. It seems that I've been testing this too long ago, when my methods was just starting to form. I've tested it again now, and it seems that everything works according to this formula. However, the formula itself is unusual: normally it is "BaseCost + (Encumbrance% * MultCost)", and I think it is more flexible this way. For example, I would rather prefer spells to be fatigue-consuming by themselves then only because of encumbrance (and I would even argue if encumbrance have something to do with magic at all).


It would be very kind of you to do this. My sincere gratitude in advance.


I've tested it in a room full of NPC. All those who saw my killing hated me. Sometimes. But most of the time they didn't. I can redo these tests, if you desire so.


I'm sorry, but I think that this is a problem for a modders, and it is worth about 10 seconds of their time: it can be solved with simply setting both of this GMST to zero or less. Personally, I would make it so that failed bargain attempt would lower relations by 1 permanently, while successful would just do nothing. However, I can imagine that someone can come up with another idea that he can live with. And by any rate adding a feature like this can hardly hurt anything: temporary boost to relations can be exploited just as well, and it is a known exploit to address in balancing mods.


I'm sorry, but I'm failing to understand this. If current patch program executes some line like "insert 'zxc 40*fBaseCost' into line 123A", what is the problem with making this 40 adjustable by patch program just once before applying the patch? If I understand correctly, the resulting .exe will not feel any difference when receiveng a line that varies only by some small number, and for a patch program this would mean just a tiny additional piece of code that seeks for a value in an input field. I can see a problem when there are more then just a number that can be changed, but even if it would only be available to adjust numbers like this, it would already be a great boon.


Thank you again for your time and efforts.

It may be along the lines of doing things is more tiring when you are carrying lots around, similar to running or jumping. It's most likely the original designer made a mistake and used * instead of +.


The problem is 95% of people will just turn that on, and not understand or use a balancing mod for it. I would not want to add another exploit to the game (even if it has many already) without checking for the best possible way to make it work. It's just bad design to do otherwise, it can take the fun away if you know about it. It will be added in a beta version so people can try and discuss it.


Yes, I'm only making clear the difference between changing constants like 40, and changing formulas, attributes used in the formula, and other things. It's a rather large difference and it's difficult to add just a little more. Even for changing constants, they are shared with other functions. To change one, I have to separate the number and give it its own storage space.

I won't disagree with you. (BTW, if anyone's following this, the specific module in the role-playing suite I was referring to is "Magicked Out"). I'd personally like to see 'stamina' loss based more on Willpower than Encumberance. (But, as far as my mod goes anyway, I don't know how to do that yet).

I can't get to the beta through tesnexus for some reason. I get an error message saying the link is dead or unavailable.

You have to turn on scripting for the links to work.

It seems so. Can you please try to fix it sometime?


Well, this GMST is set to zero by default, so one would first need to be ready to do some modding to make things exploitable. And I think that if someone is willing to mod his game, he should be trusted to know what he wants, for he will certainly find an endless number of ways to make his life easier if he wishes so. If this alone is not enough, I can think of adding some warning in the description of this option in patch program. Something saying "This option is for modders, and they better be careful not to spoil everything!" maybe.


This I cannot seem to grasp. Are you saying that, for example, this 40 in a new HtH damage formula, is not a hard number, but a constant that was taken from some other part of code just because it fits? Or are you talking about problems of coding on the patch program side? I'm sorry if I bore you with such questions, and I will understand it if you would stop wasting time on me.

I also have some other questions, I'm afraid. What about (re)moving a cap on attributes and skills? I'm sure this question was already asked many times, but I don't know if you answered it or not. It would be another great feature that allows some new ways of altering a game balance.

And finally I wanted to ask about light sources. If I understand correctly, there is currently no way of changing the range of light source. I tried to change light intensity for a torch, but it only makes light bright or dim, with no changes to the radius. I think it is pretty illogical and somewhat frustrating (though I can imagine that it has some technical reasons). And again, it would be great if it can be changed (by connecting radius to intensity), if it is possible at all and requires acceptable amount of time and work.

Both fDispBargainSuccess/FailMod and iBarterSuccess/FailDisposition are 1/-1, not zero by default.


Yes, this is correct. It's always good to ask anyway.


Lots of the functions in the game cap attributes at 100 before they are used, it will take a while to survey all the places it occurs. It's not really a game bug or a simple addition, so it's not as important to work on.


In Morrowind, vertex lighting is used. It means the lighting at the corners of a triangle is calculated, then the value is interpolated across the triangle. If you want small radius lights, or if the model you are working on has large triangles, then the lighting will just look dark. e.g. Vivec exterior ramps. The only way to make it look good with this engine is to add more triangles to the models. I'm not sure if that's what you meant, tell me if it is.

Sorry. You are right again. Still, what about simple warning?


Then it seems like a very low-priority feature indeed. Thanks for your patience.


If it is like this, then yes, I must agree.


My apologies, I've tested light sources again with greater values of radius (64 vs 4096) and found out that everything's working as intended, it just didn't look so with small values.

By the way, do you have any methods of quick and easy detection of something in the code? For example, can you look for some GMSTs in the code and see if they are used at all, and if they are, in what calculations? Or is it too much manual work? I have some insight on what most of the GMST is doing, but some of them doesn't seem to do anything (while not being confirmed unused), while some others are working strangely. Some formulas need more studying too (chances of persuasion, for example).

Testing is harder than it looks, but we do it anyway. For the sake of quality.

It's easy to find out where GMSTs are used and what the formulas are. Make a list of the most interesting ones, as there are hundreds of them.

;P Thats the first thing I do when a page doesn't work properly, but I do already have TesNexus scripts permanently active I was still receiving the error message last night (on two separate computers).

Whatever the issue was it seems its gone now though and I have downloaded the beta. *gets ready to test betas*

I may be a bit late on this, but I'll like to give my opinion on a few changes I read about on this thread.

Ammo enchanting: Wonderful feature, but extremely frustrating to be unable to enchant less than the soul size. If you plan on adding the possibility to enchant up to the soul size instead, that would be superb. However, imo an ingame message like "11 items enchanted on possible 100" would be unnecessary and very annoying after the first few times. When you soultrap, there's no "you filled only 200 of possible 600 soul capacity of the gem" message. I think a clear description for the feature would be enough. Finally, about the soul required per item, I would personally like a rate of 2 a lot, but a rate of 4 would still be enough to enchant big packs of arrows. (100 self-enchanted silver arrows is what I have in mind) Separate identical effect arrows stacks are no fun really.

Anyway, thank you for all your hard work. It's truly amazing.

This is what comes in mind:

iAutoRepFacMod
iAutoRepLevMod
It should have something to do with NPC<->PC faction and disposition/reputation, but it seems to do nothing.

fDispositionMod
It doesn't seem to affect prices or persuasion chances.

iLevelupMajorMultAttribute
iLevelupMinorMultAttribute
iLevelupMiscMultAttriubte
iLevelupSpecialization
Seems to be unused.

fCombatDistanceWerewolfMod
IIRC, it doesn't influence HtH reach for PC in werewolf form.

fSwingBlockBase
fSwingBlockMult

fAutoSpellChance
fAutoPCSpellChance
iAutoSpellTimesCanCast
iAutoSpellAttSkillMin
iAutoSpellAlterationMax
iAutoSpellConjurationMax
iAutoSpellDestructionMax
iAutoSpellIllusionMax
iAutoSpellMysticismMax
iAutoSpellRestorationMax
iAutoPCSpellMax

fMagicItemConstantMult
fMagicItemCostMult
fMagicItemOnceMult
fMagicItemPriceMult
fMagicItemStrikeMult
fMagicItemUsedMult

fMagicCreatureCastDelay
fCombatDelayCreature and fCombatDelayNPC governs delays between attacks/casts, so what is this then?

fDifficultyMult
Have a very strange (non-linear, it seems) influence on chances, damage, etc.

Finally, there are two more interesting formulas: persuasion chances and sneak chances. They are hard to test to get more or less accurate formula, and it would be very nice to know them.

If you try the latest beta, it allows what you ask for, and there are no messages. Enchanted arrows are quite rare in the original game, so I am looking at 3-4 soul points per projectile. If you have some time, please review the patch description text file (describe.txt) to see if the explanations are clear enough. Arrow enchanting does need an update, but it's not finalised yet.

Sounds good. I was about to start anew anyway, so I might as well do some testing with the beta. Beta 6 is the latest, right?

Yes, it's the latest.

To test some specific numbers, I installed the beta patch and then tested a golden saint soul with 400 ebony throwing stars (made with Morrowind Crafting and a high smithing and mining skill). I also have created a small "enchantable ammo upgrade" mod which ensures that all missile weapons have at least 1 usable enchantment point and that high-end ammo has more than low-end ammo, with daedric having 9 enchantment points, ebony having 7, glass having 5, orcish and silver having 3, and iron, steel, bonemold, and corkbulb having 1.

I used the full 7 enchantment points to make Ebony Fire Stars with a cast-on-strike 31 points of fire damage. The beta patch still doesn't include the soul-point ratio, so I created the full 400 stars. The base value was 2,000 and the new value was 5,500 for an increased enchantment value of 3,500 gold.

That's much improved even over the previous patch. However, that still leaves a 3,500 gold increase for each of 400 stars. Effectively, the golden saint soul was worth 7,200 gold before enchanting and 1,400,000 afterward. Now, I realize that this will be significantly improved when the soul points/unit change is implemented, but even if you only make 1 item for every 10 soul points, that would still result in a golden saint soul essentially worth 140,000 gold.

Dividing the enchantment increase over the total number in the batch would eliminate the money exploit, while still leaving the total increased value of the enchantment itself unchanged. It's questionable whether the value should be divided over the amount of ammo created or the amount of ammo that COULD have been created. Personally, I think it would be divided up amongst the total possible, so that the increase would be the same per item if you made 1 or 100. It doesn't make sense to me that if I were to make 1 arrow with an enchantment and then make another 100 with the exact same enchantment, that the first should be significantly more valuable than the rest.

If such a method were used, I would prefer to see the enchantment values for ammo raised just a bit. Perhaps 50% higher for ammunition only - no change to individual items. That was a fairly valuable enchantment, but the end result would have been somewhat low if it had been divided over the batch (and seriously unbalanced if it were not). If you don't use such a method, then enchantment prices could stand to be lowered again, perhaps as much as 75% (again, for ammo only). An increase of 875 gold per star would be preferable to a 3,500 gold increase.

After reading Logorouge's comment about how soul gems don't give warning messages when you use less than their full capacity, I think I have to agree. I hadn't considered that aspect when I posted my previous comment regarding warning message boxes. Neither does the game give you a warning if you enchant an item using only 1/2 its enchant potential or if you sell an item for 10% of its value. The game (rightfully) allows the player to make mistakes without hassles, warnings, or hand-holding. Perhaps I'm just too cynical, but I have no objection whatsoever to allowing the player to suffer for failing to read the instructions. I do, however, dislike the idea of being repeatedly warned by the game that my use of the enchanting skill wasn't as efficient as it might have been.

Please state which beta you are testing (that goes for everyone). This behaviour was changed in beta 6, please test it again.

Okay, an anolysis of some of those GMSTs:

iAutoRepFacMod, iAutoRepLevMod
These are settings for autocalculated stats. NPC reputation is an autocalculated attribute, dependent on faction and level. No direct effect on PC.

fDispositionMod
This affects the amount you can haggle successfully. By haggle, I mean decrease/increase the price from the offer a merchant gives you.

iLevelupMajorMultAttribute, iLevelupMinorMultAttribute, iLevelupMiscMultAttribute, iLevelupSpecialization
The first three are used to make skill levelups count multiple times towards an attribute level up, while only increasing the 'progress towards level increase' counter once. iLevelupSpecialization is used once, but I can't see what effect it is supposed to have in the end.

fCombatDistanceWerewolfMod
It affects reach, but combat distance is hard capped at 1000 units, possibly less if there is a hand to hand reach modifier.

fSwingBlockBase, fSwingBlockMult
These affect the chance of blocking attacks that have passed the hit roll. Here, swing is how hard you are striking - how long the attack key is held down for PC, randomized for NPCs. Minimum attack is 0.0, maximum attack is 1.0. Block difficulty is multiplied by fSwingBlockBase + fSwingBlockMult*swing. Higher difficulty is harder to block.

fMagicItemConstantMult, fMagicItemCostMult, fMagicItemOnceMult, fMagicItemPriceMult, fMagicItemStrikeMult, fMagicItemUsedMult, fMagicCreatureCastDelay
All these are unused.

fDifficultyMult
This is related to the difficulty slider. 100 difficulty slider -> 1.0 as used in formulas

for NPCs: damage multiplier = 1 + fDifficultyMult*difficulty
for PC: damage multiplier = 1 - difficulty/fDifficultyMult

Just wondering out loud here, but I wonder if there is some way to cap skill levels depending on specialization. Major skills could go up to 100, but minor skills would stop at, say, 80, and misc skills could only go up to 60.

Sorry. I shouldn't have assumed you would know I was referring to the most recent beta. I downloaded and installed from the beta 6 link you gave in post #51 of this thread. The resultant file was MCP_beta-26348.zip and I activated all of the beta patches in addition to the ones which were previously active. During my testing, I was still able to create 400 throwing stars from a 400 point soul, and I was unable to enchant the 9 daedric darts I had collected, because they were too few in number.

I presume that when I click the "apply chosen patches" button that it restores a backed up copy of the executable and applies the selected patches to it. Is that incorrect? Do I need to tell the program to uninstall all patches before installing the new ones?

Checked the describe.txt and all the features descriptions are crystal clear.


Testing some of the Beta 6 features:

-Larger service/chargen menus: Started a new game with Expanded Birthsigns for Purists. Some birthsigns had abilities I previously didn't even know about because the space for the description was too short. The larger service menus are also very convenient. Could something like this be applied to the alchemy ingredients selection menu?

-Reduce camera clipping: I don't use 3rd person view often, but once I'll install Abot's guar mount mod, I think it will be quite useful.

-Stable enchantment sort: This one is a bit tricky to check since the problem is so unstable. But so far so good.

-Bound Weapon expiry fix: Expiring bound spells are dangerous with bad timing, so I'm happy this one works perfectly.

-Level-up stats bug fix: No more wasted multipliers. Leveled, saw the 98->103, confirmed and got 100 intel. That works for me.

-Spell deselection bug fix: Didn't fight any NPC with enchanted items. Can't say anything about it yet.


I'm happy to say I didn't encounter any problem at all. Plus, upgrading from MCP 1.6 gave me Unrestrict Menu Size and Toggle Sneak. Oh and the arrow enchanting is...superb. Enchanting with only a fraction of the soul. With the ratio added, it will be perfect (for me at least).




That's something I would use. Major/minor skills choice would have a greater meaning. (and no more god of all trades)

GCD sort of does that, by making it take longer to increase a skill (by making it require two or three skill increases before it actually raises) once it gets to a certain point based on what the skill started off as. So, if one skill started at 45 and one started at 5, the second one would start requiring more increases at a lower skill level than the first. I'm not sure I described that very well, but personally I like that system better than a cap because it gives meaning to major/minors, while allowing non-major skills to still have the possibility of being useful with more work.

I think a skill level of 60 is still useful... just not as useful at, say, 80 or 100.