| Author | Message | ||
| Ingrid Lael (Ingridlael)
|
Hi there! Whilst in the last stage of an ongoing proyect (thought it would take somehow less time, but it's taking three months now :S) I got stuck with a depressing/dissapointing bug/misunderstanding. The thing goes like this: I'd like a piece to change to another and keep on moving. The coding I came up with was: ...do some other stuff ...(add-partial another-type-of-piece) Pretty simple, right?, well, not so, since Zillions changes the piece, but does not allow it to keep on moving. I recall reading something about it being touchy with which piece was the one which got to "keep moving" during an add-partial. Anyway, there are thousands of ways I could code the same type of thing, and I'm already doing so, but I'd like to know what is the cause of the weird/unexpected behaviour. Thanks in advance for any ideas. Cheers... ...Ingrid. | ||
| Mats W (Kålroten)
|
You must add the movetype also, e.g: (add-partial pieceX continued_jumptype) This means that the moving piece is transformed to pieceX. In the move-definition of pieceX there must be a move-type "continued_jumptype" (e.g.) which defines the movement. Then the move is continued. | ||
| Ingrid Lael (Ingridlael)
|
Hi there! Hmmm, I tried that already, to no avail... I'm familiar with the sintax (add-partial piece...piece move-type); but zillions seems to ignore partial moves when the pieces which its supposed to keep on generating moves for get changed. Any further insight anyone? (I most certainly cannot come up with anything else) Cheers... ...Ingrid | ||
| Mats W (Kålroten)
|
I used that construct in Bario.zrf and it worked. But then it was in the form (add-partial pieceX pieceY continued_movetype) The difference is that one has a choice of piece-type before continuing the move. I don't understand why this should, and only one piece-type should not work. It could be a bug. You could check how they solve this in those checkers games where one can promote to king and continue jumping immediately. | ||
| Ingrid Lael (Ingridlael)
|
Hi there! thanks for the replies btw. Yup, I was about to check that up (sometime in this weekend, my studies suddenly got demanding  ). I though the same, it SHOULD work, nevertheless it doesn't (at least in my particular case), and it's not like i'm doing any esotheric stuff, just wanna change a piece and have it move again. Anyway, thanks again for the reply, and I'll post any future findings. Cheers... ...Ingrid. | ||
| L. Lynn Smith (Interrupt27)
|
Be sure that the necessary continuing move-type is located in the target piece's declaration. So that when piece A becomes piece B, there is the appropriate move-type located in the piece B declaration to allow for the continuing move. | ||
| Ingrid Lael (Ingridlael)
|
Hi again! Yup, move declarations are OK; as a matter of fact i dont use the (add-partial piece move-type) construct, but the (add-partial piece) one instead. Could this be due to an "off n" being needed or not in the board-setup? (I'm admittedly guessing here, I'm not in front of my own pc at this time). Could this be worked around by changing: (add-partial piece) to: (change-type piece) add-partial or would this be even worst? (again, guessing) Thanks a lot for the replies. Cheers... ...Ingrid | ||
| Mats W (Kålroten)
|
Maybe I don't understand you correctly, but you can't use the (add-partial piece) construct because this finalizes the move. If you want to continue the move, you must use (add-partial piece-type move-type), (although you say you have tested this) Mats | ||
| Mats W (Kålroten)
|
I tested the construct (add-partial piece-type move-type) and it works, the move is continued. You must have made a programming error. Read again L.L. Smith's message above. | ||
| Ingrid Lael (Ingridlael)
|
Hmmm, i see... I'll better clarify: I read the chm language reference an it DOES say you can write something of the form (add-partial piece), I'm surprised it does not work (at least not as expected, although it's pretty clear how it's expected to), and thought maybe someone could clarify. I just tested the (add-partial piece-type move-type) after I typed the above paragraph and it did not work (again); i double-checked the move definitions and made sure that the move-type was defined in the "target" piece. The piece gets changed to the piece-type specified, but it gets no move after that. A piece of the desired piece-type moves fine. It looks like they don't do well toghether... Well, thanks a lot again for the replies, i just can't seem to make it work. Any further ideas will be greatly appreciated. Cheers... ...Ingrid. | ||
| L. Lynn Smith (Interrupt27)
|
You might post the declaration for each of the pieces, and their move macros. We could get a better idea what is going on. | ||
| Ingrid Lael (Ingridlael)
|
Hi again, and thanks again for replying to my posts  OK, this is going to be long... I'm implementing "The Game of Nemoroth" by Ralph Betza (http://www.chessvariants.com/other.dir/nemoroth.html). It's a pretty complicated game to implement, but I managed to get it almost going, in fact i have a playable version as of now (there's one simgle rule left to implement). That single rule is the Go Away shouting order. In short: there's a piece called "Go Away" which can, instead of moving, push every piece directly adyacent to it a single square directly away. This is as far as I got. The thing is that, under certain circumnstances, the owner of the Go Away may choose the order in wich the pieces are pushed, resulting in different outcomes. As the zrf stands now the "pushing" is done by a random player at the end of each turn, and the player needs only drop a "pushing Go Away" where he's own one stood (the random player replaces it by a normal Go Away when he's done). The pushing order of the Go Away is only important when a certain piece (a Basilisk or a Petrified Basilisk) stands next to the Go Away. Even when one such piece does, other adyacent pieces next to the Go Away need to be present and not in a "petrified" state. Even though the number of combinations may seen daunting they're not, and I got the conditions under which a shout may be "order sensitive" by simple enumeration (an afternoon's work). When I sat down and tried to implemented I was dissapointed to stumble on the error/bug/misinterpretation that names this thread. I had the following in mind: when a "shouting Go Away" gets dropped onto the board it always gets a further move (with add-partial in the drop). Now a "shouting Go Away" can only move if any of the conditions for an "order sensitive" shout are met. His move only consists of dropping a "to be petrified <piece>" on "some" of the adyacent accupied squares and give it a further move (i thought this could be done with an add-partial piece). All of the "to be petrified <piece>"s move practically as the "shouting Go Away". This effectively petrifies (after some random player help) some of the pieces adyacent to the Go Away and performs the push (again, with the help of a random player). The (add-partial piece) part is the one which is giving me a headache. I can't get it right. Now, English is not my mother language and I'm not particularly good at explaining myself, I hope this helps state what the problem is. Anyway, pleaso do ask back if there's something i left out (you can always consult the chessvariants link above for ultimate clarification on the rules). Thanks a lot in advance for any thoughts you care to share. Cheers... ...Ingrid. | ||
| Ingrid Lael (Ingridlael)
|
Errata: where it says: "(i thought this could be done with add-partial piece)" it should read: "(i thought this could be done with add-copy-partial piece)" What actually works is the transformation of the Go Away into a "shouting Go Away" (with add-partial in the drop) but the new piece does not get a further move. Cheers... ...Ingrid. | ||
| Mats W (Kålroten)
|
Perhaps you have made the correct definition of the piece. But maybe you have an additional definition of that same piece in the same file, although you don't recognize this, and this definition is faulty. Zillions won't complain when you have two definitions of the same piece. Just a thought. | ||
| Ingrid Lael (Ingridlael)
|
Hmmm, I just double checked the zrf and every include, no double defs. Maybe I'm missing something here, maybe i misunderstood the help file (very likely). I'll check everything up again from 0. Anyway, I can't thank enough for your replies, keep them coming (they're deeply appreciated)! Cheers... ...Ingrid. | ||
| L. Lynn Smith (Interrupt27)
|
Good luck on the Nemoroth implementation. I spent a couple of years trying to code this one, and eventually decided that I had other things that needed attention. If I had known that that was your project, I would have merely offered my sympathies. ;-) | ||
| Ingrid Lael (Ingridlael)
|
LOL, thank you so much. As a matter of fact this is the last issue remaining. The University is taking me too much of my precious spare time, so it's advancing slowly, but steadily. Anyway, I'll post any findings on this matter. Cheers... ...Ingrid. |