Hi Hrnchamd,
Toccatta asked me to report to you a bug that I found with the Code Patch. Not so much a bug as an incompatibility somewhere.

I realized last night while playing with the newly-installed Code Patch (latest version) that when my character became a vampire, no skills were increased. Since they usually are when becoming a vampire, this irked me a bit. So, I investigated and realized that whenever I had Vampire Realism and either of its expansion add-ons (for Tribunal and Bloodmoon respectively), the skills were not increased. If I disabled the expansion add-ons and left Vampire Realism, the skills increased as they should. Since I'd never had this problem before, I suspected it was due to the Code Patch.

I went through and uninstalled all the patches and re-installed them one by one and finally discovered that "Delayed spell crash fix" was the culprit. With it installed, no vampire skill increases took effect. They didn't even show up as spell effects. Without it, whether with Vampire Realism or without, they were fine.

In summary:
"Delayed spell crash fix" activated alongside Vampire Realism II Tribunal Add On and/or Vampire Realism II Bloodmoon Add On removed any vampire skill increases that should have been there.

Toccatta believed it should be brought to your attention, and I quite agreed. Hopefully I was clear enough!

Yensid

Given that I haven't seen any mods that involve reflective/bumpmapped skinned meshes, I'm willing to bet nobody - or at least no clothing-and-armor people - knows about this fix. Because I sure want to make some shiny clothes now...

I had no idea either.

This means I might have to go a try something.

EDIT: Now if only you could possibly get the engine to render normal maps without env maps. :hubbahubba:

This occurs because Vampire Embrace immediately teleports you to a crypt after the spell is applied, but before it becomes active. This is a similar situation to where spells in the middle of casting would become permanent and crash the game later on. The vampire abilities didn't crash as they are added by a script and not casted. I'll add another check for that kind of thing.

http://www.tesnexus.com/downloads/file.php?id=26348
Extract to Morrowind directory and re-run MCP for the new options.

Changes:

• Splash/main menu texture quality. Shouldn't affect the hit fader any more, while still making stuff look nice.
  
• Intimidate fix. Fixes disposition not increasing by minimum amount on successful intimidate actions (on marginal wins)
  
• Delayed spell crash fix. Fixes issue with acquiring vampire buffs with Vampire Realism. Caused by a false detection when adding spells and teleporting to crypt in the same frame.

If people could just check these work properly. I have to find all the other people who had problems with vampire stats.

I don't have time at the moment to check the Betas, but the "delayed spell crash fix" now works perfectly fine with VR, as you said.

Thank you very much for your prompt response on this. I really appreciate it! And thanks even more for this Code Patch. It's just amazing to me what some people are capable of.

was it ever discovered why having 100 in chameleon allows you to speak with hostiles? like vamps and bandits? why doesn't it default to "who's there?"

This response doesn't cover NPCs with nolore. That covers the vampires. Not sure about the bandits.

I'm still not seeing full range of magnitude for some variable magnitude effects when using the 'Spell magnitude fix'. In particular, the restore health from Fargoth's Engraved Ring of Healing (Heal_minor enchantment, mag 1-5). It always seems to result in the average - usually 3 points, sometimes 2; I've never seen 1, 4 or 5 points of magnitude healed. I'm making sure to test with a Race that's not resistant to magicka.

Also, magic items that show the same amount of charges left as the required cost for its enchantment will not cast - instead the 'Item does not have enough charge' messagebox gets displayed. Again as an example, Fargoth's ring has 20 charge capacity and 5 cast cost, but the 4th casting in a row results in the messagbox. The player must wait until the ring recharges to at least 6 charges to have a chance to cast again. The expectation here is that an item with an evenly divisible capacity will be able to cast its enchantment that many times resulting in no remaining charges. Maybe it's an issue with rounding up the displayed HUD value where it would be more consistent with behavior to round it down instead.


[edit] oh yeah, wanted to report that the hit indicator is behaving normally again after applying the beta 8 'Better quality splash and title screens' patch.

I created a 100% CE chameleon artifact and used it to wander around inside a daedric ruin with hostiles. I opened the console, clicked on a hostile and typed:

GetDetected "player"

Most of the time, it returned 1. On some occasions it did return a 0. However, when I went into sneak mode, it returned 0 on every attempt. So it would seem that the reason bandits don't give the "Who's there" comment is that they are somehow still detecting the chameleoned player even if they aren't responding in a hostile manner. I even used Larrius Varro's "present" to make myself temporarily 125% chameleoned. It seemed to make no difference. The response to getdetected player was still fairly arbitrarily 1 or 0 even when chameleon exceeded 100%.

To be thorough, I ran the same test in Balmora on non-hostile NPCs. The results were identical.

It seems more likely that the issue is associated with the GetDetected function itself than in the dialog system.



This has always been my assumption as well. It appears that both charges and magicka are rounded up in the HUD. Spellcasting suffers the same problem as enchantment casting in that regard. It's possible to have the same amount of magicka available as a spell requires, but be unable to cast the spell. However, if you have a magicka regen mod active, you can actually watch the percentage chance to cast jump from 0% to a normal value even when the magicka value doesn't change. I've always guessed this mean the rounded up value crossed the integer point and the spell was suddenly castable even though the indicated value was unchanged.

Oh, and I agree that rounding down in the GUI would be more intuitive under the circumstances.

[edit] I should point out with respect to your example, that the number of charges required to cast an enchantment is ALSO rounded. So when the ring starts off with 20 charges and it says it requires 5 charges to cast, that cast cost may actually be as high as 5.4999 charges to cast. This explains why you're not getting the 4th cast even though you should be able to. It also explains why you would need 6 charges on the ring to be able to cast: The difference in time between when you have the 5.4999 charges available to cast and the time when the ring's charge hits 5.5 and the value is rounded up is too short a time to even detect. For all intents and purposes, the ring would have to say 6 to cast a spell that says it requires 5 because one value is rounded up while the other is rounded down.

And as far as spell cast cost and enchantment cast cost, perhaps those values would be better off rounded to the next higher integer. (e.g. 4.2 charges available displays 4, while 4.2 charges required displays 5)

If you read http://www.gamesas.com/index.php?/topic/1097214-gameplay-mechanics-anolysis/, chameleon only adds 100 to the opposed roll, so there's still a probability of failing if you're not sneaking. Only chameleon of 200 or more will guarantee success in that case.

I'm not sure if the programmers ever used a round up. I think the spell cost is rounded down in the UI, when it can require up to 0.99 magicka more to cast (truncating float conversion is default behaviour).

That explanation makes sense with respect to enchantments, since the enchant skill does modify the number of enchantment points required to cast an enchantment. However, it doesn't explain the same problem associated with spell casting, since skill with a school of magic doesn't affect the number of spell points required to cast, and that value is defined in the construction set by integral values. So if a spell costs exactly 15 points to cast and the GUI says you have 15 points and you can't cast it, then it can only be because you have somewhere in the range of 14.500 - 14.999 magicka points and the GUI is rounding the available points up.

Oh, right. That's round to nearest integer, which technically isn't a round up operation but I see what you mean. I'll look at it.


For continous effect spells, such as restore or damage, the magnitude is randomised every frame for the whole duration. The total effect is accumulated over those frames, so by the central limit theorem you get a normal distribution of total effect applied, even over a one second spell. In other words, it's most likely the total effect is near the average, and extremes are very unlikely (0.032% for best case frame timing on Fargoth's ring).

Sorry. Minor difference in semantics. I tend to think in terms of "truncating", "rounding up" and "rounding to the next higher integer" which is basically the opposite of truncating. I understand the reason for the confusion and will try to be more explicit in the future.

In any case, I confirmed the rounding process by setting my character's willpower to 0 to effectively turn off magicka regen, then set my magicka explicitly to 300, modded the current magicka down by 50 points and then modding it back up by 0.4 points twice. The first time, the value didn't change. The second time it did. So the GUI definitely rounds to closest integer with respect to available magicka when it should probably round down).

I presume enchantments work the same with charges, but lacking any way in the console to change an object's charges, it's not as easy to verify. If that's true, then charges available should round down while charges required should round up. Neither of those values should round to the nearest integer in order to avoid confusion.

Will this allow for actual mirrors, or just mirror-like surfaces that actually respond to environmental lighting?

Thanks!

There is no rendering infrastructure for mirrors in the game, most games don't have them as it's complicated. We have environment maps with bump or gloss, and the already existing bump/reflect local lighting option makes it respond to light conditions.

While researching pickpocketing for the mechanics thread, it came up that anything over 100 septims has minimum chance to be picked at maximum stats due to the ridiculous value term. Someone should incorporate a solution into a balance mod, if interested. The existing bugfix out there that makes fPickPocketMod negative is incorrect.

Thanks for the update.
Maybe you can alter pickpocketing mechanics then? I do not think that value of an item is such a good measure of difficulty, especially when checking for detection. It is a weight of an object that makes it hard or even impossible to steal (if you are not ready to immediately put equally heavy sandbag in victim's pockets). One should be somewhat more careful with more valuable items (large sums of gold vs pocket change), but this is not always the case: take keys as an example. And you can only be careful to a certain extent, so the influence of item price should be capped. Maybe something like "min ( ( ItemPrice / 40 ), 25 )" can do. Plus complete inability for stealing items with weight 3 or higher, for example. There will be problems with stacks, however, but even like this it seems much more logical: I've never heard of pickpocketing practice that targeted not gold, jewelry or keys, but heavy books and big bottles. PCTerm will need some multiplyer, but not x2 like it is now. It should be nearly impossible to pickpocket extremely agile-lucky-sneaky NPC even with extremely agile-lucky-sneaky PC, I think. And with top PC and good NPC it should only be possible to pick something light and cheap, like keys or a small heap of coins.

Just throwing a random suggestion out here: Would it be possible to increase the number of stat multipliers you're allowed to choose at level-up? I don't mean the multipliers themselves, I mean the number of attributes that can be selected for an increase on the level-up screen (currently fixed at 3). This would eliminate the 'micro-management of skills' problem at a stroke without having to use complicated, script-heavy mods like GCD.

I was looking at that bugfix just now, wondering if it would work correctly. I got my answer...Thanks for the warning Hrnchamd. I'm checking your formula thread to understand how I could change the GMST to make pickpocket a valid option.

Anyone!
Is the feather as an abillity broken?
The common spell and CE enchantment works by subtracting the feather amount from current encumbrance.
The ability spell subtracts from BOTH current and maximum encumbrance.
I certainly hope I hit the right forum.

All abilities work by affecting current and maximum values of a certain stat. Abilities were designed for fortify spells only, for other permanent spells you should try curses.

http://www.gamesas.com/index.php?/topic/1098021-repairing-the-cogs-of-morrowind-no-20/