Perl / Scripting / *nix / Database / Sysadmin work

Discussion of all aspects of the game engine, including development of new and existing features.

Moderators: Forum Moderators, Developers

Post Reply
Skizac
Posts: 24
Joined: October 23rd, 2005, 10:24 pm
Location: Maryland

Perl / Scripting / *nix / Database / Sysadmin work

Post by Skizac »

As I stated elsewhere, I'm very interested in coding for the game itself, but my true skills currently lie with Perl, shell scripting, *nix, databases, and all kinds of sysadmin work.

So, if anybody has work for Wesnoth that falls in those areas, send it over to me.

Darth Fool
Retired Developer
Posts: 2633
Joined: March 22nd, 2004, 11:22 pm
Location: An Earl's Roadstead

Post by Darth Fool »

Well, one thing that I would love to see is a perl script that parses, optionally recursively, all the cfg files in a directory and constructs a map of how WML is used. By this I mean mapping out what the various [tags] are, what values things can be set to, etc. The purpose of this would be eventually to make an automated check of what new WML values have been added and make it easier to document what all the WML does. Just a thought. It would be a great way to learn the WML syntax as well.

Skizac
Posts: 24
Joined: October 23rd, 2005, 10:24 pm
Location: Maryland

Post by Skizac »

Darth Fool wrote:Well, one thing that I would love to see is a perl script that parses, optionally recursively, all the cfg files in a directory and constructs a map of how WML is used. By this I mean mapping out what the various [tags] are, what values things can be set to, etc. The purpose of this would be eventually to make an automated check of what new WML values have been added and make it easier to document what all the WML does. Just a thought. It would be a great way to learn the WML syntax as well.
Ok, this sounds like it could be a relatively straight-forward project. However, I'm not exactly sure what you're asking for. What would be the nature of the "map"? What would the output of the program be? Is my understanding correct that this would be a two-phase project?

1) Build a map of WML code from cfg files.
2) Make a (syntax?, semantics?) check of the WML values in the mapping.

User avatar
ivanovic
Lord of Translations
Posts: 1147
Joined: September 28th, 2004, 10:10 pm
Location: Germany

Post by ivanovic »

I think the idea behind this is making a reference of all possible WML. This would include the semantics inside the tags.
1) Get all possible commands.
2) Find out the correct/allowed semantics for the commands found before.

Something like this would be a great help to get a nice reference since only very little editing afterwards would be needed. At least if we actually are using the tags and semantics in the "mainfiles".

Skizac
Posts: 24
Joined: October 23rd, 2005, 10:24 pm
Location: Maryland

Post by Skizac »

ivanovic wrote:I think the idea behind this is making a reference of all possible WML. This would include the semantics inside the tags.
1) Get all possible commands.
2) Find out the correct/allowed semantics for the commands found before.

Something like this would be a great help to get a nice reference since only very little editing afterwards would be needed. At least if we actually are using the tags and semantics in the "mainfiles".
Ah, I get it now. Sort of automaticly-generated documentation. It's on my todo list. :)

Boucman
Inactive Developer
Posts: 2119
Joined: March 31st, 2004, 1:04 pm

Post by Boucman »

if you go in the utils/ directory, you will find an already existing WML parser... that would be a good starting point...
Fight key loggers: write some perl using vim

User avatar
Viliam
Translator
Posts: 1341
Joined: January 30th, 2004, 11:07 am
Location: Bratislava, Slovakia
Contact:

Post by Viliam »

Another idea...

The first tool could check which WML tags can include which WML tags and attributes, and could generate a description file (something like DTD files that describe what can appear in XML files). That description file could also be a WML file 8) and could be like this:

Code: Select all

[tag]
  name="unit"
  [attribute]
    name="id"
    type=string
  [/attribute]
  [attribute]
    name="name"
    type=string
    localized=yes
  [/attribute]
  [subtag]
    name="attack"
  [/subtag]
[/tag]
This means that tag "[unit]" can contain tags "[attack]" and attributes "id" and "name". Attribute "name" can be localized.

Now, another tool would check user-made files (user campaigns, etc), first check whether they are correct WML files, then validate them against the description file. The error report from such tool could be much better than the feedback provided by Wesnoth program; and also faster.

ott
Inactive Developer
Posts: 838
Joined: September 28th, 2004, 10:20 am

Post by ott »

The tagfind script (in utils/) has been in the repository since July 2005. It's not comprehensive, but it's a start, and was very useful in generating the WML index at the wiki.
This quote is not attributable to Antoine de Saint-Exupéry.

Skizac
Posts: 24
Joined: October 23rd, 2005, 10:24 pm
Location: Maryland

Post by Skizac »

Viliam wrote:Another idea...

The first tool could check which WML tags can include which WML tags and attributes, and could generate a description file (something like DTD files that describe what can appear in XML files). That description file could also be a WML file 8) and could be like this:

Code: Select all

[tag]
  name="unit"
  [attribute]
    name="id"
    type=string
  [/attribute]
  [attribute]
    name="name"
    type=string
    localized=yes
  [/attribute]
  [subtag]
    name="attack"
  [/subtag]
[/tag]
This means that tag "[unit]" can contain tags "[attack]" and attributes "id" and "name". Attribute "name" can be localized.
What would "localized" mean in this context?

torangan
Retired Developer
Posts: 1365
Joined: March 27th, 2004, 12:25 am
Location: Germany

Post by torangan »

Translated.
WesCamp-i18n - Translations for User Campaigns:
http://www.wesnoth.org/wiki/WesCamp

Translators for all languages required: contact me. No geek skills required!

scott
Posts: 5242
Joined: May 12th, 2004, 12:35 am
Location: Alexandria, VA

Post by scott »

Localized means the key has the format:
keyname / equals / underscore / quoted text
name= _ "Joe"

This format marks the quoted text as translatable by "gettext", a program that manages translations. Gettext will then collect the string and add it to the list of strings it shows translators for them to translate. Later on, gettext localizes the string by substituting the translated text into every instance of the quoted text, thus showing the information in the player's local language.

(Didn't know how long of an answer you needed)
Hope springs eternal.
Wesnoth acronym guide.

User avatar
Viliam
Translator
Posts: 1341
Joined: January 30th, 2004, 11:07 am
Location: Bratislava, Slovakia
Contact:

Post by Viliam »

scott wrote:Localized means the key has the format:
keyname / equals / underscore / quoted text
name= _ "Joe"
It is a bit more difficult, because the value can be an expression, where only a part of expression is translatable. For example:

description= _ "Max HP bonus +" {HP_ADVANCE}
(from "amla.cfg")

text="<img>src=misc/logo.png align=middle box=no</img>" + _"
Battle for Wesnoth is a turn-based fantasy strategy game..."

(from "help.cfg")

If a part of expression is localized, mark the whole attribute as localizable.

Print error when user localizes a non-localizable attribute. Print warning when user does not localize a localizable attribute (there should be a switch to turn off these warnings).

Skizac
Posts: 24
Joined: October 23rd, 2005, 10:24 pm
Location: Maryland

Post by Skizac »

Ok, I've got a somewhat working version coded up. However, the utils/wml.pm module doesn't handle preprocessor directives very well, and chokes on several wml files. Is there a way to run all of the wml files through the preprocessor so that I only have to deal with preprocessed wml?

Post Reply