Squamous Eventful Plugin Suggestions
Maintainer thường phản hồi trong vòng 3 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 30/100
Hướng nghiên cứu
The request proposes several new Eventful hooks: projectile item removal or landing, flow creation, and queued ranged weapon actions, plus a question about projectile firer data. Start by reading Eventful's existing event definitions and the DFHack hooks that expose projectile, flow, and unit action changes. Done means agreeing on which hooks and guarantees are needed, implementing the selected events, and adding coverage for them; the issue does not name specific files or tests.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
As per the prior discord conversation here is the stuff that would really benefit me currently. This is gonna be a little scatterbrained but here goes:
- Something that fires when a proj_itemst is removed from world.projectiles.all. Right now, my magazine system has to, when it is "fired", set its velocity to 0 and drop it at the shooters feet, tracking it the entire time, until it lands, at which point it is deleted and a copy added to the shooter's inventory (while this is going on, a bullet is spawned from the magazine, and the newly spawned magazine has its bullet count decreased by 1). This is what that snippet of code looks like:
local function try_return(info, attempt)
if not S.enabled then return end
local item = df.item.find(info.item_id)
if not item then return end
local still_proj = false
pcall(function() still_proj = item_is_projectile(info.item_id) end)
-- this scans all of world.projectiles.all each call
if still_proj then
if attempt <= 30 then
dfhack.timeout(1, "ticks", function() try_return(info, attempt + 1) end)
end
return
end
-- ... inventory stuff (return mag to container)
end
-- Called for every single shot:
dfhack.timeout(2, "ticks", function() try_return(ret_info, 1) end)
local function try_remove(item_id, attempt)
if not S.enabled then return end
local item = df.item.find(item_id)
if not item then return end
local still_proj = false
pcall(function() still_proj = item_is_projectile(item_id) end)
if still_proj then
if attempt <= 30 then
dfhack.timeout(1, "ticks", function() try_remove(item_id, attempt + 1) end)
end
return
end
pcall(dfhack.items.remove, item)
end
-- Called for every single shot:
dfhack.timeout(2, "ticks", function() try_remove(item.id, 1) end)
If there was something, like, say, onProjItemLanded(item_id), it could maybe look like this:
-- ammo.lua enable():
eventful.onProjItemLanded["ammo"] = function(item_id)
local info = S.pending_returns[item_id]
if not info then return end
S.pending_returns[item_id] = nil
-- ... do the inventory work directly, no polling
end
-- shotgun.lua enable():
eventful.onProjItemLanded["shotgun"] = function(item_id)
if not S.pending_removals[item_id] then return end
S.pending_removals[item_id] = nil
pcall(dfhack.items.remove, df.item.find(item_id))
end
==================================================================================
Q: is proj.firer (the unit pointer on a proj_itemst) guaranteed to be non-nil when onProjItemCheckMovement fires?
A (that i got in discord): probably not, since projectiles can also be created by things being thrown into the air by various other mechanics
o currently i have to do this to track every shot, and it happens every tick:
local function find_firer_id(bow_id)
if bow_id < 0 then return -1 end
for _, unit in ipairs(df.global.world.units.active) do
if dfhack.units.isActive(unit) and not dfhack.units.isDead(unit) then
for _, inv_item in ipairs(unit.inventory) do
if inv_item.item.id == bow_id then
return unit.id
end
end
end
end
return -1
end
But if proj.firer could be guaranteed to be set at onProjItemCheckMovement time, I can make it look like this (or even something cleaner):
local firer_unit_id = -1
pcall(function()
if projectile.firer then
firer_unit_id = projectile.firer.id
end
end)
==================================================================================
- Something like "onFlowCreated", firing when a flow is created on the map either via dfhack.maps.spawnFlow() or by DF mechanics. Right now I have a script that prunes excess fire so all the flamethrowers and incendiary grenades I have don't completely torch the map each time. The check looks like this:
local CHECK_INTERVAL = 50 -- ticks between scans
local function check_fire()
if not enabled then return end
call_tick = call_tick + 1
local seen = {}
for _, block in ipairs(df.global.world.map.map_blocks) do
for _, flow in ipairs(block.flows) do
if flow.type == df.flow_type.Fire then
local wx = block.map_pos.x + flow.pos.x
local wy = block.map_pos.y + flow.pos.y
local wz = block.map_pos.z
local key = pos_key(wx, wy, wz)
seen[key] = true
if not fire_ages[key] then
fire_ages[key] = call_tick
elseif (call_tick - fire_ages[key]) >= GRACE_CALLS then
flow.expanding = false
end
end
end
end
-- ... prune stale entries
dfhack.timeout(CHECK_INTERVAL, "ticks", check_fire)
end
But if there was something like that, I could make it look like this:
eventful.enableEvent(eventful.eventType.FLOW_CREATED, 1)
eventful.onFlowCreated["firecontrol"] = function(pos, flow_type)
if not enabled then return end
if flow_type ~= df.flow_type.Fire then return end
local key = pos_key(pos.x, pos.y, pos.z)
if not fire_ages[key] then
fire_ages[key] = call_tick
end
end
- Another thing I just ran into, something like onShootRangedWeapon), which would fire when a unit queues a ShootRangedWeapon action, would be huge for me. I could cut down a lot of uses of repeat-util.
- Ngôn ngữ chính
- C++
- Star
- 2.1k
- Fork
- 509
- Merge trung bình
- 2 ngày 19 giờ
- Pull request đã merge (30 ngày)
- 25
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của DFHack/dfhack
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 3 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
DFHack/dfhack#5853 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 3 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
Maintainer thường phản hồi trong vòng 3 ngày
-
RemoteFortressReader: GetCreatureRaws sends CP437 (not UTF-8) strings, which breaks protobuf decodingCó thể đã có người làm @dwmuller đã nhận 2 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 20/100
DFHack/dfhack#6019 · 3 bình luận ·
Maintainer thường phản hồi trong vòng 3 ngày
-
reclaim with legends continuityĐang mở
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
Maintainer thường phản hồi trong vòng 3 ngày
Tất cả issue của DFHack/dfhack
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 1 ngày
-
enhancement GUI maintainer-review
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
aethersdr/AetherSDR#6681 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Add string concatenationĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Maintainer thường phản hồi trong vòng 1 ngày