[Wesnoth-bugs] [bug #25338] Quick fighter with 5 instead of 6 MP

[Frank]

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

[Additional info]: The quick fighter (focus unit on the recall popup) is
"Anebrilmar", but the fighter shown on the left side of the recall popup is
"Vebrieril". Therefore I guess that the recall popup can get out of synch
(left side != focus unit) after dismissing a unit. 

Normally I dismiss all level 1 units with zero XP, unless they are loyal, OR
recalling is cheaper than recruiting, OR they acquired a special object like a
storm trident, OR they are quick. IOW, presumably I just dismissed
"Vebrieril", and the left side was not updated.

___

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 #25338] Quick fighter with 5 instead of 6 MP

[Frank]

URL:
  

 Summary: Quick fighter with 5 instead of 6 MP
 Project: Battle for Wesnoth
Submitted by: dunnoob
Submitted on: Thu 24 Nov 2016 05:30:46 AM UTC
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.12.6
Operating System: Windows 7sp1

___

Details:

Scenario LoW Bounty Hunters 1st turn: One of several QUICK fighters available
for recall has only 5 instead of 6 move points. The attached ZIP contains
STDERR.TXT (nothing special, but not empty), the initial LoW save, the auto
save for turn 1, a manual save within turn 1 after recruiting + moving the
dwarves, and a screenshot of elves available for recall with the focus on the
buggy fighter. I haven't checked when this "unQUICK" fighter was added in the
previous scenario.



___

File Attachments:


---
Date: Thu 24 Nov 2016 05:30:46 AM UTC  Name: unQUICK_fighter.zip  Size: 476kB 
 By: dunnoob



___

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

[Daniel]

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

> I think it would make more sense to automatically unregister any custom
definitions when the Lua kernel is destroyed. ..

Hmm yes i had the same idea, but i wonder whether that's enough ? If you have
code that adds a new definition everytme before our dialog shows those now
unused defeintions might accuuilate in ram during gameplay


> you do not want to allow existing definitions to be overridden

I agree here aswell.

___

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

[Daniel]

URL:
  

 Summary: allow custom widget definitions in umc
 Project: Battle for Wesnoth
Submitted by: gfgtdf
Submitted on: Mi 23 Nov 2016 15:15:51 UTC
Category: Feature Request
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.13
Operating System:  

___

Details:

It would be nice to allow custom widget definitions for existant widgets.
There are multiple approaches on how a syntrax could look:

1) Allow to inline the efinition directly into the widget:

...
T.button
{
  label = "Sometext"
  T.definition {
.. button_definition wml
  } 

}
...


2) add a new function wesnoth.register_widget_defnition("buttion", "my_id", {
.. button_definition wml .. })

Both approaches have differnet (dis)advantages:
(1) would require more parsing and coudl be a little slower in general when
the definition is used many times. (2) could leave these defintions
permanently loadd so that we likele need to add a second function
wesnoth.unregister_widget_defnition, sepcially when.


I'm currnetly more in favour of the second options since it allows reusing the
widgets, for exampel one resource addon can provide mode widgert defintions
that are then used by a second addon.




___

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