Difference between revisions of "User:SkeletonCrew"

From The Battle for Wesnoth Wiki
(Terrain system)
(gui toolkit: add a new link)
 
(76 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 
= WIP =
 
= WIP =
== Terrain system ==
 
The goal is to convert the old single letter terrain system
 
to a new multi letter system. The internal changes to the
 
engine are almost done.
 
  
These are the proposals and explanations for the new system,
+
=== gui toolkit ===
once these are final and implanted these texts will move
 
into the wiki.
 
  
NOTE: busy with writing version 2 but not finished yet :-(
+
[[GUIToolkit]]
 +
[[GUIToolkitWML]]
 +
[[GUICanvasWML]]
 +
[[GUIVariable]]
 +
[[Wiki_grabber]]
  
Version: proposal 2.0-pre <br>
+
== Addon server ==
Last updated: --[[User:SkeletonCrew|SkeletonCrew]] 19:52, 4 November 2006 (CET)
 
  
History:<br>
+
After collecting the info in this thread
proposal 1.1<br>
+
http://www.wesnoth.org/forum/viewtopic.php?t=15664
* added the encounter terrains
+
this is a first proposal to all changes for the addon server. Personally I'm
proposal 1.2<br>
+
most interested to do the server side changes and not the client side changes
* added the link to the new proposals of Mog and Eleazar
+
so I hope to find a victim for that part ;)
proposal 1.3<br>
 
* added reminder to add fog/shroud to the editor
 
* added idea to maybe add support to add tiles at the top and left
 
proposal 2.0<br>
 
* removed editor changes from proposal and moved to own topic
 
* removed the discussion points and wrote the conclusion
 
* rewrote [[User:SkeletonCrew#terrain_strings]]
 
* rewrote the letter proposal, with the input given so far
 
  
=== terrain ===
+
The changes are splitted in 3 parts, the general changes, the changes specific
Every terrain type gets a new field named ''string'' this
+
to improve the handling of translations and last the automatic test for some
will be the new string to use to refer to the terrain.
+
broken content.
The old char field will stay for the existing terrains,  
 
this is needed to convert older maps to be used with the
 
new engine.
 
  
This string will exist of 2 to 4 characters, the allowed
+
=== General changes ===
characters are all letters (the engine is case sensitive),
 
all numbers and the symbols / | \. Note leading numbers
 
are not allowed in the string, they might give confusion
 
with starting locations. Other characters are reserved for
 
special uses in the engine.
 
  
The limit of 4 characters is not the upper limit of the
+
==== Client side changes ====
engine, but the upper level for easy parsing. The internal
 
format uses 4 bytes and every character is 1 byte. This way
 
it's very easy to convert the characters to the internal
 
format. If more letters are required it will require some
 
modifications to the engine.
 
  
I'm considering to allow 1 character terrains as well
+
For the client side some extra fields will be available to show, some are set
since I've some trouble to find a second letter everywhere.
+
by the author and some by the admin/devs. Also note I think it might be a good
 +
idea to give some non-devs dev access to the server, that would be people the
 +
devs think should have that access. I don't want to do the voting system at the
 +
moment since that will be quite some work (due to possible abuses) and adds
 +
little benefit. (The main reason for starting this project is to allow
 +
asynchronous updates of the translations.)
  
Every terrain will also get a new field named ''theme''
+
<pre>
this is explained in the editor section.
+
icon        like current icon
 +
name        like current name
 +
title      like current title
 +
description like current description (but hopefully shown in the client)
 +
image      larger image to show (as shown in the addon menu when you select
 +
            an addon)
 +
type*      type of the content see below (the client might want to split this
 +
            displayed info per type)
 +
author      name of the author
 +
version    version number of the addon (as set by the author)
 +
date        timestamp of last upload, this way 2 updates on one day can be seen
 +
            as different. (ideally the client should notice a newer version by
 +
            this value and give a visible clue)
 +
size        download size of the addon excluding languages. Languages show
 +
            this value separately.
 +
length      number of scenarios, mainly for campaigns
 +
difficulty  difficulties available as comma separated list
 +
version_a  string with versions it should work with eg (a better tag name is to
 +
            found)
 +
            - 1.2.* all 1.2 versions
 +
            - 1.2.3+ versions equal or newer as 1.2.3
 +
            - 1.2.0 - 1.2.2 versions from (including) 1.2.0 to (including) 1.2.2
 +
version_b  string with the version used for the upload to be able to block
 +
            specific versions that are known not to work on client side or to at
 +
            least be able to show a warning to the user
 +
dependency  other content this addon depends on, comma separated list of names
 +
            (This might allow the client to allow automatic downloads of
 +
            dependencies)
 +
status      The status is split in 3 parts
 +
            - author status, the development status of the addon**
 +
            - dev status, the status the devs give to the addon***
 +
            - macroscope status, the status macroscope gives****
  
=== scenario map ===
+
* type is one of the following
The map will use the new strings instead of the old letters.
+
SP campaign
For every tile a string will be used instead of one letter,
+
MP campaign
these strings are separated with a comma. Between the string
+
MP map(s)
and the comma one or more spaces are allowed.
+
era
 +
faction
 +
mod
 +
theme (not yet possible, but might add support for it later)
 +
other
  
Instead of spaces tabs are allowed, but keep in mind what
+
** author status is one of the following
looks good in your text editor, might look horrible in the
+
under construction      addon is still in its early stages and is incomplete
editor of somebody else. The official files should use spaces.
+
alpha                  addon is pretty much complete
 +
beta                    addon is complete but needs more polishing/debugging
 +
complete                addon is complete and hopes to get a star soon
  
The WML for map will use the same format.
+
*** dev status is one of the following
The letter for map WML will use a single terrain string without
+
Unknow      default status
comma's.
+
broken      the addon doesn't work as expected
 +
buggy      the addon works almost as expected but has some bugs
 +
works      the addon works as expected but uses deprecated WML
 +
certified  the addon works and triggers no deprecated WML messages
 +
            (I don't like the word certified, so a better name is welcomed)
 +
star        same as certified but the devs enjoy to playing with this addon
  
=== Terraingraphics ===
+
**** Macroscope status
The need two modifications the map format and the type
+
Macroscope is a tool which generates an automatic status, described in more
format.
+
detail later, it has 2 possible statuses
 +
broken      a red cross, the addon is broken due to unresolved references
 +
not broken  a green V, the addon has no unresolved references (this does
 +
            not mean the addon can't be broken in other ways.)
 +
</pre>
  
==== map ====
+
==== Server ====
This format will change a bit more than the other items.
 
The old format is described here [[TerrainGraphicsWML]].
 
According to mog the letters in the map are never used,
 
only the anchors are used. The new format will only accept
 
anchors. The special characters . and * will stay the same.
 
  
This map file will no longer be space separated but comma
+
On the server is some more info stored
separatedand. Odd lines will start with a leading comma
+
<pre>
instead of 2 spaces. Spaces are allowed for padding
+
email  email address of author mandatory so it's possible to notify about status
 +
        changes
 +
</pre>
  
Also here tabs are allowed instead of spaces, see previous
+
=== Translations ===
section.
 
  
For example this
+
The goal is to separate translations from the addon so it's easier to allow
map="
+
translators and the author update independently. Also the author no longer
  1
+
needs to work with Wescamp the update is automatically send to Wescamp.
1  1
+
(If the author wants that of course.)
  2
 
1  1
 
  1"
 
  
will become
+
Note the specifics about the Wescamp are not discussed here only the general
map="
+
changes. The specifics will be discussed when the time is there and probably
,1
+
on irc.
1,1
 
,2
 
1,1
 
,1"
 
or
 
map="
 
, 1
 
1 , 1
 
, 2
 
1 , 1
 
, 1"
 
  
==== type ====
+
==== client side changes ====
The type will be a list of terrains, comma separated.
 
Spaces are allowed but then the items need to be between
 
brackets. (A WML rule.) Also after special modifiers
 
a comma is required (at the moment only the ! is a special
 
modifier, but that might change in the future.)
 
  
Mog had an idea which will also be implanted, the * can be
+
In the client a user can select 0 or more languages (s)he's interested in, this
used in a terrain string, V* would match all terrain
+
is a general preference it's used at the client as a hint. No need to show 30
strings starting with the letter 'V'. Vh* would match
+
languages with their status if the user isn't interested in it. The untranslated
all terrain strings starting with 'Vh' eg Vh, Vha, Vhaa
+
addon is always downloaded directly so English speakers might not be in
but not VH or vH.
+
translations at all.
  
=== terrain files ===
+
The client can show the following info about the translation
Eleazar would like to move the terrains in subfolders,
+
<pre>
this seems to be possible with the current system.
+
date        date of the last update
The required modifications can be found in the following
+
size        the size of the download
changelog
+
revision    revision number of the last update (Since the info is pulled from
http://svn.gna.org/viewcvs/wesnoth?rev=14069&view=rev
+
            Wescamp the updater can use this info to test for changes. The
 +
            client can use this info to determine whether the downloaded
 +
            translation is the most recent version and notify the user if not.)
 +
status      the percentage of strings translated. (Since fuzzy strings are
 +
            shown in English the count as not translated.)
 +
</pre>
  
I've no idea what the best possible directory layout
+
==== Upload ====
will be. I'll ask Eleazar to do this change when I'm
 
ready for it. At the moment I've some patches in my
 
queue which will conflict with these changes.
 
  
=== terrain strings ===
+
The pbl file will get a entry to tell whether an addon should or shouldn't be
The terrain strings will consist of 2 till 4 letters which
+
translated. If translated it will need the svn path to Wescamp for that addon.
indicate the terrain. Numbers are not allowed except for
+
If marked for translation the addon is copied to Wescamp overwriting the
starting positions. These are allowed to be between 1
+
stuff there. After the upload the version at Wescamp is directly updated.
and 4 characters. (Note Wesnoth only supports 9 starting
 
positions.) The following special characters can be used
 
/|\ these should be used for directional terrains, which
 
are only bridges at the moment.
 
  
The terrain letter _ is reserved for interal special terrains
+
This part will be updated in a later phase for now only the marking for
this will alway be used as leading character and not used
+
translation is important, the other details will depend on the implementation.
inside strings.
 
  
For readability terrains should start with a capital letter
+
==== Updating translations ====
followed by one or more lowercase letters (with a maximum of 3
 
lower case letters). The official
 
terrains must follow these rules, the custom terrains
 
should follow these rules.
 
  
There will be some letters reserved for user made content
+
The will be a cronjob on the addon server that will check all translations
these letters are Y, y, Z, z. This means every terrain
+
in Wescamp whether there's a newer revision as the last copied revision if so
with one or more of these letters inside are custom terrains.
+
the newer revision will be copied to the addon server. (It's undetermined
This way it's easier to integrate a new terrain without
+
whether this will be a real cron job or a cron like facility in the addon
having to change the terrain-graphics.cfg.
+
server.)
  
Since UTBS is mainline the custom terrain used there will
+
=== wmllint ===
be moved to the new system.
 
  
=== aliases ===
+
Esr wrote a tool, named wmllint, which can validate whether WML references
The aliases will also be a comma separated list, where the
+
are broken or not (it can do more but for the server only the broken
same discussion about the + and - can be started as in
+
references are used)
the types.
+
Broken references are
 +
- calls to non-existing macros
 +
- references to non-existing images/sound/music files
  
=== terrain list ===
+
Wmllint will run on the server, the problems with running on the clients are
This list is obselete, it was an initial proposal,
+
- Python is required
Mog and Eleazar both created a new proposal.
+
- It's possible to upload broken content by modifying wmllint
Both of them can be found here [[User:Mog]]
+
- it's required anyway due to new versions
This list remains for historical reasons.
 
  
<table border="1"><tr>
+
==== Upload ====
<th>Letter</th>
 
<th>String</th>
 
<th>Theme</th>
 
<th>Description</th>
 
</tr>
 
<tr>
 
<td>A</td>
 
<td>Vhsh</td>
 
<td>village, snow, hill</td>
 
<td>human (snow) hill village</td>
 
  
</tr><tr>
+
On upload an addon is checked whether it has no broken references.
<td>a</td>
+
If it's broken it's not allowed on the server, the output of wmllint is
<td>Vhh</td>
+
send back to the uploader so (s)he can see what the problems are.
<td>village, grassland</td>
 
<td>human hill village</td>
 
  
</tr><tr>
+
After the upload is successful there will be a preprocessed file made
<td>B</td>
+
which can be used by the dependent addons.
<td>Vda</td>
 
<td>village, desert</td>
 
<td>desert village (adobe)</td>
 
  
</tr><tr>
+
NOTE this means if addon B depends on macro A in addon A and A uploads a new
<td>b</td>
+
version without macro A then addon B is broken. A can't be blamed that B uses
<td>Vhm</td>
+
some of it's stuff so the upload of A will not be blocked. This means the
<td>village, mountain</td>
+
server needs to "remember" the reverse dependencies and test them after a new
<td>human mountain village</td>
+
upload, so B gets marked broken.
  
</tr><tr>
+
==== New version ====
<td>C</td>
 
<td>C</td>
 
<td>castle</td>
 
<td>castle</td>
 
  
</tr><tr>
+
If a new version of Wesnoth is released a preprocessed file uploaded and all
<td>c</td>
+
current available content is checked. The wmllint status is set in the
<td>Wu</td>
+
addon, upon change of status the author is notified per email (if possible)
<td>water, common</td>
 
<td>shallow water, "coast"</td>
 
  
</tr><tr>
+
Since stable versions should be compatible this shouldn't change the status.
<td>D</td>
+
For the development version it can be that a content gets broken.
<td>Vu</td>
 
<td>village, cave</td>
 
<td>underground village (cave, village), "dungeon village"</td>
 
  
</tr><tr>
+
=== Misc ===
<td>d</td>
 
<td>Pds</td>
 
<td>plain, desert</td>
 
<td>sand, (old desert)</td>
 
  
</tr><tr>
+
==== Directory structure ====
<td>E</td>
 
<td></td>
 
<td>road, desert</td>
 
<td>desert road</td>
 
  
</tr><tr>
+
At the moment there needs to be the following structure
<td>e</td>
+
$datadir/foo.cfg
<td>Ves</td>
+
$datadir/foo.pbl
<td>village, snow</td>
+
$datadir/foo
<td>elven (snow) village</td>
 
  
</tr><tr>
+
with the changes in the directory parsing the following structure would
<td>F</td>
+
also be possible and maybe should be used to make it easier to copy unpack etc stuff
<td>Fs</td>
+
$datadir/foo/_main
<td>forest, snow</td>
+
$datadir/foo/addon.pbl
<td>forest (snow)</td>
+
$datadir/foo
  
</tr><tr>
+
==== Upload ====
<td>f</td>
 
<td>F</td>
 
<td>forrest, common</td>
 
<td>forest</td>
 
  
</tr><tr>
+
At the moment it seems to be quite confusion for uploading to get things properly
<td>G</td>
+
installed, maybe allow to browse to a directory and upload that. This directory
<td>Pgs</td>
+
then needs to have a file named addon.pbl. With the wmllint interface this also
<td>plain</td>
+
can allow to save things at a different location as the upload to avoid overwriting
<td>savanna (grass)</td>
+
stuff.
  
</tr><tr>
 
<td>g</td>
 
<td>Pg</td>
 
<td>plain, common</td>
 
<td>grass</td>
 
  
</tr><tr>
 
<td>H</td>
 
<td>Hs</td>
 
<td>hill, snow</td>
 
<td>hills (snow)</td>
 
 
</tr><tr>
 
<td>h</td>
 
<td>H</td>
 
<td>hill, common</td>
 
<td>hills</td>
 
 
</tr><tr>
 
<td>I</td>
 
<td>Pd</td>
 
<td>plain, desert</td>
 
<td>desert</td>
 
 
</tr><tr>
 
<td>i</td>
 
<td>Pi</td>
 
<td>plain</td>
 
<td>ice (tundra)</td>
 
 
</tr><tr>
 
<td>J</td>
 
<td>Hd</td>
 
<td>hill, desert</td>
 
<td>desert hills</td>
 
 
</tr><tr>
 
<td>j</td>
 
<td>Ms</td>
 
<td>mountain, snow</td>
 
<td>-nothing- (will be snowy mountains)</td>
 
 
</tr><tr>
 
<td>K</td>
 
<td>K</td>
 
<td>misc</td>
 
<td>keep (castle)</td>
 
 
</tr><tr>
 
<td>k</td>
 
<td>Wf</td>
 
<td>water</td>
 
<td>river ford (grass, shallow water)</td>
 
 
</tr><tr>
 
<td>L</td>
 
<td>Vtf</td>
 
<td>village, forest</td>
 
<td>tropical forest village (savanna, village)</td>
 
 
</tr><tr>
 
<td>l</td>
 
<td>Yl using Y for strange items</td>
 
<td>misc</td>
 
<td>lava (canyon)</td>
 
 
</tr><tr>
 
<td>M</td>
 
<td>Md</td>
 
<td>mountain, desert</td>
 
<td>desert mountains</td>
 
 
</tr><tr>
 
<td>m</td>
 
<td>M</td>
 
<td>mountain, common</td>
 
<td>mountain</td>
 
 
</tr><tr>
 
<td>N</td>
 
<td>Cr</td>
 
<td>castle</td>
 
<td>ruined castle</td>
 
 
</tr><tr>
 
<td>n</td>
 
<td>Ce</td>
 
<td>castle, common</td>
 
<td>encampment (castle)</td>
 
 
</tr><tr>
 
<td>O</td>
 
<td>Co</td>
 
<td>castle</td>
 
<td>-nothing- ( will probably be an Orc Castle one day )</td>
 
 
</tr><tr>
 
<td>o</td>
 
<td>Cd</td>
 
<td>castle</td>
 
<td>dwarven castle (castle)</td>
 
 
</tr><tr>
 
<td>P</td>
 
<td>Wo</td>
 
<td>desert</td>
 
<td>desert oasis</td>
 
 
</tr><tr>
 
<td>p</td>
 
<td>Vd</td>
 
<td>village</td>
 
<td>dwarven village</td>
 
 
</tr><tr>
 
<td>Q</td>
 
<td>Crw</td>
 
<td>castle, water</td>
 
<td>sunken ruin</td>
 
 
</tr><tr>
 
<td>q</td>
 
<td>Crs</td>
 
<td>castle, water</td>
 
<td>ruin (swamp)</td>
 
 
</tr><tr>
 
<td>R</td>
 
<td></td>
 
<td>plain, common</td>
 
<td>road (grass)</td>
 
 
</tr><tr>
 
<td>r</td>
 
<td></td>
 
<td>plain</td>
 
<td>dirt (grass)</td>
 
 
 
</tr><tr>
 
<td>S</td>
 
<td>Pt</td>
 
<td>plain</td>
 
<td>tundra</td>
 
 
</tr><tr>
 
<td>s</td>
 
<td>Wd</td>
 
<td>water, common</td>
 
<td>deep water</td>
 
 
</tr><tr>
 
<td>T</td>
 
<td>Ft</td>
 
<td>forest</td>
 
<td>forest (tropical)</td>
 
 
</tr><tr>
 
<td>t</td>
 
<td>V</td>
 
<td>village, common??</td>
 
<td>village</td>
 
 
</tr><tr>
 
<td>U</td>
 
<td>Vdt</td>
 
<td>village desert</td>
 
<td>desert village (tent)</td>
 
 
</tr><tr>
 
<td>u</td>
 
<td>Pu</td>
 
<td>cave, plain</td>
 
<td>cave</td>
 
 
</tr><tr>
 
<td>V</td>
 
<td>Vs</td>
 
<td>village, snow</td>
 
<td>snow village (tundra, village)</td>
 
 
</tr><tr>
 
<td>v</td>
 
<td>Vh</td>
 
<td>village, common</td>
 
<td>human village (village)</td>
 
 
</tr><tr>
 
<td>W</td>
 
<td>Yu</td>
 
<td>cave, impassable</td>
 
<td>cavewall</td>
 
 
</tr><tr>
 
<td>w</td>
 
<td>Ws</td>
 
<td>water</td>
 
<td>swamp</td>
 
 
</tr><tr>
 
<td>X</td>
 
<td>Yc</td>
 
<td>misc</td>
 
<td>canyon (replaced by chasm in trunk)</td>
 
 
</tr><tr>
 
<td>x</td>
 
<td></td>
 
<td></td>
 
<td>reserved for UMCs</td>
 
 
</tr><tr>
 
<td>Y</td>
 
<td>Vws</td>
 
<td>village, water</td>
 
<td>swamp village (swamp, village)</td>
 
 
</tr><tr>
 
<td>y</td>
 
<td></td>
 
<td></td>
 
<td>reserved for UMCs</td>
 
 
</tr><tr>
 
<td>Z</td>
 
<td>Vwm</td>
 
<td>Village, water</td>
 
<td>mermen village (shallow water)</td>
 
 
</tr><tr>
 
<td>z</td>
 
<td></td>
 
<td></td>
 
<td>reserved for UMCs</td>
 
 
</tr><tr>
 
<td>/</td>
 
<td></td>
 
<td></td>
 
<td>bridge (grass, shallow water)</td>
 
 
</tr><tr>
 
<td>|</td>
 
<td></td>
 
<td></td>
 
<td>bridge (grass, shallow water)</td>
 
 
</tr><tr>
 
<td>\</td>
 
<td></td>
 
<td></td>
 
<td>bridge (grass, shallow water)</td>
 
 
</tr><tr>
 
<td>~</td>
 
<td></td>
 
<td></td>
 
<td>fog, can this be used in game?</td>
 
 
</tr><tr>
 
<td> </td>
 
<td></td>
 
<td></td>
 
<td>void/shroud (it uses the "space" character), can this be used in game?</td>
 
 
</tr><tr>
 
<td>[</td>
 
<td>Pur</td>
 
<td>plain, cave</td>
 
<td>rockbound cave</td>
 
 
</tr><tr>
 
<td>]</td>
 
<td>Fu</td>
 
<td>forrest, cave</td>
 
<td>mushroom grove</td>
 
 
</tr><tr>
 
<td>'</td>
 
<td>Pui</td>
 
<td>plain, cave</td>
 
<td>illuminated cave </td>
 
 
</tr><tr>
 
<td>?</td>
 
<td>Yet</td>
 
<td>forrest, misc</td>
 
<td>great Elven tree</td>
 
 
</tr><tr>
 
<td>&</td>
 
<td>Mi</td>
 
<td>mountain</td>
 
<td>impassable moutains</td>
 
</tr></table>
 
 
=== new terrains ordered ===
 
C castle castle
 
Cd castle dwarven castle (castle)
 
Ce castle, common encampment (castle)
 
Co castle -nothing- ( will probably be an Orc Castle one day )
 
Cr castle ruined castle
 
Crs castle, water ruin (swamp)
 
Crw castle, water sunken ruin
 
F forrest, common forest
 
Fs forest, snow forest (snow)
 
Ft forest forest (tropical)
 
Fu forrest, cave mushroom grove
 
H hill, common hills
 
Hd hill, desert desert hills
 
Hs hill, snow hills (snow)
 
K misc keep (castle)
 
M mountain, common mountain
 
Md mountain, desert desert mountains
 
Mi mountain impassable moutains
 
Ms mountain, snow -nothing- (will be snowy mountains)
 
Pd plain, desert desert
 
Pds plain, desert sand, (old desert)
 
Pg plain, common grass
 
Pgs plain savanna (grass)
 
Pi plain ice (tundra)
 
Pt plain tundra
 
Pu cave, plain cave
 
Pui plain, cave illuminated cave
 
Pur plain, cave rockbound cave
 
V village, common?? village
 
Vd village dwarven village
 
Vda village, desert desert village (adobe)
 
Vdt village desert desert village (tent)
 
Ves village, snow elven (snow) village
 
Vh village, common human village (village)
 
Vhh village, grassland human hill village
 
Vhm village, mountain human mountain village
 
Vhsh village, snow, hill human (snow) hill village
 
Vs village, snow snow village (tundra, village)
 
Vtf village, forest tropical forest village (savanna, village)
 
Vu village, cave underground village (cave, village), "dungeon village"
 
Vwm Village, water mermen village (shallow water)
 
Vws village, water swamp village (swamp, village)
 
Wd water, common deep water
 
Wf water river ford (grass, shallow water)
 
Wo desert desert oasis
 
Ws water swamp
 
Wu water, common shallow water, "coast"
 
Yc misc canyon (replaced by chasm in trunk)
 
Yet forrest, misc great Elven tree
 
Yl using Y for strange items misc lava (canyon)
 
Yu cave, impassable cavewall
 
 
=== terrains sorted per group ===
 
This list shows the new proposal for the terrains,
 
which takes in account the idea's of Mog and Eleazar.
 
The italic strings are reservations for terrains.
 
The only terrain which isn't backwards compatible is
 
'*'. The other terrains will be converted.
 
 
==== Snow terrains ====
 
<table border="1"><tr>
 
<th>String</th>
 
<th>Old letter</th>
 
<th>Description</th>
 
<th>Theme</th>
 
</tr>
 
 
<tr>
 
<td><i>Aa</i></td>
 
<td></td>
 
<td>snow "Artic"</td>
 
<td>snow</td>
 
</tr>
 
 
<tr>
 
<td>Ai</td>
 
<td>i</td>
 
<td>ice</td>
 
<td>snow</td>
 
</tr>
 
 
</table>
 
 
==== Bridges ====
 
Since bridges are directional all strings here
 
will be appended with either /|\ to show their
 
direction. In this list these signs are replaced
 
with a *.
 
 
<table border="1"><tr>
 
<th>String</th>
 
<th>Old letter</th>
 
<th>Description</th>
 
<th>Theme</th>
 
</tr>
 
 
<tr>
 
<td><i>Bx*</i></td>
 
<td></td>
 
<td>Bridge chasm for aboveground</td>
 
<td>bridge</td>
 
</tr>
 
 
<td><i>Bxu*</i></td>
 
<td></td>
 
<td>Bridge over chasm underground</td>
 
<td>bridge</td>
 
</tr>
 
 
<td><i>Bsw*</i></td>
 
<td></td>
 
<td>wooden bridge over swamp NOTE bws Brigde wood swamp</td>
 
<td>bridge</td>
 
</tr>
 
 
<td><i>Bws*</i></td>
 
<td></td>
 
<td>Stone Bridge over shallow water NOTE bss Bridge stone swamp not better?</td>
 
<td>bridge</td>
 
</tr>
 
 
<td>Bww*</td>
 
<td>/|\</td>
 
<td>wooden bridge bridge, over wadeable, wooden NOTE Brigde wood or Bridge wood water not better?</td>
 
<td>bridge, common</td>
 
</tr>
 
 
</table>
 
 
==== Castles ====
 
 
<table border="1"><tr>
 
<th>String</th>
 
<th>Old letter</th>
 
<th>Description</th>
 
<th>Theme</th>
 
</tr>
 
 
<tr>
 
<td>Ce</td>
 
<td></td>
 
<td>encampment (castle)</td>
 
<td>castle, common</td>
 
</tr>
 
 
<tr>
 
<td>Ch</td>
 
<td></td>
 
<td>human castle</td>
 
<td>castle, common</td>
 
</tr>
 
 
<tr>
 
<td>Chr</td>
 
<td></td>
 
<td>ruined castle</td>
 
<td>castle</td>
 
</tr>
 
 
<tr>
 
<td>Chs</td>
 
<td></td>
 
<td>human ruin (swamp)</td>
 
<td>castle</td>
 
</tr>
 
 
<tr>
 
<td>Chw</td>
 
<td></td>
 
<td>human sunken ruin</td>
 
<td>castle</td>
 
</tr>
 
 
<tr>
 
<td><i>Co</i></td>
 
<td></td>
 
<td>will be an Orc Castle one day</td>
 
<td>castle</td>
 
</tr>
 
 
<tr>
 
<td>Co</td>
 
<td></td>
 
<td>dwarven castle "castle underground, dwarf"</td>
 
<td>castle, underground</td>
 
</tr>
 
 
</table>
 
 
==== desert ====
 
NOTE still need to add the UTBS terrains
 
<table border="1"><tr>
 
<th>String</th>
 
<th>Old letter</th>
 
<th>Description</th>
 
<th>Theme</th>
 
</tr>
 
 
<tr>
 
<td><i>Dd</i></td>
 
<td></td>
 
<td>desert</td>
 
<td>desert</td>
 
</tr>
 
 
<tr>
 
<td>Do</td>
 
<td></td>
 
<td>desert oasis</td>
 
<td>desert</td>
 
</tr>
 
 
<tr>
 
<td>Ds</td>
 
<td></td>
 
<td>sand, (old desert)</td>
 
<td>desert</td>
 
</tr>
 
 
</table>
 
 
==== Forest ====
 
 
<table border="1"><tr>
 
<th>String</th>
 
<th>Old letter</th>
 
<th>Description</th>
 
<th>Theme</th>
 
</tr>
 
 
<tr>
 
<td>Fa</td>
 
<td></td>
 
<td>forest (snow) "forest arctic"</td>
 
<td>forrest, snow</td>
 
</tr>
 
 
<tr>
 
<td><i>Fb</i></td>
 
<td></td>
 
<td>Sinister Forest "Forest, Bad"</td>
 
<td>forrest</td>
 
</tr>
 
 
<tr>
 
<td>Fet</td>
 
<td></td>
 
<td>great Elven tree</td>
 
<td>forrest</td>
 
</tr>
 
 
<tr>
 
<td>Ff</td>
 
<td></td>
 
<td>forrest</td>
 
<td>forrest, common</td>
 
</tr>
 
 
<tr>
 
<td>Ft</td>
 
<td></td>
 
<td>forrest tropical</td>
 
<td>forrest</td>
 
</tr>
 
 
</table>
 
 
==== Grass ====
 
 
<table border="1"><tr>
 
<th>String</th>
 
<th>Old letter</th>
 
<th>Description</th>
 
<th>Theme</th>
 
</tr>
 
 
<tr>
 
<td><i>Gb</i></td>
 
<td></td>
 
<td>dying "Grass brown/bad"</td>
 
<td>grass</td>
 
</tr>
 
 
<tr>
 
<td><i>Gf</i></td>
 
<td></td>
 
<td>Farmer's Fields</td>
 
<td>grass</td>
 
</tr>
 
 
<tr>
 
<td>Gg</td>
 
<td></td>
 
<td>grass</td>
 
<td>grass, common</td>
 
</tr>
 
 
<tr>
 
<td>Gs</td>
 
<td></td>
 
<td>savanna (grass)</td>
 
<td>grass</td>
 
</tr>
 
 
</table>
 
 
==== hill ====
 
 
<table border="1"><tr>
 
<th>String</th>
 
<th>Old letter</th>
 
<th>Description</th>
 
<th>Theme</th>
 
</tr>
 
 
<tr>
 
<td>Ha</td>
 
<td></td>
 
<td>hills (snow) "hills arctic"</td>
 
<td>hill, snow</td>
 
</tr>
 
 
<tr>
 
<td>Hd</td>
 
<td></td>
 
<td>desert hills (dunes)</td>
 
<td>hill, desert</td>
 
</tr>
 
 
<tr>
 
<td>Hh</td>
 
<td></td>
 
<td>hills</td>
 
<td>hill, common</td>
 
</tr>
 
 
</table>
 
 
==== Keep ====
 
 
<table border="1"><tr>
 
<th>String</th>
 
<th>Old letter</th>
 
<th>Description</th>
 
<th>Theme</th>
 
</tr>
 
 
<tr>
 
<td>Kk</td>
 
<td></td>
 
<td>keep (castle)</td>
 
<td>common NOTE if more keeps are made a keep theme could be wanted</td>
 
</tr>
 
 
</table>
 
 
==== Mountain ==== 
 
 
<table border="1"><tr>
 
<th>String</th>
 
<th>Old letter</th>
 
<th>Description</th>
 
<th>Theme</th>
 
</tr>
 
 
<tr>
 
<td>Ma</td>
 
<td></td>
 
<td>snowy mountains</td>
 
<td>mountain, snow</td>
 
</tr>
 
 
<tr>
 
<td>Md</td>
 
<td></td>
 
<td>desert mountains</td>
 
<td>mountain, desert</td>
 
</tr>
 
 
<tr>
 
<td>Mm</td>
 
<td></td>
 
<td>mountain</td>
 
<td>mountain, common</td>
 
</tr>
 
 
</table>
 
 
==== (mostly) Impassable ====
 
 
<table border="1"><tr>
 
<th>String</th>
 
<th>Old letter</th>
 
<th>Description</th>
 
<th>Theme</th>
 
</tr>
 
 
<tr>
 
<td><i>Qx</i></td>
 
<td></td>
 
<td>chasm for above ground</td>
 
<td>???</td>
 
</tr>
 
 
<tr>
 
<td><i>Qxu</i></td>
 
<td></td>
 
<td>chasm for underground</td>
 
<td>???, underground</td>
 
</tr>
 
 
<tr>
 
<td><i>Qxw</i></td>
 
<td></td>
 
<td>chasm with water pouring over the edge</td>
 
<td>???</td>
 
</tr>
 
 
<tr>
 
<td>Ql</td>
 
<td></td>
 
<td>lava</td>
 
<td>misc</td>
 
</tr>
 
 
<tr>
 
<td><i>Qsq</i></td>
 
<td></td>
 
<td>stone wall</td>
 
<td>???</td>
 
</tr>
 
 
</table>
 
 
==== road ====
 
 
<table border="1"><tr>
 
<th>String</th>
 
<th>Old letter</th>
 
<th>Description</th>
 
<th>Theme</th>
 
</tr>
 
 
<tr>
 
<td><i>Rc</i></td>
 
<td></td>
 
<td>Carpeted Floor</td>
 
<td>road</td>
 
</tr>
 
 
<tr>
 
<td>Rd</td>
 
<td></td>
 
<td>desert road</td>
 
<td>road, desert</td>
 
</tr>
 
 
<tr>
 
<td>Rr</td>
 
<td></td>
 
<td>dirt road</td>
 
<td>road, common</td>
 
</tr>
 
 
<tr>
 
<td>Rs</td>
 
<td></td>
 
<td>stone road</td>
 
<td>road</td>
 
</tr>
 
 
<tr>
 
<td><i>Rw</i></td>
 
<td></td>
 
<td>Wood floor (interior)</td>
 
<td>road</td>
 
</tr>
 
 
</table>
 
 
==== swamp ====
 
 
<table border="1"><tr>
 
<th>String</th>
 
<th>Old letter</th>
 
<th>Description</th>
 
<th>Theme</th>
 
</tr>
 
 
<tr>
 
<td><i>Sb</i></td>
 
<td></td>
 
<td>fetid swamp "Swamp Bad"</td>
 
<td>swamp</td>
 
</tr>
 
 
<tr>
 
<td><i>Ss</i></td>
 
<td></td>
 
<td>swamp</td>
 
<td>swamp, water?</td>
 
</tr>
 
 
</table>
 
 
==== underground ====
 
 
<table border="1"><tr>
 
<th>String</th>
 
<th>Old letter</th>
 
<th>Description</th>
 
<th>Theme</th>
 
</tr>
 
 
<tr>
 
<td>Uf</td>
 
<td></td>
 
<td>mushroom grove "underground forest"</td>
 
<td>underground</td>
 
</tr>
 
 
<tr>
 
<td>Uh</td>
 
<td></td>
 
<td>rockbound cave (functionally "underground hill")</td>
 
<td>underground</td>
 
</tr>
 
 
<tr>
 
<td>Uu</td>
 
<td></td>
 
<td>normal cave</td>
 
<td>underground</td>
 
</tr>
 
 
<tr>
 
<td><i>Uuc</i></td>
 
<td></td>
 
<td>normal cave, carved</td>
 
<td>underground</td>
 
</tr>
 
 
<tr>
 
<td>Uui</td>
 
<td></td>
 
<td>illuminated cave</td>
 
<td>underground</td>
 
</tr>
 
 
</table>
 
 
==== village ====
 
 
<table border="1"><tr>
 
<th>String</th>
 
<th>Old letter</th>
 
<th>Description</th>
 
<th>Theme</th>
 
</tr>
 
 
<tr>
 
<td></td>
 
<td></td>
 
<td></td>
 
<td></td>
 
</tr>
 
 
</table>
 
 
Vda      desert village (adobe)
 
Vdt      desert village (tent)
 
Veg  +    elven village "village elven grassland"
 
Ves      elven (snow) village
 
Vha  +    village, snow            snow village (tundra, village)
 
Vhg  +    human village (village)
 
Vhh      human hill village
 
Vhhs      human (snow) hill village
 
Vhm      human mountain village
 
Vht  +    tropical village (savanna, village) --nothing foresty about this village
 
Vu        underground village (cave, village)
 
Vud      dwarven village
 
Vwm      mermen village (shallow water)
 
Vws      swamp village (swamp, village)
 
 
==== water ====
 
 
<table border="1"><tr>
 
<th>String</th>
 
<th>Old letter</th>
 
<th>Description</th>
 
<th>Theme</th>
 
</tr>
 
 
<tr>
 
<td>Wo</td>
 
<td></td>
 
<td>deep water "water, ocean"</td>
 
<td>water, common</td>
 
</tr>
 
 
<tr>
 
<td>Ww</td>
 
<td></td>
 
<td>shallow water, "water, wade-able"</td>
 
<td>water, common</td>
 
</tr>
 
 
<tr>
 
<td>Wwf</td>
 
<td></td>
 
<td>river ford "water wadeable, ford"</td>
 
<td>water</td>
 
</tr>
 
 
<tr>
 
<td><i>Wwu</i></td>
 
<td></td>
 
<td>shallow underground water</td>
 
<td>water, underground</td>
 
</tr>
 
 
</table>
 
 
==== Impassable ====
 
 
<table border="1"><tr>
 
<th>String</th>
 
<th>Old letter</th>
 
<th>Description</th>
 
<th>Theme</th>
 
</tr>
 
 
<tr>
 
<td>Xm</td>
 
<td></td>
 
<td>impassable moutains</td>
 
<td>impassable, mountain</td>
 
</tr>
 
 
<tr>
 
<td><i>Xsw</i></td>
 
<td></td>
 
<td>Impassable stone wall (interior)</td>
 
<td>impassable</td>
 
</tr>
 
 
<tr>
 
<td>Xu</td>
 
<td></td>
 
<td>cavewall</td>
 
<td>impassable, underground</td>
 
</tr>
 
 
<tr>
 
<td><i>Xuc</i></td>
 
<td></td>
 
<td>cavewall, carved</td>
 
<td>impassable, underground</td>
 
</tr>
 
 
<tr>
 
<td>Xww</td>
 
<td></td>
 
<td>Impassable wooden wall (interior)</td>
 
<td>impassable</td>
 
</tr>
 
 
</table>
 
 
=== encounter terrains ===
 
This list maintains the encountered terrains by the user
 
this list is used in the help function to decide what
 
to show and what not. This is now a comma seperated list.
 
The new version will also be a comma separated list but
 
with the new terrain strings instead of letters. In order
 
to keep it backwards compatible at startup the system
 
will check for
 
''encountered_terrains'' and ''encountered_terrains13''
 
. Then test the following conditions is this order:
 
* if ''encountered_terrains13'' is found these are loaded.
 
* if ''encountered_terrains'' is found, these are converted to ''encountered_terrains13'' format and loaded
 
* none are found, nothing will be done.
 
 
When writing only ''encountered_terrains13'' will be used.
 
 
The reason to keep it backwards compatible is that if
 
somebody tries an 1.3.x version and doesn't like it,
 
it's no problem to return to 1.2.x. If we convert
 
''encountered_terrains'' to the new format it might
 
give troubles when loading it with 1.2.x.
 
  
 
== editor ==
 
== editor ==
Line 1,294: Line 268:
 
'''Discussion:''' Is this handy?
 
'''Discussion:''' Is this handy?
  
=== resize map ===
+
== MP dialog ==
maybe there should be an option to add tiles to the left and
+
 
top instead of only to the right and bottom.
+
See [[UseMapSettings]]
See http://www.wesnoth.org/forum/viewtopic.php?p=192326#192326
+
 
  
=== Small maps ===
 
It would be handy to be able to create maps smaller than
 
20 x 20 for WML usage. IMO as soon as the map goes below
 
this threshold a warning should be shown, that the map
 
might nog work properly as main scenario map.
 
See http://www.wesnoth.org/forum/viewtopic.php?p=192435#192435
 
  
 
= Todo =
 
= Todo =
Thing I plan to do after I finished my WIP's.
+
Things I plan to do after I finished my WIP's.
  
 
== team sides ==
 
== team sides ==
Line 1,328: Line 296:
 
Various things I want to look at at some time.
 
Various things I want to look at at some time.
 
* version checks for WML, needed or not?
 
* version checks for WML, needed or not?
* modulo WML, needed or not?
+
* modulo WML, needed or not? Done, might cleanup similair code the same way.
 
* continue to work on the Python AI
 
* continue to work on the Python AI
 +
 +
 +
 +
= Savegame format =
 +
 +
It would be nice to have the format of the savegame and the
 +
data send by the MP server to be a bit more the same. The other
 +
idea is that the MP server holds a minimal part in a config
 +
object and the rest of the data is stored in a gzipped config.
 +
This gzipped config is seen as a blob and not unpacked by
 +
the server but simply forwarded to the clients. This
 +
is a rough draft used to discuss about on the FOSDEM.
 +
 +
The format will get the following sections
 +
* ''header'' basic info which is at the moment at the root of the file.
 +
** ''kind'' this key contains SP/MP value.
 +
** ''state'' this key is like the current key, but can also be start.
 +
* ''carry_over'' this section is only used in campaigns and contains the gold carry over info. This info is the same for all players.
 +
* ''dependencies'' 0 or more sections containing the id's of the dependencies. (Use sections since we might want to add more info later.)
 +
* ''summery'' this section isn't really needed for a savegame but it contains the info the addon server needs to know about (not sure what's needed.)
 +
* ''start_of_scenario'' section with all info regarding the start of scenario (a bit like replay_start atm).
 +
** ''player'' the player data stored from the previous scenario, always saved.
 +
** ''scenario'' this section always exists in MP but not in SP (in SP there's a key scenario_id) and contains the scenario data.
 +
** ''era'' this section contains the era data for MP, section doesn't exist in SP.
 +
* ''snapshot'' section wit the info about the current state of the game.
 +
** ''player'' current state of the players
 +
** ''scenario'' current state of the scenario
 +
** ''era'' current state of the are
 +
* ''statictics'' same as atm.
 +
* ''replay'' same as atm.
 +
 +
What to do with unit info? I want to remove some info from the unit like
 +
movement cost, defence stats, animations etc. Should this info be saved
 +
or not?
 +
 +
BTW it might be a nice project to have a something like a DOM viewer
 +
but then for WML.
 +
 +
See also [[SavefileWML]]

Latest revision as of 17:26, 24 April 2008

WIP

gui toolkit

GUIToolkit GUIToolkitWML GUICanvasWML GUIVariable Wiki_grabber

Addon server

After collecting the info in this thread http://www.wesnoth.org/forum/viewtopic.php?t=15664 this is a first proposal to all changes for the addon server. Personally I'm most interested to do the server side changes and not the client side changes so I hope to find a victim for that part ;)

The changes are splitted in 3 parts, the general changes, the changes specific to improve the handling of translations and last the automatic test for some broken content.

General changes

Client side changes

For the client side some extra fields will be available to show, some are set by the author and some by the admin/devs. Also note I think it might be a good idea to give some non-devs dev access to the server, that would be people the devs think should have that access. I don't want to do the voting system at the moment since that will be quite some work (due to possible abuses) and adds little benefit. (The main reason for starting this project is to allow asynchronous updates of the translations.)

icon        like current icon
name        like current name
title       like current title
description like current description (but hopefully shown in the client)
image       larger image to show (as shown in the addon menu when you select
            an addon)
type*       type of the content see below (the client might want to split this
            displayed info per type)
author      name of the author
version     version number of the addon (as set by the author)
date        timestamp of last upload, this way 2 updates on one day can be seen
            as different. (ideally the client should notice a newer version by
            this value and give a visible clue)
size        download size of the addon excluding languages. Languages show
            this value separately.
length      number of scenarios, mainly for campaigns
difficulty  difficulties available as comma separated list
version_a   string with versions it should work with eg (a better tag name is to
            found)
            - 1.2.* all 1.2 versions
            - 1.2.3+ versions equal or newer as 1.2.3
            - 1.2.0 - 1.2.2 versions from (including) 1.2.0 to (including) 1.2.2
version_b   string with the version used for the upload to be able to block
            specific versions that are known not to work on client side or to at
            least be able to show a warning to the user
dependency  other content this addon depends on, comma separated list of names
            (This might allow the client to allow automatic downloads of
            dependencies)
status      The status is split in 3 parts
            - author status, the development status of the addon**
            - dev status, the status the devs give to the addon***
            - macroscope status, the status macroscope gives****

* type is one of the following
SP campaign
MP campaign
MP map(s)
era
faction
mod
theme (not yet possible, but might add support for it later)
other

** author status is one of the following
under construction      addon is still in its early stages and is incomplete
alpha                   addon is pretty much complete
beta                    addon is complete but needs more polishing/debugging
complete                addon is complete and hopes to get a star soon

*** dev status is one of the following
Unknow      default status
broken      the addon doesn't work as expected
buggy       the addon works almost as expected but has some bugs
works       the addon works as expected but uses deprecated WML
certified   the addon works and triggers no deprecated WML messages
            (I don't like the word certified, so a better name is welcomed)
star        same as certified but the devs enjoy to playing with this addon

**** Macroscope status
Macroscope is a tool which generates an automatic status, described in more
detail later, it has 2 possible statuses
broken      a red cross, the addon is broken due to unresolved references
not broken  a green V, the addon has no unresolved references (this does
            not mean the addon can't be broken in other ways.)

Server

On the server is some more info stored

email   email address of author mandatory so it's possible to notify about status
        changes

Translations

The goal is to separate translations from the addon so it's easier to allow translators and the author update independently. Also the author no longer needs to work with Wescamp the update is automatically send to Wescamp. (If the author wants that of course.)

Note the specifics about the Wescamp are not discussed here only the general changes. The specifics will be discussed when the time is there and probably on irc.

client side changes

In the client a user can select 0 or more languages (s)he's interested in, this is a general preference it's used at the client as a hint. No need to show 30 languages with their status if the user isn't interested in it. The untranslated addon is always downloaded directly so English speakers might not be in translations at all.

The client can show the following info about the translation

date        date of the last update
size        the size of the download
revision    revision number of the last update (Since the info is pulled from
            Wescamp the updater can use this info to test for changes. The
            client can use this info to determine whether the downloaded
            translation is the most recent version and notify the user if not.)
status      the percentage of strings translated. (Since fuzzy strings are
            shown in English the count as not translated.)

Upload

The pbl file will get a entry to tell whether an addon should or shouldn't be translated. If translated it will need the svn path to Wescamp for that addon. If marked for translation the addon is copied to Wescamp overwriting the stuff there. After the upload the version at Wescamp is directly updated.

This part will be updated in a later phase for now only the marking for translation is important, the other details will depend on the implementation.

Updating translations

The will be a cronjob on the addon server that will check all translations in Wescamp whether there's a newer revision as the last copied revision if so the newer revision will be copied to the addon server. (It's undetermined whether this will be a real cron job or a cron like facility in the addon server.)

wmllint

Esr wrote a tool, named wmllint, which can validate whether WML references are broken or not (it can do more but for the server only the broken references are used) Broken references are - calls to non-existing macros - references to non-existing images/sound/music files

Wmllint will run on the server, the problems with running on the clients are - Python is required - It's possible to upload broken content by modifying wmllint - it's required anyway due to new versions

Upload

On upload an addon is checked whether it has no broken references. If it's broken it's not allowed on the server, the output of wmllint is send back to the uploader so (s)he can see what the problems are.

After the upload is successful there will be a preprocessed file made which can be used by the dependent addons.

NOTE this means if addon B depends on macro A in addon A and A uploads a new version without macro A then addon B is broken. A can't be blamed that B uses some of it's stuff so the upload of A will not be blocked. This means the server needs to "remember" the reverse dependencies and test them after a new upload, so B gets marked broken.

New version

If a new version of Wesnoth is released a preprocessed file uploaded and all current available content is checked. The wmllint status is set in the addon, upon change of status the author is notified per email (if possible)

Since stable versions should be compatible this shouldn't change the status. For the development version it can be that a content gets broken.

Misc

Directory structure

At the moment there needs to be the following structure

$datadir/foo.cfg
$datadir/foo.pbl
$datadir/foo

with the changes in the directory parsing the following structure would also be possible and maybe should be used to make it easier to copy unpack etc stuff

$datadir/foo/_main
$datadir/foo/addon.pbl
$datadir/foo

Upload

At the moment it seems to be quite confusion for uploading to get things properly installed, maybe allow to browse to a directory and upload that. This directory then needs to have a file named addon.pbl. With the wmllint interface this also can allow to save things at a different location as the upload to avoid overwriting stuff.


editor

The editor also will need an overhaul due to the changes, since the terrain consists of a maximum of 4 characters I propose it writes the terrain as a string of 6 characters; the terrains string followed by a comma and padded with spaces. eg the following terrain string

Vh,Vha,Vhaa,Vha,Vh 

will be written as

123456123456123456123456123456 (numbers won't be written.)
Vh,   Vha,  Vhaa, Vha,  Vh 

Discussion: Should the editor be able to write the old format terrain or not.

custom terrains

Zookeeper told me there's no option to add custom terrains at the moment. I want to add a button to add a custom terrain, once clicked it will prompt for the terrain string and insert the tile to the list of available tiles and allow to use this tile. The tile will be 'painted' with the terrain string. When loading a map with unknown strings these will be added to the list of terrains. The only problem will be the location of the terrains but I'll worry about that later.

There should also be an option to add fog/shroud tiles to the map. See http://www.wesnoth.org/forum/viewtopic.php?p=192326#192326

Discussion: Would this solve the unkown tile problem?

themes

In my opinion the list with terrains to browse is pretty long and this will only grow in the future. I want to add an extra grid of buttons with theme's the buttons will have an icon for their theme. When a button is clicked the list of terrains is filtered per theme. eg when the theme villages is selected only village tiles are shown. Every terrain gets one or more themes for example a snow forest can be in the theme forest and the theme snow, so with either theme this tile is shown. There will be 2 special theme's favorites and map. Favorites are your favorite tiles saved in preferences and can contain unknown terrains. Map are all tiles already used on this map, including the unknown.

Discussion: Is this handy?

MP dialog

See UseMapSettings


Todo

Things I plan to do after I finished my WIP's.

team sides

After the terrain system has been modified it's possible to define more teams, EdB asked this in irc at 20061027.

It would be nice to support 12 sides in multiplayer with their own tcolour. The engine should support more sides for the AI to use. These will use and scenario WML defined colour. It's not sure whether WML supports this if not the support should be made. EdB will look for an possible algo to define nice auto colours.

terrain archtypes

Eleazar had an idea for terrain archtypes in the terrain thread. It looks sane and would be nice to implant. http://www.wesnoth.org/forum/viewtopic.php?p=191410#191410

Misc

Various things I want to look at at some time.

  • version checks for WML, needed or not?
  • modulo WML, needed or not? Done, might cleanup similair code the same way.
  • continue to work on the Python AI


Savegame format

It would be nice to have the format of the savegame and the data send by the MP server to be a bit more the same. The other idea is that the MP server holds a minimal part in a config object and the rest of the data is stored in a gzipped config. This gzipped config is seen as a blob and not unpacked by the server but simply forwarded to the clients. This is a rough draft used to discuss about on the FOSDEM.

The format will get the following sections

  • header basic info which is at the moment at the root of the file.
    • kind this key contains SP/MP value.
    • state this key is like the current key, but can also be start.
  • carry_over this section is only used in campaigns and contains the gold carry over info. This info is the same for all players.
  • dependencies 0 or more sections containing the id's of the dependencies. (Use sections since we might want to add more info later.)
  • summery this section isn't really needed for a savegame but it contains the info the addon server needs to know about (not sure what's needed.)
  • start_of_scenario section with all info regarding the start of scenario (a bit like replay_start atm).
    • player the player data stored from the previous scenario, always saved.
    • scenario this section always exists in MP but not in SP (in SP there's a key scenario_id) and contains the scenario data.
    • era this section contains the era data for MP, section doesn't exist in SP.
  • snapshot section wit the info about the current state of the game.
    • player current state of the players
    • scenario current state of the scenario
    • era current state of the are
  • statictics same as atm.
  • replay same as atm.

What to do with unit info? I want to remove some info from the unit like movement cost, defence stats, animations etc. Should this info be saved or not?

BTW it might be a nice project to have a something like a DOM viewer but then for WML.

See also SavefileWML

This page was last edited on 24 April 2008, at 17:26.