[Wesnoth-bugs] [bug #23024] ghazi plays the slow sound even when missing the shield bash

[George]

Follow-up Comment #2, bug #23024 (project wesnoth):

Great, thanks!

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21961] Units are not attacking if the attack was issued from more than one hex away

[George]

Follow-up Comment #5, bug #21961 (project wesnoth):

1.11.13 is the version where this bug was discovered.  It has been fixed on
the development version (not released yet... but soon).  Please check again
after that release to confirm it really is fixed.  Thanks for the report!

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21961] Units are not attacking if the attack was issued from more than one hex away

[George]

Follow-up Comment #2, bug #21961 (project wesnoth):

More details would be good as this is happening a lot for some people, less
for others and not at all for still others.  Any hints as to what causes it?

Also, that commit doesn't seem to be included in master.  Can you double check
the commit ID?

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21961] Units are not attacking if the attack was issued from more than one hex away

[George]

Update of bug #21961 (project wesnoth):

Severity:  3 - Normal => 5 - Blocker

___

Follow-up Comment #1:

Moved up to blocker, as testing indicates this happens frequently and we can't
ship stable while this is going on.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21903] Scenario transitions in networked MP don't work unless host transitions first

[George]

Follow-up Comment #9, bug #21903 (project wesnoth):

Let's be sure to test how observers are handled as well.  Ideal behavior would
be that observers also progress.  I can help test that, hit me up on IRC (as
happygrue) and we can make sure this works.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21903] Scenario transitions in networked MP don't work unless host transitions first

[George]

Follow-up Comment #8, bug #21903 (project wesnoth):

As someone who has played a lot of MP campaigns as both host and player, that
seems a reasonable way to handle it IMO.  We just need to make players aware
of this now, though really they will also figure it out.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21915] resolution settings in windowed mode incorrect

[George]

Update of bug #21915 (project wesnoth):

 Open/Closed:  Closed => Open   


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21915] resolution settings in windowed mode incorrect

[George]

Update of bug #21915 (project wesnoth):

  Status:None => Fixed  


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21915] resolution settings in windowed mode incorrect

[George]

Update of bug #21915 (project wesnoth):

 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21405] Don't force players to cheat in multiplayer (after disconnect)

[George]

Follow-up Comment #7, bug #21405 (project wesnoth):

I am not 100% sure at present, but it certainly used to be true that it was
"way to complicated to mess with".  Years ago I asked for skipping replays
entirely to be possible and the basic answer was "you can't".  It was not long
after that IIRC that we got "fast replays" (maybe you remember the days before
that...), but AFAIK that is as good as it gets without a major overhaul of how
replays work.  I hope I am wrong!

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21405] Don't force players to cheat in multiplayer (after disconnect)

[George]

Follow-up Comment #5, bug #21405 (project wesnoth):

editing blooper:  Mentally delete my last sentence, there isn't a perfect
solution that I can see without redoing everything about how replays work now.
 I thought I deleted that line.

To recap:  An idle placeholder of some kind and then saving to the lobby seems
like the best option to me.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21405] Don't force players to cheat in multiplayer (after disconnect)

[George]

Follow-up Comment #4, bug #21405 (project wesnoth):

One other problem with the OP preferred solution (add an option that allows to
put the side in an 'idle' mode) is that any player rejoining the game to claim
their side will have to watch at least part of the replay, so I'm not sure it
would really work to just put that side in "idle" unless that also allowed
some way to get the player back into their side without seeing anything else
in the process.  That means freezing the game, one way or another I think?

If we have to pause the game and wait for someone else to come back while in
"idle mode" then suddenly perhaps saving and re-hosting becomes preferable -
except the same issue of seeing both player's sides in the game creation lobby
comes in.

Finally, in larger games the player might drop and reconnect several times in
a game while other people are taking their turns.  Ideally, the rest of the
players would be able to play on while the person rejoining could skip the
replay and be giving their side back without being the wiser.

However, given the reality of how replays work, I would suggest the best
option we have for now would be an idle mode (AI that doesn't move or
whatever) that could be saved.  That way if the players want to wait they can,
hoping the returning player doesn't peak at the map.  And if they want to quit
and host anew they can do that.
To me, the "perfect"

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21662] maximizing window causes portrait to cover message text

[George]

Additional Item Attachment, bug #21662 (project wesnoth):

File name: screenshot2.pngSize:1006 KB


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21662] maximizing window causes portrait to cover message text

[George]

URL:
  

 Summary: maximizing window causes portrait to cover message
text
 Project: Battle for Wesnoth
Submitted by: wintermute
Submitted on: Sun 16 Feb 2014 03:50:13 PM UTC
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: User Interface
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.11.8+dev
Operating System: Windows 7

___

Details:

When Wesnoth is running in windowed mode in a smaller than maximum sized
window and a message pops up, maximize the window and the portrait now covers
some message text.  Screenshot from vultraz attached.




___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21214] MP Statistics wrongly lumps together all sides' recruits, kills, and losses

[George]

Update of bug #21214 (project wesnoth):

  Status:  Ready For Test => Fixed  

___

Follow-up Comment #12:

I tested it, and the bug seems fixed now.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21214] MP Statistics wrongly lumps together all sides' recruits, kills, and losses

[George]

Update of bug #21214 (project wesnoth):

Severity:   4 - Important => 5 - Blocker

___

Follow-up Comment #9:

Marked as a blocker pending khalifate inclusion.  If the khalifate are going
to be added then we expect more server traffic on the development branch
server - and this bug is really bad for serious multiplayer games.  If the
khalifate are not going to be included then it could probably be relegated to
important for now - but surely it needs to be fixed before a stable release.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21214] MP Statistics wrongly lumps together all sides' recruits, kills, and losses

[George]

Update of bug #21214 (project wesnoth):

Severity:  3 - Normal => 4 - Important  


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21214] MP Statistics wrongly lumps together all sides' recruits, kills, and losses

[George]

Follow-up Comment #7, bug #21214 (project wesnoth):

Yep, sorry - I should have checked more closely, I was noticing while playing
and wanted to note it before I forgot.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21214] MP Statistics wrongly lumps together all sides' recruits, kills, and losses

[George]

Follow-up Comment #5, bug #21214 (project wesnoth):

Still broken in 1.11.7 and presumably trunk.  This is bad news for anyone who
wants to play multiplayer.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #19353] Update 6p_Vocano.map

[George]

Follow-up Comment #3, bug #19353 (project wesnoth):

Yes, this can be closed.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #19883] MP village_gold default set incorrectly when launched from commandline

[George Koehler]

Follow-up Comment #1, bug #19883 (project wesnoth):

In general, 'wesnoth -m' uses the wrong default values. A 'wesnoth -m' game
can have the following problems:

* The number of turns is 50. It should be unlimited.
* You can start with the wrong amount of gold (bug #19895).
* You do not share vision with your allies! Try 'wesnoth -m --scenario
multiplayer_Volcano', your allies hide under fog.
* It ignores some map settings; for example, 'wesnoth -m --scenario
multiplayer_A_New_Land' fails to lock the faction to Loyalists, and change the
recruit list to Mage and Peasant.


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #19895] Starting gold defaults to 0 when launched from command line

[George Koehler]

Follow-up Comment #1, bug #19895 (project wesnoth):

With 1.10, 'wesnoth -m' starts with 100 gold or the map setting, whichever is
more.  For example, 'wesnoth -m --scenario multiplayer_Volcano' starts with
125 gold, equaling the map setting; but 'wesnoth -m --scenario
multiplayer_Hamlets' starts with 100 gold, though the map setting is 75 gold.

With 1.11.0-svn (54838), 'wesnoth -m --scenario multiplayer_Volcano' starts
with 125 gold, but 'wesnoth -m --scenario multiplayer_Hamlets' starts with 0
gold.  So Hamlets has this bug but Volcano does not.

See also bug #19883.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #19805] CALL_FUNCTION uses wrong subtag

[George Koehler]

URL:
  

 Summary: CALL_FUNCTION uses wrong subtag
 Project: Battle for Wesnoth
Submitted by: kernigh
Submitted on: Thu 14 Jun 2012 02:51:18 AM GMT
Category: Bug
Severity: 2 - Minor
Priority: 5 - Normal
  Item Group: WML
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.10.3+svn (54405)
Operating System: OpenBSD 5.1

___

Details:

CALL_FUNCTION in data/core/macros/event-utils.cfg wrote:


[fire_event]
name={EVENT_NAME}
[primary_unit]
x,y=$unit.x,$unit.y
[/primary_unit]
[second_unit]
x,y=$second_unit.x,$second_unit.y
[/second_unit]
[/fire_event]


This must be wrong: [fire_event] has no [second_unit] subtag. The wiki* says
[secondary_unit], not [second_unit]. Also, the code in data/lua/wml-tags.lua
seems to use [secondary_unit], not [second_unit].
*http://wiki.wesnoth.org/InternalActionsWML#.5Bfire_event.5D

This might be a good bug, because I never see any errors or warnings about
$second_unit, though I always use CALL_FUNCTION in places where $second_unit
does not exist. Right now, I see "error engine: failed to auto-store $unit at
(-999,-999)" and "warning engine: variable_info: retrieving member of
non-existent WML container, unit.x" (or unit.y) when I use CALL_FUNCTION in a
side turn event, but I see no such error or warning about $second_unit.

See discussion at http://forum.wesnoth.org/viewtopic.php?f=21&t=36989




___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #19783] WML menu items can interrupt themselves

[George Koehler]

URL:
  

 Summary: WML menu items can interrupt themselves
 Project: Battle for Wesnoth
Submitted by: kernigh
Submitted on: Mon 04 Jun 2012 10:11:41 PM GMT
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: WML
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.10.3+svn (54373)
Operating System: OpenBSD 5.1

___

Details:

A player, who is fast with a mouse, can click a WML menu item, and then click
a WML menu item, such that the second action interrupts the first action. This
glitches the first action.

WML menu items come from [set_menu_item]. Wesnoth does not disable WML menu
items while a WML menu item runs an action.

To reproduce this bug, you need a slow menu item. I attach an add-on, _Menu
Test Era_, that provides a slow menu item, "Build and Burn". This action
builds 5 villages and then destroys them. It is slow because it uses [delay].

Steps to reproduce:
0 Install _Menu Test Era_ (from attachment) and start Wesnoth.
0 Start a multiplayer Local Game with Menu Test Era.
0 Play with the menu item, "Build and Burn".
0 You can cause some glitches if you start a second "Build and Burn" before
the first "Build and Burn" finishes its action. For example, the first action
might burn the wrong hexes.

It seems that the second action interrupts the first action, and changes
variables such as $x1 and $y1.

I have also caused glitches by opening and closing the right-click menu,
without clicking a menu item. Perhaps the menu changes $x1 and $y1 while
running [show_if] filters.

You can also reproduce this bug with add-ons from the add-on server. I first
encountered this bug with _Era of Explicit Economy_. In version 0.2.0.1, if I
"Show workable area", there is enough lag to trigger this bug. Then I can
order two peasants to "Get to Work!", so the second peasant interrupts the
first peasant. The first peasant glitches and works the wrong hex.

I can reproduce this bug with _A New Land Classic_ 0.14.3, but the only glitch
so far is to send warnings about variables to standard error.

I have compiled Wesnoth for OpenBSD 5.1 with the system compiler (g++ 4.2.1).



___

File Attachments:


---
Date: Mon 04 Jun 2012 10:11:41 PM GMT  Name: Menu-Test-Era.tar.gz  Size: 638B 
 By: kernigh
Menu Test Era


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #19681] cache is never valid

[George Koehler]

URL:
  

 Summary: cache is never valid
 Project: Battle for Wesnoth
Submitted by: kernigh
Submitted on: Tue 01 May 2012 03:16:34 AM GMT
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: WML
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.10.2+svn (54047)
Operating System: OpenBSD 5.0

___

Details:

Wesnoth 1.10.x always rejects the cache in ~/.cache/wesnoth and generates the
cache again. To reproduce this bug:

0 Start Wesnoth, then choose Multiplayer, Local Game. When you reach the map
list, you now have a current cache (at least for multiplayer games).
0 Quit Wesnoth.
0 Start Wesnoth again, then choose Multiplayer, Local Game. Notice that
Wesnoth generates the cache again.

This bug is more obvious if you install more multiplayer add-ons, including
SXCollection. Then cache generation is slower.

Wesnoth 1.8.6 does not have this bug. I first noticed this bug with Wesnoth
1.9.x, but I did not report the bug until now, because I often used _svn up_
or edited WML files.

Today, I hacked config_cache.cpp and learned much about this bug. Wesnoth has
trouble when reading each *.checksum.gz file. Each file looks like


$ zcat *b4ed1f*.checksum.gz
modified=1335817180
nfiles=4425
size=212649201


These are the correct values. If _file_tree_checksum dir_checksum_ would have
these values, then the checksum would pass, and Wesnoth would use my cache.
However, Wesnoth fails to load the correct values.

Around config_cache.cpp:197, I added these lines,


ERR_CACHE << "looks like " << checksum_cfg["nfiles"] << " " <<
checksum_cfg["size"] << " " << checksum_cfg["modified"] << "\n";
config_writer writer(std::cerr, false);
writer.write(checksum_cfg);


Their output is


20120430 22:01:46 error cache: looks like 4425 2.12649e+08 1.33582e+09
modified=1335817180
nfiles=4425
size=212649201


Then around config_cache.cpp:215, I added these lines,


file_tree_checksum tru_checksum = data_tree_checksum();
if(dir_checksum != tru_checksum) {
ERR_CACHE << "wrong checksum: " << fname << extension << "\n"
<< "  have: " << dir_checksum.nfiles << " " << 
dir_checksum.sum_size << " "
<< dir_checksum.modified << "\n"
<< "  need: " << tru_checksum.nfiles << " " << 
tru_checksum.sum_size << " "
<< tru_checksum.modified << "\n";
}


Their output is


20120430 22:01:46 error cache: wrong checksum:
/home/kernigh/.cache/wesnoth/cache-v1.10.2+svn
(54047M)-b4ed1f8db3a4af53f5455db4def5f31f899667cd.gz
  have: 4425 2 1
  need: 4425 212649201 1335817180


Because 2 != 212649201, or 1 != 1335817180, so the checksum fails, and Wesnoth
rejects the cache.

Wesnoth seems to convert 212649201 to "2.12649e+08" to 2, and likewise
1335817180 to "1.33582e+09" to 1. This bug might relate to bug #19201, which
claims that Wesnoth has trouble when reading numbers from WML.

I am not sure how to fix this bug. The actual conversion happens at
filesystem.cpp:866, where


file_tree_checksum::file_tree_checksum(const config& cfg) :
nfiles  (lexical_cast_default(cfg["nfiles"])),
sum_size(lexical_cast_default(cfg["size"])),
modified(lexical_cast_default(cfg["modified"]))
{
}


This converts cfg[...] from _config::attribute_value_ to _size_t_ or _time_t_,
but I know not how Wesnoth does this conversion.

I compiled Wesnoth 1.10.2+svn (54047) for OpenBSD 5.0, with this compiler


$ g++ -v 
Reading specs from /usr/lib/gcc-lib/amd64-unknown-openbsd5.0/4.2.1/specs
Target: amd64-unknown-openbsd5.0
Configured with: OpenBSD/amd64 system compiler
Thread model: posix
gcc version 4.2.1 20070719 


and these packages


$ pkg_info -I boost pango sdl   
boost-1.42.0p7  free peer-reviewed portable C++ source libraries
pango-1.28.4p2  library for layout and rendering of text
sdl-1.2.13p15   cross-platform multimedia library






___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #19433] Option "Save replay on SP/MP victory or MP defeat" has no effect

[George Koehler]

Follow-up Comment #1, bug #19433 (project wesnoth):

Did you click the "End Scenario" button? I am able to save a replay when I
click "End Scenario" in a multiplayer game. (If it is network game and I am
not host, then I manually "Save Replay" and "Quit".)

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #19393] Units invisible after victory

[George Koehler]

Follow-up Comment #1, bug #19393 (project wesnoth):

I first noticed this with 1.9.x. The linger mode (at end of scenario)
preserves fog of war, so the map shows no units unless you have survivors, and
then only shows units near your survivors. Is this an intentional change? My
guess is yes.

However, minimap must be consistent with big map. If linger mode wants to hide
units in fog, then it is bug to select these units or see them on minimap. Or,
if linger mode wants to allow selecting these units or seeing them on minimap,
then it is bug to hide units in fog.

To reproduce this bug, go Multiplayer, start Local Game, play 2 player versus
AI, and allow AI to kill your leader.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #19351] missing image: soulless-drake-defend.png

[George Koehler]

URL:
  

 Summary: missing image: soulless-drake-defend.png
 Project: Battle for Wesnoth
Submitted by: kernigh
Submitted on: Mon 30 Jan 2012 01:36:13 AM GMT
Category: Bug
Severity: 2 - Minor
Priority: 5 - Normal
  Item Group: Units
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.1.10+svn (52780)
Operating System: OpenBSD

___

Details:

The drake flavor of Soulless has a missing animation. Its image disappears and
reappears during combat, and this error appears in my terminal:


20120129 20:09:36 error display: could not open image
'units/undead/soulless-drake-defend.png'


There is no such image as soulless-drake-defend.png.

I noticed this bug while observing a multiplayer game on official 1.10 server.
However, I did not save replay and did not find replay on replays.wesnoth.org
(it would be 5p - The Wilderlands, Age of Heroes, 2012 January 30 somewhere
before 1:30 AM UTC).




___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #19343] weird glitch with [endlevel] in moveto [event]

[George Koehler]

URL:
  

 Summary: weird glitch with [endlevel] in moveto [event]
 Project: Battle for Wesnoth
Submitted by: kernigh
Submitted on: Sun 29 Jan 2012 03:47:50 AM GMT
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Multiplayer
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.1.10+svn (52780)
Operating System: OpenBSD

___

Details:

If all of the following are true:

0 There is a hex with a moveto [event] that contains an [endlevel] tag.
0 You order a unit to attack from that hex (and trigger the event).
0 You are playing on the multiplayer server.

Then there is a weird glitch. The combat happens during linger mode, after
the scenario ends. The "End Scenario" button is active, but clicking it does
nothing. Also, the Menu misses the options to Save Game or Save Replay, so
there is no way to save. The only way out is to Quit Game.

To reproduce this bug:

0 Install the attached add-on, Test-Moveto-Endlevel.tar.gz.
0 Start Wesnoth.
0 Join official server (not a local game).
0 Start game with scenario "Test moveto [endlevel]".
0 Attack enemy Elvish Sylph from signpost hex.

This bug only happens with the multiplayer server. If you do a local game,
the combat happens before the scenario ends. I wonder if I can use this trick
in singleplayer to kill Konrad in (but still win) the 1st scenario of Heir to
the Throne.



___

File Attachments:


---
Date: Sun 29 Jan 2012 03:47:50 AM GMT  Name: Test-Moveto-Endlevel.tar.gz 
Size: 616B   By: kernigh
simple test scenario to reproduce this bug


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #19312] src/sha1.cpp is not really SHA-1

[George Koehler]

URL:
  

 Summary: src/sha1.cpp is not really SHA-1
 Project: Battle for Wesnoth
Submitted by: kernigh
Submitted on: Fri 20 Jan 2012 10:11:16 PM GMT
Category: Bug
Severity: 2 - Minor
Priority: 5 - Normal
  Item Group:  None of the others
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: v1.9.14+svn (52635)
Operating System: OpenBSD

___

Details:

Since http://r.wesnoth.org/t32494 from December 2010, we know that Wesnoth
makes incorrect SHA-1 hashes.

I found two mistakes in src/sha1.cpp:
* sha_ch() must use ~ bitwise complement, not ! boolean negation.
* Length at end of block requires 8 bytes, not 4 bytes.

I attached a patch (fix-sha1.diff) to fix both problems. I used a small
program (try-sha1.cpp) to test my fix. I can compile it with


g++ `sdl-config --cflags` -o try-sha1 try-sha1.cpp


The correct output from try-sha1.cpp matches the hashes from FIPS 180-1
.


abc
  a9993e364706816aba3e25717850c26c9cd0d89d
abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq
  84983e441c3bd26ebaae4aa1f95129e5e54670f1
million 'a's
  34aa973cd4c4daa4f61eeb2bdbad27316534016f


As far as I know, Wesnoth uses these hashes only to identify cache files; so
fix-sha1.diff should not break network games.



___

File Attachments:


---
Date: Fri 20 Jan 2012 10:11:16 PM GMT  Name: fix-sha1.diff  Size: 814B   By:
kernigh


---
Date: Fri 20 Jan 2012 10:11:16 PM GMT  Name: try-sha1.cpp  Size: 548B   By:
kernigh



___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #19281] problems with loyal units of Hornshark Island

[George Koehler]

URL:
  

 Summary: problems with loyal units of Hornshark Island
 Project: Battle for Wesnoth
Submitted by: kernigh
Submitted on: Fri 13 Jan 2012 05:17:16 PM GMT
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Multiplayer
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: v1.9.14+svn (52569)
Operating System: OpenBSD

___

Details:

About 2p - Hornshark Island, forum user Nobun wrote at
http://r.wesnoth.org/t35870, 'This is so true mainly if you try to load map
with a non-standard era. the player with a non-standard race will have
NO LOYAL UNITS AT ALL,' and, 'Minor aspect: no "loyal icon" on loyal units.'

Anonymissimus wrote, 'This unit-adding code looks for the unit type of the
first recruit in the side's recruit list and thereby tries to "detect" the
faction. This is very fragile and thus easy to break, with eras other than the
default one.'

To reproduce this bug, start Hornshark Island with Age of Heroes. I try this,
and find that AoH Loyalists get extra units, but no other faction gets them.
Hornshark Island might not work with other eras, for like reasons.

Map checks if first recruit is Drake Burner. With AoH Drakes, first recruit
is Drake Arbiter, not Drake Burner. I suggest to search entire list for Drake
Burner.

I attach a svn diff that adds loyal icons to loyal units. This diff does not
solve the problem with Age of Heroes or other eras.



___

File Attachments:


---
Date: Fri 13 Jan 2012 05:17:16 PM GMT  Name: add-loyal-icons.diff  Size: 13kB
  By: kernigh
add loyal icons to loyal units


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #19260] typo in 5p_The_Wilderlands.cfg

[George Koehler]

URL:
  

 Summary: typo in 5p_The_Wilderlands.cfg
 Project: Battle for Wesnoth
Submitted by: kernigh
Submitted on: Tue 10 Jan 2012 02:36:58 AM GMT
Category: Bug
Severity: 2 - Minor
Priority: 5 - Normal
  Item Group: Multiplayer
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: v1.9.14+svn (52556
Operating System: OpenBSD

___

Details:

data/multiplayer/scenarios/5p_The_Wilderlands.cfg contains a typo: in the
[ai] tag of side 5, villages_value=0 should be village_value=0. I attach a svn
diff.

According to http://wiki.wesnoth.org/AiWML, village_value is the correct name
of the key. Also, src/ai only uses "village_value". So villages_value is
wrong.

However, this fix might not affect gameplay. I restarted Wesnoth after the
fix, and started a new game of The Wilderlands, but the ai of side 5 seemed to
want villages, as much as it wanted them before the fix. My best guess is that
the RCA AI ignores village_value.



___

File Attachments:


---
Date: Tue 10 Jan 2012 02:36:58 AM GMT  Name: wilderlands-typo.diff  Size:
436B   By: kernigh
fix typo in 5p_The_Wilderlands.cfg


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #19210] unescaped ampersands in map descriptions

[George Koehler]

URL:
  

 Summary: unescaped ampersands in map descriptions
 Project: Battle for Wesnoth
Submitted by: kernigh
Submitted on: Wed 21 Dec 2011 02:23:06 AM GMT
Category: Bug
Severity: 2 - Minor
Priority: 5 - Normal
  Item Group: Multiplayer
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.9.13+svn (52352)
Operating System: OpenBSD

___

Details:

Errors about "unescaped ampersands" appear in my terminal, when I view the
map descriptions of certain multiplayer maps.

To reproduce this bug:
0 Run wesnoth in a terminal.
0 Create a multiplayer game.
0 Choose one of these maps: "4p - Isar's Cross", "4p - Loris River", or "4p -
Paths of Daggers".
0 Hover mouse over minimap to see the map description. An error will appear
in the terminal.

These errors appear:

20111220 21:18:01 error gui/layout: ttext::set_markup text 'A very small 2
vs. 2 map. Close quarters fighting means the successful rotation of units and
planning of moves is important. Teams set for players 1&4 vs. 2&3 (northeast
vs. southwest). Designed for 75 starting gold, 20 villages.' has unescaped
ampersands '&', escaped them.
20111220 21:18:02 error gui/layout: ttext::set_markup text 'A 25x25 2 vs. 2
map centered around a river with keeps in opposite corners. Designed for
players 1&4 vs. 2&3. There are 28 villages. Recommended setting of 2 gold per
village.' has unescaped ampersands '&', escaped them.
20111220 21:18:03 error gui/layout: ttext::set_markup text 'A 35X27 2 vs. 2
map with 5 separate paths of engagement. Balanced to be played east vs. west
(1&4 vs. 2&3), but works well with any teams or FFA. Recommended setting of 2
gold per village, 28 villages.' has unescaped ampersands '&', escaped them.


This is a minor bug, because the map description still appears, and still has
ampersands in it.

I guess that someone should escape the ampersands, but I have no idea how to
escape them, nor why ampersands need any escaping.




___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #19096] link errors for wesnoth, wesnothd (CMake)

[George Koehler]

URL:
  

 Summary: link errors for wesnoth, wesnothd (CMake)
 Project: Battle for Wesnoth
Submitted by: kernigh
Submitted on: Fri 02 Dec 2011 11:07:59 PM GMT
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group:  None of the others
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: trunk r52150
Operating System: OpenBSD

___

Details:

I get link errors about missing libraries when trying to link wesnoth,
wesnothd. I compiled trunk r52150 and used CMake 2.8.4. My system is OpenBSD
5.0, amd64. My compiler is g++ (GCC) 4.2.1 20070719. My system has these
libraries.

I had to edit src/CMakeLists.txt to solve the link errors. I am attaching a
patch.

The link error for wesnoth was


[ 99%] Building CXX object src/CMakeFiles/wesnoth.dir/network_worker.cpp.o
Linking CXX executable ../wesnoth
/usr/bin/ld: cannot find -lpixman-1
collect2: ld returned 1 exit status
*** Error code 1

Stop in /home/kernigh/park/wesnoth-trunk/build (line 7529 of
src/CMakeFiles/wesnoth.dir/build.make).
*** Error code 1

Stop in /home/kernigh/park/wesnoth-trunk/build (line 267 of
CMakeFiles/Makefile2).
*** Error code 1

Stop in /home/kernigh/park/wesnoth-trunk/build (line 133 of Makefile).


I have this library at /usr/X11R6/lib/libpixman-1.so.22.2 (because OpenBSD
has X11R7 in /usr/X11R6). The error happens because src/CMakeLists.txt links
to ${PANGOCAIRO_LIBRARIES} but forgot to use ${PANGOCAIRO_LIBRARY_DIRS}. All
libraries from pkg_check_modules() have _LIBRARY_DIRS.

The other link error for wesnothd was


[100%] Building CXX object
src/CMakeFiles/wesnothd.dir/loadscreen_empty.cpp.o
Linking CXX executable ../wesnothd
[...skipping some warnings...]
libwesnoth-core.a(gettext.cpp.o)(.text+0x2c): In function `dsngettext(char
const*, char const*, char const*, int)':
: undefined reference to `libintl_bind_textdomain_codeset'
libwesnoth-core.a(gettext.cpp.o)(.text+0x3d): In function `dsngettext(char
const*, char const*, char const*, int)':
: undefined reference to `libintl_dngettext'
libwesnoth-core.a(gettext.cpp.o)(.text+0x95): In function `sngettext(char
const*, char const*, int)':
: undefined reference to `libintl_ngettext'
libwesnoth-core.a(gettext.cpp.o)(.text+0xea): In function `dsgettext(char
const*, char const*)':
[...more undefined references...]


My fix was easy: just move LIBINTL_LIBRARY from game-external-libs to
common-external-libs. My attached patch has both fixes.



___

File Attachments:


---
Date: Fri 02 Dec 2011 11:07:59 PM GMT  Name: link-error.diff  Size: 838B  
By: kernigh
link-error.diff: edit src/CMakeLists.txt to prevent link errors


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #19095] gcc warning in src/pathfind/astarsearch.cpp

[George Koehler]

URL:
  

 Summary: gcc warning in src/pathfind/astarsearch.cpp
 Project: Battle for Wesnoth
Submitted by: kernigh
Submitted on: Fri 02 Dec 2011 10:30:17 PM GMT
Category: Bug
Severity: 2 - Minor
Priority: 5 - Normal
  Item Group:  None of the others
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: trunk r52150
Operating System: OpenBSD

___

Details:

I am attaching a patch to prevent a gcc warning in
src/pathfind/astarsearch.cpp. This is a bug because CMakeLists.txt puts
-Werror in the compiler flags, so every gcc warning becomes an error that
stops the compile.

I compiled trunk r512150 and used CMake 2.8.4. My system is OpenBSD 5.0,
amd64. My compiler is g++ (GCC) 4.2.1 20070719. The error is


[ 82%] Building CXX object
src/CMakeFiles/wesnoth-game.dir/pathfind/astarsearch.cpp.o
cc1plus: warnings being treated as errors
/usr/include/g++/bits/stl_algo.h: In function '_RandomAccessIterator
std::__find(_RandomAccessIterator, _RandomAccessIterator, const _Tp&,
std::random_access_iterator_tag) [with _RandomAccessIterator =
__gnu_cxx::__normal_iterator > >,
_Tp = long unsigned int]':
/usr/include/g++/bits/stl_algo.h:327:   instantiated from '_InputIterator
std::find(_InputIterator, _InputIterator, const _Tp&) [with _InputIterator =
__gnu_cxx::__normal_iterator > >,
_Tp = size_t]'
/home/kernigh/park/wesnoth-trunk/src/pathfind/astarsearch.cpp:223:  
instantiated from here
/usr/include/g++/bits/stl_algo.h:208: warning: comparison between signed and
unsigned integer expressions
/usr/include/g++/bits/stl_algo.h:327:   instantiated from '_InputIterator
std::find(_InputIterator, _InputIterator, const _Tp&) [with _InputIterator =
__gnu_cxx::__normal_iterator > >,
_Tp = size_t]'
/home/kernigh/park/wesnoth-trunk/src/pathfind/astarsearch.cpp:223:  
instantiated from here
/usr/include/g++/bits/stl_algo.h:212: warning: comparison between signed and
unsigned integer expressions
/usr/include/g++/bits/stl_algo.h:216: warning: comparison between signed and
unsigned integer expressions
/usr/include/g++/bits/stl_algo.h:220: warning: comparison between signed and
unsigned integer expressions
/usr/include/g++/bits/stl_algo.h:228: warning: comparison between signed and
unsigned integer expressions
/usr/include/g++/bits/stl_algo.h:232: warning: comparison between signed and
unsigned integer expressions
/usr/include/g++/bits/stl_algo.h:236: warning: comparison between signed and
unsigned integer expressions
*** Error code 1

Stop in /home/kernigh/park/wesnoth-trunk/build (line 583 of
src/CMakeFiles/wesnoth-game.dir/build.make).
*** Error code 1

Stop in /home/kernigh/park/wesnoth-trunk/build (line 342 of
CMakeFiles/Makefile2).
*** Error code 1

Stop in /home/kernigh/park/wesnoth-trunk/build (line 133 of Makefile).


The offender is line 223 of astarsearch.cpp, which is


std::push_heap(pq.begin(), 
std::find(pq.begin(), pq.end(),
index(locs[i])) + 1, node_comp);


In this code, pq is a vector, but index() returns a size_t. The code in
/usr/include/g++/bits/stl_algo.h seems to compare int == size_t. Because int
is signed and size_t is unsigned, there is "comparison between signed and
unsigned integer expressions".

My patch uses static_cast(index(locs[i])) so that the comparisons are
int == int and the compile succeeds.



___

File Attachments:


---
Date: Fri 02 Dec 2011 10:30:17 PM GMT  Name: astar-warning.diff  Size: 619B  
By: kernigh
astar-warning.diff: prevent gcc warning


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #18117] Save games with the Khalifate Qatif-al-nar become corrupted.

[George]

Update of bug #18117 (project wesnoth):

  Status:   Confirmed => Fixed  


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #18123] Khalifate units use get_hit_sound= attribute

[George]

Update of bug #18123 (project wesnoth):

  Status:None => Confirmed  


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #18120] no ALMAs for Khalifate units

[George]

Update of bug #18120 (project wesnoth):

  Status:   Confirmed => Fixed  


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #18117] Save games with the Khalifate Qatif-al-nar become corrupted.

[George]

Update of bug #18117 (project wesnoth):

  Status:None => Confirmed  


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #18117] Save games with the Khalifate Qatif-al-nar become corrupted.

[George]

Update of bug #18117 (project wesnoth):

 Assigned to:None => wintermute 


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #18120] no ALMAs for Khalifate units

[George]

URL:
  

 Summary: no ALMAs for Khalifate units
 Project: Battle for Wesnoth
Submitted by: wintermute
Submitted on: Tue 10 May 2011 06:00:23 PM GMT
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Multiplayer
  Status: Confirmed
 Privacy: Public
 Assigned to: wintermute
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.9.6
Operating System: all

___

Details:

Khalifate units are missing the default ALMA macro, and so aren't getting an
ALMA.

I'll fix this later this week.




___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #18117] Save games with the Khalifate Qatif-al-nar become corrupted.

[George]

Follow-up Comment #1, bug #18117 (project wesnoth):

This was submitted by me.  Assuming the proposed solution works I can take
care of it later this week.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #17462] Allow registered users to bypass banned IP ranges

[George]

URL:
  

 Summary: Allow registered users to bypass banned IP ranges
 Project: Battle for Wesnoth
Submitted by: wintermute
Submitted on: Tue 11 Jan 2011 03:52:46 PM GMT
Category: Feature Request
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Networking
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: all
Operating System: all

___

Details:

Some legitimate users are being blocked by the ranged IP bans put in place to
deal with some of the most troublesome individuals.  The multiplayer
moderators suggest that we allow users to bypass the ban range if they have
registered their account.  This would be a straightforward way to deal with
users that have been blocked unintentionally.




___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #17407] faction_from_recruit=yes confuses the multiplayer lobby

[George Koehler]

URL:
  

 Summary: faction_from_recruit=yes confuses the multiplayer
lobby
 Project: Battle for Wesnoth
Submitted by: kernigh
Submitted on: Wed 29 Dec 2010 01:49:58 AM GMT
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Multiplayer Lobby
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.8.5
Operating System: OpenBSD

___

Details:

A multiplayer scenario that uses faction_from_recruit=yes can confuse the
multiplayer lobby. This bug often happens with '4p - A New Land'. Some players
cannot choose a leader, or receive the wrong choice. There are two parts of
confusion:

* The lobby allows a player to choose a leader from a wrong faction.
* If a player cancels, then the lobby forces the next player (on the same
slot) to have a random leader.

This bug only happens when using a server, and only when the host enables
'Use map settings'.

How to reproduce:

0 Start two wesnoths.
0 With first wesnoth, 'Host Networked Game'.
0 With second wesnoth, 'Connect to Server'. The server is 'localhost'.
0 With first wesnoth, create game of '4p - A New Land', select 'Default' era,
enable 'Use map settings'. See that the lobby locks the faction to
'Loyalists'. Now the host can change the leader of any side, but can only
choose Loyalist leaders.
0 With second wesnoth, join the game. See that the lobby offers the leaders
from all factions.
0 With second wesnoth, choose a Loyalist leader.
0 Notice that the player on slot 2 has the chosen leader.
0 With second wesnoth, cancel.
0 With first wesnoth, see that the lobby locked the leader of side 2 to '-'.
Now the host cannot change the leader of side 2.
0 With second wesnoth, join the game again, and choose a Loyalist leader.
0 See that the lobby never displays the chosen leader of side 2.
0 With first wesnoth, set slots 3 and 4 to empty, then start the game.
0 With second wesnoth, see that side 2 receives a random leader, who might be
different from the chosen leader.

Can also reproduce this bug with any other multiplayer scenario that uses
faction_from_recruit=yes. I am attaching WML_Faction_Test.zip, a copy of
Isar's Cross where all sides have recruit="Goblin Spearman,Naga Fighter" and
faction_from_recruit=yes. The faction is Northerners (not Loyalists).

I run wesnoth 1.8.5, compiled by me using cmake.



___

File Attachments:


---
Date: Wed 29 Dec 2010 01:49:58 AM GMT  Name: WML_Faction_Test.zip  Size: 8kB 
 By: kernigh
a copy of Isar's Cross using faction_from_recruit=yes, to reproduce this bug


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #17406] ANL mages yield wrong amount of research

[George Koehler]

URL:
  

 Summary: ANL mages yield wrong amount of research
 Project: Battle for Wesnoth
Submitted by: kernigh
Submitted on: Tue 28 Dec 2010 11:02:22 PM GMT
Category: Bug
Severity: 2 - Minor
Priority: 5 - Normal
  Item Group: Multiplayer
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.8.5
Operating System: OpenBSD 4.8

___

Details:

With the scenario "4p - A New Land", the units who study at universities can
yield the wrong amount of research.

* Expected behavior: At side turn, each such unit should yield an amount
equal to its level. For example, a Mage should yield 1 point of research; a
Red Mage or White Mage should yield 2 points.
* Actual behavior: Each unit uses the amount of the first unit in the array.

The bug is a typo in definition of macro AUTO_STUDYING, in file
data/multiplayer/scenarios/ANL_utils/ANL_auto_working.cfg. The code now says
'$researchers.level', it needs to say '$researchers[$i].level' (the '[$i]' is
missing).

The bug happened to me when I leveled my first Mage to a White Mage. I run
wesnoth 1.8.5, compiled by me using cmake.

Please add the missing '[$i]' to the code.




___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #17152] cmake: wesnothd needs to link with libintl

[George Koehler]

Follow-up Comment #1, bug #17152 (project wesnoth):

I found that wesnoth already has a cmake/FindLibintl.cmake module, but
*never* uses it!

I am attaching a patch to the CMakeLists.txt and src/CMakeLists.txt to use
the module, and link wesnoth and wesnothd to libintl. This fixes the bug for
me.

(file #11452)
___

Additional Item Attachment:

File name: link-to-libintl.diff   Size:1 KB


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #17151] FRIBIDI_CHARSET_UTF8, not FRIBIDI_CHAR_SET_UTF8

[George Koehler]

Follow-up Comment #2, bug #17151 (project wesnoth):

silene wrote:
> I don't know why they decided to change the way it is written on openbsd.

I checked more carefully. Fribidi 0.10.4 has FRIBIDI_CHARSET_UTF8, but
Fribidi 0.10.5 renames it to FRIBIDI_CHAR_SET_UTF8. OpenBSD still packages
Fribidi 0.10.4.

Wesnoth already has code to handle Fribidi 0.10.4. I only need to define
OLD_FRIBIDI, then Wesnoth will work with Fribidi 0.10.4. The problem is that
the CMake build system fails to define OLD_FRIBIDI.

First, I am retracting my old patch (file #11389) because it is wrong.
CHAR_SET is correct for fribidi >= 0.10.5.

Second, I am attaching a new patch that fixes the CMake build system so that
it can define OLD_FRIBIDI. This patch edits cmake/FindFriBiDi.cmake.

(file #11451)
___

Additional Item Attachment:

File name: old-fribidi.diff   Size:1 KB


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #17152] cmake: wesnothd needs to link with libintl

[George Koehler]

URL:
  

 Summary: cmake: wesnothd needs to link with libintl
 Project: Battle for Wesnoth
Submitted by: kernigh
Submitted on: Friday 11/26/2010 at 19:14
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group:  None of the others
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.8.5
Operating System: OpenBSD 4.8

___

Details:

OpenBSD + CMake fails to compile Wesnoth 1.8.5.

One of the reasons is that the link of wesnothd fails with a bunch of linker
errors about missing libintl_* symbols. I think that CMakeLists.txt forgot to
link wesnothd to libintl.

There is no problem finding /usr/local/include/libintl.h (which has lines
like '# define gettext libintl_gettext'); the only problem is to link with
the library.

The link of wesnoth succeeds by accident, because CMakeLists.txt links
wesnoth to everything in `pkg-config pangocairo --libs` which luckily has
libintl. The link of wesnothd fails.

My system is OpenBSD 4.8 and has the packages of cmake-2.8.2p0 and
gettext-0.18.1; libintl is part of the gettext package. The correct way to
link to libintl seems to be '-L/usr/local/lib -lintl'.

To work around this problem, I edited src/CMakeList.txt and added
'-L/usr/local/lib -lintl' to server-external-libs. This is good enough for
OpenBSD, but might be wrong for other systems.

CMake has a FindLibIntl module (so cmake --help-modules tells me). A better
fix for this problem might be to pass LibIntl to FIND_PACKAGES and, if
LIBINTL_FOUND, link both wesnoth and wesnothd to LIBINTL_LIBRARIES. I have
not tried this.




___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #17151] FRIBIDI_CHARSET_UTF8, not FRIBIDI_CHAR_SET_UTF8

[George Koehler]

URL:
  

 Summary: FRIBIDI_CHARSET_UTF8, not FRIBIDI_CHAR_SET_UTF8
 Project: Battle for Wesnoth
Submitted by: kernigh
Submitted on: Friday 11/26/2010 at 18:47
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: User Interface
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.8.5
Operating System: OpenBSD 4.8

___

Details:

OpenBSD + CMake fails to compile Wesnoth 1.8.5.

One of the reasons seems to be a typo in src/font.cpp. Wesnoth tries to use
FRIBIDI_CHAR_SET_UTF8, but the fribidi header files only have
FRIBIDI_CHARSET_UTF8. There is no underscore '_' between 'CHAR' and 'SET'.

My system is OpenBSD 4.8 and has the packages of cmake-2.8.2p0 and
fribidi-0.10.4p0. I used cmake to build Wesnoth.  FRIBIDI_CHARSET_UTF8 is
from an enum in /usr/local/include/fribidi/fribidi_char_sets.h, while
FRIBIDI_CHAR_SET_UTF8 is nowhere.

To reproduce this problem, install Fribidi and use cmake to build Wesnoth.
The compiler will complain about undefined FRIBIDI_CHAR_SET_UTF8.

I am attaching a diff that changes FRIBIDI_CHAR_SET_UTF8 to
FRIBIDI_CHARSET_UTF8. This works for me, though I only use English language,
so I only see left-to-right text.



___

File Attachments:


---
Date: Friday 11/26/2010 at 18:47  Name: charset.diff  Size: 763B   By:
kernigh



___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #17150] gui::menu::nitems() conflicts with nitems() macro of OpenBSD sys/param.h

[George Koehler]

URL:
  

 Summary: gui::menu::nitems() conflicts with nitems() macro
of OpenBSD sys/param.h
 Project: Battle for Wesnoth
Submitted by: kernigh
Submitted on: Friday 11/26/2010 at 18:31
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: User Interface
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.8.5
Operating System: OpenBSD 4.8

___

Details:

OpenBSD + CMake fails to compile Wesnoth 1.8.5.

One of the reasons is that g++ errors about 'sizeof' wherever something
mentions the gui::menu::nitems() function defined at src/widgets/menu.hpp.
There seems to be a conflict with this nitems() macro at
/usr/include/sys/param.h:


#define nitems(_a)  (sizeof((_a)) / sizeof((_a)[0]))


I am not sure how Wesnoth pulls sys/param.h, but I am sure that some nitems()
macro causes the problem. The compiler error typically happens at
src/widgets/menu.hpp:189, where Wesnoth defines nitems(), but the error can
also happen at files that call nitems().

To work around this problem, and allow Wesnoth to compile, I added an '#undef
nitems' at two places: src/widgets/menu.hpp:189 and
src/multiplayer_create.cpp:435. (The second file seems to pull sys/param.h
_after_ src/widgets/menu.hpp, so it needs the '#undef nitems' at a different
place.) The attached diff shows where I added '#undef nitems'.

One fix might be to rename the nitems() function to some other name. Another
fix might be to find exactly where Wesnoth pulls sys/param.h, and add '#undef
nitems' to that place, with a comment that the line is a workaround for
OpenBSD. I suspect that Wesnoth includes some header file (perhaps a boost
header?) which includes the DNS resolver ( or ). With
OpenBSD, both netdb.h and resolv.h include sys/param.h.

My system is OpenBSD 4.8 (including g++ 4.2.1) and has these packages:
* boost-1.42.0p2
* sdl-1.2.13p14
* sdl-net-1.2.7p1




___

File Attachments:


---
Date: Friday 11/26/2010 at 18:31  Name: undef-nitems.diff  Size: 709B   By:
kernigh
where I added '#undef nitems' to Wesnoth 1.8.5


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #16606] tip of the day italics not working

[George]

URL:
  

 Summary: tip of the day italics not working
 Project: Battle for Wesnoth
Submitted by: wintermute
Submitted on: Tuesday 08/31/2010 at 12:31
Category: Bug
Severity: 2 - Minor
Priority: 5 - Normal
  Item Group: Graphics
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.9.0+svn (46104)
Operating System: all

___

Details:

after starting Wesnoth the italics for "The Wesnoth Tactical Guide" are not
working.  See attached screenshot, lower right corner.



___

File Attachments:


---
Date: Tuesday 08/31/2010 at 12:31  Name: italic_bug.jpg  Size: 380kB   By:
wintermute



___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #16119] change add-on server menu buttons to be more descriptive of exact function.

[George]

URL:
  <http://gna.org/bugs/?16119>

 Summary: change add-on server menu buttons to be more
descriptive of exact function.
 Project: Battle for Wesnoth
Submitted by: wintermute
Submitted on: Sunday 06/06/2010 at 01:20
Category: Feature Request
Severity: 1 - Wish
Priority: 5 - Normal
  Item Group: User Interface
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.8.2
Operating System: all

___

Details:

Currently, when browsing for add-ons the two buttons available are "OK",
which downloads an add-on, and "cancel", which exits back to the main menu.

This doesn't seem intuitive to me.  I think "OK" should be changed to
something more descriptive, perhaps "Add" or "Install".  Likewise, "cancel"
might cause users to think that their install will be cancelled.  To me,
cancel means exit without saving changes, which is not really what the button
does.  I suggest changing it to "exit" or "quit" or "finished".

George (Wintermute/happygrue)




___

Reply to this item at:

  <http://gna.org/bugs/?16119>

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #14300] in game chat gets blurry on small maps, refresh command cleans it up.

[George]

Follow-up Comment #3, bug #14300 (project wesnoth):

I noticed that the letter "m" is still being chopped off in 1.8.1.  The font
in general looks a bit squished, not as nice as, say, the font when bringing
up the chatlog.  Attached is a screenshot of an "m" being cutoff.

(file #9103)
___

Additional Item Attachment:

File name: font_bug.jpg   Size:345 KB


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #15940] graphics glitch: cave wall terrain covers great tree

[George]

URL:
  

 Summary: graphics glitch: cave wall terrain covers great
tree
 Project: Battle for Wesnoth
Submitted by: wintermute
Submitted on: Friday 04/23/2010 at 20:06
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Graphics
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.9.0+svn (42170)
Operating System: all

___

Details:

The cave wall at 16,12 of the new multiplayer map 2p Elensefar Courtyard
covers up most the great tree located at 16,13.

This doesn't happen in the same version of the map on 1.8.0.




___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #15826] persistent memory of lobby tab state

[George]

URL:
  

 Summary: persistent memory of lobby tab state
 Project: Battle for Wesnoth
Submitted by: wintermute
Submitted on: Thursday 04/08/2010 at 20:08
Category: Feature Request
Severity: 1 - Wish
Priority: 3 - Low
  Item Group: Multiplayer Lobby
  Status: None
 Privacy: Public
 Assigned to: ilor
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.8.0
Operating System: all

___

Details:

lobby tabs in 1.8.0 currently reset to default behavior after joining/leaving
a game or logging on/off.

Ideal behavior would be for the tabs to remember the last settings, so that
players who prefer to see all players (selected games, lobby, and other
games), for example, can do so without having to reset the tabs each time
they return to the lobby from a game.




___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #15656] OOS errors in LoW from differing starting gold for host vs. other player.

[George]

URL:
  

 Summary: OOS errors in LoW from differing starting gold for
host vs. other player.
 Project: Battle for Wesnoth
Submitted by: wintermute
Submitted on: Saturday 03/20/2010 at 04:16
Category: Bug
Severity: 4 - Important
Priority: 5 - Normal
  Item Group: Multiplayer
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.7.15
Operating System: Vista

___

Details:

jb and I were testing LoW on 1.7.15 and ran into some OOS problems just after
starting the second scenario.  As host, it seemed to me that I had 188 gold
and he had 196 gold at the start of the scenario.  To him it seemed that I
had 88 and he had 96.  Neither of us got a gold bonus from the first scenario
(jb was -4 and I was also negative though I am not sure how much).

The minimum starting gold for the next scenario is 100, so both of us should
have started with 100 gold, but neither of us did and we started with
different amounts.  Attached is a save from later on from the host (me). 
Unfortunately, jb doesn't have his saves.  I'll try to reproduce it an get
the OOS saves also.





___

File Attachments:


---
Date: Saturday 03/20/2010 at 04:16  Name: Bug_-_Hostile_mountains_Turn_15.gz 
Size: 77kB   By: wintermute



___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #14300] in game chat gets blurry on small maps, refresh command cleans it up.

[George]

Follow-up Comment #2, bug #14300 (project wesnoth):

I just tried everything I can think of to reproduce the problem, and I got
*one* character worth of fudged up text (whereas nearly every line of text
was garbled before) in 1.7.9.  I guess that indicates that there may still be
some issue.  I'll keep trying and see if I can narrow it down.

The only thing that I could reproduce was that after scrolling around a bit
if your sentence ends in "m"  as in:  mm

then the last m looks a bit chopped off.  The text also donesn't look as
'clean' as in 1.6.x.  The font defiantly doesn't look anywhere near as nice
and crisp on my machine as it does in the stable branch, but that may be
unrelated ... or it may be related.

Here is a replay from 1.7.9.  "D" also looks a bit chopped.

(file #7461)
___

Additional Item Attachment:

File name: 2p_-_Sablestone_Delta_replay_-_bug.gz Size:9 KB


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #14440] Game unplayable if you try to load a new game while in the middle of combat

[George Ghali]

URL:
  

 Summary: Game unplayable if you try to load a new game while
in the middle of combat
 Project: Battle for Wesnoth
Submitted by: gghali
Submitted on: Monday 10/05/2009 at 02:10
Category: Bug
Severity: 4 - Important
Priority: 5 - Normal
  Item Group: Campaign
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.7.6
Operating System: Windows

___

Details:

If you are in the middle of an attack (or defense, I think) and you hit
CTRL-O to load a saved campaign, the game will come up but you will be unable
to control any units.




___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #14300] in game chat gets blurry on small maps, refresh command cleans it up.

[George]

URL:
  

 Summary: in game chat gets blurry on small maps, refresh
command cleans it up.
 Project: Battle for Wesnoth
Submitted by: wintermute
Submitted on: Saturday 09/12/2009 at 20:02
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Multiplayer
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.7.5
Operating System: Vista 32

___

Details:

chatting in game looks like the attached screenshot on maps like sablestone
delta that are narrow.  Confirmed by my opponent and an observer (not sure
what OS).

the refresh command cleans it up, but after we continue to chat things get
blurry again.

The observer indicated that he has seen this on 1.6 as well, but I have not.

Further testing indicates that Wesnoth changes my resolution to 1680x1000
every turn? which then causes the bug.  When I change the resolution back to
1680x1050 in-game (which is my system resolution), everything clears up.

Very strange. 

P.S.  I am running in windowed mode.

P.P.S.  an observer running Mac OSX ver 10.6 in windowed and fullscreen mode
sees all text clearly without problems with resolution 1055x768.  Perhaps
this is a widescreen issue?



___

File Attachments:


---
Date: Saturday 09/12/2009 at 20:02  Name: font_bug.jpg  Size: 324kB   By:
wintermute



___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #13275] Turn Bell Not Functioning

[George]

Follow-up Comment #3, bug #13275 (project wesnoth):

I am not positive what initially causes the problem, but it seems to be
changing some sound/music settings.  Perhaps some combination of turning them
off and leaving/restarting Wesnoth - so far I can't reproduce it reliably. 
However, once produced, it seems that turning on special effects sounds and
turn bell sounds will fix the problem, for as long as special effects sounds
remain on.  Turning them off will also render the turn bell mute, even if the
turn bell is on.  AFAICT those two are the only relevant settings.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #13247] "The wilderlands" misplaced in the multiplayer maps list

[George]

Update of bug #13247 (project wesnoth):

  Status:None => Fixed  

___

Follow-up Comment #2:

fixed in r34065.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #13247] "The wilderlands" misplaced in the multiplayer maps list

[George]

Update of bug #13247 (project wesnoth):

 Assigned to:None => wintermute 


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #13228] Checkbox to disallow/reduce frequency of 1v1 mirror matches

[George]

URL:
  

 Summary: Checkbox to disallow/reduce frequency of 1v1 mirror
matches
 Project: Battle for Wesnoth
Submitted by: wintermute
Submitted on: Friday 03/20/2009 at 20:04
Category: Feature Request
Severity: 1 - Wish
Priority: 5 - Normal
  Item Group: Multiplayer
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.7.x
Operating System: Win XP

___

Details:

There is consensus on #wesnoth-mp and elsewhere that 1v1 mirror matches (I.E.
Elves vs Elves) are not as interesting as other matchups.  This is, IMHO not
an issue for 2v2 games, but it is for 1v1 games on the multiplayer server. 
Many times, a 1v1 game is aborted as soon as the players realize they are
fighting a mirror match.  

I propose a check-box that the host could set as an option while creating the
game, that would reduce the frequency of mirror matches.  I think that this
would be the best option for players, so that they can still have the
occasional mirror, but it is more of an interesting rarity rather than a
common occurrence.

I would suggest reducing the probability of getting a mirror match in a 1v1
game from 1/6 to 1/20 or perhaps 1/25.

Other factors and my suggestions:
* This should only be applicable to 1v1 games, I think trying to do it for
larger games is not desirable.
* I think this option should be checked by default.
* An alternative would be to have a slider that you could drag to a desired
frequency of mirror matches - this would be better, but perhaps more work.
* Another alternative would be to just have a box to disallow mirror matches,
if this were much easier.  I would rather have such a box than nothing at all.




___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #13209] AI in multiplayer stopped doing anything

[George]

Follow-up Comment #1, bug #13209 (project wesnoth):

will test more later, here are the files from playing a few turns

(file #5445, file #5446, file #5447)
___

Additional Item Attachment:

File name: BUG_AI_side_4_not_moving.gzSize:33 KB
File name: stdout.txt Size:3 KB
File name: stderr.txt Size:101 KB


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #13166] AI is shuffling instead of finishing off a lonely enemy leader

[George]

Follow-up Comment #4, bug #13166 (project wesnoth):

base map used to produce the bug, for testing purposes.

(file #5434)
___

Additional Item Attachment:

File name: AI_Bug_Map Size:7 KB


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #13166] AI is shuffling instead of finishing off a lonely enemy leader

[George]

Follow-up Comment #1, bug #13166 (project wesnoth):

I think that this same behavior is very noticeable in 'survival' type
scenarios, where you can watch the AI spawn and then sit there, rather than
attacking.  It only seems to attack if the player moves into range and/or
attacks.  Otherwise it just shuffles around.

Attached is a save of an example of this in 1.5.13.

Watch the replay and cringe at how broken the AI looks.  :(

(file #5415, file #5416)
___

Additional Item Attachment:

File name: REPLAY_Temples_of_the_nagas_BROKEN_AI.gz Size:33 KB
File name: SAVE_BROKEN_AI_Temples_of_the_nagas_Turn_10.gz Size:105 KB


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #9317] Units avaible for recruit have doubled / tripled

[George]

Update of bug #9317 (project wesnoth):

  Status:None => Duplicate  

___

Follow-up Comment #1:

This bug seems to be a duplicate of Bug #9291.  I am still not sure what
causes it.  

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #8923] Deoran's HP incorrectly listed as 60/38, an impossible value

[George Koehler]

Follow-up Comment #5, bug #8923 (project wesnoth):

I described  this
same bug on the Wesnoth forums. At 14 February 2007 I wrote:

_Deoran becomes a "Dismounted Commander" in this scenario. His stats are
exactly like before, except that he has less max HP (60/38 instead of 60/60).
The second turn, Deoran loses 22 HP to become 38/38. Even worse, if I save and
restore the game, Deoran's stats change! He loses a movement point, but his HP
becomes 38/60, and Etheliel or Minister Hylas can heal him over the next
several turns. I wondered if I was cheating, whether I had one Deoran or the
other Deoran._

I was playing Wesnoth 1.2.0 above some operating system (probably OpenBSD
4.0).

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #9356] Does victory matter in the last South Guard scenario?

[George]

Update of bug #9356 (project wesnoth):

Category: Bug => Feature Request
  Status:None => In Progress


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #9356] Does victory matter in the last South Guard scenario?

[George]

Follow-up Comment #1, bug #9356 (project wesnoth):

Disclaimer: I am not the original author of this campaign but I am the person
working on it now.

That ending is working as designed.  There is some ambiguity from the
player's point of view about if that was a successful ending or not, but the
bottom line is that the only way the scenario ends is either moving to the
destination, or dying along the way.  This is something that may change in
later versions.  If you have any suggestions for making the ending clearer or
proposing an alternate ending, you can post them here:

http://www.wesnoth.org/forum/viewtopic.php?t=16309&highlight=making+south+guard

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #8914] AMLA option had no visible effect

[George]

Update of bug #8914 (project wesnoth):

  Status:None => Works For Me   


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #8923] Deoran's HP incorrectly listed as 60/38, an impossible value

[George]

Follow-up Comment #3, bug #8923 (project wesnoth):

I was also unable to produce this one.  When I loaded the save, Deoran's hp
was 60/60.

This one I have seen in game though, so I know that it is still a problem. 
I'm not quite sure what the problem is, but I'll look into it.  Thanks for
the bug reports, and keep them coming!

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #8914] AMLA option had no visible effect

[George]

Follow-up Comment #2, bug #8914 (project wesnoth):

I was unable to reproduce the error.  I also note that Gerrick already had 4
strikes, so had you taken this option before?

Bascially, I killed the bone shooter, and then chose the extra strike ALMA,
and then I had 5 strikes.  Odd.  Perhaps you could try it again yourself?

Also:  I tested your save on 1.3.2, since I don't have 1.3.1 installed.  It's
possible that this has somehow already been fixed.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #9202] CtD when an elf triggers an event that kills all elves

[George]

URL:
  

 Summary: CtD when an elf triggers an event that kills all
elves
 Project: Battle for Wesnoth
Submitted by: wintermute
Submitted on: Friday 05/25/2007 at 17:52
Category: Bug
Severity: 5 - Blocker
Priority: 5 - Normal
  Item Group: WML
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.3.2+svn
Operating System: Win XP

___

Details:

I have a "sighted" event in scenario 5 (Choice in the Fog) of The South Guard
that kills all elves off durring the event.  If an elf is the unit that
triggers the event, the game crashes.  Any other type of unit seems to be
fine.

Attached is a savegame.  To reproduce the bug:  move any of the frendly units
south of 40,20 onto 40,20 (they will sight the enemy leader and trigger the
event).  If you click through the dialouge and select the first option (side
with the bandits), then the game will crash if your moving unit was an elf. 
The game will be fine for the other units.

Also attached is a textfile with the problem event.  I commented the killing
line, and also where the game actually crashes.

Thanks,
Wintermute (happygrue on IRC)



___

File Attachments:


---
Date: Friday 05/25/2007 at 17:52  Name: BUG_-_savegame  Size: 495kB   By:
wintermute


---
Date: Friday 05/25/2007 at 17:52  Name: event.txt  Size: 3kB   By: wintermute



___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #9064] Segfault at scenario 5_Choice_In_The_Fog

[George]

Follow-up Comment #4, bug #9064 (project wesnoth):

I have a savegame (from 1.3.2) where there is no dialogue at all from the
Outlaw.  That is, there is never any choice!

Also attached is a replay of the whole scenario showing that no choice
dialogue occurs.

(file #2328)
___

Additional Item Attachment:

File name: choice.zip Size:86 KB


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs