Comments/Ratings for a Single Item

That's precisely the link I was asking for. If H.G. would just (please!) put it into the article, I'd find this much, much easier.

But it has nothing to do with the Wizard for GAME Code Generation. Why not just look on the Game Courier page, where there is a link to it?

But it has nothing to do with the Wizard for GAME Code Generation.

Doesn't it? Is it actually less important of a step than using the Play-Test Applet, which does have a link?

Why not just look on the Game Courier page, where there is a link to it?

Why not have a link here, where creating GC presets is already under discussion, than just assume that anyone would know where to look?

Is it actually less important of a step than using the Play-Test Applet, which does have a link?

I never use this Wizard to generate presets, but I presume that using the Play-Test Applet is actually a step in using the Wizard, whereas starting with the default preset is no more of a step in this than having a blank canvas is a step in generating AI art.

Why not have a link here, where creating GC presets is already under discussion, than just assume that anyone would know where to look?

This page is about using a Wizard to generate a preset for you. It is not about making your own from scratch. For that, I would refer you to the Game Courier documentation and various tutorials.

The Wizard generates GAME code. It does not create a preset.

For generating the preset additional information would be required. Such as the name of the game. I suppose I could add a field where you could enter that, and a button for creating a preset of that name.

For generating the preset additional information would be required. Such as the name of the game. I suppose I could add a field where you could enter that, and a button for creating a preset of that name.

That could be done, or just take the text "Invoke the preset" and add "(click here to start)" or some such. The simipler the better.

This is just a testimony. I'm not a champion in coding and sometimes I don't understand 100% of what I'm doing, but the Wizard is really very good to generate a game code for GC. I have done it for Bigorra, for Camel Decimal Chess and yesterday for Patchanka. The only difficulty I had is when I have several different promotions to manage. I had to use the "morph" instructions and this is not given automatically by the Wizard. I solved my difficulty by copying from the Bigorra's GC where that issue had been solved for me by someone else.

What I found strange in the full process of submitting a new game with "all features inside" is to write 1) a regular page for presenting the game (in which I now put the ID in the Setup section) like this one; 2) a page "play" for presenting the GC preset where some information is duplicated, and the diagram is often shown with wrong pieces as it uses default pieces, like this one; 3) the preset itself where the Wizard is helpful indeed, like this one.

Maybe the process could be simplifed a bit, for instance I'm not sure that the page 2) is really useful.

I do not discard also that I'm doing something not optimal. I have often the feeling that Fergus, HG you are doing your best to help us (and you do it very nicely and kindly) but you do not always realize how much things looking simple for you can be difficult for common people with no specific education in coding.

2) a page "play" for presenting the GC preset where some information is duplicated, and the diagram is often shown with wrong pieces as it uses default pieces, like this one;

I never tried to publish a GC preset, but it seems to me that the diagram that is shown on that page is entirely the responsibility of the user. So if it doesn't show the same pieces as what the actual preset uses, it is because you ordered it to show different pieces.

You could even use an Interactive Diagram on that page, instead of a static one from the Diagram Designer. I recall that I made such a substitution on several GC pages, for variants that only appeared to exist on this site as GC presets, without a real article describing the rules. (Matts Winther's variants are typically presented like this; the GC page links to his own website for the rule descriptions.)

I agree that in most cases this page is entirely redundant, and just an annoyance to the user. There might be a reason for it if the same variant has multiple presets with different piece representation, to give the user a possibility to pick the representation he prefers.

Thanks HG. After all, there is no real need of a diagram at all in (what I call) page 2. So I have modified the cases which were showing a diagram with a wrong piece set. I have removed those faulty diagrams.

Should I be able to use $dest to get the destination square before HandleMove runs?

Should I be able to use $dest to get the destination square before HandleMove runs?

I suppose not, because to work with betza.txt the preset has the "do not add moves" checkbox ticked, so that Game Courier does not handle the move itself before it invokes to the Post-Move code. And I suppose $dest would be set during GC's handling of that move.

I am not even sure this variable would be set after HandleMove returns. At some point HandleMove passes the move to GC with the aid of an "eval MOVE: xxx" statement, but I am not sure whether this is equivalent to latting the move be handled automatically.

But HandleMove has its own variables to describe the move: #ori, #desti, #moved and #victim, which will be set after HandleMove returns. And for side effects: #promo, #suicide, #freedrop and #dropped. When not applicable the first three will have value 0, and #dropped will be undefined if #freedrop is invalid.

Anyway, HandleMove true starts with calling ParseMove true. This extracts the values for all these parameters in so far these were explicitly specified by the move notation. Implide side effects are then derived by generating all moves of the indicated piece, and match those with the move parameters that were given in the input notation. If there is a match it then takes the additional parameters from the generated move (such as #suicide when the move was an e.p. capture).

So in a code section where HandleMove is not useful (e.g. because you are in the prelude), and you don't feel like parsing the 'move' that the player entered yourself, you could call ParseMove if the syntax of what the player was supposed to enter is compatible with that of normal moves.

This game is showing a problem with castling. The king disappears. The same problem happens in other presets I made using the same castling. I'm sure it was working before

Since that game I mentioned appears to be missing, the problem is that in games where the king castles onto the rook's location, the king disappears when castling.

Umm, indeed. It seems I spoiled this when adding fast castling. There one always also has a 1-step castling possibility, and to avoid the ambiguity this causes it has to be entered as capture of the Rook you want to castle with. Normal 1-step castling also would require such a kludge, but so far was never implemented (because it occurs only rarely). So for normal castling moving the King on top of your own Rook would be interpreted as castling to the Rook square. The code I added to take care of the fast-castling case relied on the setting of a 'realto' variable, which would hold the true King destination if the input move put that at the Rook. As last thing during move execution the King would then be moved there. But in case of normal castling this 'realto' currently remains undefined, and moving the King there would make it disappear.

For now I let normal castling always set 'realto' to the King location indicated by the input move. This should fix the problem in Skica.

This means there is still no support for O1 castling. But when it would be needed I suppose it can now be easily implemented by replacing the destination of the generated move by the Rook location in the generated move when the King makes only a single step. (Which the fast-castling generator already does.) But that would still leave an issue in variants where the King can both make a single step or end at the Rook square. One then would have to design a move-entry kludge for distinguishing those moves. I suppose entering 1-step castling as RxK would not be very crazy, as in this case the Rook would indeed end on the King square (and it cannot be confused with any legal Rook move).