Closed onikiienko closed 8 months ago
Confirmed, even with the smaller amount of blips on our radar.
We'll investigate how to solve this. Ideally, the blips would behave like atoms or magnets with equal poles and repel to maintain a minimum distance.
Out of curiosity: how many items do you have on the radar at the moment?
It's 290 items on the radar at the moment
Hi, @srotsch! are there any updates on this issue? Do you need any additional information from my side?
Hi @onikiienko! Nothing to do on your side, it's us being busy with other things… sorry about that. But as we're planning to release a new version of our technology radar within the next couple of weeks, we're committed to fix this issue as soon as possible. Thanks for the reminder and your patience.
Great! Thanks, looking for further news🙌
Fingers crossed that the new version 4.0.0 also reduces the problem of overlapping entries to a minimum for you. ✊
BTW: If this doesn't help, it may help to increase the size of the first ring (rings[0].radius
), via config.json
, "radius": 0.6
https://github.com/AOEpeople/aoe_technology_radar/blob/main/data/config.json#L46
I'll try to upgrade to the latest version. You rock, guys!
Hi! I do like a lot the idea of deterministic behavior for radar by storing the random fractions when generating rd.json introduced in the v3.5.3
But, unfortunately, I've faced a problem with blips overlapping. Especially when those blips are many. It seems that chosen approach started to pick worse coordinates for blips, it looks a bit "collapsed" now than it was made by d3 while rendering the chart. Is there a way to fix this issue, or, at least, switch off storing the random fractions?
I could see the same situation www.aoe.com/techradar but it is less critical because of a number of blips.
v3.5.2
v3.5.3