Comments/Ratings for a Single Item
I wanted to do ID but sth went wrong;) simply I never did it alone.
I've made a Game Courier preset, but in first time it made to move King as Silver, Silver was immobile, castling was disabled; but in second time, there is an error on line I haven't any access to.
The error occurs in the include file, and the indicated line number suggest there is something worng with the value of the variable 'rng', which is the maximum range of a sliding move. Now the legdefs table that the Play-Test Applet generated appears to contain the value 'true' as first element on some of its lines (which is supposed to contain the range). Which is highly suspect, and should likely have been 1 instead. So it seems the GAME-code generation routine in the Play-Test Applet has a bug, which only expresses itself in the final leg of a mult-leg move.
It would help if you could post the HTML code of the Interactive Diagram this GAME code was generated from.
Thx very much for your attention, so catch:
files=8 ranks=8 promoZone=1 promoChoice=MRNS graphicsDir=/graphics.dir/alfaeriePNG/ squareSize=50 graphicsType=png pawn:P:ifmnDfmWfceF:pawn:a2,d2,e2,h2,,a7,d7,e7,h7 warrior:W:fmFifmnAfceWfcnD:berolinapawn:b2,c2,f2,g2,,b7,c7,f7,g7 knight:N:N:knight:b1,g1,,b8,g8 rook:R:R:rook:a1,h1,,a8,h8 magician:M:afyafyafsK:mage:d1,,d8 silver:S:FfW:silvergeneral:c1,f1,,c8,f8 king:K:KisO2:king:e1,,e8
I don't know the reason comptuer makes Silver more valuable than all (exc. for King), when Silver must be a little cheaper than Knight. I tried to fix it manually and bring the Silver on his (normal) place, but it was started a flood of errors in GC preset. Before it worked, King was royal, but he moved as Silver (and castling was illegal), when Silvers were fully immobile. Very strange)))
UPD: this GAME code was edited a lot by me.
The problem with the GAME-code generation should be solved (flush browser cache to use new version of the script), in the sense that it now generates 1 for a range after toggling it from slide to leap through the y modifier, rather than 'true'. In the JavaScript 1 and true were equivalent, but the error message suggested that in GAME code they are not. I hope this solves the problem.
BTW, rather than generating the GAME code again through the fixed Play-Test Applet, you could just edit the GAME-code you already had, replacing the 'true' in the legdefs array definition by 1 everywhere.
I don't know the reason comptuer makes Silver more valuable than all (exc. for King), when Silver must be a little cheaper than Knight. I tried to fix it manually and bring the Silver on his (normal) place, but it was started a flood of errors in GC preset. Before it worked, King was royal, but he moved as Silver (and castling was illegal), when Silvers were fully immobile. Very strange)))
I cannot reproduce this. When I copy-paste your code for the HTML into the Play-Test Applet (I have to remove some trailing spaces that apparently were added by the copy-paste process to make that work) and ask for the piece-value estimates, Knight, Magician and Rook are all considered more valuable than Silver.
Can you publish it, please? Thx for helping)
BTW, rather than generating the GAME code again through the fixed Play-Test Applet, you could just edit the GAME-code you already had, replacing the 'true' in the legdefs array definition by 1 everywhere.
Still same result(
Still same result(
Well, it seems you have been messing up the legdefs array, swapping piece definitions, as the numbers returned by the piece functions no longer correspond to the move definitions for the corresponding piece. In some cases they are even 'out of phase', so that the y-step of a piece is interpreted as a range, and this causes the error when the y-step is too negative.
For example, you have
def N cond #0 135 0;
But in fact the legdefs array contains the definition of Silver in that location, not Knight. You apparently have inserted the Silver definitions before that of Knight, with as a result that the definition of the Knight moves now starts at 187 instead of 135. You cannot juggle the move definitions in legdefs without adapting the piece routines to the new location of their moves.
10 comments displayed
Permalink to the exact comments currently displayed.
This is ready.