[bug] Идентификаторы света взрывов сталкиваются для одинаковых tick и целой X #15

New Issue

2026-10-29T11:59:36Z

chexit commented

2026-10-29 11:59:36 +00:00

Проверка исходников на 90379f6. Полный Horizon/GPU на Mac не запускался; оценки сложности и ресурсов ниже не являются замерами FPS.

ID HD-light взрыва вычисляется из b.start и целой b.at.x. Координаты Y/Z и отдельная идентичность Blast не участвуют. Два взрыва в одном тике на одинаковой целой X, но разных Z получают одинаковый ID. В Game::update_mod_models() lights складываются в HashMap по (owner, id), поэтому один перезаписывает другой.

Простой контрпример по текущей формуле: start=100, x=0, z=100 и z=200 → оба id=0x61000c1c. Из двух lights после HashMap остаётся один. Это может приводить к пропаданию подсветки при одновременных перехватах/детонациях.

Предложение: выделять Blast стабильный уникальный ID при создании и использовать его для light до конца жизни эффекта. Не использовать только индекс в меняющемся Vec (интерполяция требует стабильной identity); выбрать namespace без пересечений с model lights. Хеш всех координат всё равно не гарантирует уникальности.

Критерий: несколько blasts в одном тике с одинаковой X сохраняют отдельные lights и корректную интерполяцию; удаление одного не перемещает другой.

Код:

		airdef/airdef-mod/src/lib.rs
		Line 310 in 90379f6
	
				            let id = 0x6100_0000 ^ (b.start as u32).wrapping_mul(31) ^ (b.at.x as i32 as u32).wrapping_mul(7);

,

airdef/horizon-patches/0011-HD-lighting-G-buffer-pass-per-pixel-mod-point-lights.patch Line 120 in 90379f6

+ pub(super) fn mod_hd(&self) -> Option<horizon_client::gfx::HdSettings> {

.

Проверка исходников на `90379f6`. Полный Horizon/GPU на Mac не запускался; оценки сложности и ресурсов ниже не являются замерами FPS. ID HD-light взрыва вычисляется из `b.start` и целой `b.at.x`. Координаты Y/Z и отдельная идентичность Blast не участвуют. Два взрыва в одном тике на одинаковой целой X, но разных Z получают одинаковый ID. В `Game::update_mod_models()` lights складываются в HashMap по `(owner, id)`, поэтому один перезаписывает другой. Простой контрпример по текущей формуле: start=100, x=0, z=100 и z=200 → оба id=0x61000c1c. Из двух lights после HashMap остаётся один. Это может приводить к пропаданию подсветки при одновременных перехватах/детонациях. Предложение: выделять Blast стабильный уникальный ID при создании и использовать его для light до конца жизни эффекта. Не использовать только индекс в меняющемся Vec (интерполяция требует стабильной identity); выбрать namespace без пересечений с model lights. Хеш всех координат всё равно не гарантирует уникальности. Критерий: несколько blasts в одном тике с одинаковой X сохраняют отдельные lights и корректную интерполяцию; удаление одного не перемещает другой. Код: https://gitea.maoniao.team/chexit/airdef/src/commit/90379f6/airdef-mod/src/lib.rs#L310, https://gitea.maoniao.team/chexit/airdef/src/commit/90379f6/horizon-patches/0011-HD-lighting-G-buffer-pass-per-pixel-mod-point-lights.patch#L120.

chexit added the area:rendering priority:P2 type:bug labels 2026-10-29 13:09:51 +00:00

chexit referenced this issue from a commit

2026-10-29 13:28:10 +00:00

P2/P3 issues: network-fed launchers priced into smart routes (#4), stable blast light ids (#15), retargeted smart drones replanned round the defences (#21), sim tick without per-unit clones and linear scans (#26), ground cache swept rarely (#31), Oreshnik pieces keep their sector (#32), drives with acceleration and fire only once aimed (#33), radar monitor range (#19), delayed sound volume (#22), world change clears transient state (#23), score line always shown (#24), replay map without full paths (#25), text fit by bisection (#27), docs (#29), glow occlusion by ray distance (#14), blasts composited nearest first (#16)

chexit commented

2026-10-29 13:29:21 +00:00