Sorry, I bungled this big time. I just slipped in a simple line of code in all 3 betza.js scripts before switching off the PC and going to bed. That will teach me to never, never make a change without testing. The almost infallible rule is that when I paste in a line of code in multiple places it ALWAYS contains a bug or typo.
In this case I had written "if(sats === undefined)", and it turns out this causes a run-time error when sats is undefined. It had to be "if(typeof(sats) == 'undefined')".
I fixed that now, and to test whether it worked as expected I scrolled down through the Comments list until I encountered a page with three Diagrams. The first of that was apparently the Comment you are using for experimenting with the background buttons. The second Diagram, which was my recent, modernized copy of the old Xiangqi Diagram, refused to be parsed unless I viewed it is isolation.
In figuring that out, and to explain the unexpected Diagram numbering the sats[] array showed of the other two Diagrams (the one appearing first had the highest number!), I discovered the following problems:
1) The two Xiangqi Diagrams used the same value for satellite=xiang. This thwarts the purpose of allowing external elements to recognize which Diagram they belong to by discriminating them by satellite.
2) Your Diagram was cloned from mine, which was again cloned from the very old Xiangqi Diagram. In that thime Diagrams were recognized by the betza.js script by having id="diagram". Both clones still had that. But in HTML the ids are supposed to be unique, and with getElementById() it would only find the first one. This is why my Diagram was ignored. For allowing multiple Diagrams on one page I later switched to recognizing Diagrams by class="idiagram"; with geteElementsByClassName() you can then get an array of all Diagrams on the page. For backward compatibility it still also looks for an id="diagram", and if it finds one it adds that to the array as last element. This explained why the first Diagram got the highest index in the array.
I now corrected both issues by having my Xiangqi diagram use satellite=xiang2, and making all Diagrams flagging their presence through class, rather than id. This should cause the page to behave less erattically. In the console log the script now prints
Object { piece: 2, xiang2: 1, xiang: 0 }
for the sats[] array after the last Diagram has been parsed. ('piece' is the default value for satellite, and represents HaruN Y's Diagram on that page).
BTW, I noticed you were using very many buttons for different styles. I don't know what your objections were to the layout of the auto-generated buttons, but it is possible to control that layout somewhat: If a set name starts with an asterisk, like set=*Oriental, the asterisk would be stripped off the name, and the button would be placed on a new line. That way you can prevent uncontrolled wrapping in a large row of buttons.
If you don't want to use auto-generated buttons, you can still divide up the Diagram definition in sets, by using numeric values for the set indicators; this suppresses creation of buttons. You can then make your own buttons select a set by having them call TwitchDiag(diagNr, setNr). The diagNr you could get in a reliable way as sats[satelliteValue]. But for the main Diagram on an article page, where no one can pre-empt you with other Diagrams, it would always be 0. (If you identify the Diagram by class, that is.)
Sorry, I bungled this big time. I just slipped in a simple line of code in all 3 betza.js scripts before switching off the PC and going to bed. That will teach me to never, never make a change without testing. The almost infallible rule is that when I paste in a line of code in multiple places it ALWAYS contains a bug or typo.
In this case I had written "if(sats === undefined)", and it turns out this causes a run-time error when sats is undefined. It had to be "if(typeof(sats) == 'undefined')".
I fixed that now, and to test whether it worked as expected I scrolled down through the Comments list until I encountered a page with three Diagrams. The first of that was apparently the Comment you are using for experimenting with the background buttons. The second Diagram, which was my recent, modernized copy of the old Xiangqi Diagram, refused to be parsed unless I viewed it is isolation.
In figuring that out, and to explain the unexpected Diagram numbering the sats[] array showed of the other two Diagrams (the one appearing first had the highest number!), I discovered the following problems:
1) The two Xiangqi Diagrams used the same value for satellite=xiang. This thwarts the purpose of allowing external elements to recognize which Diagram they belong to by discriminating them by satellite.
2) Your Diagram was cloned from mine, which was again cloned from the very old Xiangqi Diagram. In that thime Diagrams were recognized by the betza.js script by having id="diagram". Both clones still had that. But in HTML the ids are supposed to be unique, and with getElementById() it would only find the first one. This is why my Diagram was ignored. For allowing multiple Diagrams on one page I later switched to recognizing Diagrams by class="idiagram"; with geteElementsByClassName() you can then get an array of all Diagrams on the page. For backward compatibility it still also looks for an id="diagram", and if it finds one it adds that to the array as last element. This explained why the first Diagram got the highest index in the array.
I now corrected both issues by having my Xiangqi diagram use satellite=xiang2, and making all Diagrams flagging their presence through class, rather than id. This should cause the page to behave less erattically. In the console log the script now prints
for the sats[] array after the last Diagram has been parsed. ('piece' is the default value for satellite, and represents HaruN Y's Diagram on that page).
BTW, I noticed you were using very many buttons for different styles. I don't know what your objections were to the layout of the auto-generated buttons, but it is possible to control that layout somewhat: If a set name starts with an asterisk, like set=*Oriental, the asterisk would be stripped off the name, and the button would be placed on a new line. That way you can prevent uncontrolled wrapping in a large row of buttons.
If you don't want to use auto-generated buttons, you can still divide up the Diagram definition in sets, by using numeric values for the set indicators; this suppresses creation of buttons. You can then make your own buttons select a set by having them call TwitchDiag(diagNr, setNr). The diagNr you could get in a reliable way as sats[satelliteValue]. But for the main Diagram on an article page, where no one can pre-empt you with other Diagrams, it would always be 0. (If you identify the Diagram by class, that is.)