Some questions about Metalstorm

[onthos]

First off, I would like to say that I have read through this whole forum for details on this mod and I cannot wait for its release.
I do have some questions about it though.
Will the tohit % be capped at 95, or will there be a possibility of 100% chance to hit?
Will casting overlays on certain spells stack or cancel/restart when casted before the overlay ends? I've always hated how vanilla doesn't even cancel/restart the casting overlay on sorceress skills.

[kazein]

First off, I would like to say that I have read through this whole forum for details on this mod and I cannot wait for its release. I do have some questions about it though:

Will the tohit % be capped at 95, or will there be a possibility of 100% chance to hit?

Will casting overlays on certain spells stack or cancel/restart when casted before the overlay ends?
(I've always hated how vanilla doesn't even cancel/restart the casting overlay on sorceress skills.)

[Nefarius]

1.) It's still capped at 5-95%*, however there are some spells and attacks can allow units to bypass the routine. The underlaying mechanics are completely different though and will likely get even more aspects added in the future (the mechanics sticky is at least half a year outdated at the moment so it's not a reliable source), I'll probably update it when the current major work is done with.

* The % displayed in the charscreen can be below 5% if the unit can block, as the display now takes the target's blocking into account.


2.) Nice to see someone else was bothered by how vanilla handles the overlays. Yes, there are now stacking overlays for casting, and more notably for hitclass effects.

[onthos]

Wonderful.

This next item has less to do with Metalstorm than it does with your knowledge of other things, and thus may not be within the context of this forum, but I will post it here anyway.
I read in a thread about the *.INI file that there will be an option to assign the D2 process to a single core on multicore processors. Is this because multicore processors (or possibly Windows) natively try to divide work between each core?

[Nefarius]

There are bugs with mulitcore and multicpu technology. Each core keeps it's own count, so in games that use this for sync each core, depending on which the thread currently resides, can return a different count, which can lead to stuttering (time can suddenly jump backwards etc). There are several patches that address this issue, there is a provisionary patch by M$ that addresses the issue, and several hardware specific patches by vendors, but this does not resolve the problem for everyone. Old games like D2 weren't designed with stuff like this in mind, they dont gain any real benefit when they reside on more then one core unless you reach extremely high cpu load. A single 1 GHZ core is enough to run this game smoothly (and depending on your hardware and patches, more stable too).

On a multiprocessor computer, it should not matter which processor is called. However, you can get different results on different processors due to bugs in the basic input/output system (BIOS) or the hardware abstraction layer (HAL).