Please check my math on Troll vs Ogre Shaman

[Baler]

for fuck sakes. Have a good night man. I'm out.

[sonofbaal]

you guys are both bringing up valid points and make this really hard

i did see

https://wiki.project1999.com/Sap_Encrusted_Branch

but the likelyhood of me every getting that prob low

[DMN]

I guess it would depend on exactly what "logic" you want to assume.

If the programmers logic was they wanted to minimize the amount of calculations the server is being forced to do, it would make more sense for to have a single random chance table like such as a 1-100 where anything above 50 results in an automatic interrupt and above 75 would result in a stun. In that case you'd still get interrupted as an ogre because above 75 is also above 50.

I'm not sure how it works on p99, and don't know how it worked back in 1999.

[DeathsSilkyMist]

Originally Posted by DMN [You must be logged in to view images. Log in or Register.]

I guess it would depend on exactly what "logic" you want to assume.

If the programmers logic was they wanted to minimize the amount of calculations the server is being forced to do, it would make more sense for to have a single random chance table like such as a 1-100 where anything above 50 results in an automatic interrupt and above 75 would result in a stun. In that case you'd still get interrupted as an ogre because above 75 is also above 50.

I'm not sure how it works on p99, and don't know how it worked back in 1999.

That is incorrect, based on how p99 currently handles bash. A bash has a spell interrupt component, AND a stun component. This much is fact. You can see this by getting bashed on a non-ogre. If the bash does not stun you, you will sometimes still finish casting the spell. This means there are two separate calculations. One for stuns, and one for spell interrupts. If you wanted to build the bash function as simple and generic as possible, the logic would look like this:

1. Calculate if a stun occurs. If a stun occurs, end the function.
2. If a stun has not occurred, calculated the interrupt chance.

This would be the default way to program bash in a generic manner. It keeps your options open in case some mechanics change in the future.

Your logic would require one more step, which means bash was intentionally designed to make Stun Immunity in general less effective:

1. Calculate if a stun occurs. If a stun occurs, and it is not prevented by a special mechanic, end the function.
2. If a stun occurs, but it is prevented by a special mechanic, set the interrupt chance to 100% and end the function.
3. If a stun has not occurred, calculated the interrupt chance.

Unless there is evidence to suggest Stun Immunity was specifically designed to prevent the stun, and not the spell interrupt, you would assume the function is built in the simpler, more generic way.

While your idea does make sense from a simplicity sake (one random number), you would limit your game designers ability to adjust stun percentages independently of spell interrupt percentages. They would be tied together since they are using the same number. If you wanted a 60% chance for stuns, and a 60% chance for spell interrupts, you couldn't do it using your system.

[DeathsSilkyMist]

Not sure how accurate this is, but I found this quote on Bash here https://fanra.fandom.com/wiki/Skill_...Combat_Effects :

"As a side investigation, we asked the Devs why a bash that failed to stun was so much more likely to interrupt casting than a bash that would have stunned, but didn't (due to resist or immunity). It turns out that the mechanism first determines if a bash will stun or not; if not a stun, it checks for interrupt or not. When bash was put in to the game, they did not take into account stun immunity or the development of stun resist mods; so that if the first check yeilds a (potential) stun, it doesn't check for interrupt (assuming the stun would do the interrupting). The Ogre racial immunity to frontal stuns seems to be well worth the 70 levels of experience penalty at this point."

This logic is basically what I was describing above, except it apparently didn't check for interrupts at all if the stun was resisted. Of course, I am not sure where this quote came from, exactly.

[DMN]

Originally Posted by DeathsSilkyMist [You must be logged in to view images. Log in or Register.]

That is incorrect, based on how p99 currently handles bash. A bash has a spell interrupt component, AND a stun component. This much is fact. You can see this by getting bashed on a non-ogre. If the bash does not stun you, you will sometimes still finish casting the spell. This means there are two separate calculations. One for stuns, and one for spell interrupts. If you wanted to build the bash function as simple and generic as possible, the logic would look like this:

1. Calculate if a stun occurs. If a stun occurs, end the function.
2. If a stun has not occurred, calculated the interrupt chance.

This would be the default way to program bash in a generic manner. It keeps your options open in case some mechanics change in the future.

Your logic would require one more step, which means bash was intentionally designed to make Stun Immunity in general less effective:

1. Calculate if a stun occurs. If a stun occurs, and it is not prevented by a special mechanic, end the function.
2. If a stun occurs, but it is prevented by a special mechanic, set the interrupt chance to 100% and end the function.
3. If a stun has not occurred, calculated the interrupt chance.

Unless there is evidence to suggest Stun Immunity was specifically designed to prevent the stun, and not the spell interrupt, you would assume the function is built in the simpler, more generic way.

Ya, I don't know what you are going on about here. You mentioned how something wasn't "logical" and i showed you it made logical sense if you wanted to minimize the server's resources.

I could go even further and offer why it is illogical for a roleplaying game to operate in this manner too.

The idea of a bash is some sort of hard blow focused on knocking you off balance, like a trip or shove or something along those lines. You have 3 outcomes of a successfully landed bash:

The best outcome you don't get stunned or interrupted. RPG wise you got hit the softest.
The second worst outcome you get your spell immediately interrupted. RPG wise you got hit the second hardest.
The worst outcome you spell is immediately interrupted and you are stunned for 1.5 seconds. RPG wise you got hit the hardest possible. Similar to a "critical hit".


"Gee, I'm glad that guy hit me so damn hard. If only the fool would have hit me much softer would it have interrupted my spell." -- not logical RPG dialogue



So it's pretty piss poor logic from an RPG perspective as well server performance perspective.

[DeathsSilkyMist]

Originally Posted by DMN [You must be logged in to view images. Log in or Register.]

Ya, I don't know what you are going on about here. You mentioned how something wasn't "logical" and i showed you it made logical sense if you wanted to minimize the server's resources.

I could go even further and offer why it is illogical for a roleplaying game to operate in this manner too.

The idea of a bash is some sort of hard blow focused on knocking you off balance, like a trip or shove or something along those lines. You have 3 outcomes of a successfully landed bash:

The best outcome you don't get stunned or interrupted. RPG wise you got hit the softest.
The second worst outcome you get your spell immediately interrupted. RPG wise you got hit the second hardest.
The worst outcome you spell is immediately interrupted and you are stunned for 1.5 seconds. RPG wise you got hit the hardest possible. Similar to a "critical hit".


"Gee, I'm glad that guy hit me so damn hard. If only the fool would have hit me much softer would it have interrupted my spell." -- not logical RPG dialogue



So it's pretty piss poor logic from an RPG perspective as well server performance perspective.

There is always a trade-off between an absolute minimum resource usage, and flexibility. One number vs. two numbers, even in 1999, wasn't a big deal performance wise. The problem with your idea of a single 1-100 number is you cannot give individual percentages to stun AND interrupt chance. This is because the numbers are tied together. If you have a 30% stun chance, you can NOT have greater than a 70% interrupt chance.

From a game design perspective, it is better to take the very slight performance hit, and keep the two chances separate. This allows greater flexibility for balance tweaking. Overall, this is a better design pattern too, because you can keep the stun function generic. This means a stun from bash and a stun from spells can share the same stun function. Having a specially designed stun function for bash, and a specially designed stun function for spells, is harder to maintain.

From a pure programming perspective, the logic I described is a more common design pattern.

From a pure story perspective, this makes sense too. If an ogre is tough enough to brush off a blow that would otherwise stun a normal human being, it would make sense that they are less likely to be interrupted while casting a spell. The idea is they are less affected by heavy blows.

[DMN]

Originally Posted by DeathsSilkyMist [You must be logged in to view images. Log in or Register.]

There is always a trade-off between an absolute minimum resource usage, and flexibility. One number vs. two numbers, even in 1999, wasn't a big deal performance wise. The problem with your idea of a single 1-100 number is you cannot give individual percentages to stun AND interrupt chance. This is because the numbers are tied together. If you have a 30% stun chance, you can NOT have greater than a 70% interrupt chance.

From a game design perspective, it is better to take the very slight performance hit, and keep the two chances separate. This allows greater flexibility for balance tweaking. Overall, this is a better design pattern too, because you can keep the stun function generic. This means a stun from bash and a stun from spells can share the same stun function. Having a specially designed stun function for bash, and a specially designed stun function for spells, is harder to maintain.

From a pure programming perspective, the logic I described is a more common design pattern.

From a pure story perspective, this makes sense too. If an ogre is tough enough to brush off a blow that would otherwise stun a normal human being, it would make sense that they are less likely to be interrupted while casting a spell. The idea is they are less affected by heavy blows.

They would still be less affected because instead of getting stunned they only have the spell interrupted, at which point they can immediately start casting again. As far as "server performance", you generally want to optimize the system however it currently works. If eventually they want to change the system, it will be easy enough to simply change the code.

[DeathsSilkyMist]

Originally Posted by DMN [You must be logged in to view images. Log in or Register.]

They would still be less affected because instead of getting stunned they only have the spell interrupted, at which point they can immediately start casting again. As far as "server performance", you generally want to optimize the system however it currently works. If eventually they want to change the system, it will be easy enough to simply change the code.

The problem is you do not understand how trivial an optimization that is. We are taking about one integer variable on the heap. Micro optimizations are not usually preferred over flexibility, unless there is a specific need. This calculation is not being run hundreds of thousands of times per second. You wouldn't be sending this data over the network, either. Losing your ability to set individual percentages and keep the functions generic is not worth one integer variable on the heap.

I see no serious "lore" issue either. If your skull is too thick to be stunned, and your weight makes you difficult to move around, a bash would have much less affect on any actions you are taking, including spell casting.

It makes complete sense from programming optimization, programming design patterns, and lore.

[DMN]

A programmer would never intentionally write shitty code. What you are suggesting is someone intentionally wrote shitty code in the hopes that the shitty code might eventually become an "ugly duckling" and morph into something not shitty.

And i already debunked your "lore" claim. Not wasting my time to do it again.

Originally Posted by DMN [You must be logged in to view images. Log in or Register.]

The best outcome you don't get stunned or interrupted. RPG wise you got hit the softest.
The second worst outcome you get your spell immediately interrupted. RPG wise you got hit the second hardest.
The worst outcome you spell is immediately interrupted and you are stunned for 1.5 seconds. RPG wise you got hit the hardest possible. Similar to a "critical hit".


"Gee, I'm glad that guy hit me so damn hard. If only the fool would have hit me much softer would it have interrupted my spell." -- not logical RPG dialogue



So it's pretty piss poor logic from an RPG perspective as well server performance perspective.