0006364: Weight fraction not considered when calculating weapon velocities

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0006364

Dwarf Fortress

Combat -- General

public

2013-07-30 23:40

2014-07-23 10:49

Reporter

UristDaVinci

Assigned To

Toady One

Priority

low

Severity

minor

Reproducibility

always

Status

resolved

Resolution

fixed

Platform

OS Version

Product Version

0.34.11

Target Version

Fixed in Version

0.40.05

Summary

0006364: Weight fraction not considered when calculating weapon velocities

Description

Item weight appears to be stored as two numbers. The first number is the integer weight of the item. The second is the xxxxxx/1000000 fractional weight of the item. It appears that only the integer weight is used in the calculation of the (melee or ranged) weapon's (swing/shoot) velocity.

However, the momentum of the weapon appears to be calculated using both the integer weight and the weight fraction. This puts discontinuities in the plot of weapon momentum vs weight, and causes weapons of weights 0.999999 or less to travel at the MAX_VEL.

Steps To Reproduce

A melee weapon of weight 0.999999 has roughly 2x the momentum of a weapon of weight 1.000001

A melee weapon of weight 1.999999 has roughly 1.5x the momentum of a weapon of weight 2.000001

Etc.

I discovered the bug through various experiments in the arena, but Toady should be able to debug the numbers directly.

Additional Information

Bug 0006262 is a sub-bug (child) of the larger problem.

Tags

binary patch, Probable Quick Fix

Attached Files

Relationships

related to

0006262

resolved

Toady One

Rounding Error in Calculation of Projectile Velocities

Notes
(0024143) UristDaVinci (reporter) 2013-09-26 18:55	The bug is due to weight_fraction being divided by 100000 instead of 10000, causing a weapon of weight x.yyyyyy to act like a weapon of weight x.0yyyyyy The following binary patch fixes this problem in Win32 v0.34.11 SDL: 0x006C8BE2 : 89 b5 f8 14 -> d7 c5 6d 34 0x006C8BEE : 0D -> 0B so you end up with this at 0x006C8BE0 : ff b8 d7 c5 6d 34 6b db 64 f7 6f 60 cl fa 0b 8b

(0024163) UristDaVinci (reporter) 2013-10-09 12:33 edited on: 2013-10-09 21:16	The binary patch doesn't fix the related bug 0006262, which is caused by a different problem in other code.

(0027330) Toady One (administrator) 2014-07-23 10:49	This one bizarrely had the correct calculation in the debug log on the line below it. The extra zero must have gotten in later somehow... Scamps will be blamed.

Issue History
Date Modified	Username	Field	Change
2013-07-30 23:40	UristDaVinci	New Issue
2013-08-02 04:28	Knight Otu	Relationship added	related to 0006262
2013-09-26 18:55	UristDaVinci	Note Added: 0024143
2013-09-26 18:58	UristDaVinci	Tag Attached: binary patch
2013-09-26 18:58	UristDaVinci	Tag Attached: Probable Quick Fix
2013-10-09 12:33	UristDaVinci	Note Added: 0024163
2013-10-09 21:16	Footkerchief	Note Edited: 0024163	View Revisions
2014-01-15 14:49	Kirig Stonebeard II	Issue Monitored: Kirig Stonebeard II
2014-01-17 10:09	Kirig Stonebeard	Issue Monitored: Kirig Stonebeard
2014-03-25 13:22	Dwarfu	Assigned To	=> Dwarfu
2014-03-25 13:22	Dwarfu	Status	new => acknowledged
2014-07-23 10:49	Toady One	Note Added: 0027330
2014-07-23 10:49	Toady One	Status	acknowledged => resolved
2014-07-23 10:49	Toady One	Fixed in Version	=> Next Version
2014-07-23 10:49	Toady One	Resolution	open => fixed
2014-07-23 10:49	Toady One	Assigned To	Dwarfu => Toady One