Add the ability to manually turn blocking on and off on demand

[julealgon]

Summary

This is a proposal to introduce a new active command in the game: a button to toggle blocking on and off at any point. This will allow advanced players to decide whether it is beneficial to block or not in any given situation, regardless of their resistances, armor, blocking chance, etc.

Background

Some people voiced concern over the behavior difference between Diablo and Hellfire when it comes to blocking elemental projectiles. In Diablo, when a player has positive resistance to an element, the hero will not attempt to block projectiles of that element type. In Hellfire, this behavior was changed so that blocking would happen normally regardless of resistances.

Instead of opting for one or the other, I'm proposing a more general purpose solution that leaves the decision to the player. This would introduce extra strategies where the player has more control of the blocking, opting to try to block or not at any given situation.

I feel this would solve the debate on Diablo vs Hellfire difference, while generally improving on the game and introducing a solution that is more flexible to the codebase.

This is one of the rare changes that I feel could be integrated natively in DevilutionX instead of only being a mod. It has an impact on gameplay, but the impact can mostly be reproduced today anyways by swapping equipment around (unequiping the shield, for example). In that sense, it could be seen as a QOL feature.

Details

• By default, behavior should be "always try to block" (current standard). Emphasis on "try" (block chance logic is unchanged)
• Pressing a button should toggle the behavior between "try to block" and "do not try to block"
• It should not be specific to any type of attack or element type. It's a "block everything" or "block nothing" toggle
• When blocking is disabled, something should be shown to the player to indicate that. A new icon would be ideal. Open to discussions about where in the screen this would show. When enabled (default behavior), nothing is displayed.
• Toggling the block behavior should send the information over the network to other players, so that the heroes behave consistently on all instances of the game
• The behavior should ONLY impact blocking. Other benefits of having the shield equipped should remain, including its armor. This is NOT equivalent to outright unequipping the shield
• The toggle should also affect other forms of blocking besides shield. All blocking should be consistently toggled (see monk)
• New entry on the help menu should be included to explain the new command
• There should NOT be a .ini toggle for this. It's inherently "opt-in". If someone never wants to use it, they are free to do so by never pressing the switch button

[AJenbo]

An interesting mechanic, feels like a good idea, even if we decide that the mentioned issue is a hellfire bug

[Psojed]

On the topic of blocking spells above 0% resistances, I see it as a positive change, a nice improvement for the melee classes that previously had to risk taking heavy damage from wearing no resistances if they wanted to block. The original Diablo setting makes little sense: I can deflect a sphere of fire when not resistant to it, but as soon as you become a little resistant, the sphere automagically passes through shield and deals damage :)

I believe that in most cases, players would get block-locked only when getting surrounded by fast attacking monsters. These situations can be counteracted (simply by not walking into a mob of demons for example), so the resulting block-lock issue is probably the player's own fault. I like the idea of giving the players an option to choose to stop blocking and (potentially) die, preventing being stuck in a corner, not dying but also not being able to escape.

However, I dislike the idea of the toggle affecting all players in a multiplayer game. I can imagine a sorcerer player disabling blocking to avoid the block animation, but damaging a warrior player's survivability significantly in the process.

---

PS: I thought of another solution. What if you could consecutively block X amount of times, and when you reach that amount, the block calculation gets temporarily disabled. This would simulate fatigue when continuously blocking attacks. Performing a non-blocking action (attacking, spellcast, going into hit recovery ..) would reset the counter. 20 blocks should be sufficient.

[julealgon]

However, I dislike the idea of the toggle affecting all players in a multiplayer game. I can imagine a sorcerer player disabling blocking to avoid the block animation, but damaging a warrior player's survivability significantly in the process.

I have no idea why you got the impression that it would be a global toggle @Psojed . What I suggested is a per-player toggle, and a way to "communicate to other players about your toggle" so that the same character would behave consistently on all players' screens.

Making this a global toggle would make zero sense.

PS: I thought of another solution. What if you could consecutively block X amount of times, and when you reach that amount, the block calculation gets temporarily disabled. This would simulate fatigue when continuously blocking attacks.

This sounds like a stamina system to me, and I consider those mod territory. I have a bunch of ideas regarding stamina but have not proposed them for DevilutionX for that reason.

Performing a non-blocking action (attacking, spellcast, going into hit recovery ..) would reset the counter. 20 blocks should be sufficient.

This seems all very arbitrary to me.

[yuripourre]

@julealgon this is a very interesting idea, looking forward to it. The first time I read the network part I misunderstood too.

[Psojed]

I have no idea why you got the impression that it would be a global toggle @Psojed . What I suggested is a per-player toggle, and a way to "communicate to other players about your toggle" so that the same character would behave consistently on all players' screens.

I got that idea from this sentence: Toggling the block behavior should send a new command over the network to other players, so that the heroes behave consistently on all instances of the game Since the idea was actually to send information about a player using the toggle, not a command to toggle other players' behaviour, consider editing the sentence to: Toggling the block behavior should send the information over the network to other players, so that the heroes behave consistently on all instances of the game @julealgon

[thebigMuh]

At first I didn't like it at all, but it has grown on me a lot.

I suggest naming it "Stance switching" - the player can switch between "Defensive Stance" (default, current Hellfire behavior) and "Aggressive Stance" (blocking is disabled - or maybe blocking only happens when the player stands still? - in any case, blocking should no longer interrupt attacks in this stance, which is what causes the grief with the Hellfire change).

• Pressing a button should toggle the behavior between "try to block" and "do not try to block"

I suggest to both assign a button, and create a UI element that clearly indicates the current stance. Pressing the button or clicking the UI element could switch between the stances.

• It should not be specific to any type of attack or element type. It's a "block everything" or "block nothing" toggle

If in aggressive stance, I would still allow blocking if there is no player input. I.e. alter the current check for the player mode from PM_STAND || PM_ATTACK to ignore PM_ATTACK while aggressive mode is enabled..

• When blocking is disabled, something should be shown to the player to indicate that. A new icon would be ideal. Open to discussions about where in the screen this would show. When enabled (default behavior), nothing is displayed.

I would show a new element on the bottom panel. Maybe somewhere next to the HP demon. I would show two different states (aggressive and defensive, maybe switching between crossed swords and a shield) and always show that element when the feature is enabled.

• There should NOT be a .ini toggle for this. It's inherently "opt-in". If someone never wants to use it, they are free to do so by never pressing the switch button

I would add a [Game] ini entry to enable that feature explicitly, and disable it by default, similar to how other non-vanilla features are handled. If someone wants to have this, they have to enable it. While the feature is disabled, no trace of it shows up in game.

If there's maybe an advanced in-game options screen planned for the future, that would also be a good spot.

Like I wrote at the beginning, I really like this.

[julealgon]

@thebigMuh insteresting idea associating this with a "stance". That does seem quite intuitive and easy to explain.

I would add a [Game] ini entry to enable that feature explicitly, and disable it by default, similar to how other non-vanilla features are handled.

Emphasis mine. Not all new features have a toggle. See shift+clicking potions and items in inventory, preserving cursor position, auto heal at pepin, etc. I don't think this needs a toggle because the feature itself is a toggle ingame. If one doesn't want to use it, he just doesn't change stances, and nothing is affected.

I disagree with the concept of "every change being a toggle in the ini file".

[thebigMuh]

I disagree with the concept of "every change being a toggle in the ini file".

Certainly not every change, but in this case I'm for having a clearly visible indicator/button in the hud at all times that informs the player in which stance his character is. The ini option would completely toggle the entire feature, including that button.

[julealgon]

but in this case I'm for having a clearly visible indicator/button in the hud at all times that informs the player in which stance his character is. The ini option would completely toggle the entire feature, including that button.

Why do you feel having an extra button in the UI that one doesn't need to use is a problem @thebigMuh ? I see zero harm.

[Psojed]

XP bar is also an extra element in the UI, yet it was implemented as a toggle in the ini file.

[thebigMuh]

Why do you feel having an extra button in the UI that one doesn't need to use is a problem @thebigMuh ? I see zero harm.

Don't think it would do harm as such, but I think it's nice that, by default, devilutionX looks and feels pretty much identical to standard Diablo/Hellfire. If someone wants to play without additional stuff, there should at least be an option to do so. Is there some reason NOT to have an ini setting?

[AJenbo]

Don't think it would do harm as such, but I think it's nice that, by default, devilutionX looks and feels pretty much identical to standard Diablo/Hellfire. If someone wants to play without additional stuff, there should at least be an option to do so. Is there some reason NOT to have an ini setting?

It gets cluttered, both in the code and to the end user. People already struggle understanding it. If we can find a better way to deal with this first there is more of a chance that we would be ok with adding more to it.

[julealgon]

XP bar is also an extra element in the UI, yet it was implemented as a toggle in the ini file.

Personally, I don't think there was a need to have a toggle for the XP bar at all. Again, this is my, personal view. Please do not conflate what I believe personally with what DevilutionX goes with. Using those examples to counter my personal opinion on each feature is not very useful @Psojed .

---

but I think it's nice that, by default, devilutionX looks and feels pretty much identical to standard Diablo/Hellfire. If someone wants to play without additional stuff, there should at least be an option to do so.

Are you in favor of a "20 FPS cursor" toggle then @thebigMuh ? What about a toggle to "opt-in to shift+clicking to/from inventory"? Should we not be widescreen by default, to preserve the original feeling of vanilla?

Is there some reason NOT to have an ini setting?

Feature flags (the general design pattern, also called feature toggling) adds complexity to a system. For every flag, the code needs to branch to support 2 distinct behaviors, and you have to maintain those 2 behaviors indefinitely while the toggle is exposed. They also tend to start interacting with each other, in which case the complexity of handling them becomes exponential.

Believe me, I've worked on an enterprise ecommerce system where we had upwards of 300 feature toggles and this made the whole system extremely complex and bug prone. Sometimes you cannot properly predict the correct interaction between several flags and this creates unpredictable behavior.

Lastly, having the flags there adds significant cognitive load on users too. With each flag, there needs to be readme updates, explanations, and the ini file grows. The more the ini file grows, the more complex it becomes, and the more users misuse it and create reports about "nonissues". It really snowballs very fast when you start to add too much configuration.

This is why I think its best to consider things on a case-by-case whether it really makes sense to have it toggleable, or if it could be implemented as the "native behavior". The latter is usually preferred for its simplicity.

I hope this clarifies my position about toggles and why I think "just add an ini flag" is ill-advised for the health of the project.

[AJenbo]

Personally, I don't think there was a need to have a toggle for the XP bar at all.

I actually also considered having the XP bar there, at least by default. It integrates nicely and the only change is that you don't have to frantically open the char panel like some streams do (very unpleasant to watch). In the end I decided against it for 1.2.0 just to be on the safe side.

[Belix161]

This is one of the rare changes that I feel could be integrated natively in DevilutionX instead of only being a mod. It has an impact on gameplay, but the impact can mostly be reproduced today anyways by swapping equipment around (unequiping the shield, for example). In that sense, it could be seen as a QOL feature.

While I admire the merit of your suggestion aiming to add more tactical decisions to the game and your desire to do so in a way that respects the original game balances and behavior, as someone who spent most of his Diablo time playing multiplayer (online/offline) and Ironman as opposed to single player, I strongly disagree about having this implemented natively.

1) It's already too common in multiplayer that someone is standing in a choke point on someone else's screen when on their own client they aren't. The Rogue or Sorcerer getting ripped to shreds because the Warrior played a block animation in or adjacent to a doorway on their screen isn't one of the game's fun points, IMO, and this feature will only make that type of stuff happen more often.

Here's why: In MP, taking hits and blocking are not synchronized at all, but are simulated visually by each game client. When you see another player being stunned or blocking, that's your game rolling to hit chances against their stats and deciding if they're hit or not. The other player's client only reports to you changes in their health, and death. This is quirky enough already with vanilla D1 behavior, because on your screen you see them block hits that they actually took, or get stunned by hits that missed them on their own game. Allowing part or all of Hellfire's blocking behavior to remain means more desync. I'll describe an example scenario of this further below.

2) Due to the above, you wouldn't even be able to see another player using this ability properly. Even if the network code was changed as you suggest so that each client was aware of another player's block setting, it still wouldn't synchronize correctly -- and modifying all the networking code to correct the many things that don't sync properly in MP is probably far outside the scope of a Vanilla + QOL experience and goes into mod territory also.

3) For playing Ironman sessions (which used to be a popular way to play the classic game back in the day -- I'm pretty sure that's why they added the 'Hardcore' button to the Diablo II character creation screen), both of the above issues are worth extra consideration:

First, regarding block/desync, in Hellfire, Block chance was checked before Armor Class was checked, which meant a lot more blocking was going on. Because it isn't synchronized properly it increases the chance of player location desynchronizing. Here's a situation that can happen in vanilla Diablo: Let's say a Warrior and Rogue are doing an Ironman duo. It's a melee only floor, so the Warrior is pulling monsters back to a doorway. The Warrior walks through successfully and stands next to the Rogue on their screen, allowing the Rogue to fire on the enemy, but on the Rogue's screen the Warrior just stopped to block a melee attack in the doorway. The Warrior, now through the door on his own screen, now clicks to attack an enemy, and this action is sent over the network. On the Rogue's screen, the Warrior is now attacking enemies while standing in the doorway and blocking it completely so she can't fire or help. The Warrior now also appears to be taking a lot of blocks/hits, even though his HP isn't going down. If we increase cases where blocking can happen like Hellfire did, risks of desync like this increase with each case. Even if we only implemented part of that blocking behavior (like being able to block spells with resists), this same example and other cases become more likely to play out in doorways in the Caves thanks to acid beasts, magma demons and succubi. Any of these various situations generally lead to these three undesirable scenarios:

a) A fellow player appears to get surrounded and trashed by mobs, but is actually somewhere much safer. b) A fellow player seems to be rudely obstructing your bow or spells, but is standing somewhere else on their screen and unaware that they're blocking you on yours. c) A fellow player is blocking your movement when you're trying to escape enemies, and you get murdered while on their screen your passage was clear.

Second, regarding individual players being able to toggle it, anything that deviates from classic gameplay is essentially a cheat in Ironman. In this case, it would let you block hits you would have normally taken without much indication to other players that you're using it. Nothing would prevent someone from using it and not telling anyone to shrug off some spell damage on a melee/caster mixed floor, and since you can't see another player's resists you wouldn't have any easy way to know if they're blocking because they unequipped up to 75% resistance and are risking taking hits with 0% resist, or just turned this proposed block feature on so they can block while still having 75% resists.

* There should NOT be a .ini toggle for this. It's inherently "opt-in". If someone never wants to use it, they are free to do so by never pressing the switch button

If this was implemented, I would raise hell (hah) if it was implemented active by default. If done at all, I think it should absolutely be an .ini option.

Also, I personally believe it is bad practice to add potentially unwanted doodads to people's screens and claim it's okay just because "they don't have to click it" -- have you seen all the enraged posts across the internet about things like Discord adding the "Stage Discovery" button in the friends list column that no one has to click...? And that's a case where it is a change made by the owners of the program. Here we're talking about adding things to someone else's game UI that hasn't changed in 2 decades. I feel having the XP bar by default is fine because the sequel does it and honestly, trying to figure out how much closer you are to reaching Level 40 (169122009 XP) from Level 39 (135274799 XP) by looking at the numbers is mental abuse to humans.

One last thought: we should consider newcomers just trying Diablo for the first time. They won't understand how that button works, and may not even realize that it isn't a feature from the original game. It would need a lengthy tooltip blurb on screen because there's no way they're going to go peck around for some help explanation buried away elsewhere.

Well, I'm pretty sure I've made my plea to leave this feature for the realm of mods clear. With any luck I've convinced someone here. :)

[AJenbo]

Here's why: In MP, taking hits and blocking are not synchronized at all, but are simulated visually by each game client.

Since we are actively working to solve sync issues like these it would seam to render a good part of your argument moot.

[julealgon]

@Belix161 Most of your concerns over implementing this are based on other bugs. As ajenbo said, we intend to fix those, not keep them. Implementing something that actually causes them to happen more often is actually beneficial to us, as it makes it easier to reproduce and debug them.

Second, regarding individual players being able to toggle it, anything that deviates from classic gameplay is essentially a cheat in Ironman.

Do you consider using widescreen resolutions a cheat in ironman? What about shift clicking potions to belt?

In this case, it would let you block hits you would have normally taken without much indication to other players that you're using it.

Nothing prevents us from having visual indicators as well.

If this was implemented, I would raise hell (hah) if it was implemented active by default. If done at all, I think it should absolutely be an .ini option.

Not sure what you mean by "active by default". What i proposed was for it to be "the vanilla behavior by default.

Also, I personally believe it is bad practice to add potentially unwanted doodads to people's screens and claim it's okay just because "they don't have to click it" -- have you seen all the enraged posts across the internet about things like Discord adding the "Stage Discovery" button in the friends list column that no one has to click...?

I'm of the (unpopular) opinion that "people don't know what they want/need". I don't particularly care about anyone's specific take on any single feature and don't necessarily consider that when coming up with something new.

And that's a case where it is a change made by the owners of the program. Here we're talking about adding things to someone else's game UI that hasn't changed in 2 decades.

Not sure what your expectations are. Devilutionx is not vanilla. The UI is bound to change. It hasn't been changed yet because of lack of resources on our end (creating art is hard).

I feel having the XP bar by default is fine because the sequel does it and honestly, trying to figure out how much closer you are to reaching Level 40 (169122009 XP) from Level 39 (135274799 XP) by looking at the numbers is mental abuse to humans.

That seems very arbitrary to me, you just contradicted yourself.

One last thought: we should consider newcomers just trying Diablo for the first time. They won't understand how that button works, and may not even realize that it isn't a feature from the original game. It would need a lengthy tooltip blurb on screen because there's no way they're going to go peck around for some help explanation buried away elsewhere.

I'm actually adding help text to any new commands i add to the game. I've done so for shift clicking into/from belt for example. There is nothing i can do if people don't want to read the game help, that's on them. I certainly don't want to litter the game with hand holding tooltips and things like that.

Additionally, if they are newcomers, they shouldn't know about anything else in the game anyways and would have to read the help or discover by themselves.

If they rely on a resource that was created for vanilla to understand a mod, that's again on them.

[Belix161]

Since we are actively working to solve sync issues like these it would seam to render a good part of your argument moot.

I wasn't aware of that; that's good to know. I'd love to be able to play the game some day knowing that everyone is seeing mostly the same stuff going on for a change. :)

Most of your concerns over implementing this are based on other bugs. As ajenbo said, we intend to fix those, not keep them.

That makes sense if you classify these networking quirks as bugs. I wasn't sure if that was the case since Diablo's network implementation was a final hour rush job; these issues don't stem from unintended code behavior so much as code that they just never had the time to write. Obviously they would have wanted everything to be synchronized better if they had had more time to work on it, but this stuff is classic game behavior as it was written to behave and not just mistakes in the code.

Do you consider using widescreen resolutions a cheat in ironman? What about shift clicking potions to belt?

Personally, yes and no. I suspect this is a rhetorical question, but I'm happy to explain if you're really interested.

Nothing prevents us from having visual indicators as well.

Besides the actual blocking animation? Because if I can't check a player's resistances or check if they have this enabled or not, I don't have a reliable way to tell if they're using it or not besides doing some guesswork with math to figure out the damage range they should be taking when they're hit by certain projectiles.

Mind you, nowhere have I read that DevilutionX necessarily endorses or cares about Ironman whatsoever, so I don't expect it to be much concern for anyone working on it, but it was one of the most popular alternative ways to play back in the day and was at least worth mentioning.

Not sure what you mean by "active by default". What i proposed was for it to be "the vanilla behavior by default.

I was referring to where you stated that you didn't want it to be an ini file option, therefore enabling this new feature by default natively where it would be an interface button present in the game at all times. Unless I misunderstood?

**What is DevilutionX

DevilutionX is a source port of Diablo and Hellfire that strives to make it simple to run the game while providing engine improvements, bugfixes, and some optional quality of life features.**

Having a block behavior toggle is not a QoL feature; you're introducing a new game play mechanic. That isn't consistent with this project's stated front page goal. Just because it was a feature in Hellfire doesn't mean you aren't proposing adding something new that wasn't formerly possible. There's also no mention at all in this discussion of the fact that Hellfire used to check Block chance before Armor Class dodge chance, so unless I'm missing something, you're not even proposing to re-implement the Hellfire blocking mechanic fully but only the advantageous part (blocking with resists) with none of the disadvantages (blocking even if your AC would have been high enough to not take the hit).

I'm of the (unpopular) opinion that "people don't know what they want/need". I don't particularly care about anyone's specific take on any single feature and don't necessarily consider that when coming up with something new.

Well, nothing personal against you, but it's my opinion that a project aimed at staying faithful to the original game experience doesn't benefit much from that type of attitude.

Not sure what your expectations are. Devilutionx is not vanilla. The UI is bound to change. It hasn't been changed yet because of lack of resources on our end (creating art is hard).

I expect what's written on the package: Engine improvements, bugfixes, and QoL features. Adding a toggle to change block behaviors is none of these things. As an aside, adding new UI elements that don't compliment the game's original behaviors doesn't sound like something that fits in with that description, either.

That seems very arbitrary to me, you just contradicted yourself.

I hope you better understand my concerns now. I don't think accepting the XP bar as a QoL feature and not wanting a block toggle button is contradictory at all. The XP bar improves usability of information that was already available to the player, whereas a block behavior toggle... well, I surely don't need to repeat myself. :)

[julealgon]

That makes sense if you classify these networking quirks as bugs. I wasn't sure if that was the case since Diablo's network implementation was a final hour rush job; these issues don't stem from unintended code behavior so much as code that they just never had the time to write. Obviously they would have wanted everything to be synchronized better if they had had more time to work on it, but this stuff is classic game behavior as it was written to behave and not just mistakes in the code.

You are the first person I've seen not classifying these network issues as bugs. They are definitely bugs to everybody else. And they will be fixed eventually.

Personally, yes and no. I suspect this is a rhetorical question, but I'm happy to explain if you're really interested.

Yes it was rhetorical, to point out how you have contradicted yourself. Widescreen actually provides gameplay benefits by allowing you to cast farther and hit and see enemies from further away. As does resolution increases.

Besides the actual blocking animation?

Yes. We can add anything to the game, no need to limit yourself to what exists in vanilla. New visual indicators are possible.

Because if I can't check a player's resistances or check if they have this enabled or not, I don't have a reliable way to tell if they're using it or not besides doing some guesswork with math to figure out the damage range they should be taking when they're hit by certain projectiles.

Why do you need to know other players resistances again?

Mind you, nowhere have I read that DevilutionX necessarily endorses or cares about Ironman whatsoever, so I don't expect it to be much concern for anyone working on it, but it was one of the most popular alternative ways to play back in the day and was at least worth mentioning.

I love ironman, it's probably my preferred play style.

I was referring to where you stated that you didn't want it to be an ini file option, therefore enabling this new feature by default natively where it would be an interface button present in the game at all times. Unless I misunderstood?

No, you are correct. However, the default selection for this new toggle would be the default behavior in the game currently. This is why an ini toggle is not necessary.

Having a block behavior toggle is not a QoL feature; you're introducing a new game play mechanic. ... Just because it was a feature in Hellfire doesn't mean you aren't proposing adding something new that wasn't formerly possible

You can mostly emulate the behavior here by manually equipping/unequipping your shield. In that sense, it's mostly QOL.

That isn't consistent with this project's stated front page goal.

IMHO, you are taking the description too literally. The goal is not a 100% objective thing that we can "calculate" whether or not a given feature adheres to it. It's more nuanced than that.

There's also no mention at all in this discussion of the fact that Hellfire used to check Block chance before Armor Class dodge chance, so unless I'm missing something, you're not even proposing to re-implement the Hellfire blocking mechanic fully but only the advantageous part (blocking with resists) with none of the disadvantages (blocking even if your AC would have been high enough to not take the hit).

Wasn't even aware of that difference from Hellfire. And you are right, this proposal has nothing to do with that specifically.

Well, nothing personal against you, but it's my opinion that a project aimed at staying faithful to the original game experience doesn't benefit much from that type of attitude.

Well we'll agree to disagree on this one. I think it's extremely beneficial to have this mindset especially when it comes to innovation. Users tend to want what they have seen before somewhere else and never think outside the box. I try to think of devilutionx as something as innovative as it can be and not just a simple reimplementation of what other games do.

I expect what's written on the package: Engine improvements, bugfixes, and QoL features. Adding a toggle to change block behaviors is none of these things. As an aside, adding new UI elements that don't compliment the game's original behaviors doesn't sound like something that fits in with that description, either.

Again, you'll invariably be disappointed if you stick to the description this strictly.

I hope you better understand my concerns now. I don't think accepting the XP bar as a QoL feature and not wanting a block toggle button is contradictory at all. The XP bar improves usability of information that was already available to the player, whereas a block behavior toggle... well, I surely don't need to repeat myself. :)

Neither do I have to repeat myself. See above.

And again, you seem to have accepted high resolutions and widescreen, even though those provide very significant gameplay advantages.

[AJenbo]

I don't mind adding options for finer control like this issue seams to describe. I would probably prefer not involving the ui to much and have it as a optional keybind. But for discoverability we kinda need an ingame options menu.

[Belix161]

I don't want to bloat this discussion thread with too much cross-chatter about differences in our personal views, so I'm going to narrow reply text down a bit. If there's anything you feel warrants further discussion we can discuss it elsewhere.

Yes it was rhetorical, to point out how you have contradicted yourself. Widescreen actually provides gameplay benefits by allowing you to cast farther and hit and see enemies from further away. As does resolution increases.

I'm aware of that, but widescreen support is a very basic feature added by practically every modern compatibility project anywhere. Changes in field of view are normal and expected here, as well as any accompanying advantages. I'm not really sure what point you're trying to make with this at all. I'm not contradicting myself by accepting an incidental change that provides an advantage, while objecting to a deliberate change to a way part of the game works like you are proposing here.

Yes. We can add anything to the game, no need to limit yourself to what exists in vanilla. New visual indicators are possible.

I'm aware of this as well. But unless I'm mistaken, you're now suggesting a possible new UI element to display the blocking behavior status of other players... so you want to add more non-classic UI stuff to the screen to compliment the non-classic blocking behavior toggle button that you propose should be omni-present in one of the UI panels and not something the user can disable in the INI file? Even when the XP and health meters are opt-in and disabled by default, you want your game play changing button to always be present and not something that can be turned off? And you don't see how some people might be reasonably annoyed by that, even a little bit? Or do you just not care?

I love ironman, it's probably my preferred play style.

Same. That first time was amazing. It was like getting to play the game for the very first time again. I'm glad someone who can represent that player perspective is working actively among the project's contributors, even if I may not agree with all your ideas or reasoning.

No, you are correct. However, the default selection for this new toggle would be the default behavior in the game currently. This is why an ini toggle is not necessary.

It's not necessary to be able to turn off a feature/new button added 25 years after the game's release that I don't want to see on my screen just because it doesn't do anything unless I click on it? I beg to differ, and trust me, just because I'm the first person to object doesn't mean I'm the only one. I predict it will even be among the forefront of changes to the base game any mod branched from DevilutionX will remove early in its development.

You can mostly emulate the behavior here by manually equipping/unequipping your shield. In that sense, it's mostly QOL.

Not even close. No amount of shield swapping in vanilla Diablo allows me to block projectiles that land a successful To Hit chance while also wearing up to 75% Resists. What you propose, for example, lets me max resist Lightning from Maelstroms while simultaneously being able to block Charged Bolts from Magistrates (same with a floor that has Balrogs/Inferno and Counselors/Firebolt combo, and more). Previously I would have to choose one (any/max resistance) or the other (blocking).

As a fellow Ironman player, it's also strangely hypocritical of you to suggest my acceptance of Shift Clicking potions to the belt as something that should seem a cheat in Ironman as an example of my logic contradicting itself, then use "I can just equip/unequip a shield" as justification for this change being okay. There's no comparison there at all. For the time it takes me to Shift+Click a potion from my inventory to my belt, I could have just right-clicked on it and drank it. I consume potions out of my inventory all the time. Experienced Ironman players also drop potions on the ground to fast-slot them into their belt -- and that works even faster than having them in your inventory and shift-clicking them. The potion belt feature might make a difference of a fraction of a second somewhere in some cases at most, and can still be done in other ways. So as you tried to reason, this is game functionality that already exists and doesn't arguably help the player gain any sort of advantage outside of convenience... except in your case, you're using this argument to defend something that absolutely enables the player to do something new. Choosing to block spells while also having up to 75% resistance with no new penalty added is totally impossible in either vanilla or the expansion.

There is nothing you can say that will convince me that giving players the ability to block spells even when they have resists isn't a significant game play change and, arguably, a cheat. My friends who have played Diablo since around release feel the same way. This is far outside of the 'mod lite' QoL territory that DevilutionX's project goals will lead one to expect. I wouldn't endorse this even if you wanted to keep Hellfire's full harsh blocking behavior and not just the good part. And adding such a niche button to the UI for something like this is downright silly.

IMHO, you are taking the description too literally. The goal is not a 100% objective thing that we can "calculate" whether or not a given feature adheres to it. It's more nuanced than that.

Not at all. I actually appreciate this complexity, because I had to walk that line myself when I authored my own Hellfire patch/mod. I can't draw a magical line that will determine forever what should or shouldn't be done with DevilutionX, but I can say that until its description changes, I do not expect DevilutionX to start natively implementing mod-like features that allow the player to change how game rules work at the click of a button -- a button that can't be removed(!?). That's why I'm here trying to tell you now that I think you're way off base suggesting this should be implemented natively... most especially in a way where people can't remove it.

Well we'll agree to disagree on this one. I think it's extremely beneficial to have this mindset especially when it comes to innovation. Users tend to want what they have seen before somewhere else and never think outside the box. I try to think of devilutionx as something as innovative as it can be and not just a simple reimplementation of what other games do.

That's great in general, and you're exactly the type of person I'd want spearheading an awesome mod or original IP, but I don't think that's the right mindset to approach DevilutionX with (again, based on its current description). DevilutionX is a reimplementation of what other games do - specifically, Diablo 1. It isn't your personal playground and you shouldn't be promoting features forced onto players that they can't turn off just because you want to use it and not allow other players to turn it off when hosting a game so you can't. For someone claiming to be so innovative, I don't understand why you're so fixated on trying to preserve an archaic blocking mechanic from an older version of the game. An older version of the game developed by people who had a lot less experience with how the game worked than the original designers did, I might add.

If you want to get more creative than staying close to vanilla D1, I think you should create your own mod instead of making proposals like this. That's the proper place to demonstrate your innovation, not in a project that describes itself as basically "Diablo with minor changes and improvements." QoL features, especially hardwired ones, should be chosen by popular demand; you've used the word 'arbitrary' several times when describing my thoughts and ideas, yet you seem determined to defend this highly arbitrary suggestion of yours. Maybe a fraction of players would use this button if it existed, but I'm certain the number of people that would look for a way to disable the button because they find it jarring and/or unwanted would be multiples greater than the ones using it.

If you're passionate about your ideas and don't back down easily, I can respect that, but I'm also not going to go back and forth with you for 10-20 posts over minutia. I feel I've made my points as clearly as possible; I think it's a bad idea and I object to it wholeheartedly. If you're still set on it, so be it. Good luck!

[recv5x]

I am an experienced Diablo and Ironman player with over 20 years of experience whom this project caters to as part of their audience, and I agree with all of the issues Belix161 has raised, and with all of his stances. I might even say that he provides a voice for hardcore veteran players like myself who wish to see their game preserved for the foreseeable future, rather than having it manipulated into some abomination of a project such as what Diablo Belzebub HD turned out to be. I object to this spell blocking not being an ini toggle in the strongest terms possible; in such strong terms that I wrote an entire 2000 word response here before deciding not to post it, because I felt it was unnecessarily abrasive, and I deeply appreciate the work that has been done on this project so far. The source material should be preserved and adhered to, not innovated upon like some mod. I get that this project is your baby, but given that it's an open source project targeted at the community, it is a project that is dear to all of us as well. So please, don't discount an entire part of your player base when a mod or even an ini option can easily suffice as a compromise, and make everyone happy in the long term.

And I’m not the only one. There are a lot of players who use this project who will never sign up here to make their thoughts known, some of which I have gotten permission to share some quotes from. Here’s a quote from a discord that I’m in from a guy who probably won’t post here:

SoloT4 — Today at 5:31 PM I personally don't like it because imo it removes a part of the game that involves player skill.

And here's another one; This time from yet another Veteran hardcore Ironman player:

Althea — Today at 2:02 PM rofl hellfire should just work the way regular d1 works is what i think they have done a pretty good job of just keeping it vanilla mostly now its time to mess it up i guess =D not sure how they are going to handle mod but it seems like a fine thing for a mod like if you want xyz feature that someone made feel free to download it

[AJenbo]

@recv5x I'm not sure what you think it means to have something as an ini setting, key mapping is done via the ini. An ini setting isn't precluded from being in multiplayer or affecting one or multiple players at any given time.

Regarding the quotes from people who don't care enough to get involved I find it kinda insulting. It seams they where told that this is a planed and approved feature, it is in the diskussion phase and simply a suggestion made by a community member who has spend a lot of time helping to improve the game. If talking about future development is messing up the game then you are taking part in doing so.

[StephenCWills]

I'd also like to mention that the maintainers of this project have been doing an excellent job in terms of carefully considering whether features and fixes make sense, not necessarily to any particular group of players, but in respect to the game as a whole. From that perspective, rather than arguing, "I know a few people who won't like this," any argument against this feature should probably address the following questions.

1. Does it make sense for the player to be able to block magic? That is to say, if a person was actually in a dungeon and had a firebolt lobbed at them, what happens when and if the player raises their shield to block it?
2. Does it make sense that the player is unable to opt out of blocking magic? And perhaps more to the point, does it make sense that the player is not able to consciously opt out of blocking anything without manipulating their gear or stats? In other words, should the player be able to allow an attack to hit his armor instead of always automatically bringing his shield up to block it?
3. How does this change negatively affect gameplay?

Specifically in regards to the ironman community, I would say that DevilutionX ironman does not have to be the same as vanilla ironman. We can all already play vanilla Diablo if we want to play vanilla ironman. Plus, based on some of the points brought up earlier in this discussion, we've already deviated from The True Path. Personally, I haven't seen any arguments that would convince me that these complaints aren't just knee-jerk reactions to change. There's no reason you can't still have fun playing a more restrictive game mode when this feature exists. Furthermore, the fact that DevilutionX is intended to be moddable means that the possibility will always be open for someone to develop an ironman mod that would more strictly enforce ironman restrictions, both for the host and their guests.

Currently, I'm in favor of this particular change. In support of this feature, I'd also like to point out that this would make the Monk class much more playable in general because he always blocks everything in nearly any situation, even if you don't want him to.

[recv5x]

@recv5x I'm not sure what you think it means to have something as an ini setting, key mapping is done via the ini. An ini setting isn't precluded from being in multiplayer or affecting one or multiple players at any given time.

Regarding the quotes from people who don't care enough to get involved I find it kinda insulting. It seams they where told that this is a planed and approved feature, it is in the diskussion phase and simply a suggestion made by a community member who has spend a lot of time helping to improve the game. If talking about future development is messing up the game then you are taking part in doing so.

I'm well aware that an ini setting isn't precluded from being in multiplayer or affecting one or multiple players at any given time; generally speaking when I want to play with a group of friends, we all pass the ini file around to ensure that we're all playing with the exact same settings. I'm not technologically clueless; in fact I just graduated with a degree in computer science from my local university just 5 days ago.

Don't care enough to get involved? Try people who aren't dedicated programmers, or people who are too old to care to figure out how to sign up for and use yet another site, but still deeply care about the project. Not everyone has a github who uses this project, many people just download and enjoy what you have created here; and many older members of the Diablo community who use this project will likely never have one due to the sheer fact that people who are older tend to also be the same people who struggle with technology. However, I suspect these same legacy players are part of what are the silent majority. People don't generally start to speak up and make their thoughts known unless it directly effects them - and it doesn't mean they don't appreciate the project and what you've done for it, and it doesn't mean they don't like you either. I know I certainly don't tend to comment on anything unless it concerns me - the last comment I made on this project was with regards to correcting controls for US-layout keyboards, remember? No news is good news.

I also never said talking about future development is messing up the game; your words, not mine. All of us who oppose this entirely understand this is just a proposed change and that no decision is locked in yet. I just think forcing this as the default onto everyone with no way to turn it off is completely the wrong way to go about it.

[recv5x]

I'd also like to mention that the maintainers of this project have been doing an excellent job in terms of carefully considering whether features and fixes make sense, not necessarily to any particular group of players, but in respect to the game as a whole. From that perspective, rather than arguing, "I know a few people who won't like this," any argument against this feature should probably address the following questions.

Ok fair; let's take a look at these questions from the way the game was originally designed:

1. Does it make sense for the player to be able to block magic? That is to say, if a person was actually in a dungeon and had a firebolt lobbed at them, what happens when and if the player raises their shield to block it?

2. Does it make sense that the player is unable to opt out of blocking magic? And perhaps more to the point, does it make sense that the player is not able to consciously opt out of blocking anything without manipulating their gear or stats? In other words, should the player be able to allow an attack to hit his armor instead of always automatically bringing his shield up to block it?

Not really, no, it does not make sense - on the basis that it was not how the source material in either Diablo or Hellfire was designed. This is a significant core gameplay alteration to something which is not an original product, but something which is a faithful modernization of an existing thing. If this were a mod, these would be valid points; but this is a source port - there are so many other things in this game that don't make sense - monks blocking explosions from barrels with their fists being an example, but are preserved on the basis that this project is a source port. That is why this toggle able blocking idea belongs in a mod.

3. How does this change negatively affect gameplay?

By completely changing the dynamics of the original gameplay in a way that distorts the original experience. This is effectively a mod, not the original game itself. The core gameplay itself should be treated no differently from how we strive to preserve historical architecture.

Specifically in regards to the ironman community, I would say that DevilutionX ironman does not have to be the same as vanilla ironman. We can all already play vanilla Diablo if we want to play vanilla ironman. Plus, based on some of the points brought up earlier in this discussion, we've already deviated from The True Path. Personally, I haven't seen any arguments that would convince me that these complaints aren't just knee-jerk reactions to change. There's no reason you can't still have fun playing a more restrictive game mode when this feature exists. Furthermore, the fact that DevilutionX is intended to be moddable means that the possibility will always be open for someone to develop an ironman mod that would more strictly enforce ironman restrictions, both for the host and their guests.

I absolutely disagree; Diablo 1 is a MASSIVE hassle to get running on modern machines; and not everyone is going to buy the GOG version either. Plus, what are we to do with the GOG version when it stops working, or if say, mainstream computer manufacturers swap architectures to say, ARM architecture, just as Apple is doing, thus making the game incompatible once again. Citing the main page of this project (which absolutely should be taken literally BECAUSE words have meaning that don't get to be hand waived away): "DevilutionX is a source port of Diablo and Hellfire that strives to make it simple to run the game while providing engine improvements, bugfixes, and some optional quality of life features." No one is saying you can't have the changes you want, but put them into a mod or an ini toggle - this is a source port and should be faithful to the source material. We already set this game up as vanilla as possible when considering Ironman thanks to the wealth of options provided in the ini file, and we generally accept the bug fixes as something that was fixed for the intended gameplay to be achieved.

[StephenCWills]

Not really, no, it does not make sense - on the basis that it was not how the source material in either Diablo or Hellfire was designed. This is a significant core gameplay alteration to something which is not an original product, but something which is a faithful modernization of an existing thing.

You knew full well what I meant and yet you chose to say this anyway. Feel free to argue past me all you want, I suppose.

If this were a mod, these would be valid points; but this is a source port - there are so many other things in this game that don't make sense - monks blocking explosions from barrels with their fists being an example, but are preserved on the basis that this project is a source port. That is why this toggle able blocking idea belongs in a mod.

I see what you're saying, and I will address it later. However, I would like to point out that you have no basis for the claim that Monks blocking explosions is being preserved because this project is a source port. If someone thought it was worthwhile to put in the effort to eliminate blocking explosive barrels, then I'm sure even that change would be on the table for discussion.

By completely changing the dynamics of the original gameplay in a way that distorts the original experience. This is effectively a mod, not the original game itself. The core gameplay itself should be treated no differently from how we strive to preserve historical architecture.

This is entirely subjective, and I consider the fact that you think so to be somewhat superficial. You seem to be implying that it perverts the original experience of the game if the player should never have to learn and consider nonsensical mechanics like blocking magic if and only if the player has zero resistance. I see it as more of a ridiculously obscure edge-case, and having more straightforward options for accomplishing the same thing does not hurt the gameplay experience.

I absolutely disagree; Diablo 1 is a MASSIVE hassle to get running on modern machines; and not everyone is going to buy the GOG version either. Plus, what are we to do with the GOG version when it stops working, or if say, mainstream computer manufacturers swap architectures to say, ARM architecture, just as Apple is doing, thus making the game incompatible once again.

I have the original game, and I know this isn't true. You can literally just install it, maybe add a ddraw.dll to the folder, and then play. The hardest part is patching, which just requires tracking down the latest patch and running as admin. Furthermore, the Devilution project produces an executable that's fully patched. If you can't figure it out, then maybe you should consider buying the GOG version if you want to play vanilla so bad. Making older games easier to install and play is kind of GOG's mission statement.

If you need vanilla to run on ARM or other platforms, you can apply the relevant DevilutionX changes to the Devilution source. In fact, I believe AJenbo has been trying to maintain a 1.0.x branch of DevilutionX specifically for that purpose.

Citing the main page of this project (which absolutely should be taken literally BECAUSE words have meaning that don't get to be hand waived away): "DevilutionX is a source port of Diablo and Hellfire that strives to make it simple to run the game while providing engine improvements, bugfixes, and some optional quality of life features."

So we're back to the argument that DevilutionX is a source port. I actually think that this is a fair point. It could certainly be argued that this particular change falls most accurately into the QoL feature bucket and should therefore be optional. However, it could also be argued that the original logic is in need of improvement, and this may well be the cleanest and most user-friendly way to do that. Making it toggleable in the ini means we'll have to maintain the original behavior, which detracts from the elegance of this particular solution, IMO.

No one is saying you can't have the changes you want, but put them into a mod or an ini toggle - this is a source port and should be faithful to the source material. We already set this game up as vanilla as possible when considering Ironman thanks to the wealth of options provided in the ini file, and we generally accept the bug fixes as something that was fixed for the intended gameplay to be achieved.

I can and already did turn your argument right back at you. If you really, really, really desire the original behavior for your ironman runs, you can put it in an ironman mod just as easily as I can put this blocking feature in my own mod.

[AJenbo]

I'm not technologically clueless; in fact I just graduated with a degree in computer science from my local university just 5 days ago.

I wasn't implying that you were, but from what is being written there seams to be a misunderstanding of what something being an ini setting, or a key-bind is.

we all pass the ini file around to ensure that we're all playing with the exact same settings

The game state is synced to that of the host so there isn't really a need to do so.

Don't care enough to get involved? Try people who aren't dedicated programmers, or people who are too old to care to figure out how to sign up for and use yet another site,

The discussion here is in no way technical, why else would you be adding quotes from them as an argument? By your own words they do not care, for one reason or another. Besides opinion debates like this are better had on Discord which you say is the very site where they wrote this on.

I also never said talking about future development is messing up the game; your words, not mine.

No, they are the words in the quote you used as back up for why we should listen to you: "now its time to mess it up i guess =D"

hellfire should just work the way regular d1 works

That would be mod territory as well. This topic is way off track and it seams people are more or less aimlessly arguing at this point. For further debating and opinions please see Discord.

[recv5x]

You knew full well what I meant and yet you chose to say this anyway. Feel free to argue past me all you want, I suppose.

I made a legitimate point with regards to what you wrote. I don't know you, or anything about you, personally or otherwise, so I don't know what you meant, and if you don't feel that way, and you took it personally, I'm sorry to hear that, but that's on you.

I see what you're saying, and I will address it later. However, I would like to point out that you have no basis for the claim that Monks blocking explosions is being preserved because this project is a source port. If someone thought it was worthwhile to put in the effort to eliminate blocking explosive barrels, then I'm sure even that change would be on the table for discussion.

Well actually, that's what a source port is; modernizing what previously was based on the source material; that is the basis for what I have said.

This is entirely subjective, and I consider the fact that you think so to be somewhat superficial. You seem to be implying that it perverts the original experience of the game if the player should never have to learn and consider nonsensical mechanics like blocking magic if and only if the player has zero resistance. I see it as more of a ridiculously obscure edge-case, and having more straightforward options for accomplishing the same thing does not hurt the gameplay experience.

No it's not subjective; we're talking about the most fundamental mechanic of this game; the combat - that's about as objective as it gets. Yes it does pervert the mechanics of the original game because this is core to the game. But then again, this works great for a mod if you wanna take this there.

I have the original game, and I know this isn't true. You can literally just install it, maybe add a ddraw.dll to the folder, and then play. The hardest part is patching, which just requires tracking down the latest patch and running as admin. Furthermore, the Devilution project produces an executable that's fully patched. If you can't figure it out, then maybe you should consider buying the GOG version if you want to play vanilla so bad. Making older games easier to install and play is kind of GOG's mission statement.

Don't forget not installing it into C:\Program Files. Don't forget having to make firewall exceptions so that you can make net play work, bnet or IPX. Don't forget installing the IPX wrapper to get LAN to work, and then installing some other kind of VPN software to play with people in the LAN mode. The rest of your statement here regarding how people should just buy off GOG comes off as incredibly asinine; who are you to exclude people on the basis of expediency or technical competence and tell them how to spend their money, especially if they already own an original copy of the game? Maybe you don't mean it that way, and I should give you the benefit of the doubt, but that definitely rubs me the wrong way, because that's how it comes off.

Maybe this doesn't seem like a lot to people like you or me, but for a normal user who doesn't do tech, and who's only desire is to play Diablo, and if they already own an original copy of the game, what's easier? Going through all of that above? or setting up Devilution X. Given too much resistance in getting things set up, most people will just give up, and not bother playing the game at all. At least with Devilution X, it's friendly enough such that people can set it up on their own and enjoy the game as they once did.

If you need vanilla to run on ARM or other platforms, you can apply the relevant DevilutionX changes to the Devilution source. In fact, I believe AJenbo has been trying to maintain a 1.0.x branch of DevilutionX specifically for that purpose.

And good on him for that. I'm especially pleased for everything AJenbo has done so far.

So we're back to the argument that DevilutionX is a source port. I actually think that this is a fair point. It could certainly be argued that this particular change falls most accurately into the QoL feature bucket and should therefore be optional. However, it could also be argued that the original logic is in need of improvement, and this may well be the cleanest and most user-friendly way to do that. Making it toggleable in the ini means we'll have to maintain the original behavior, which detracts from the elegance of this particular solution, IMO.

It absolutely doesn't matter if the original logic is in need of improvement; what matters is loyalty to the source material. If you want to alter or improve the source material in some way, make a mod. Nobody is stopping you. People will even download it and play it, and may even say it is better than the original. Many people said that about Diablo Belzebub HD. But what's original should stay original.

I can and already did turn your argument right back at you. If you really, really, really desire the original behavior for your ironman runs, you can put it in an ironman mod just as easily as I can put this blocking feature in my own mod. You should knock the chip off your shoulder, stop talking down at me, and listen to what I have to say - I didn't come here to pick a fight with you, I came to make the concerns of people like me heard.

I shouldn't have to go to that extent in order to achieve what is original. This is a source port isn't it? That demands adherence to the original behavior not just for ironman runs but for the sake of preserving and being true to the source material itself, the same way we do with historical architecture. If you don't recognize the legitimacy of that point, then we're just running in circles here, and we'll never get anywhere.

---

The game state is synced to that of the host so there isn't really a need to do so.

Good to know for future use; this should make things easier. Thanks!

The discussion here is in no way technical, why else would you be adding quotes from them as an argument? By your own words they do not care, for one reason or another. Besides opinion debates like this are better had on Discord which you say is the very site where they wrote this on.

By my own words? No way, they absolutely care; these are people that play Devilution X nearly every day, as do I, putting hundreds of hours into playing the game because we appreciate what you have done. In fact we all prefer it to the GOG port (which most of us already own anyways just for the sake that it is Diablo) - and as a Linux user I especially prefer and am grateful for the fact that this works out of the box without jumping through hoops in WINE. Just because these people don't have a github and they don't post here doesn't mean they don't care. They just want to use the work that you've done to preserve the original experience, just as I do; though we're also still thankful for the bug fixes as well.

No, they are the words in the quote you used as back up for why we should listen to you: "now its time to mess it up i guess =D"

That's not actually an accurate statement about the quotation. They're not saying talking about the game will screw it up, they're saying that they expect things to go south, but they're also saying that putting this behavior into a mod could make everybody happy - both people who want to retain the original gameplay, and people who want something a little more refined. I'm here just to try to help another side of the argument be heard. This project has a good thing going here, and it means a hell of a lot to legacy players; especially to myself.

That would be mod territory as well.

I actually agree with you; just because I posted quotations doesn't mean I agree with the opinions in their entirety; I was just trying to get some different views out there. However, certainly you agree that this toggle-able blocking would also be mod territory?

For further debating and opinions please see Discord.

I've said all I have to say here - you won't be hearing anymore from me on this subject. There's no point continuing to hash out arguments over and over again anyways, and I'm not the most sociable guy in the world - I'm not gonna join a discord just for this discussion. It's an open source project, right? If people like how things go, they can stick with it, and if they don't, they can fork and do their own thing.

[StephenCWills]

I made a legitimate point with regards to what you wrote. I don't know you, or anything about you, personally or otherwise, so I don't know what you meant, and if you don't feel that way, and you took it personally, I'm sorry to hear that, but that's on you.

Then I guess you just didn't read my questions and answered however you wanted to. Allow me to spell it out for you. I was asking whether it makes sense canonically, not whether it's faithful to the original.

Well actually, that's what a source port is; modernizing what previously was based on the source material; that is the basis for what I have said.

If you want to argue semantics about what a source port is, then you're arguing to the wrong person. I prefer to engage in meaningful discussion.

No it's not subjective; we're talking about the most fundamental mechanic of this game; the combat - that's about as objective as it gets. Yes it does pervert the mechanics of the original game because this is core to the game. But then again, this works great for a mod if you wanna take this there.

Unfortunately, you're wrong. We've already encountered several mechanics that fall into the gray area between bugfix and feature, or even just inconsistent mechanics where it's difficult to determine the original developer's intent. And it is absolutely possible to tweak combat mechanics while remaining faithful to the original.

Don't forget not installing it into C:\Program Files. Don't forget having to make firewall exceptions so that you can make net play work, bnet or IPX. Don't forget installing the IPX wrapper to get LAN to work, and then installing some other kind of VPN software to play with people in the LAN mode.

Fair enough. Multiplayer is a bit of a sore spot for the original game. I'm not sure how much easier this gets on the GOG version.

The rest of your statement here regarding how people should just buy off GOG comes off as incredibly asinine; who are you to exclude people on the basis of expediency or technical competence and tell them how to spend their money, especially if they already own an original copy of the game? Maybe you don't mean it that way, and I should give you the benefit of the doubt, but that definitely rubs me the wrong way, because that's how it comes off.

Sorry if I struck a nerve. You're right that I have no authority to exclude anyone on whatever basis you'd like to think up. I wasn't aware I was excluding people by suggesting they might have an easier time installing the GOG version.

And good on him for that. I'm especially pleased for everything AJenbo has done so far.

Yes, he's pretty great. I'm continually impressed with how he handles this project.

It absolutely doesn't matter if the original logic is in need of improvement; what matters is loyalty to the source material. If you want to alter or improve the source material in some way, make a mod. Nobody is stopping you. People will even download it and play it, and may even say it is better than the original. Many people said that about Diablo Belzebub HD. But what's original should stay original.

Personally, I think you need to take a step back and reflect on the assertion you're making. That is quite literally just your opinion, and this thread is for discussing the pros and cons of this feature. All I did when I chimed in was to suggest justifying the arguments against this feature canonically and in terms of the actual negative effect to gameplay. Instead, you clung to the assertion that we shouldn't be changing gameplay mechanics as if it's a basic truth of the universe.

I shouldn't have to go to that extent in order to achieve what is original. This is a source port isn't it? That demands adherence to the original behavior not just for ironman runs but for the sake of preserving and being true to the source material itself, the same way we do with historical architecture. If you don't recognize the legitimacy of that point, then we're just running in circles here, and we'll never get anywhere.

Sorry, but I don't know anything about how historical architecture is preserved so the comparison is lost on me. And yes, it seems you've finally reached the understanding that I don't necessarily share your opinion about exactly how faithful this source port should be. It honestly doesn't matter to me whether this ends up in DevilutionX or a mod. If I find that I like it, I can make it work in my build either way. But I do still think this is a good candidate for inclusion in DevilutionX.