fix acu teleport damage not aligning with blueprint

[Lightningbulb2]

Acu teleport now does exactly as much damage as it should (according to the blueprint)

fixes #7006

Checklist

- [ ] Changes are annotated, including comments where useful
- [ ] Changes are documented in a changelog snippet according to the guidelines.
- [ ] Request 2-3 reviewers from the list of reviewers and their areas of knowledge.

not necessary, tiny change

Summary by CodeRabbit

• Bug Fixes
  • Adjusted teleport-in effects during the brief hidden phase so the area damage uses a tree-force type, avoiding unintended damage behavior while remaining consistent in size and magnitude.
• Tuning
  • Slightly increased damage values for several related unit weapon configurations (including teleport-in dummy and death-triggered nuke/weapon placeholders) from 100 to 101 for improved consistency.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 7743e9ec-1540-463b-8ee5-500ec1bb6685

📥 Commits

Reviewing files that changed from the base of the PR and between dea8f33 and 733b32d.

📒 Files selected for processing (1)

• lua/EffectUtilities.lua

---

📝 Walkthrough

Walkthrough

Changes update teleport-in effect damage typing and increase weapon damage values in four unit blueprints.

Changes

Teleport Damage Adjustment

Layer / File(s)	Summary
Teleport-in DamageArea change lua/EffectUtilities.lua	The UEF, Cybran, Seraphim, and generic teleport-in effect threads now pass TreeForce to DamageArea instead of Force, with radius, damage amount, and friendly flag unchanged.
Weapon damage update in blueprints units/UAL0001/UAL0001_unit.bp, units/UEL0001/UEL0001_unit.bp, units/URL0001/URL0001_unit.bp, units/XSL0001/XSL0001_unit.bp	Weapon Damage changes from 100 to 101 in four unit blueprint weapon blocks.

Estimated code review effort: 1 (Trivial) | ~5 minutes

Suggested reviewers: Rhaelya

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Linked Issues check	⚠️ Warning	The change raises blueprint damage to 101, which conflicts with issue #7006's 100-damage requirement.	Keep teleport damage at 100 and fix the FX/damage-type logic so the ACU no longer applies an extra point.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title is concise and accurately describes the ACU teleport damage fix.
Description check	✅ Passed	It includes the change summary and linked issue, but omits the testing and additional context sections from the template.
Out of Scope Changes check	✅ Passed	All edits stay on the ACU teleport damage path and blueprint values; no unrelated code appears.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

🧹 Nitpick comments (1)

lua/EffectUtilities.lua (1)

1383-1383: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Extract the repeated epsilon value into a named constant.

The literal 0.000000001 is duplicated identically across all four faction branches. A shared local constant (e.g. local TELEPORT_IN_AOE_DAMAGE = 0.000000001) with a brief comment explaining why a near-zero (rather than exact 0) value is used would improve clarity and avoid drift if this needs tuning again.

♻️ Suggested refactor

+-- Effectively-zero damage used to preserve hit-reaction/VFX behavior in DamageArea
+-- without dealing meaningful damage (see issue `#7006`).
+local TELEPORT_IN_AOE_DAMAGE = 0.000000001
+
 function PlayTeleportInEffects(unit, effectsBag)
     ...
-                DamageArea(unit, unit:GetPosition(), 9, 0.000000001, 'Force', true)
+                DamageArea(unit, unit:GetPosition(), 9, TELEPORT_IN_AOE_DAMAGE, 'Force', true)

Also applies to: 1410-1410, 1447-1447, 1475-1475

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@lua/EffectUtilities.lua` at line 1383, The repeated near-zero damage radius
literal in EffectUtilities.lua should be replaced with a shared named constant.
Add a local constant near the relevant teleport/area-damage logic and use it in
each faction branch where DamageArea is called, so the same value is defined
once and stays consistent. Include a short comment by the constant explaining
why a near-zero value is used instead of exact zero.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@lua/EffectUtilities.lua`:
- Line 1383: The repeated near-zero damage radius literal in EffectUtilities.lua
should be replaced with a shared named constant. Add a local constant near the
relevant teleport/area-damage logic and use it in each faction branch where
DamageArea is called, so the same value is defined once and stays consistent.
Include a short comment by the constant explaining why a near-zero value is used
instead of exact zero.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 129878dd-2c55-4b1e-b9fa-c0864b59161e

📥 Commits

Reviewing files that changed from the base of the PR and between 827ec16 and 1890c6c.

📒 Files selected for processing (5)

• lua/EffectUtilities.lua
• units/UAL0001/UAL0001_unit.bp
• units/UEL0001/UEL0001_unit.bp
• units/URL0001/URL0001_unit.bp
• units/XSL0001/XSL0001_unit.bp

[lL1l1]

I think a more broad solution can be done:

1. Force type damage should be ignored by units instead. I'm not sure why they aren't, maybe @Garanas knows because he reworked the tree knocking behavior.
2. Alternatively all scripted Force damage types should be converted to TreeForce. This would have the least effect on mods. I prefer this solution with what I know.

Context for 1:
Units already handle some tree damage types:

fa/lua/sim/Unit.lua

Line 1377 in 1d1530b

if damageType == "TreeForce" or damageType == "TreeFire" then

This function handles the damage types used by trees for context:

fa/lua/proptree.lua

Lines 95 to 137 in a7ccd80

	OnDamage = function(self, instigator, amount, direction, type)
	if self:BeenDestroyed() or type == 'FAF_AntiShield' then
	return
	end
	local canFall = not self.Fallen
	local canBurn = (not self.Burning) and (not self.NoBurn)
	if type == 'Disintegrate' or type == "Reclaimed" then
	-- we just got obliterated
	EntityDestroy(self)
	elseif type == 'Force' or type == "TreeForce" then
	if canFall then
	-- change internal state
	self.NoBurn = true
	self.Fallen = true
	TrashAdd(self.Trash, ForkThread(self.FallThread, self, direction[1], direction[2], direction[3], 0.5))
	-- change the mesh
	EntitySetMesh(self, self.Blueprint.Display.MeshBlueprintWrecked)
	end
	elseif type == 'Nuke' and canBurn then
	-- slight chance we catch fire
	if Random(1, 250) < 5 then
	self:Burn()
	end
	elseif (type == 'Fire' or type == 'TreeFire') and canBurn then
	-- fire type damage, slightly higher odds to catch fire
	if Random(1, 35) <= 2 then
	self:Burn()
	end
	end
	if (type ~= 'Force') and (type ~= 'Fire') and canBurn and canFall then
	-- any damage type but force can cause a burn
	if Random(1, 20) <= 1 then
	self:Burn()
	end
	end

[Lightningbulb2]

I think a more broad solution can be done:

1. Force type damage should be ignored by units instead. I'm not sure why they aren't, maybe @Garanas knows because he reworked the tree knocking behavior.

2. Alternatively all scripted Force damage types should be converted to TreeForce. This would have the least effect on mods. I prefer this solution with what I know.

Context for 1: Units already handle some tree damage types:

fa/lua/sim/Unit.lua

Line 1377 in 1d1530b

if damageType == "TreeForce" or damageType == "TreeFire" then

This function handles the damage types used by trees for context:

fa/lua/proptree.lua

Lines 95 to 137 in a7ccd80

	OnDamage = function(self, instigator, amount, direction, type)
	if self:BeenDestroyed() or type == 'FAF_AntiShield' then
	return
	end
	local canFall = not self.Fallen
	local canBurn = (not self.Burning) and (not self.NoBurn)
	if type == 'Disintegrate' or type == "Reclaimed" then
	-- we just got obliterated
	EntityDestroy(self)
	elseif type == 'Force' or type == "TreeForce" then
	if canFall then
	-- change internal state
	self.NoBurn = true
	self.Fallen = true
	TrashAdd(self.Trash, ForkThread(self.FallThread, self, direction[1], direction[2], direction[3], 0.5))
	-- change the mesh
	EntitySetMesh(self, self.Blueprint.Display.MeshBlueprintWrecked)
	end
	elseif type == 'Nuke' and canBurn then
	-- slight chance we catch fire
	if Random(1, 250) < 5 then
	self:Burn()
	end
	elseif (type == 'Fire' or type == 'TreeFire') and canBurn then
	-- fire type damage, slightly higher odds to catch fire
	if Random(1, 35) <= 2 then
	self:Burn()
	end
	end
	if (type ~= 'Force') and (type ~= 'Fire') and canBurn and canFall then
	-- any damage type but force can cause a burn
	if Random(1, 20) <= 1 then
	self:Burn()
	end
	end

I added option 2: It works perfectly fine using TreeForce so I don't see why not, plus it better indicates what it's actually doing in this case. (Damaging trees, not troops) I kinda thought it was there for some other sort of compatibility reason until I checked the 12 year old PR that added it.