Recent Posts

Yes for me, all arrows with overlapping moves even after e4 e5 is the pgn included Qf3 then the arrows will be present even deeply, i honestly have been using the arrows just fine so it's not an issue for me anymore if anything they're still good illustrations albeit sometimes annoying, but wherever there is overlap there was surviving arrows, at least that's how i remember it. if you tried it and it worked as you said then i probably am mistaken

Thanks, when I tested this, with exactly your small PGN snippet, what I found is that only moves that overlapped with other repertoires kept the arrows. So I loaded the PGN you showed in your post , and then deleted that repertoire (then did a page reload just to make sure any in-memory arrows were also cleared - this step may not have been necessary, but I just wanted to make sure), then loaded a modified version of your repertoire with none of the arrow annotations, i.e this:

Code:

[Event "E5 Repertoire"]
[Site "?"]
[Date "2024.04.13"]
[Round "?"]
[White "1) 1.e4 e5 - Weird tries"]
[Black "2.Qf3 #1"]
[Result "*"]

1. e4
1... e5
2. Qf3 $6
2... Nf6
{ Best move}
3. g4 $2
{  Too stubborn}
3... d5 $1
{ playing for the centre. }
4. exd5 Bxg4 5. Bb5+
5... Nc6 $19
{ develop with every move}
*

At that point 1.e4 and 1.e5 arrows/colours had survived, as I still had those moves in other repertoires, so the delete repertoire would not have removed them (in fact there was a bug where these moves didn't show their arrows until after I reloaded the page, so it seems for overlapping moves to get their arrows a page reload was required, a bug which I've filed a todo list item against in our bug tracker). However none of the subsequent moves from 2.Qf3 onwards had arrow or square highlights shown.

So when you loaded your new repertoire, I assume you had cleared all the arrow/square annotations from the PGN as in my example above? Are you sure the persistent annotations were not from overlapping moves in other repertoires? i.e did the deeper moves in the repertoire that were unlikely to overlap still have arrows/square highlights?

Ur assumption is correct, but the thing is the moves ARE present in the new pgn for example there's E4 E5 in the previous pgn and this repeats in the new one but in the new one there's no arrows so the arrows from the previous pgn are sticking even to the new one but just where there is overlap, as for a snippet here's one

[Event "E5 Repertoire"]
[Site "?"]
[Date "2024.04.13"]
[Round "?"]
[White "1) 1.e4 e5 - Weird tries"]
[Black "2.Qf3 #1"]
[Result "*"]

1. e4
{ [%cal Gd1h5,Gf1c4,Ye4d5] [%csl Gd5,Ge4]}
1... e5
{ [%csl Ge4,Ge5]}
2. Qf3 $6
{ [%cal Gg1f3] [%csl Rf3]}
2... Nf6
{ Best move}
3. g4 $2
{ [%cal Yg4g5,Yf1c4,Yc4f7,Yf3f7] [%csl Rf7] Too stubborn}
3... d5 $1
{ [%cal Yf6e4,Yf6g4,Yc8g4] [%csl Gd5,Re4,Ge5,Gf6,Rg4]playing for the centre. }
4. exd5 Bxg4 5. Bb5+
5... Nc6 $19
{ [%csl Rd5]develop with every move}
*

but honestly i got the pgn as such so i have no idea how these were defined and/or what these symbols are/ what they imply but considering it's Anormal i would say they're used for board annotations.

I'm glad you're finding the opening trainer useful. I've added a todo list item for an animation on click-click movement, but as mentioned with a very large existing todo list, something like this is probably going to be a bit further down the priority queue (and so far you are the only person that has requested it).

I'm assuming the issue was that you had imported a PGN with arrow annotations, then in attempt to remove them, deleted the repertoire and reimported it with a PGN without arrow annotations, and that after that reimport, the arrows from the previously deleted repertoire were still attached to the moves despite the new PGN import not including them. If this assumption is correct then I'm just after an example position/move pair and repertoire name I can use to lookup in the database exactly what is going on. If the unwanted arrows appear in moves directly off the initial position, without any move needed to be played then just the repertoire name should be enough, although the arrow might be attached to the target training move for that position, so perhaps mention what that is too. If you still have the original PGN with the arrow annotations in place, just provided an example snippet from the PGN of the first move or two so I can see how the PGN is defining the arrows might be useful in helping debug the issue too.

Alright, no problem, I finally got used to it . I also get that it minimizes move times. Although I think enabling that option  shouldn't be completely forgotten even if it's not a priority. In some other platforms, this animation exists and it might disturb some people who are not used to having zero delay for their piece movements.
This minor point aside, thank you a lot for this website, I find the opening trainer remarkably useful as well as really ergonomic. I also recently downloaded the app which is also reallly ergonomic.

I didn't understand sorry do you mean the current repertoire i have? like the name of it and the fen of the move prior? or do u want me to erase my current repertoire( with the board annotations) import another one without them and send the fen for the first move with arrows for the repertoire i imported without the annotations? as the annotations begin from move one really as soon as e4 is played there's annotations, but the current repertoire i imported has the annotations built in

Ok, can you give us a repertoire name, and fen position and move example with a unkillable board arrow so we can further investigate. You can get the fen for the current position by pressing g then f (grab fen), I think we need the fen BEFORE the move in question is played.

Hello, yes i'm sure i deleted all my repertoires and my comments(several times) and still even if i import a completely different repertoire with SOME overlaps but there's no board annotations there the arrows always show so the annotations get carried even if the moves themselves don't, i have a ton as well so it might be a bit of a hassle to delete all

Note that the 'wrong one' isn't necessarily always going to be bad, sometimes it is just not as good as the first option.

The try again responses are all auto-decided by stockfish at reasonably high depth, so if SF thinks the alternative move is still winning then a try again will be given. In practice I don't think this is a major issue, in general, you still need to find the best move (although you may need to play around with the 'try again' book specific options as some good moves might trigger a hint  or auto-play on the best move, especially if there were a lot of good moves and hunting for one good move amongst many would be annoying, so if you don't want that you can make the providing of a hint optional using the try again settings).

Stockfish can still get some positions wrong, for example you can get a try again sometimes in a fortress that stockfish hasn't correctly analysed as drawn. If you find cases like that, please let us known, and we'll override them manually.