Standards For Finding Speed via In-game Values

[Lilybitdun]

Currently there is a contradiction on if the wiki allows people to calc speed using in-game speed values. Overwatch and Brawl Stars both have accepted calcs that utilize in-game speed values instead of manual pixel-scaling, meanwhile TF2 and Minecraft have gotten rejected for doing the same practice; despite it being accepted in another calc for the latter.

In all these games the same thing is true, speed stays consistent across the game.

• Lucio's soundwaves always travel the same speed in every match at an in-game 50 m/s
• Shelly's shotgun always fires at the same speed in every match at an in-game 3100 points
• TF2 projectiles always move the same speed in every match with each a consistent in-game speed measured in Hammer Units
• Skulker sound waves always travel the same speed through air in every world with an in-game speed measured in 20 blocks/s with 1 block = 1 meter

There currently isn't a reason given why the former two are more valid than the latter two

These games do not progress / power up like other verses, for example Dungeons and Dragons. You can technically have a level 1 character kill a Tarrasque via cheese but is obviously not the intended power level, despite the possibility of this happening due to the game's sandbox nature.
Games like Undertale where battle speeds can never interact with other without modification cannot be compared, like for example comparing Knight Knight's Meteors to Vulkin's Bolts when they cannot be in the same battle without modification of the game.

In the four games I've brought up these aren't the case, every vanilla game interaction (that aren't bugs ofc) is intended by the developers to happen and be consistent across the game.

Disallowing the use of in-game speed values creates it's own problems

1. Calculating speed becomes needlessly tedious as site members now must manually find footage and compare speeds via pixel-scaling despite there being pre-existing work done to find the in-game values. Forcing members to pixel scale when it's unnecessary only causes slow-down in an already slow process
2. Using pixel-scaling can end up more inaccurate than using known in-game speed values as if the footage isn't at the right frame rate and/or is low quality it can throw off the measured speed from the true value.

My proposal is to create guidelines for when it is fine to calculate using in-game speed values in a verse, I'm not sure about what would be the best wording so I'm hoping to discuss what it would be but my rough idea is essentially:

When a game verse is shown to have speed consistent across all possible instances then it is valid to use derived in-game speed values for calculation purposes.
Things that disqualify scaling via this method are:

1. Verses where simultaneous instances are impossible without modification of the game would be deemed invalid. (Example: Comparing Knight Knight's Meteors to Vulkin's Bolts or vice versa)
2. It contradicts with canonical values (for example a laser-based weapon calculated via in-game value comparisons is FTL+, however in canon it's verbatim to be Speed of Light).
3. It isn't consistent with feat showings (for example a character calculated via in-game value comparisons is Hypersonic+ in combat speed, however in canon they consistently get tagged by bullets).
4. It conflicts with inverse scaling (for example character A has a greater in-game speed value than character B, however in canon character B is implied to be a marginally faster character, with character A barely keeping up in actual showings).
5. The baseline reference value the other speeds are compared to varies (this isn't too much of an issue for other speeds, however if the baseline used to compare other speed values to varies greatly in-game, then it is too unreliable to use).

Agree: Ednaxel2
Disagree:
Neutral:

 

[StarShooter80]

I'm glad someone is finally covering this topic. I think some additional rules could be:

Speeds values calculated from in-game values cannot be used if:

• It contradicts with canonical values (for example a laser-based weapon calced via in-game value comparisons is FTL+, however in canon it's verbatim to be Speed of Light).
• It isn't consistent with feat showings (for example a character calced via in-game value comparisons is Hypersonic+ in combat speed, however in canon they consistently get tagged by bullets).
• It conflicts with inverse scaling (for example character A has a greater in-game speed value than character B, however in canon character B is implied to be a marginally faster character, with character A barely keeping up in actual showings).
• The baseline value the other speeds are compared to varies (this isn't too much of an issue for other speeds, however if the baseline used to compare other speed values to varies greatly in-game, then it is too unreliable to use).

Plus agree

 

[WeeklyBattles]

I'm glad someone is finally covering this topic. I think some additional rules could be:

Plus agree

The first two wouldnt work. It is very much possible to get FTL yields from reacting to SoL lasers, and the second calc is treating movement and combat/reaction speed as one and the same when they are not

 

[StarShooter80]

The first two wouldnt work. It is very much possible to get FTL yields from reacting to SoL lasers, and the second calc is treating movement and combat/reaction speed as one and the same when they are not

The first one refers to the verbatim SoL lasers themselves becoming FTL through this method, second one just wasn't worded the best I'll change it to combat

 

[Lilybitdun]

I'm glad someone is finally covering this topic. I think some additional rules could be:

Plus agree

These look good

 

[Mommyleona]

1. It isn't consistent with feat showings (for example a character calculated via in-game value comparisons is Hypersonic+ in combat speed, however in canon they consistently get tagged by bullets).
2. It isn't consistent with feat showings (for example a character calculated via in-game value comparisons is Hypersonic+ in combat speed, however in canon they consistently get tagged by bullets).

 

[Lilybitdun]

Oops I pasted it twice
Fixed it

 

[KLOL506]

@DontTalkDT @Executor_N0

 

[DontTalkDT]

From what I see the calcs weren't rejected because they used in-game speed where the same result could be calculated via pixel scaling (quite frankly, if that were the problem you at worst would need to redo the calc), but because comparing the speeds of objects by in-game value returned unreconcilable results were either one reference value needs to be faster than natural or another slower than natural, putting the reference value into doubt. That won't get fixed by pixel scaling either.
So this appears to focus on the wrong issue entirely and the actual issue is not listed in the list of disqualifying things.

 

[Lilybitdun]

From what I see the calcs weren't rejected because they used in-game speed where the same result could be calculated via pixel scaling (quite frankly, if that were the problem you at worst would need to redo the calc), but because comparing the speeds of objects by in-game value returned unreconcilable results were either one reference value needs to be faster than natural or another slower than natural, putting the reference value into doubt. That won't get fixed by pixel scaling either.
So this appears to focus on the wrong issue entirely and the actual issue is not listed in the list of disqualifying things.

I'm not sure I'm getting what you're saying here, that might be the case for the TF2 example (I'm not super familiar with the verse but they seem to have an inconsistency problem) but in the minecraft it doesn't have this problem. It was still rejected despite it being accepted in another calc for the same verse

Could you elaborate?

 

[LandonTheGuy]

finally someone covering this issue