#Show rez sub sonar coverage by lower sonar filter rendering
1 messages · Page 1 of 1 (latest)
This could also fix garpike sonar rendering because they have 175 sonar also not rendered
@serene forge
We found there is a nasty filter at 250 which pruned every sonar coverage below this number, i suggest lower this filter at 149 to permit rez sub and garpike/pincer to show their sonar coverage, what do you think ?
Rez sub sonar => 150
Garpike => 175
Pincer => 180
Cetus => 180
Whose name is on the widget?
#1426088895636049950 message
You remember the widget that contain the filter @unreal mural ?
I would ask what the original intent was. It sounds like an intentional exclusion to prevent excessively noisy trivial sonar ranges.
Like, maybe it's supposed to be Los equivalent for underwater units for when they are close enough to "bump" into things
Because it would be very silly if you're navigating around things you can't see lol
Yeah the small sonar values are just that. They make things a bit less silly. I think this could be reworked in the Itanthias radar branch, but that's a separate thought.
I believe the widget is gui_sensor_ranges.lua. Changing the cutoffs for the filters seems fine to allow, and would use a settings slider. But I think the suggestion is also to change the default cutoffs, somehow.
Line 33 :
local minSonarDistance = 250
for unitDefID, unitDef in pairs(UnitDefs) do
if unitDef.sonarDistance and unitDef.sonarDistance > minSonarDistance then -- save perf by excluding low sonar range units
if string.find(unitDef.name, "raptor", nil, true) then
-- skip raptors from sonar
else
unitRange[unitDefID] = unitDef.sonarDistance
end
end
end
Look like it is for performance indeed, but having rez sub with sonar coverage rendered have value, even more with new unified "reclaim enemies" and F special move "reclaim enemies".
Modify filter minSonarDistance at 149 maybe for safety.
@wind vigil Any major reasons to keep this filter that high ?
https://github.com/beyond-all-reason/Beyond-All-Reason/pull/5477
Small sonar rings are important though, because of how sonar affects vision.
Otherwise how will a user work out why tumbleweed can't see things but pincer can?
Sounds to me like the tumbleweed was a exemption overlooked, unintentional that it can't discover things by bumping into them
Now you talk about tumbleweed, indeed they never had sonar, weird because one of his use case is to kill opponent sea mex, so you need a sonar unit near it to see things UW or just random self D if you think there is a mex (easy to deduct as it block path).
Would be cool to have beherith opinion on this, i pinged him one time, don't want to ping more, if you can contact him, would be op.
The filter on jammer coverage is 63 and the first units with jammer that lower is minelayer with 64.
If we apply the same logic with sonar coverage, we should put the filter at 149
We are just unlikely to make the change until it's been discussed a bit, with or without Beherith.
Whether this is for performance or for UI declutter, then we could identify a high-strain case and just test it, like 400 rez subs. I'm back on the road for a day, no testing for me rn.
And I think re: tumbleweed that might be good as it is.
Rez sub still not have his sonar coverage rendered, any news on this ?
I don't think anyone has thought about this
I might test and PR this today
Set a reminder in 2 hours from now (<t:1774889808:f>)
View reminders with the reminders command
Reminder for @midnight umbra
Take a look at this
Tested and PR made:
https://github.com/beyond-all-reason/Beyond-All-Reason/pull/7277
@serene forge
Expect it to get picked up in the next PR review session (1-2 weeks)
OP !
Look i'm on tv!
@midnight umbra Tyty !!
Cortex