[Wesnoth-bugs] [task #8013] Data Export #69 (bugs)

[Celtic Minstrel]

URL:
  <http://gna.org/task/?8013>

 Summary: Data Export #69 (bugs)
 Project: Battle for Wesnoth
Submitted by: celticminstrel
Submitted on: Mon 01 May 2017 09:46:09 PM EDT
Category: None
 Should Start On: Mon 01 May 2017 12:00:00 AM EDT
   Should be Finished on: Tue 02 May 2017 12:00:00 AM EDT
Priority: 5 - Normal
  Status: None
 Privacy: Private
Percent Complete: 0%
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
  Effort: 0.00

___

Details:

A new export job has been registered.
 
This task has been created to keep the project informed. However, only Celtic
Minstrel, that created the job, can remove the job itself. 

= Job URL =

Once the job will be done, it will be available at:

  <https://gna.org/export/wesnoth/celticminstrel/69.xml>


= Job Removal  =

Closing this task will not remove the job. To remove the job, Celtic Minstrel
must go at: 

  <https://gna.org/bugs/export.php?group=wesnoth>


= Job Details =

The SQL query will be:
SELECT bug_id  FROM bugs  WHERE group_id=\'1242\'  AND status_id IN (\'3\') 


(Note: We are aware this information is not tremendously user-friendly. This
will be improved in future Savane releases)





___

Reply to this item at:

  <http://gna.org/task/?8013>

___
  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] [task #8014] Data Export #70 (bugs)

[Celtic Minstrel]

URL:
  <http://gna.org/task/?8014>

 Summary: Data Export #70 (bugs)
 Project: Battle for Wesnoth
Submitted by: celticminstrel
Submitted on: Mon 01 May 2017 09:46:16 PM EDT
Category: None
 Should Start On: Mon 01 May 2017 12:00:00 AM EDT
   Should be Finished on: Tue 02 May 2017 12:00:00 AM EDT
Priority: 5 - Normal
  Status: None
 Privacy: Private
Percent Complete: 0%
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
  Effort: 0.00

___

Details:

A new export job has been registered.
 
This task has been created to keep the project informed. However, only Celtic
Minstrel, that created the job, can remove the job itself. 

= Job URL =

Once the job will be done, it will be available at:

  <https://gna.org/export/wesnoth/celticminstrel/70.xml>


= Job Removal  =

Closing this task will not remove the job. To remove the job, Celtic Minstrel
must go at: 

  <https://gna.org/bugs/export.php?group=wesnoth>


= Job Details =

The SQL query will be:
SELECT bug_id  FROM bugs  WHERE group_id=\'1242\'  AND status_id IN (\'1\') 


(Note: We are aware this information is not tremendously user-friendly. This
will be improved in future Savane releases)





___

Reply to this item at:

  <http://gna.org/task/?8014>

___
  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 #25670] App Crash when canceling or Esc a Lua dialog

[Celtic Minstrel]

Update of bug #25670 (project wesnoth):

  Status:   Confirmed => Fixed  

___

Follow-up Comment #1:

Fixed in master.

___

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 #25619] using invalid unit types in debug mode

[Celtic Minstrel]

Update of bug #25619 (project wesnoth):

Category: Feature Request => 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 #25639] [remove_object] heals units with amla

[Celtic Minstrel]

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

I doubt this is a bug with [remove_object]. If the situation is as you
suggest, it should also affect objects with an expiry, such as the "stun"
weapon special. I don't know of any good way to fix 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 #25625] Translation mark _ in text key breaks event with [animate_unit]

[Celtic Minstrel]

Update of bug #25625 (project wesnoth):

  Status:None => Ready For Test 
 Assigned to:None => celticminstrel 


___

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 #18679] [ai] blocks are ignored

[Celtic Minstrel]

Update of bug #18679 (project wesnoth):

  Status:   Confirmed => Invalid

___

Follow-up Comment #4:

The problem here is that only one of each aspect can be specified in the
side's AI - in other words, you can have only one [avoid]. If you want to
avoid multiple areas, you need to merge them into a single [avoid] tag. It
doesn't matter how many [ai] tags you use - with a few minor exceptions,
multiple [ai] tags are equivalent to stuffing everything into a single [ai]
tag.

That's not to say that multiple [avoid] tags are useless, mind you. Each
[avoid] tag stacks on a new facet, so if you want the AI to avoid one area,
but halfway through the scenario they stop that and start to avoid a different
area, you could use two [avoid] tags. The second tag would come into effect
immediately; you could then use a [modify_ai] halfway through the scenario to
remove it (with a path of aspect[avoid].facet[0] if I recall correctly), at
which point the first [avoid] tag would be in effect.

In any case, this is not a bug but rather an misunderstanding of how the AI
system works, so I'm marking this invalid.

___

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 #25390] [for] tag ignores start/end attributes

[Celtic Minstrel]

Update of bug #25390 (project wesnoth):

  Status:None => Invalid


___

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 #25558] lua error with micro ai

[Celtic Minstrel]

Update of bug #25558 (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 #25555] Use of [place_shroud] & [remove_shroud] throw errors

[Celtic Minstrel]

Update of bug #2 (project wesnoth):

  Status: In Progress => 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 #25555] Use of [place_shroud] & [remove_shroud] throw errors

[Celtic Minstrel]

Update of bug #2 (project wesnoth):

  Status:   Fixed => 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 #25555] Use of [place_shroud] & [remove_shroud] throw errors

[Celtic Minstrel]

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

What exactly goes wrong? Shroud is updated incorrectly? Updated but doesn't
take effect until next redraw? Something else?

Is it the shroud removal or placement that doesn't work? (Your line numbers
seem to be different from master so I can't be sure which you're referring
to.)

___

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 #25558] lua error with micro ai

[Celtic Minstrel]

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

gfgtdf pointed out something I missed in the previous commit, so try this
one:

https://github.com/wesnoth/wesnoth/commit/6fe8e65502cc319e61166a3f63b76d5964e947b7

___

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 #25558] lua error with micro ai

[Celtic Minstrel]

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

This isn't exactly a fix, but it'll help determine whether I'm on the right
track with respect to the cause...

Try adding [] to the end of the path strings on lines 99 and 157 of
data/ai/micro_ais/micro_ai_helper.lua.

(My build isn't working currently so I can't test it myself.)

___

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 #25558] lua error with micro ai

[Celtic Minstrel]

Update of bug #25558 (project wesnoth):

 Assigned to:None => celticminstrel 


___

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 #25558] lua error with micro ai

[Celtic Minstrel]

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

Is this fixed by the following commit?

https://github.com/wesnoth/wesnoth/commit/6de1c9441f25b9c96a524e2c342e9f82483dd1c2

___

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 #25561] stderr message about unescaped

[Celtic Minstrel]

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

Ah. I'd say it's fine to disallow markup in the author, but I'm sure there
would be people who disagree, so I dunno...

___

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 #25561] stderr message about unescaped

[Celtic Minstrel]

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

I disagree on that commit; an exceptional situation should be warning or
error, not log.

As for the actual issue... it makes sense to allow marked-up text in the
add-on or scenario description, so IMO the real problem here is the choice of
markup syntax. We should probably drop Pango markup and implement a friendlier
custom markup syntax. (Or maybe use Markdown or something.) It would then be
rendered to Pango markup which is passed on to Pango.

___

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 #25013] weapon naming: with or without space?

[Celtic Minstrel]

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

The "longsword" as a type of weapon in its own right is a construct of games
such as Dungeons and Dragons. There is no historical "longsword". Thus, I
would say there's no real difference between "longsword" and "long sword"
except maybe that the latter could also include even larger swords (like a
greatsword), which doesn't seem like a useful thing here.

___

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 #23841] a [make_tag] tag to create custom wml tags.

[Celtic Minstrel]

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

Normally when you overwrite an existing tag, it's to extend it; the original
implementation is saved first, and then called from the new implementation.
It's not a problem to be able to overwrite an existing tag, but it's not good
to be able to _accidentally_ overwrite an existing tag.

___

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 #23752] gui2 listboxes header not working correctly

[Celtic Minstrel]

Follow-up Comment #6, bug #23752 (project wesnoth):

When you say no mainline listboxes need horizontal scrollbars, I sure hope
that means on 800x600 resolution...

___

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 #25390] [for] tag ignores start/end attributes

[Celtic Minstrel]

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

The array and start/end/step attributes are intended to be mutually exclusive,
as documented on the wiki. In effect, the array attribute is a shorthand.

If you simply remove array=test from that example, it should work.

___

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 #25337] allow custom widget definitions in umc

[Celtic Minstrel]

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

You shouldn't be adding definitions before the dialog shows. You should do
that early, in a load event or similar.

Plus, if you try to add the same definition twice, obviously it won't actually
be added twice. So even if you DID add your definitions just before the dialog
shows, they wouldn't accumulate. Unless of course you somehow use a different
definition ID each time.

___

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 #25337] allow custom widget definitions in umc

[Celtic Minstrel]

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

I too prefer the second method, but rather than an unregister function, I
think it would make more sense to automatically unregister any custom
definitions when the Lua kernel is destroyed. (Which means that any
definitions registered in the Application Lua Kernel are available everywhere,
but that shouldn't be a huge issue since no-one uses the Application Lua
Kernel, plus it's not really meant to be used for GUI stuff.)

Basically, the register_widget_definition would do two things: 1) Register the
definition in the GUI settings, and 2) Add the definition to a list of ones to
unregister, stored in the Lua kernel class (probably lua_kernel_base). Then
the class's destructor would call an appropriate function to remove the
definitions from the GUI settings.

Naturally, this approach would mean you do not want to allow existing
definitions to be overridden, so register_widget_definition would need to
check that the definition doesn't exist before doing anything.

___

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 #25224] add translation friendly string.format function

[Celtic Minstrel]

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

If it's in the lua_kernel_base you can simply press the tilde key (more
specificall, ` ) at the title screen. If it's in the game_lua_kernel you would
need to start a game before pressing that key.

___

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 #25224] add translation friendly string.format function

[Celtic Minstrel]

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

1. It makes most sense to me to use the WML variable substitution syntax (as
vgettext does), not the % syntax noted by gfgtdf.

2. You might want to think of this as having two parts - first, a
"wesnoth.format" or similar function that handles the formatting; second, a
way to encode the format parameters into the t_string so that the format
doesn't occur until the translation is resolved. 

The second part would probably be a feature of the same format function
though, I guess; as gfgtdf said, if the format string is a t_string, it could
output a t_string instead of performing the format immediately. Then t_string
would perform the format once the translation is resolved.

___

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 #25077] memleak in wesnoth help

[Celtic Minstrel]

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

This appears to be the same as #25083.

___

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 #25083] leaks in AI vs AI match

[Celtic Minstrel]

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

These are all unit attacks being allocated, but in all cases they're stored in
a boost::intrusive_ptr, so I don't see how they're being leaked. My guess
would be that either there's something wrong with the refcount or the messages
are spurious. I can't see anything wrong with the refcounting myself
(src/units/attack_type.hpp, lines 129-137).

___

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 #12098] allow [message] to take multiple 'speakers'

[Celtic Minstrel]

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

data/gui/dialogs/wml_message.cfg

That file contains three separate [window] tags and three separate
[window_definition] tags. The issue would be (almost certainly) in the
[window] tag that has two portraits.

___

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 #12098] allow [message] to take multiple 'speakers'

[Celtic Minstrel]

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

I'm not sure exactly of the cause here, but it seems like something in the
markup - that is, the GUI2 markup defining the window. I'll try to remember to
look into it later (or get Vultraz to do so, as he's better at GUI2 layout),
unless you manage to figure it out on your own.

___

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 #25041] Unit types always exist in Lua (segmentation fault)

[Celtic Minstrel]

Update of bug #25041 (project wesnoth):

 Open/Closed:Open => Closed 

___

Follow-up Comment #3:

https://github.com/wesnoth/wesnoth/commit/91bd6ab6d09e28048cb12018fea2f6f9c323762b

___

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 #25041] Unit types always exist in Lua (segmentation fault)

[Celtic Minstrel]

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

Looks like this is simple to fix. I've already done so locally, just need to
double-check to make sure it actually 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 #24930] image_pos="right" does not display correctly

[Celtic Minstrel]

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

I disagree about second_portrait making it irrelevant - it's only irrelevant
when second_portrait is actually specified.

___

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 #12098] allow [message] to take multiple 'speakers'

[Celtic Minstrel]

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

I'm not sure. I have no immediate plans to do so, at least.

___

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 #22820] GUI2 menus and context menus

[Celtic Minstrel]

Update of bug #22820 (project wesnoth):

 Release:  1.13.0 => 1.13.6 

___

Follow-up Comment #2:

gfgtdf created the menu backend (intended for "comboboxes", which are really
not comboboxes), and I went and linked it into the game and contextual menus,
so GUI1 menus are now dead and gone.

___

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 #11811] Support for gettext plurals in WML

[Celtic Minstrel]

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

A general solution to this would be quite hard, I think. The first proposal
isn't flexible enough as stated, so that's out (although something similar to
it could be implemented more easily). The second proposal requires changes to
the WML parser, which I'm not presently confident in touching, and furthermore
runs into the problem that variables are not known at parse time.

However, I have gone ahead and implemented gettext plurals support into the
Lua API. The syntax is essentially the same as proposal 2, except for
differences stemming from it being Lua rather than WML. Furthermore, I have
used this new feature to fix the specific string that GunChleoc identified as
problematic in the [objectives] tag, though wmlxgettext has not yet been
updated to understand it. (I haven't fixed the HTTT case since a WML solution
is not yet implemented.)

The new API could in principle be used to implement a WML-based way to perform
plural lookup, perhaps like this:


# Assign a plural string to the result variable
[set_variable]
  variable=result
  [plural]
domain=wesnoth
# Not marked translatable, because otherwise wmlxgettext would interpret
them as singular translatable strings
singular="a thing"
plural="several things"
count=$num_things
  [/plural]
[/variable]


However, this is a poor solution in my opinion, as it would be difficult to
make wmlxgettext recognize them (although perhaps it could be made viable with
a standard macro), and it also requires temporary variables for working with
plural strings (though maybe other tags could also support [plural] subtags).

___

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 #24930] image_pos="right" does not display correctly

[Celtic Minstrel]

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

The image_pos=right behaviour should be exactly the same as appending ~RIGHT()
to the image path though, so I don't think this is new with the image_pos key.

___

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 #24931] Allow specifying both a left image and a right image on [message]

[Celtic Minstrel]

Update of bug #24931 (project wesnoth):

  Status:None => Duplicate  

___

Follow-up Comment #2:

(Also, this is a duplicate of https://gna.org/bugs/?12098 )

___

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 #12098] allow [message] to take multiple 'speakers'

[Celtic Minstrel]

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

I have added support for this to the Lua API (the wesnoth.show_message_dialog
function), though it has not been wired into the [message] tag at this time.

To show a message with two portraits, the portrait and mirror keys in the
first argument to show_message_dialog define the left portrait, while the
second_portrait and second_mirror keys define the right portrait. With two
portraits, the left_side key is ignored.

___

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 #24931] Allow specifying both a left image and a right image on [message]

[Celtic Minstrel]

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

I have added support for this to the Lua API (the wesnoth.show_message_dialog
function), though it has not been wired into the [message] tag at this time.

To show a message with two portraits, the portrait and mirror keys in the
first argument to show_message_dialog define the left portrait, while the
second_portrait and second_mirror keys define the right portrait. With two
portraits, the left_side key is ignored.


___

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 #24933] hotkeys list cannot be sorted by hotkey

[Celtic Minstrel]

Update of bug #24933 (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 #16107] [modify_side][ai]ai_algorithm= doesn't work

[Celtic Minstrel]

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

Also note that [modify_side]switch_ai can already be used to achieve this
behaviour, though it needs the path to the AI definition file (under
data/ai/ais/ for default AI and data/ai/dev/ for idle AI) rather than the AI
ID and is thus not as neat.

___

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 #20052] Initiialization for Lua AI new Syntax

[Celtic Minstrel]

Update of bug #20052 (project wesnoth):

  Status:None => Invalid
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

You can do initialization work at toplevel in the body of the file that is
defined by "location", so an init function is not needed. Basically, any code
at toplevel will be run when the AI is initialized at the start of that side's
first turn.

___

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 #21294] undocumented "backwards compatability" code silently strips out custom ais

[Celtic Minstrel]

Update of bug #21294 (project wesnoth):

  Status:None => Fixed  
 Open/Closed:Open => Closed 

___

Follow-up Comment #4:

The backwards compatibility code has actually been removed (though some of its
functionality - converting simple aspects to the full form - is still present
in a different form) and the version key is no longer used. Furthermore, the
old AI interface class has also been removed, so this issue is basically very
obsolete.

___

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 #22777] add a "pixel art friendly" scaling algorithm for zooming in on sprites

[Celtic Minstrel]

Update of bug #22777 (project wesnoth):

  Status:None => Fixed  
 Open/Closed:Open => Closed 

___

Follow-up Comment #2:

As of 1.13.5, there are a number of scaling options available, so I believe
this is no longer a problem. In particular, the xBRZ algorithm is now
available.

___

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 #22855] floating point emulation unit test failing, with g++ 4.9

[Celtic Minstrel]

Update of bug #22855 (project wesnoth):

  Status:None => Wont Fix   
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

Since we're not currently supporting any platforms that need floating-point
emulation, this has been removed in 1.13.5+dev.

___

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 #24712] Units with select events cannot be selected

[Celtic Minstrel]

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

That invites a potential fix, assuming there's some way in Lua to determine
whether the speaker is currently selected. Does anyone know of something like
that?

___

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 #24864] Campaign use of random maps causes crash

[Celtic Minstrel]

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

Ah, I see, so that's the thing I quickly fixed afterwards?

___

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 #24864] Campaign use of random maps causes crash

[Celtic Minstrel]

Update of bug #24864 (project wesnoth):

 Assigned to:None => celticminstrel 


___

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 #24864] Campaign use of random maps causes crash

[Celtic Minstrel]

Update of bug #24864 (project wesnoth):

 Assigned to:  celticminstrel => None   


___

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 #24864] Campaign use of random maps causes crash

[Celtic Minstrel]

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

gfgtdf: The function in which that fix applied was removed by the PR, so that
makes sense. Are you saying the bug resurfaced, or just making a wild
observation?

___

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 #16107] [modify_side][ai]ai_algorithm= doesn't work

[Celtic Minstrel]

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

(The preceding comment applies to current master.)

___

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 #16107] [modify_side][ai]ai_algorithm= doesn't work

[Celtic Minstrel]

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

There have been significant changes in this area recently, though I believe it
has not fixed this bug yet. I'm posting mainly because the test code given
below would need to be tweaked a little - to switch back to the default AI,
you would need ai_algorithm=ai_default_rca rather than default_ai.

___

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 #24709] Assertion Failure when selecting a UMC random map

[Celtic Minstrel]

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

I think I roughly understand the cause of this issue - it looks like a null
dereference in the default_map_generator_job::generate_name function. PR 661
deletes this function and no longer holds possibly-null pointers to name
generators, so I think it should fix the issue.

___

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 #24672] Leadership ability does not work when applied as an object in [modify_unit]

[Celtic Minstrel]

Update of bug #24672 (project wesnoth):

  Status:None => Fixed  
 Summary: Leadership ability does not work when applied as an
object => Leadership ability does not work when applied as an object in
[modify_unit]

___

Follow-up Comment #6:

I'll mark it as fixed, then.

___

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 #24672] Leadership ability does not work when applied as an object

[Celtic Minstrel]

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

I don't think this is possible to fix in the leadership definition since it's
apparently caused by premature variable substitution. So you should be able to
get it to work by adding "delayed_variable_substitution=yes" in your [object].
I guess that will need to be mentioned somewhere as well, possibly in release
notes.

Does this affect any mainline campaigns or MP scenarios, by the way?

___

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 #24186] Using a different keyboard layout causes letter based hotkeys not to work.

[Celtic Minstrel]

Follow-up Comment #12, bug #24186 (project wesnoth):

...wait a second. I just marked it as closed, but should it actually be left
open until a release happens?

___

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 #24186] Using a different keyboard layout causes letter based hotkeys not to work.

[Celtic Minstrel]

Update of bug #24186 (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 #24550] std::placeholders might clash with boost::bind::placeholders

[Celtic Minstrel]

Update of bug #24550 (project wesnoth):

  Status:None => Fixed  
 Assigned to:None => celticminstrel 
 Open/Closed:Open => Closed 

___

Follow-up Comment #9:

The fix was to just use Boost placeholders; std::bind provides a way to define
arbitrary types as placeholders.

___

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 #24527] AOI S2 broke by a recent change

[Celtic Minstrel]

Update of bug #24527 (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 #12098] allow [message] to take multiple 'speakers'

[Celtic Minstrel]

Update of bug #12098 (project wesnoth):

 Assigned to:mordante => celticminstrel 


___

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 #24527] AOI S2 broke by a recent change

[Celtic Minstrel]

Update of bug #24527 (project wesnoth):

  Status:None => Fixed  
 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 #24529] Mainline MP Random Maps show no starting postions

[Celtic Minstrel]

Update of bug #24529 (project wesnoth):

  Item Group:  None of the others => 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 #24517] Load map dialog should have shortcut to game data

[Celtic Minstrel]

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

This is even worse on Mac, where the game data directory is hidden inside the
App package, so I definitely agree here.

___

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 #18679] [ai] blocks are ignored

[Celtic Minstrel]

Update of bug #18679 (project wesnoth):

 Assigned to:crab => celticminstrel 


___

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 #24304] [item]s missing during replay

[Celtic Minstrel]

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

Just now I reproduced it on master with the following steps:

1. Start the Son of the Black Eye campaign. This creates a turn 1 auto-save,
or you could make an explicit save. Note the pair of big flags near the orc
camp.
2. Go to Load Game, select the save. Open it. The flags are still there.
3. Go to Load Game, select the save. This time check Show Replay at the
bottom, then open it. The flags are gone.


I also tried it on 1.12.4 just now, with the same results.

___

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 #24304] [item]s missing during replay

[Celtic Minstrel]

URL:
  

 Summary: [item]s missing during replay
 Project: Battle for Wesnoth
Submitted by: celticminstrel
Submitted on: Tue 12 Jan 2016 05:39:57 AM UTC
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Replays
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.2+dev
Operating System: All

___

Details:

When a saved game is loaded as a replay (either by loading a replay save or by
checking "Show Replay" when loading), scenery items created via [item] are
missing.

This affects my build compiled from master. I don't know if it affects 1.12 or
any earlier builds, but I imagine it likely does.




___

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 #24288] WML formulas evaluated too soon

[Celtic Minstrel]

Update of bug #24288 (project wesnoth):

  Status:None => Fixed  
 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 #24288] WML formulas evaluated too soon

[Celtic Minstrel]

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

I think commit c2ac138 (in pull request 578) should fix 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 #24200] Dark Forecast maps not aligned

[Celtic Minstrel]

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

This might be caused by a change in how [terrain_mask] works (commit 1b22a97).
If so, I believe adding "border=no" to the [terrain_mask] should fix the
issue.

___

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 #23917] const [event]s

[Celtic Minstrel]

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

I'm a little uncertain about this idea. The intent of saving space in the
savefile is good, but somehow the idea of an event that can't be deleted
doesn't quite sit right with me.


However, should this be implemented, I think "permanent" would be a better
name for the key than "const". Events are already "const" as far as I know -
there's no way to alter the WML of an event (and the use of [insert_tag]
doesn't count because it's the WML prior to substitution that I'm thinking
of). Thus, "permanent" better gets across the idea that it stays around
forever (or, until the end of the scenario at least).

___

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 #23918] UI Graphics In OS X El Capitan

[Celtic Minstrel]

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

I removed that class because I was getting a runtime warning about multiple
definitions of the class, but it looks like for some reason the other
definition doesn't exist for you.

The class is still defined in SDLmain.m but only enabled for SDL1.2, so if you
edit that file you should be able to get it to compile.

___

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 #23490] Side specific variables

[Celtic Minstrel]

Follow-up Comment #6, bug #23490 (project wesnoth):

Oh, right. Somehow I didn't think of that. It's possible without using the
save_id directly as a variable name, though. I imagine it'd be a little slower
because lookup requires iterating over an array, but it would be possible.

As for unit variables, there's a __cfg attribute. You should be able to use
the helper.* functions on that to get an array you can work with... the only
thing I'm not sure of is if you can modify unit array variables in that way. I
won't deny it could use work.

___

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 #23490] Side specific variables

[Celtic Minstrel]

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

I can see your point about save_id maybe containing spaces and other special
characters, but you can easily ensure that it doesn't (because you control
what the save_id is), so I don't see that being a significant issue.

The advantage of automatic removal, on the other hand, does make sense.

Regarding Lua API though, I'd suggest mirroring the API for unit variables,
which means using a metatable with __index and __newindex methods rather than
having functions.

___

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 #23490] Side specific variables

[Celtic Minstrel]

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

My suggestion is to store the inventory in the unit variables of the side
leader. Unless you need inventory for sides without a 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 #23490] Side specific variables

[Celtic Minstrel]

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

(Another idea: If the issue is that side numbers change, reference something
that won't change - the save_id. Probably not possible at the moment, would
need save_id added to SSF or something.)

___

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 #23896] [show_if] no longer works

[Celtic Minstrel]

Update of bug #23896 (project wesnoth):

 Assigned to:None => celticminstrel 


___

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 #23896] [show_if] no longer works

[Celtic Minstrel]

Update of bug #23896 (project wesnoth):

  Status:None => Fixed  

___

Follow-up Comment #1:

Looks like it was a typo in the new [message] implementation (it was checking
[message][show_if] instead of the [option][show_if]). Seems to work 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 #23896] [show_if] no longer works

[Celtic Minstrel]

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

(Where "now" means commit d5eea2abbf3d )

___

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