Comments/Ratings for a Single Item
I can't find the game courier preset. Is there one?
One of us could make it. I'm interested in trying this too
💡📝H. G. Muller wrote on Sat, Apr 20 07:56 PM UTC in reply to Daniel Zacharias from 07:36 PM:Don't count on automatic conversion of the Interactive Diagram to GAME code, though. There are some aspects of this variant that are not supported yet by the betza.txt include file that powers such GAME code. In particular the captureMatrix, which is used to make the flying pieces block each other.
I thought that might be the case. They don't seem too different from pieces I've done before with GAME code. It's the Terror that looks most difficult, actually. I have not yet managed to comprehend rule enforcing for multi-moving pieces.
Might it work to use the generated code for most of it and manually define the pieces that wouldn't work?
💡📝H. G. Muller wrote on Sat, Apr 20 08:47 PM UTC in reply to Daniel Zacharias from 08:09 PM:Might it work to use the generated code for most of it and manually define the pieces that wouldn't work?
I suppose this would be an option; the 'Custom Pieces' section of the 'Wizard for GAME-code generation' article described how to add pieces that would need explicit programming. I think the Terror would not be problematic for the automatic conversion; it is the flying pieces that would need separate coding, in particular their jump-capturing moves. I suppose you could define thir moves in the I.D. as QK, RW and BF, and then replace the K, W or F moves by a routine for generating jump-captures in the described way.
But it might be simpler to clone the betza.txt file, and modify the move generator there with some dedicated code for this variant. And then use this modified version instead of the standard betza.txt in the preset. All that would have to be done is to insert some code at the point where it now is decided that an encountered piece can be hopped over by a test whether both pieces belong to the set {bat, eagle, raven, archer, spearman}, and abort the generation of that hopping move when they do.
Since this code would only be invoked when a hopper move hits a potential mount, it would not slow down the move generation very much, and I could even insert that in the standard include file. Then all what would have to be done is defining the pieces that cannot hop over each other in the Pre-Game code, like
set flying (...);
where the ... would be the list of labels of all the pieces (of either color) to which this applies.
I think the Terror would not be problematic for the automatic conversion
If I'm reading the rules correctly, the ID doesn't handle the capture restriction for the Terror.
I'll do it today!
💡📝H. G. Muller wrote on Sun, Apr 21 07:08 AM UTC in reply to Daniel Zacharias from Sat Apr 20 09:33 PM:I think it did, at least partly. But it is not obvious, because the I.D. does pseudo-legal highlighting, and the capture restriction on Terrors is a context-dependent rule that results in some pseudo-legal moves to be illegal. If I set up a position where the AI can gain a Queen by trading Terrors (TxT, QxT, BxQ), it does not capture.
The I.D. in the article had configured the rule the obsolete way, though, through a protected=32 parameter. This could not specify the 'asymmetric' version of the rule, which forbids Eagles to capture protected Terrors, but not Terrors to capture protected Eagles. I changed that now by using the captureMatrix for specifying the forbidden cases by marking those with a % sign.
The betza.txt include file currently also doesn't support asymmetric anti-trading; the I.D.'s anti-trading through the protected parameter is implemented there by initializing an array
set protected (...);
which lists the labels of all pieces mentioned in protected parameters. But it then bans all captures of the mentioned pieces by each other (when protected). So if both the Terror and Eagle go in there, T x protected E would also be forbidden. I suppose I could fix this by having the betza.txt include use two attays, 'protected' and 'restricted', and then ban only the captures of a piece mentioned in 'protected' by one mentioned in 'restricted'. When the PTA translates an I.D. that contains protected= parameters to GAME code, it could then define both arrays with the same pieces in them (where it now only defines 'protected' in the Pre-Game code).
More precise definition of what can capture what will have to wait for full implementation of the captureMatrix in the generated GAME code. But in most case (including Megalomachy) such a temporary fix would be sufficient.
[Edit] I now modified the betza.txt include file to support these changes. So in Pre-Game you would have to define an array 'opaque' with the flying pieces and those that can shoot them down, an array 'protected' with the Terror, and an array 'restricted' with Terror and Eagle.
I did not figured out what to copy and paste into the wizard. On my variants I start with this line:
script type="text/javascript" src="../membergraphics/MSinteractive-diagrams/betza.js?nocache=true"
as far as I remember.
But a similar line seems to end the Megalomachy diagram.
💡📝H. G. Muller wrote on Sun, Apr 21 04:22 PM UTC in reply to Aurelian Florea from 08:08 AM:You must only paste the name=value and piece lines, which normally are between HTML <div> and </div> tags. The script line is not part of the Diagram definition; it specifies to the browser what script to run to create an I.D. on the page. Something the GAME code would never have to do.
Thank for refreshing my memory, HG!
I don't think it works. I keep getting orthodox chess. Can it be that the description is too long. I have tried an Grand Apothecary game it it works fine. This is how I know I have followed the proper steps.
You must remove borders=0 because that messes it up somehow
💡📝H. G. Muller wrote on Mon, Apr 22 06:31 AM UTC in reply to Aurelian Florea from Sun Apr 21 06:57 PM:Strange that it doesn't work for you. When I copy-paste the I.D. definition into the PTA directly from the Page Source (from the line satellite=megalo to the line king::KispO9::k1) I do get a 16x16 board with the Megalomachy setup. It doesn't look very well, because even the specified squareSize of 33x33 is too large to fit it on the PTA page, and the I.D. in the Megalomachy article uses the 50x50 alfaerie pieces. Because it also uses betzaNew.js it automatically shrinks those images to fit the squares, but the PTA still uses betza.js, which doesn't do that, but clips the pieces instead. But that should not affect the generation of GAME code.
I get this error:
Cannot make a diagram with 0 pieces on an 8x8 board!
| satellite=megalo | |
| files=16 | |
| ranks=16 | |
| promoZone=1 | |
| maxPromote=2 | |
| promoChoice=EA,AM,G | |
| graphicsDir=/graphics.dir/alfaeriePNG/ | |
| graphicsDir=http://chessvariants.com/graphics.dir/alfaeriePNG/ | |
| squareSize=33 | |
| graphicsType=png | |
| theme=DD | |
| whitePrefix=w | |
| blackPrefix=b | |
| borders=0 | |
| firstRank=1 | |
| useMarkers=1 | |
| newClick=1 | |
| captureMatrix=/"27/27^^^^^=/"/27^^^^^%/32% | |
| pawn::fmWfceFifmnDifmnH::a5-p5 | |
| warrior::fmWfmnnDfceFbhcN:quickpawn:a2-d2,m2-p2 | |
| ram:RM:mgQcfD::c1,n1,e2,l2 | |
| scout::mNcA:knightpawn:g4,j4 | |
| vao::mBpcB::d1,m1 | |
| camel::::d3,m3 | |
| zebra::::e3,l3 | |
| war machine:D:yafpabmRWD:warmachinewazir:f4,k4 | |
| elephant::yafpabmBFA:elephantferz:d4,m4 | |
| frog::FH::a4,p4 | |
| guard:GD:yafpabmRK:duke:b3,o3 | |
| knight:N:yafafafpabmBN::b4,o4 | |
| bishop::::h4,i4 | |
| cannon:CN:::e1,l1 | |
| rook::::a3,p3 | |
| leo:LE:mQpcQ:paovao:c3,n3 | |
| nightrider:NR:::b1,o1 | |
| dragon horse:DH:BW:promotedbishop:c4,n4 | |
| dragon king:DK:RF:promotedrook:a1,p1 | |
| rhino:RH:[W?fsB]::g1 | |
| gryphon::[F?fsR]::f1 | |
| archbishop:::cardinal:e4 | |
| marshall:::chancellor:l4 | |
| queen::::j1 | |
| lion::KNAD::h2 | |
| amazon:AM:QN::i2 | |
| archer:AR:WA::f3,k3 | |
| spearman:SM:FD:nspearman:g3,j3 | |
| bat:BA:B(paf)14cB::h3,i3 | |
| raven:FA:R(paf)14cR:bird2:g2,j2 | |
| eagle:EA:Q(paf)14cQ:bird:h1,i1 | |
| terror::QNADcamK:dragon:f2,k2 | |
| king::KispO9::k1 |
💡📝H. G. Muller wrote on Mon, Apr 22 07:42 AM UTC in reply to Aurelian Florea from 07:10 AM:I get this error:
Cannot make a diagram with 0 pieces on an 8x8 board!
It probably means that you copy a lot of invisible stuff together with the Diagram definition; the line below the quoted error message makes an attempt to show you what you actually pasted. If I copy-paste directly from your latest comment into the PTA, I also get the error message, and for the pasted text it says:
<main><article id="maincontent"><div class="commentgroup"><div class="Comment"><div><table><tbody><tr><td class="line-content">satellite=megalo</td>...
So there is an enormous amount of HTML garbage prefixed and interleaved with the actual definition, and the PTA chokes on it. What exactly corrupts the Diagram definition might depend on your browser. I made the PTA resistant to the garbage that is added by copying from a FireFox Page Source (but you might have to flush the browser cache to benefit from that?)
Anyway, the safest method is to first paste the Diagram definition into NotePad;this will cleanse it of most invisible stuff. Then you can copy-paste it from there into the PTA.
Now I get this:
Please report any bugs or errors to H.G. Muller
I probably mismatched something.
But neither &showcode=true (I got this from the developer guide) or &edit=true work
💡📝H. G. Muller wrote on Mon, Apr 22 03:12 PM UTC in reply to Aurelian Florea from 11:30 AM:The correct query for opening the preset in Edit mode is &submit=Edit, not &edit=true.
The problem appears to be the fast castling, and now that I think about it, I believe I never implemented fast castling in the betza.txt GAME-code include file. So the entries in the legdefs table that would be interpreted by the JavaScript powering the Interactive Diagram as fast castling are mistaken for something that makes the GAME code crash.
For now I recommend commenting out the four lines that define the fast castling at the end of legdefs, like:
1 1 -1 1 3 //2 99 1 0 88 // 1 9 0 25 //2 99 -1 0 88 // 1 -9 0 25 0);
The King will then not be able to castle, but at least you can continue implementing the other aspects of the variant in the preset. In the mean time I will try to support fast castling in betza.txt. And when I have done that, you can uncomment the lines again.
💡📝H. G. Muller wrote on Tue, Apr 23 08:43 AM UTC in reply to Aurelian Florea from Mon Apr 22 12:07 PM:I have made an attempt to support fast castling in the betza.txt GAME-code include file. I could not test it in the context of your preset, though, because there seems to be a mismatch between the labels used in the I.D. that youconverted, and the piece set you use in the preset. So it still crashes because of an unknown piece 'E'. I suppose you would have to use the custom set as the PTA suggests it to make it work.
Anyway, to try the fast castling you should replace the lines
2 99 1 0 88 1 9 0 25 2 99 -1 0 88 1 -9 0 25
at the end of the legdefs array by
1 -3 1 0 FastCastle 1 -3 -1 0 FastCastle
This uses the existing mechanism for invoking dedicated routines for generating piece moves. But the routine FastCastle, which is invoked by this, is already supplied in the betza.txt include file.
I still have to adapt the PTA to generate these lines automatically, when encountering a fast castling.
Oh, that seems a lot of work. But I'll do it in the evening!
💡📝H. G. Muller wrote on Tue, Apr 23 09:58 AM UTC in reply to Aurelian Florea from 09:44 AM:Oh, that seems a lot of work. But I'll do it in the evening!
Not really. You should just select the Completely Custom set, and then paste the set definition the PTA suggests into the preset.
25 comments displayed
Permalink to the exact comments currently displayed.
It could be a fun game. Maybe I'll try it these days!