Closed EntranceJew closed 9 months ago
Can you try the latest changes and see if the problem persists? I believe this is caused by the child circle's position not being set properly when CIRCLE:SetPos is called on the parent.
Can you try the latest changes and see if the problem persists? I believe this is caused by the child circle's position not being set properly when CIRCLE:SetPos is called on the parent.
I updated the lib, but something that I observed was that it wouldn't work unless I did this in the usage case, so you were correct about the child circle: https://github.com/TTT-2/TTT2/pull/1267/commits/3e0267c186df5945f91b092237efc2b3cf43f192
For reasons unknown to me, this other irrelevant error emits from LVS:
[EntranceJew|2|STEAM_0:1:19600218] Lua Error:
[[LVS] - Framework] lua/lvs_framework/autorun/cl_circles.lua:22: bad argument #1 to 'New' (number expected, got nil)
1. assert - [C]:-1
2. New - lua/lvs_framework/autorun/cl_circles.lua:22
3. unknown - addons/ttt2/gamemodes/terrortown/gamemode/client/cl_tbuttons.lua:16
4. include - [C]:-1
5. ttt_include - addons/ttt2/gamemodes/terrortown/gamemode/shared/sh_include.lua:184
6. unknown - addons/ttt2/gamemodes/terrortown/gamemode/client/cl_main.lua:92
7. include - [C]:-1
8. ttt_include - addons/ttt2/gamemodes/terrortown/gamemode/shared/sh_include.lua:184
9. unknown - addons/ttt2/gamemodes/terrortown/gamemode/cl_init.lua:3
Which doesn't seem right, maybe they're shipping a different version, I didn't look into it further.
Out of the box, though, calling the draw function still doesn't seem to update the child circle's position as having been marked dirty.
I updated the lib, but something that I observed was that it wouldn't work unless I did this in the usage case, so you were correct about the child circle:
Can you provide any standalone code that reproduces this? All the use cases I can think of are working as intended.
For reasons unknown to me, this other irrelevant error emits from LVS:
[EntranceJew|2|STEAM_0:1:19600218] Lua Error: [[LVS] - Framework] lua/lvs_framework/autorun/cl_circles.lua:22: bad argument #1 to 'New' (number expected, got nil) 1. assert - [C]:-1 2. New - lua/lvs_framework/autorun/cl_circles.lua:22 3. unknown - addons/ttt2/gamemodes/terrortown/gamemode/client/cl_tbuttons.lua:16 4. include - [C]:-1 5. ttt_include - addons/ttt2/gamemodes/terrortown/gamemode/shared/sh_include.lua:184 6. unknown - addons/ttt2/gamemodes/terrortown/gamemode/client/cl_main.lua:92 7. include - [C]:-1 8. ttt_include - addons/ttt2/gamemodes/terrortown/gamemode/shared/sh_include.lua:184 9. unknown - addons/ttt2/gamemodes/terrortown/gamemode/cl_init.lua:3
No idea what could be happening there other than the CIRCLE_* enums not being made globals for some reason.
Out of the box, though, calling the draw function still doesn't seem to update the child circle's position as having been marked dirty.
Changing a circle's position doesn't require it to be flagged dirty as CIRCLE:SetPos translates the vertices, which is considerably more performant than calculating a new set.
this is the stripped down code that causes it, and the commit i linked is the implementation where the only difference from master is some comment lines
local _R = debug.getregistry()
local circles = _R.Circles
local button_circle = circles.New(1, 16, 0, 0, 4)
button_circle:SetMaterial(true) -- Makes draw.NoTexture get called internally.
button_circle:SetColor(COLOR_WHITE)
local outlineColor = Color(255, 0, 0)
hook.Remove("HUDPaint", "circledemo")
hook.Add("HUDPaint", "circledemo", function()
local plypos = LocalPlayer():GetPos()
local midscreen_x = ScrW() * 0.5
local midscreen_y = ScrH() * 0.5
local pos, scrpos, d
local focus_but
local focus_d, focus_scrpos_x, focus_scrpos_y = 0, midscreen_x, midscreen_y
local usableRange = 400
local passable = {}
for _, ent in pairs(ents.GetAll()) do
if not IsValid(ent) then continue end
pos = ent:GetPos()
scrpos = pos:ToScreen()
d = pos - plypos
d = d:Dot(d) / (usableRange * usableRange)
-- draw if this button is within range, with alpha based on distance
if d >= 1 then continue end
passable[#passable + 1] = ent
end
for i = 1, #passable do
local ent = passable[i]
pos = ent:GetPos()
scrpos = pos:ToScreen()
d = pos - plypos
d = d:Dot(d) / (usableRange * usableRange)
local percent = i/#passable
local end_angle = 360 * percent
button_circle:SetStartAngle(-90)
button_circle:SetEndAngle(end_angle - 90)
button_circle:SetPos(scrpos.x, scrpos.y)
-- comment the next 3 lines out for a fun surprise
if button_circle and button_circle.m_ChildCircle then
button_circle.m_ChildCircle:SetPos(scrpos.x, scrpos.y)
end
button_circle:SetColor(ColorAlpha(outlineColor, 200 * (1 - d)))
button_circle()
end
end)
video of it occuring: https://youtu.be/cteW_GUGBWQ
It seems to be working as intended on my end with the provided code, with and without the code commented out, on both the stable and x64 branches of the game, and with multicore rendering enabled and disabled: https://img.sneakysqu.id/cimnwQg3.jpg
Also if you have the headroom for it you should consider lowering the distance on the circle since they tend to look jagged when they're that small.
unfortunately the size for them is dictated by the finger prompt thing and I'm not sure I can really change how big it appears on a screen
seems like the LVS version is just defining it first so the early registry check for it, if suppressed, allows the new version to function
I meant use CIRCLE:SetDistance. The default distance is 10 and for a circle with a radius of 16 that's only 10 vertices.
OH, yeah, this looks a lot better. Thanks!
I'm going to assume this is sorted and close the issue.
I was attempting to implement the
CIRCLE_OUTLINED
effect on this repo here, but the resulting effect looks like this instead:It's totally possible that something else is awry with our rendering stack that prevents this from working correctly, but it is confusing as to what it could be. In this photo, the area that is supposed to cut out from the main fill tracks the center of the screen / cursor, so the outline is only visible when perfectly aligned with the viewer.