wesnoth-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Wesnoth-patches] [patch #3359] Separate recall lists for each side


From: Guillaume Melquiond
Subject: [Wesnoth-patches] [patch #3359] Separate recall lists for each side
Date: Wed, 29 Dec 2004 16:06:24 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.7.5) Gecko/20041219 Firefox/1.0 (Debian package 1.0+dfsg.1-1)

This mail is an automated notification from the patch tracker
 of the project: Battle for Wesnoth.

/**************************************************************************/
[patch #3359] Latest Modifications:

Changes by: 
                Guillaume Melquiond <address@hidden>
'Date: 
                mer 29.12.2004 at 20:51 (Europe/Paris)

            What     | Removed                   | Added
---------------------------------------------------------------------------
          Resolution | None                      | Wont Apply
              Status | Open                      | Closed


------------------ Additional Follow-up Comments ----------------------------
Has been sitting around for too long; cleaning up. Please submit again if 
needed.






/**************************************************************************/
[patch #3359] Full Item Snapshot:

URL: <http://savannah.nongnu.org/patch/?func=detailitem&item_id=3359>
Project: Battle for Wesnoth
Submitted by: 0
On: dim 12.09.2004 at 01:03

Category:  None
Priority:  1 - Later
Resolution:  Wont Apply
Privacy:  Public
Assigned to:  None
Originator Email:  address@hidden
Status:  Closed


Summary:  Separate recall lists for each side

Original Submission:  From my post at 
http://www.wesnoth.org/forum/viewtopic.php?t=3054 :


With this patch, there are two representations of a player's state in the game. 
The information-rich "team" structure is still where all the information about 
a running scenario goes, while the new "player" structure stores persistent 
information about a player (information that carries from one scenario to the 
next). Currently this is just the amount of gold the player has, his recall 
list, and the units he can recruit, but it could easily be expanded to cover 
more exotic stuff. This persistent information is stored only in save files 
(not in campaign scenarios).

To bind dynamic player information to persistent player information, the new 
"save_id" side attribute is used. Each side can have a separate "save_id", 
which is a string that uniquely identifies the side. If "save_id" is not 
present, it defaults to the "description" attribute of the side, which is the 
leader's name (this means single-player campaigns generally don't need to be 
modified, although there is a potential problem in multiplayer -- see below). 
At the beginning of a scenario, the persistent information will be read to 
initialize the corresponding fields in the "team" structure; at the end of a 
scenario, the values from the "team" structure will be written back to the 
"player" structure.

By default, only human players are stored in save files. By putting 
"persistent=1" in a side's definition, you can make its gold and recall list 
carry over between scenarios no matter who controls it -- although currently 
there's no point in doing so.

WML and game semantics have changed in the following ways that I know of:
- You can no longer ever store a unit in the recall list of another side. In 
the past, creating a unit "off the board" would put it in the player's recall 
list no matter which side it was on; now it will just vanish into the ether. 
This incidentally might fix Circon's "recallable troll" and other weirdnesses 
caused by a typo.
- The [role] tag now accepts a "side" attribute. If the attribute is not 
present, the old behavior is the default: all units on the board and in EVERY 
recall list are potential targets. Otherwise, only units in the side(s) listed 
in "sides" will be matched. (this may be unnecessary complexity)
- all other filters that used to match anything on the board plus a recall list 
will now search all recall lists for matching units

The multiplayer problem I referred to above: In single-player, the names of 
leaders are generally unique, particularly human leaders. However, in 
multi-player, while human names are unique, AI leader names are auto-generated. 
This could cause weirdness to occur in multi-scenario campaigns if two AIs got 
the same name, or an AI got the same name as a human. The solution is probably 
for designers of multi-scenario campaigns (which can't be done yet anyway) to 
use explicit save_id attributes in every [side] tag.


Daniel

Follow-up Comments
------------------


-------------------------------------------------------
Date: mer 29.12.2004 at 20:51       By: Guillaume Melquiond <silene>
Has been sitting around for too long; cleaning up. Please submit again if 
needed.






File Attachments
-------------------

-------------------------------------------------------
Date: dim 12.09.2004 at 01:03  Name: wesnoth-multi-recall.patch.gz  Size: 
8,24KB   By: None
Multiple recall lists for Wesnoth.
http://savannah.nongnu.org/patch/download.php?item_id=3359&amp;item_file_id=3659






For detailed info, follow this link:
<http://savannah.nongnu.org/patch/?func=detailitem&item_id=3359>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/







reply via email to

[Prev in Thread] Current Thread [Next in Thread]