[Wesnoth-bugs] [bug #24959] gui2::ttext renders worse than font::ttext

[Charles Dang]

URL:
  

 Summary: gui2::ttext renders worse than font::ttext
 Project: Battle for Wesnoth
Submitted by: vultraz
Submitted on: Wed 10 Aug 2016 11:06:36 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: All
Operating System: Windows 10

___

Details:

gui2::tcontrol widgets like tlabel seems to call font::ttext directly, while
gui2 canvas operations call gui2::ttext (which then calls font::ttext). The
output of the latter seems to be worse than the output of the former.

The latter also doesn't seem to handle newline characters correctly.

Needs investigation.




___

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 #24952] Unstored unit is slowed when recalled

[Daniel]

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

mostlikeley the Delfador's Memoirs wml code doesnt heal those units properly
when storing them.

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


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

[Wesnoth-bugs] [bug #24952] Unstored unit is slowed when recalled

[Inky]

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

Sorry, I wasn't clear enough - I mean it only happens when the player is
separated from their recall list for a while due to story reasons. In
Delfador's Memoir's the player's recalls are taken away after Scenario 8 and
given back in Scenario 18.

I attached the Scenario 18 starting save - the Paladin on the recall list was
slowed at the end of Scenario 8 and will still be slowed when recalled.

(file #28241)
___

Additional Item Attachment:

File name: DM-The_Portal_of_Doom.gz   Size:23 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 #23897] Neither 1.12.x nor 1.13.x unit tests build with boost 1.59.0

[Jon Ciesla]

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

Right, the RPM byte compiler assumes Python2.  When I change it to Python3 it
discovers other scripts whose syntax is invalid for Python3.  Is the project
currently a mix of both 2 and 3?

___

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 #24955] When add-ons are downloaded, the dialogs do not disappear properly

[Hunter Hintz]

URL:
  

 Summary: When add-ons are downloaded, the dialogs do not
disappear properly
 Project: Battle for Wesnoth
Submitted by: the_squished_elf
Submitted on: Wed 10 Aug 2016 01:30:50 PM UTC
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: 13.5 English
Operating System: MacOS X 10.11.6

___

Details:

When an add-on is downloaded, all "successfully downloaded" dialog boxes don't
go away until the add-on manager is completely closed.
Also some of the border of the add-on browser may remain as well.

The effect continued after shutting down Wesnoth, restarting the computer,
etc.

Images are provided, the second has been edited to highlight the browser
border remaining.




___

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 #24954] Eastern Invasion: Outlaws won't appear in 05_Northern Outpost

[Hunter Hintz]

URL:
  

 Summary: Eastern Invasion: Outlaws won't appear in
05_Northern Outpost
 Project: Battle for Wesnoth
Submitted by: the_squished_elf
Submitted on: Wed 10 Aug 2016 12:48:01 PM UTC
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Campaign
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 13.5 English
Operating System: MacOS X 10.11.6

___

Details:

When a village is entered and the Outlaws are in the village, the dialog box
proclaiming such appears but the Outlaws themselves don't appear. This is
followed by a message in the message log announcing a Lua error:

lua/helper.lua:383: helper.rand expects a string or table as parameter , got
number instead
stack traceback:
   [C]: in function 'assert'
   lua/helper.lua:383: in function 'rand'
   campaigns/Eastern_Invasion/lua/bandits.lua:41: in function 'bandits_found'
   campaigns/Eastern_Invasion/lua/bandits.lua:85: in function 'cmd'
   lua/wml-utils.lua:137: in function 'hnadle_event_commands'
   lua/wml-flow.lua:6: in function 

The message doesn't change, just keeps repeating each time you capture bandit
villages.

Naturally this prevents regular progress through the campaign since you need
to kill their leader but since it doesn't exist, debug is necessary.

Save file included, just move a unit to a village. If there aren't bandits in
that village, you can end turn and move units to other unoccupied villages, or
enter debug and use unit moves=[x] to keep visiting villages quickly, it
doesn't matter.



___

File Attachments:


---
Date: Wed 10 Aug 2016 12:48:01 PM UTC  Name: EI-Northern_Outpost copy.zip 
Size: 754B   By: the_squished_elf



___

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 #23897] Neither 1.12.x nor 1.13.x unit tests build with boost 1.59.0

[Ignacio R. Morelle]

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

data/tools/wesnoth/campaignserver_client.py is supposed to be run with Python
3 since version 1.13.2, and the log excerpt you posted makes it seem like
something in the pipeline is assuming Python 2.

Perhaps adding a /usr/bin/python3 shebang to it would solve the issue? Note
that normally it wouldn't need one since it's not intended to be run on its
own, but rather it's imported by data/tools/wesnoth_addon_manager which does
have the correct shebang.

___

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 #24952] Unstored unit is slowed when recalled

[Wedge009]

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

I don't know all the details of how units are carried over throughout the
scenarios but this doesn't sound right to me (the distinction between units
recalled frequently vs seldom).

Do you have a save file on hand to demonstrate this, please?

___

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 #24952] Unstored unit is slowed when recalled

[Inky]

URL:
  

 Summary: Unstored unit is slowed when recalled
 Project: Battle for Wesnoth
Submitted by: inky
Submitted on: Wed 10 Aug 2016 06:20:53 AM UTC
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Campaign
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.5
Operating System: windows 10

___

Details:

In Delfador's Memoirs, I had a unit which was slowed at the end of Scenario 8,
then when I recalled it later in S18 it was still slowed.
This seems to only happen with the recalls which leave for a while and then
come back in later scenarios.




___

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