Welcome to Crestfall Gaming

Register now to Crestfall Gaming. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.

namreeb

Will nampower be allowed?

Hello.  I have created an automatic stopcast tool for the Windows 1.12.1 client.  It functions to bypass client-side restrictions on simultaneous spell casts to work around a design flaw in the client.  The source, binary, and more detailed description of the tool are available here: https://github.com/namreeb/nampower

 

The executable is in the releases section here: https://github.com/namreeb/nampower/releases

 

I am hoping to receive some official word in this thread so I can include a link to it in the README.  This will let users know that it is safe to use here.

 

Thank you!

1

Share this post


Link to post
Share on other sites

How will this interact with Crestfall's spell batch / delay system?

I realize one is server-side while the other is client-side but other projects don't have that complication.

  • What happens when spam-clicking or key-spamming? Are you in perpetual self-interrupt mode?
  • Is the intended usage that you use a cast-timer with a UseAction Hook and try to time the next cast at the end of the nominal (client-side) cast-time?
  • This looks like something that could very easily be automated further with Lua addons removing any opportunity cost (stop-casting your in progress cast) from it and making it trivial to spam-cast.
  • It also seems to be shifting more workload to server-side for spell cast integrity checks?

I also don't really get the latency NA / EU justification.

Anyone who doesn't use this is at a disadvantage regardless of where they connect from, only the % of disadvantage changes.

 

I have to say I'm extremely ambivalent about this on the face of it, if I understand what it does correctly...

But anyway that's a player perspective, I'll wait to hear from project admins.

Edit: The 20% boost to DPS mentioned on the readme is also massive. I mean it makes all the effort to compensate for 1.12 talents / spells pale in comparison.

If you read a blue post during any time in WoW's life that said "we boosted all caster dps by 20%" you'd be pulling your hair out to put it in perspective.

Edited by Roadblock
0

Share this post


Link to post
Share on other sites

I can't imagine this having any negative impact on the spell batch / delay implementation.  If there were any, it would signify a bug in the server code.

The intended use is that you create a macro with a value of /script CastSpellAtTarget(12345) where 12345 is the id of a spell you know.  Instead of having the spell itself on your action bar, you have that macro.  Then when you spam the key for that button on your action bar, the tool's spell cast code is called, rather than the client's.  And you're right, it already makes it trivial to spam cast.  It is up to the server to prevent a user from casting a spell when they are already casting one.

The reason this tool is useful for people in NA (or anywhere with large latency) is the DPS reduction due to latency.  The higher your latency, the less frequently you can cast spells, and therefore the more benefit you would have from removing latency as a factor.  It essentially allows casters with higher latency to be competitive with casters who have little to no latency.  It does NOT allow high latency casters to completely outperform casters with no latency.

For what it's worth, I used this tool (in a much uglier implementation) when classic wow was on retail, and consistently outperformed all other casters.

The 20% dps increase is by no means a fixed, empirical value.  It is an educated guess based on rough estimates.  Example:

Fireball rank 12 (spell id 25306) has a cast time of 3.0 seconds (assuming you have Improved Fireball), or 3000ms.  Personally, my average latency to OVH France hosted realms is 250ms.  European players often have no more than 50ms latency.

Therefore, a European player can cast one Fireball Rank 12 every 3000 + 50 + 50 or 3100ms.  I can only cast one every 3000 + 250 + 250 or 3500ms.  In a four minute fight, the EU player can cast 77 fireballs.  I can only cast 68.  A player with NO latency, for example one who is using nampower, can cast 80.

For the European player, using this tool would yield an approximate percentage DPS increase of (80-77)/77 or roughly 4%.  However for me, it yields an approximate percentage DPS increase of (80-68)/77 or roughly 16%.

Another way to estimate is just based on the time.  From 3500ms to 3000ms represents a 17% speed increase, whereas from 3100ms to 3000ms represents only a 3% increase.

This is more thought than I've ever given it before.  So yes, the 20% claim may be excessive in the case of a Fire mage, but only slightly.  I guess 16% would be more reasonable.

Edit: Also, if you consider Frostbolt Rank 11 (spell id 25304) under the same conditions, with the improved frostbolt talent, that is a cast time of 3000ms versus 2500ms.  That resembles a DPS increase of exactly 20%, assuming my arithmetic is correct.

Edited by namreeb
1

Share this post


Link to post
Share on other sites

Yeah on the face of that my vote would be "no".

I'm pretty sure you'd get banned on classic for this if you were caught using it.

Also

7 hours ago, namreeb said:

For what it's worth, I used this tool (in a much uglier implementation) when classic wow was on retail, and consistently outperformed all other casters.

The 20% dps increase is by no means a fixed, empirical value.  It is an educated guess based on rough estimates.  Example:

Fireball rank 12 (spell id 25306) has a cast time of 3.0 seconds (assuming you have Improved Fireball), or 3000ms.  Personally, my average latency to OVH France hosted realms is 250ms.  European players often have no more than 50ms latency.

<snip>

This is more thought than I've ever given it before.  So yes, the 20% claim may be excessive in the case of a Fire mage, but only slightly.  I guess 16% would be more reasonable.

Edit: Also, if you consider Frostbolt Rank 11 (spell id 25304) under the same conditions, with the improved frostbolt talent, that is a cast time of 3000ms versus 2500ms.  That resembles a DPS increase of exactly 20%, assuming my arithmetic is correct.

That's called cheating, just because you're using an exe modified in memory and not on disk, you're still gaining an advantage by playing with a custom client.

 

I'll re-iterate that all the efforts being made to properly replicate combat table mechanics, npc armor and resistance values and player abilities to approximate a blizz-like experience are made a joke if you allow a custom WoW.exe that buffs caster dps by 15-20%.

Also spell batching / spell delay already was the Blizzard way to (1) optimize spell processing on the server-side and (2) smooth out latency-driven performance disparity for the 0-400ms range (400ms being the spell delay "tick" server-side)

I don't think 400ms+ latencies are going to be a thing on Crestfall, special circumstances aside.

0

Share this post


Link to post
Share on other sites

The statement that it 'buffs caster dps by 20%' is misleading.  It would be more accurate to say that it removes a 20% dps reduction (manually stopcasting would, too, without any client modifications).

0

Share this post


Link to post
Share on other sites
6 minutes ago, namreeb said:

The statement that it 'buffs caster dps by 20%' is misleading.  It would be more accurate to say that it removes a 20% dps reduction (manually stopcasting would, too, without any client modifications).

Not really, what's misleading is calling a design decision a "design flaw" ;)

Manually stop-casting comes with an opportunity cost (you can fuck it up and you also have to trade effort for result)

0

Share this post


Link to post
Share on other sites

What would you call it?  Do you believe that Blizzard intended to punish people with higher latency?  This flaw was fixed in TBC, by the way.  That is why I only have released this tool for classic wow.

2

Share this post


Link to post
Share on other sites

I've spoken with @namreeb, as well as looked at code. While I see the concept of attempting malicious activity with similar ideas, I don't see an actual issue with nampower. If we do find it as a cause for issue down the road, it will be restricted, but until then, I don't have a problem with it personally.

I will close this to prevent any arguments.

8

Share this post


Link to post
Share on other sites

Note:  This is a tentative pass.  We will investigate this further when we have more time.

We have a lot of work to do and not much time to look at individual mods or add-ons to determine compatibility or potential exploits.  Most client mods will simply be forbidden, and we will consider white-listing certain ones, eventually.  We will allocate more time and energy towards this topic during Open Beta and after Release.

3

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.