Project 1999

Go Back   Project 1999 > Class Discussions > Priests

Closed Thread
 
Thread Tools Display Modes
  #91  
Old 06-14-2020, 07:53 PM
Baler Baler is offline
Planar Protector

Baler's Avatar

Join Date: Mar 2014
Posts: 9,523
Default

for fuck sakes. Have a good night man. I'm out.
__________________
  #92  
Old 06-14-2020, 07:55 PM
DMN DMN is offline
Planar Protector

DMN's Avatar

Join Date: May 2016
Location: My own special hell
Posts: 3,364
Default

Quote:
Originally Posted by DeathsSilkyMist [You must be logged in to view images. Log in or Register.]
It is very simple. I will break it down in an example:

Lets say you get bashed 5 times in a fight:

1. Bash with stun, and interrupt.
2. Bash with stun, no interrupt.
3. Bash with stun, no interrupt.
4. Bash with stun, no interrupt.
5. Bash with stun, and interrupt.

A Troll would get spell interrupted 5 times. An Ogre will get spell interrupted 2 times. That is LESS spell interrupts lol.
There is no way to know whether a non-ogre would ever be interrupted by a non-stunning bash. Similarly an ogre could just as well get interrupt 5 times in a row regardless of not getting stunned. Even worse, he tried to cast a spell and had to eat the entire cast time of the spell instead of the 1.5 second stun time.
  #93  
Old 06-14-2020, 08:05 PM
sonofbaal sonofbaal is offline
Skeleton


Join Date: May 2011
Posts: 19
Default

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
__________________
Bombata the Bearslayer - Shaman
Last edited by sonofbaal; 06-14-2020 at 08:15 PM..
  #94  
Old 06-14-2020, 08:20 PM
DeathsSilkyMist DeathsSilkyMist is offline
Planar Protector

DeathsSilkyMist's Avatar

Join Date: Jan 2014
Posts: 8,197
Default

Quote:
Originally Posted by DMN [You must be logged in to view images. Log in or Register.]
There is no way to know whether a non-ogre would ever be interrupted by a non-stunning bash. Similarly an ogre could just as well get interrupt 5 times in a row regardless of not getting stunned. Even worse, he tried to cast a spell and had to eat the entire cast time of the spell instead of the 1.5 second stun time.
You are correct, there is no 100% fool-proof way to prove this is how the code works, without actually looking at the code.

There are a few reasons for me being fairly confident in my understanding of the game logic:

1. I do have an Ogre Shaman. I see visibly less spell interrupts on him than on my other characters. I pull a lot of monsters on both my Shaman and my Shadowknight. Monsters tend to bash as their first action when they reach you. If I am casting a spell on my Shadowknight when this happens, I have a good chance of being interrupted. Quite a few of these interrupts come from stuns, specifically. On my Shaman, I land spells in this specific case way more often. I am not saying I never get interrupted, but it is a noticeable difference.

2. There is no logical reason to combine the stun and spell interrupt aspects of Bash from a programming perspective. Bash would calculate the stun percentage, and the spell interrupt percentage separately. Then, if the stun gets called, the game simply checks for the special exceptions when determining if the stun should land or not. This means having FSI, being a mob that is immune to stuns, having Divine Aura on, etc. Obviously the programming could be poorly done, or specifically made to screw over Ogres, but I don't really think that is the default assumption to be made here.
  #95  
Old 06-14-2020, 09:04 PM
DMN DMN is offline
Planar Protector

DMN's Avatar

Join Date: May 2016
Location: My own special hell
Posts: 3,364
Default

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.
Last edited by DMN; 06-14-2020 at 09:06 PM..
  #96  
Old 06-14-2020, 10:11 PM
DeathsSilkyMist DeathsSilkyMist is offline
Planar Protector

DeathsSilkyMist's Avatar

Join Date: Jan 2014
Posts: 8,197
Default

Quote:
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.
Last edited by DeathsSilkyMist; 06-14-2020 at 10:23 PM..
  #97  
Old 06-14-2020, 11:13 PM
DeathsSilkyMist DeathsSilkyMist is offline
Planar Protector

DeathsSilkyMist's Avatar

Join Date: Jan 2014
Posts: 8,197
Default

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.
  #98  
Old 06-14-2020, 11:40 PM
DMN DMN is offline
Planar Protector

DMN's Avatar

Join Date: May 2016
Location: My own special hell
Posts: 3,364
Default

Quote:
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.
  #99  
Old 06-14-2020, 11:56 PM
DeathsSilkyMist DeathsSilkyMist is offline
Planar Protector

DeathsSilkyMist's Avatar

Join Date: Jan 2014
Posts: 8,197
Default

Quote:
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.
  #100  
Old 06-15-2020, 12:59 AM
DMN DMN is offline
Planar Protector

DMN's Avatar

Join Date: May 2016
Location: My own special hell
Posts: 3,364
Default

Quote:
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.
Closed Thread


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -4. The time now is 01:28 AM.


Everquest is a registered trademark of Daybreak Game Company LLC.
Project 1999 is not associated or affiliated in any way with Daybreak Game Company LLC.
Powered by vBulletin®
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.