We must go deeper!local l = df.global.world.proj_list
l=l.next
while l do
printall(l.item)
print("-")
l = l.next
end
Copy the lines of script.
Open your text editor of choice.
Paste the text and save as chkproj.lua or whatever name you want, and put it in the scripts folder of your DFhack directory.
In the DFhack console, make sure you're in the root menu and not in liquids, dfusion or lua mode. Type chkproj or whatever name you used for the script.
You'll see something like this:
DFHack is ready. Have a nice day!
Type in '?' or 'help' for general help, 'ls' to see all commands.
{DFHack}# chkproj
link = <proj_list_link: 0x12cdd958>
id = 0
firer = <unit: 0x128d0fc8>
origin_pos = <coord: 0x1096a620>
target_pos = <coord: 0x1096a626>
cur_pos = <coord: 0x1096a62c>
prev_pos = <coord: 0x1096a632>
distance_flown = 4
fall_threshold = 60
min_hit_distance = 9
min_ground_distance = 59
flags = <projectile_flags: 0x1096a648>
fall_counter = 0
fall_delay = 0
hit_rating = 21
unk21 = 0
unk22 = 1000
bow_id = 0
unk_item_id = -1
unk_unit_id = -1
pos_x = 0
pos_y = 0
pos_z = 0
speed_x = 0
speed_y = 0
speed_z = 0
accel_x = 0
accel_y = 0
accel_z = 0
item = <item_ammost: 0x0e890c88>
-
{DFHack}#
The hit_rating has something to do with accuracy and gets larger as you increase dwarf skill.
The names above were chosen by the DFHack developers, so anything with "unk" is unknown. I highlighted unk22 because I figured out what it is. unk22 is never larger than the crossbow's SHOOT_MAXVEL, and varies according to bolt weight and the SHOOT_FORCE, so I think unk22 is the projectile "velocity". The pre-minecart projectiles didn't travel faster across the screen when they had a high velocity (they instead move 1 tile/tick), but the new parabolic projectiles do and they use the new xyz numbers in the data structure.
By varying material density, SHOOT_FORCE, and SHOOT_MAXVEL, I found the following algorithm:
- Find the weight of your bolt (candy 0.03, iron 1.18, platinum 3.21, wood 0.15)
- Floor that number to an integer (0, 1, 3, 0)
- Divide the SHOOT_FORCE by the integer, and integer the results (∞, 1000, 333, ∞)
- Cap the results by the SHOOT_MAXVEL (1000, 1000, 333, 1000)
So I tested candy, iron, platinum, gold, slade, and wood bolts using SHOOT_FORCE=2012 and SHOOT_MAXVEL=3000 and got unk22 values of (candy 3000, iron 2012, platinum 670, gold 1006, slade 67, and wood 3000).
An implication of this algorithm to a default-force, superhigh-maxvel crossbow is that a bolt which weighs 1.01 urists will be shot at velocity 1000, whereas a bolt which weighs 0.99 urists will be shot at "divide by zero" speed. This is absurd since the crossbow hasn't propelled the projectile with more force. Decreasing the bolt's weight by a negligible amount has made it orders of magnitude more dangerous. This problem wouldn't exist if Toady was using a floating point calculation for the bolt weight and shoot force.
So what happens when you compare the velocities calculated from this algorithm to the deflection data?