| Author |
Message |
Patrick S. Duff (Pduff)
| | Posted on Thursday, August 10, 2000 - 3:44 am: | |
Here's a topic for posting any tricks you've come up with for debugging Zillions rules files. |
Patrick S. Duff (Pduff)
| | Posted on Thursday, August 10, 2000 - 3:54 am: | |
If you've got a load-time problem with unbalanced quote marks or parenthesis and aren't sure where the problem is, or you're getting an error message and aren't sure what part of the rules file is causing the problem, here's one way to narrow it down.
Go to about the 50% mark in your rules file and type in a nonsense word such as 'asdf'. Then load the rules file again. If you see something like "parse error at 'asfd'", then the rules file was parsed successfully at least that far, and the problem is somewhere after the 'asdf'. Otherwise, the problem is before the 'asdf'. Move the 'asdf' up or down in the rules file and try loading it again. |
Patrick S. Duff (Pduff)
| | Posted on Thursday, August 10, 2000 - 4:03 am: | |
If you're having trouble when calling 'abc' or '(abc)' after doing a '(define abc ...)', try adding an extra set of parentheses around the '...' part of the define, or if you already have parentheses around the '...' part, try removing them.
It helps if you can imagine what the complete code will look like when the call to the define is replaced with the define's code.
Also, remember to check the case used in the name of the define. The calls to the define should use the same case as the define itself; also don't confuse 0 and 0, 1 and l, or - and _. |
Patrick S. Duff (Pduff)
| | Posted on Sunday, October 15, 2000 - 7:10 pm: | |
If you define a position which falls outside the board's image graphic, you can still see piece graphics at that position if you drag the window edge out to reveal the position.
This is an alternative to using dummy positions. Players of the game will not see the pieces on the outlying positions, since Zillons sizes the window dimensions based upon the size of the board's image graphic. (You, the game designer, won't see them either, unless you drag the edges of the window out far enough.)
The one possible drawback of doing this is that dummy positions don't show up in the moves list, but outlying positions do.
There could be a command added to the rules language which would change the position's name in the moves list, or surpress the display of the position in the moves list, similar to the "(notation "...")" command which controls the display of piece names in the move's list. |
Alfred Pfeiffer (Apf)
| | Posted on Tuesday, October 17, 2000 - 3:10 am: | |
> There could be a command added to the rules language which would change the position's name in the moves list, or surpress the display of the position in the moves list,
The 'translate' command can do this.
(To surpress replace the name by a blank char.) |
Patrick S. Duff (Pduff)
| | Posted on Tuesday, October 17, 2000 - 6:10 am: | |
I hadn't thought of using "translate" that way!
Right now "translate" only supports one translation for each word. It should be extended to have several named translations, such as "french", "german", "spanish", then the menu interface should show you a list of available translations and let you pick one.
There should be a set of default translations built into Zillions, such as translating "White" into half a dozen or so languages. The "translate" command in the rules file could then be used to supplement the standard translations with any words not covered in the default table.
This way every game would benefit from translation capability, without every zrf writer having to research and enter translations. |
David GLAUDE (Glu)
| | Posted on Friday, October 20, 2000 - 4:47 pm: | |
Another approach for internationalisation [May I suggest].
A ZRF file would be quiet complex if it contain a list of four or five translations inside.
Also it is difficult to maintain as translator might not be aware of ZRF format or don't want to go there.
If we need to merge translation from three different person it become a nightmare.
And if you modify the rules you will have to reapply those change to other languages.
!!!I have similar concearn with Zillions-of-Skins version of games!!!
Now the typical solution to this problem is to externalise the string from the source file.
Let's take "mygame.zrf".
Pre-process the file to extract all the strings "mygame.txt".
Give this to various translator for various language that give you the same text file with a translated string associate to each english string ("mygame_french.txt").
Then process again "mygame.zrf" + "mygame_french.txt" to give "mygame_french.zrf".
Now the nice thing about this technique is that it does not require any change within the ZRF file (except automatic one). If you change the logic of the rule (without changing the string) then the translation is still right.
The best thing would be for Zillions developpement to start build the translation process into Zillions and to provide the pre-processor. That way they can standardise the way to do it and offer native multilanguage support (don't forget to permit translation of build-in string like menu, error message, ...).
Please have a look at MAME and Linux internationalisation effort, you will find libraries, tools, ideas. If you start right it is not too difficult to offer multi-language. I am Belgian and in my country we have the problem for every program we write. ;-)
But if ever this is not TOP priority for Zillions developpement, but it start to be TOP priority for the user community, then we don't need Zillions developpement to start the process. I could write the two pre-processors and start working on French (my spelling is not very good) to show how to do it.
David GLAUDE
PS: It is not my top priority. |
Patrick S. Duff (Pduff)
| | Posted on Saturday, November 04, 2000 - 1:17 pm: | |
More debugging tips for finding "parse errors":
I've seen "parse errors" which I finally traced to using "(cascade)" instead of "cascade" or "(if not friend? ...)" instead of "(if (not friend?) ...)".
Be sure to use single-back-quotes instead of double-quotes inside strings.
Try commenting out most of the code in your largest define, leaving behind at least one reference to each of the define's $1 $2 $3 ... arguments. If the rules file still fails to parse, do the same with the next largest define. If all of the defines are stubbed and the problem still persists, start commenting out entire variants. Eventually you should find the section of code which is causing the parse-error. |
|