Elvish_Hunter's Lua thread

[melinath]

I think that Crendgrim is right that the current layout is confusing. I can't say for sure whether (his?) is better without seeing it in action. Part of the reason that I want to try porting this to ModularLua is that it has some utilities for making dialog creation easier, which would make testing things easier. (Potentially.) I'll let you know how if I make any progress on that.

[Max]

This looks a bit cluttered up and you'll search long for the desired information.
My suggestion would be to keep the labels in the top column and use the bottom column for the values:

Code: Select all

 X   Y   Type           Name         ID                Can recruit  Valid  Petrified
 14  10  Elvish Archer  Urandeladir  Elvish Archer-17  no           map    no

why not try to mimic how this information is shown in the unit panel? people or already used to that (apart from x/y coordinates)...

[Anonymissimus]

What else could one want than the unit being killed when setting hitpoints to 0 ?

I frequently want to set the hitpoints to 0 to ensure a kill when one unit attacks another.

Actually this use case is valid (and abuses a corner case in the engine). There are some conditions which let the defender always die and the hit animation be played if the defender was at 0hps and the defender dies no matter what the chance to be hit was. Amazing to see thunderers hit with 100% precision. So it's useful if one needs a second_unit for the events

Would it be all right with you if I port this into ModularLua?

IMHO a bad idea since it introduces redundant code.

[Elvish_Hunter]

I think that Crendgrim is right that the current layout is confusing. I can't say for sure whether (his?) is better without seeing it in action.

Done in the latest SVN commit.

I also added [get_movement_type], that I found on the forums, and that was made by silene some time ago , but that's another story.

why not try to mimic how this information is shown in the unit panel? people or already used to that (apart from x/y coordinates)...

If you're referring to the panel shown on the right side of the screen while playing, that panel doesn't show ID, Can recruit and Valid fields. Also, I have some formatting limitations, because Label widget doesn't yet support Pango markup - unless it was recently introduced; in this case, I'll do an svn update.

Actually this use case is valid (and abuses a corner case in the engine). There are some conditions which let the defender always die and the hit animation be played if the defender was at 0hps and the defender dies no matter what the chance to be hit was. Amazing to see thunderers hit with 100% precision. So it's useful if one needs a second_unit for the events

So, should I add back the Fire events checkbutton, perhaps making it true by default? And it's even better to see Dragonguards hitting an Elvish Ranger on forest with 100% chance to kill...

[Exasperation]

The label widget does support Pango, but not in a way that's currently accessible from Lua (and since Pango support defaults to off, that means it's currently stuck off). I have a patch pending for it.

Not sure what's going on with the warning. Does it still show up if the unit is at full health to begin with?

Is there a reason that petrified shows up both in the top area as a label and below as a checkbox?

Finally, you can use image path functions (http://wiki.wesnoth.org/ImagePathFunctionWML) in image widgets. So you can do something like

Code: Select all

wesnoth.set_dialog_value ( string.format("%s~TC(%d,magenta)", lua_dialog_unit.__cfg.image, lua_dialog_unit.side), "unit_image" )

and have the unit's image show up properly team-colored. If you felt like it you could even put a couple of conditionals in and use ~GS() to turn the image black&white if the unit is petrified or ~CS() to make it green if poisoned.

[melinath]

In terms of the look of things: Right now, it mostly looks strange to me to have such a long line of things across the top and then have a narrow two-column layout down the center of the window. Perhaps explore a four-column layout? Try putting the unit picture and stats that are currently across the top down the left side instead.

IMHO a bad idea since it introduces redundant code.

Don't worry. I'm not planning on copying it, but rather porting it. This will probably involve a refactor of the code at the time of porting. Especially since this is being implemented as a menu item, whereas I'd prefer to use it as a function. (i.e. debug.unit(x, y))

[Elvish_Hunter]

Not sure what's going on with the warning. Does it still show up if the unit is at full health to begin with?

It shows every time that a special slider label is shown. In this tag, that means every time that the unit has (or the slider is set to) full HP, 0 HP or full XP. If you have any other question, please ask.

Is there a reason that petrified shows up both in the top area as a label and below as a checkbox?

From http://wiki.wesnoth.org/LuaWML:Units :

# petrified, canrecruit: booleans (read only)
# role, facing: strings (read/write)
# status: proxy associative table (read only, read/write fields) (Version 1.9 and later only)

It will be removed, but why we have two petrified (one as direct field, and one inside the status table) in the unit proxy table?

Finally, you can use image path functions (http://wiki.wesnoth.org/ImagePathFunctionWML) in image widgets.

The funny thing is that I already used them in past; I simply didn't yet thought of implementing it. It will be done.

In terms of the look of things: Right now, it mostly looks strange to me to have such a long line of things across the top and then have a narrow two-column layout down the center of the window. Perhaps explore a four-column layout? Try putting the unit picture and stats that are currently across the top down the left side instead.

Partially done (I need to make a nested grid for the unit image; when it's finished, I'll commit it):

Looks better, now?
Another question: in Python/Tkinter/ttk, when I want to disable a widget inside a dialog, I can set its state as disabled, either while creating it, or using its configure method. Examples:

Code: Select all

disabled_button=Button(self.parent,text="This button is disabled",width=25,state=DISABLED)
disabled_button.configure(text="This button is disabled",state=DISABLED)

and (after using pack, grid or place) the button is grayed out. There is any way to do it in Lua, using wesnoth.set_dialog_callback? I wasn't able to find anything.

[melinath]

Yeah, I think that looks better.

In terms of widget state: I would love to know this, as well. I tried to figure it out a while back, but though states clearly exist, I couldn't find any way to change between them with Lua.

[Anonymissimus]

why we have two petrified (one as direct field, and one inside the status table) in the unit proxy table?

The redundancy is also in the engine (unit::incapacitated() to unit::get_state(STATE_PETRIFIED)), apparently silene got confused by that. Well, removing it would break backwards compatibility now...

but though states clearly exist, I couldn't find any way to change between them with Lua.

Can you describe an ingame situation where a gui2 item gets greyed out ? (That'd be the starting point for a lua function setting this.)
IIRC shadowmaster was looking for this too upon writing the *allow_end_turn tags.

EDIT
The preferences don't count afaik since it's not converted to gui2.

[Exasperation]

Selectively quoting myself from IRC:

< Exasperation> I've been thinking more about widgets+Lua
< Exasperation> anyway, I've been thinking about what other important capabilities might be missing from the Lua interface to GUI2
< Exasperation> The big thing I noticed that was missing is the ability to assign callbacks to buttons. You (apparently) can make buttons that close the window and return a value, or that don't do anything, but there doesn't yet appear to be a way to attach a function to the button from Lua. I think I see how you would do it, though.
< Exasperation> the minor thing I noticed is that you don't seem to have access to the enable/disable widget commands from Lua

I already submitted a patch for the button callback issue, I could probably put together a patch for enable/disable in the next couple of days (I got distracted by other stuff - such as being able to enable markup in labels - before getting to that part).

I was going to say something about petrified, but Anonymissimus got to it while I was writing this.

[Anonymissimus]

Elvish_Hunter: Can you please remove those log messages. There should only be something in case of an error.
You could use the [wml_message] tag for this in such way that messages important for debugging are omitted if wesnoth was started with --log-debug=wml. But this should only be used for things that are really important and might cause a bug, you get spammed in the long run otherwise.

[Elvish_Hunter]

Yeah, I think that looks better.

Finished, and committed.

gui2 item gets greyed out ?

How can I understand if a dialog is GUI or GUI2?

Can you please remove those log messages.

Done.
I also noticed that you made this commit:

WLP: fixed out-of-bounds if current values exceed maximums (can be if e.g. set by the debug mode console)

This made me think: "And if the unit has negative experience?" So, I made another commit:

Used math.min to avoid out-of-bounds error if unit has negative HP or XP (it may happen by use of debug console, or when fighting against units with negative levels)

Apparently, this will be useful only for HP and HP, since setting moves and attacks left to negative values using the debug console, and then inspecting the unit, results in such values being set to 0 (I tested).

[Anonymissimus]

How can I understand if a dialog is GUI or GUI2?

1. You ask mordante.
2. You inspect the code path/call stack of a dialog of interest to see whether it calls stuff from the namespace gui::... or gui2::...
3. You launch the MSVC debugger and follow the code path/call stack to see the same.
EDIT
4. You search in data/gui/ whether the dialog in question is defined there since afaik gui1 dialogs are hardcoded. But since you don't know what and where to look for you prefer 2).

For the lua dialogs for example it's easy to know where to start (lua.cpp) and to find it (intf_show_dialog etc) and to see that they're all gui2.

[8680]

This made me think: "And if the unit has negative experience?" So, I made another commit:

Used math.min to avoid out-of-bounds error if unit has negative HP or XP (it may happen by use of debug console, or when fighting against units with negative levels)

Shouldn't you have used math.max()?

[Elvish_Hunter]

Because I needed to set the minimum value of such sliders.

Code: Select all

> return math.max(-5,0)
0
> return math.min(-5,0)
-5

Using math.max won't solve the issue at all, while math.min does.