| Author | Message | ||
| Ole Meinert (Buttercup)
|
The below code is producing perfect moves, but the macro "Mainmoves" is only executed correctly if called by "leap1" or "leap2". If called by "slide1" or "slide2" the end-"add" is executed (move is generated) but not the macro-call "Mainmove". I tested it with just a command (without a condition (if)), but it wasn't executed either. I narrowed the problem down to the while-loop. If this is absent it works... but I can't find a workaround. Once I thought I had it, "Mainmove" was executed but the slide-move was wrong, it ended one step before the enemy. Sadly, I forgot, how I did it, but I think the while was there then. Am I missing anything important here? Please help me - Workarounds are welcome  Ole (define leap1 ($1 (verify not-friend?) (Mainmove))) (define leap2 ($1 $2 (verify not-friend?) (Mainmove))) (define slide1 ($1 (while empty? add $1)(verify not-friend?)(Mainmove))) (define slide2 ($1 (while empty? add $2)(verify not-friend?)(Mainmove))) (define Mainmove (if (in-zone? Hauptfeld)(add-partial Hauptzug) else add)) | ||
| Sean Duggan (Dream)
|
Does a slide only create a Hauptzug within the Hauptfeld on the last move? That's how you've got it set up right now. The while loop employs the regular add rather than your MainMove macro. I guess I just need clarification as to what's the problem. Could you give me a scenario using the leap and using the slide, and tell me what's supposed to happen, and what is happening? | ||
| Sean Duggan (Dream)
|
Right. And I seem to have misstated things. With the add-partial as you have it, I'm not sure one could indeedkeep dropping the pieces, at least without some fancy code. ^_^ Of course, I could be barking up entirely wrong trees. I must hear what it is you intend to do here. | ||
| Ole Meinert (Buttercup)
|
Hi, thanks for your help. It seems it doesn't matter what the outcome should be: As I said I tested it with just a command not a condition that needs to be met, like: (define Mainmove (create f3) else add) And even then, this "creation" will happen only when "Mainmove" is called by a leap... As for your question: Indeed "Mainmove" should only happen when a piece lands on "Hauptfeld" where the player may choose one of his opponents pieces to be taken off the board. But again this works fine (as the "create"-variant does) when called by a leap but not after a slide. What could that be? (And, if anyone is interested: After occupying the Hauptfeld I needed to scan the board step by step for enemy-pieces, because I couldn't use "grid" for the board. After that you can click on the piece you want to take. It is being captured by the piece on "Hauptfeld" which then changes it's image to a fully green invisible one, and a new piece - but the same quality - is created on "Hauptfeld". Thus it looks a bit nicer but it really took a days work | ||
| Ole Meinert (Buttercup)
|
Of course that is: (define Mainmove (create f3) add) without the "else" | ||
| Sean Duggan (Dream)
|
{furrows brow} Perhaps it comes as a result of the actual Hauptzug move. I tried inputting your program using the framework of chess, using the middle two rows as the Hauptfeld, and placing a pawn rather than the Hauptzug. In all 4 cases, if the piece ended its turn within the Hauptfeld, it was replaced by a Pawn, which then got to take its partial move. *blink* Ok, just reread your setup and realized I forgot to test a particular setup. On the slide, do you want the possibility of generating a Hauptzug if it stops one shy of a friendly piece? In which case, you will need to use "(Mainmove)" in replacement to the "add" within the while loop. Please, if you can give me an example scenario of how things work and how they don't with a description of where pieces are before and after, it would make life simpler. | ||
| Ole Meinert (Buttercup)
|
You are my hero! That just simply solves it (replacing "add" with "Mainmove") - I can't believe it. Next time, I'll ask you first, before trying for hours myself. And now I even understand why it couldn't work before This is my first project and I think I wasn't enough into the mechanics of "add" before you enlighted me. I know I'm bound to run into another problem these days when trying to implement a move, where a piece can go as far as it wants as long as it is in contact (no empty- or enemy-field in between) to another team-piece. May I ask you again when I'm stuck? Again, thank you very much. Ole |