Dixie's Thread

[silene]

The question might look dumb, but it's essentially jsut to make sure: I put it in a preload event just like that, no need to put it in the usual lua tag?

You put it in a [lua] tag, and you also make sure the event is first_time_only=no.

[Dixie]

Ok, so let's move on to something else. Everything being dandy so far with Internet Meme Era and things stalling a little since we're in "test, appreciate and design" mode, I went and put a little more work on Paintball Era.

I am currently working on a base scenario: the era will be much more enjoyable if played with the maps/scenarios that suits it. I just ran into a bit of a problem with Victory/Defeat.

So AFAIK, I need to trigger victory/defeat with a [end_level] in an [event]. However, Paintball Era is designed to be primarily a competitive thing, and this [end_level] tag doesn't contain a "side_for" string or anything vaguely related to it. So how can I end the scenario without everybody getting either a victory or a defeat, but rather the winners getting a victory and the losers, a defeat?

If there really is no solution for competitive MP scenarios with costum mission objectives, I guess a solution could be just sending an ordinary message saying either "Victory" or "Defeat", maybe along with the game stats or something, but it doesn't feel as professionnal... And it will prevent players from post-game chatting among themselves.

Thanks for any insight!

EDIT:
Alternatively, if any of you any competitive MP scenarios I could go look at for reference, it'd be appreciated

[Dixie]

Sorry for the double post, ugh. I hope enough hours have passed for it to be acceptable.

I still haven't found the answer to my previous question, although I am looking into some stuff at the moment and might successfully work myself through it.

So as you know, I have resumed work on Paintball Era. And maybe you remember my big issue, at the time, was filter a variables stored in a unit within the [filter_self] of a [hides] ability. No, no need to celebrate: the problem is still standing. At the time, I said I'd wait and test it when I had an about complete scenario, which I now have and allows me to actually test the whole thing in context. So I tried stuff.

First, I tried formula, which I hadn't at the time. Needless to say, it didn't work. Here's how my filter looked:

Code: Select all

[filter_self]
	formula="variables.stealth < moves"
	formula="variables.flag = 0"
[/filter_self]

I also tried with "this_unit.variables.stealth" etc., which didn't work, and with both cases but adding "$" before them, which outright crashed the app. I thought it might be simpler than Lua since I actually understood what I was doing, but it doesn't seem to be working either.

So I previously had this Lua code:

Code: Select all

    [event]
      name=preload
      first_time_only=no

      [lua]
         code=<<
         helper = wesnoth.require("lua/helper.lua")
         function filter_unit (unit)
         local unit = unit.__cfg
         local variables = helper.get_child(unit, "variables")
         return variables and variables.flag == 0 and unit.moves >= variables.stealth
         end
         >>
      [/lua]
   [/event]

And I call it like this:

Code: Select all

[filter_self]
	lua_function="stealth_check"
[/filter_self]

Since I wanted to look into lua_function anyway, I tested it out - adding the event containing the lua function with [side][unit] works. You may kill that unit afterwards.
When re-adding a unit with the ability, the function is called again. It is called very frequently btw, whenever a unit is selected, starts or ends a move, ...

I'm still not sure I understand that bit. I'll try to be clear: I tried placing the preload event at the very top of my [era], of the leader's [unit_type] and of my [multiplayer]. None worked: in the [era] case, the unit never hid, and in the other two, it always did. There is only one kind of leader and every side gets it, so I figured it was a good [unit_type] for a preload event, even though it is not added in the [side] per se. Should I put the preload event in the [unit_type], but create an extra unit of that type in side 1's [side], which I kill quickly at the start, or should I rather define a [unit] in [side] and put my preload event there? Am I missing something else?

Also, if I wanted to define two lua functions, could I define them in the same preload event?

---

On another note, I ran into the weird problem of the macros SET_LABEL and SET_LABEL_PERSISTENT not actually setting their labels, but doing it the long, traditionnal way (exactly like it is defined in the macro) works fine. Weird, I guess I'll just do it the long way and use like 10 lines instead of 1 for each label.

[Anonymissimus]

The defined function is named
filter_unit
but what you're calling is
stealth_check
how do you expect it to work ?

Also, if I wanted to define two lua functions, could I define them in the same preload event?

yes

[Dixie]

Arg, I'm sorry, I made an error in that last post. I started writing it before I had actually tested the code, and copy/pasted a previous version from the thread, which contained the mistake. Here is the code I actually used for my tests:

Code: Select all

    [event]
      name=preload
      first_time_only=no

      [lua]
         code=<<
         helper = wesnoth.require("lua/helper.lua")
         function stealth_check (unit)
         local unit = unit.__cfg
         local variables = helper.get_child(unit, "variables")
         return variables and variables.flag == 0 and unit.moves >= variables.stealth
         end
         >>
      [/lua]
   [/event]

Thanks a lot! Going to bed now

[Dixie]

Ok, so I'm still looking to fix my problem with Paintball Era's Stealth ability. A quick recap: I want to filter and compare variables stored into a unit container (like, "this_unit.variables.stealth less_than_equal_to=this_unit.moves") inside a [hides] ability, so the unit is hidden or not depending on those factors. Since [if]s are not allowed in ability tags and [filter_wml] and formula apparently both failed me, I'm back to trying to make that darn Lua thing work.

What I really don't understand, is that it apparently worked for you guys (Silene and Anonymissimus), but not for me, so I guess I must be doing it wrong.I tried to fix it by myself, I really did: I looked at the code, read a good part of the LuaWiki and tried a bunch of stuff, but it's giving headaches and I don't understand much of what goes on in there. I have no scripting background besides WML (and some html as a teen, but my programmer friends tell me never to mention this to programmers or I'd be laughed at ), so this is kinda hard on me.

Anyway, here is how I defined them:

in PE_Era.cfg:

Code: Select all

[era]
    [event]
      name=preload
      first_time_only=no

      [lua]
         code=<<
         helper = wesnoth.require("lua/helper.lua")
         function stealth_check (unit)
         local unit = unit.__cfg
         local variables = helper.get_child(unit, "variables")
         return variables and variables.flag == 0 and unit.moves >= variables.stealth
         end
         >>
      [/lua]
   [/event]

# Other unrelated code follows

And here is how I call them:

in PE_Abilities.cfg:

Code: Select all

# These are only two excerpts

[hides]
        id=stealth
        name= _ "Stealth"
        description= _ "Stealth:
This unit can hide in all terrains as long as it has {VALUE} or more moves left, and will remain undetected by its enemies.

Enemy units cannot see this unit except if they have units next to it. Any enemy unit that first discovers this unit immediately loses all its remaining movement."
     
   affect_self=yes

[filter_self]
	lua_function="stealth_check"
[/filter_self]
[/hides]

I also tried placing the preload event at the very top of the leader's [unit_type] and at the very top of my [multiplayer], but the result is the same: units are always hidden regardless of their moves or the value of the flag variable they contain.

I wonder if the problem could come from this?:

in _main.cfg:

Code: Select all

{~add-ons/Paintball_Era/macros/PE_deathmatch_settings.cfg}
{~add-ons/Paintball_Era/macros/PE_captureflag_settings.cfg}
{~add-ons/Paintball_Era/macros/PE_domination_settings.cfg}
{~add-ons/Paintball_Era/macros/PE_game_settings.cfg}
{~add-ons/Paintball_Era/macros/PE_specials.cfg}
{~add-ons/Paintball_Era/macros/PE_abilities.cfg}
{~add-ons/Paintball_Era/macros/PE_promotions-mobility.cfg}
{~add-ons/Paintball_Era/macros/PE_promotions-ability.cfg}
{~add-ons/Paintball_Era/macros/PE_promotions-equipment.cfg}
{~add-ons/Paintball_Era/PE_era.cfg}
{~add-ons/Paintball_Era/macros/PE_amla.cfg}
{~add-ons/Paintball_Era/scenarios/}

Note how PE_Era.cfg comes after PE_Abilities.cfg. However, I can hardly change that: PE_Abilities.cfg contains macro definitions that are called in PE_promotions-whatever.cfg, which contain macros that are called in PE_Era.cfg. So if that causes the problem, I'd need to move the preload event elsewhere. Where could that be? Scenarios are defined at the end, and units are defined even later. Unless that's not the order in which things are read when playing an actual scenario?

On another note:

you say it works for you... and it doesn,t for me.

You should write a small testcase and post it. If the Lua filter never matches for you, it means that either your units don't have a "flag" attribute equal to "0" in [variables] or they don't have a "stealth" attribute in [variables] or their "stealth" attribute is not an integer smaller than the unit remaining move points.

How would I do that? Is it the same as:

You can insert a (for example)
wesnoth.message(variables.flag)
in the lua code after the
local variables = helper.get_child(unit, "variables")
line to test whether code execution reaches the function.
(equivalent: {DEBUG_MSG $unit_var.variables.flag})

Thanks a lot for your much needed help!

[silene]

Code: Select all

        description= _ "Stealth:
This unit can hide in all terrains as long as it has {VALUE} or more moves left, and will remain undetected by its enemies.

Unrelated to your issues, but never use macro arguments inside translatable strings. They prevent strings from being translated.

I also tried placing the preload event at the very top of the leader's [unit_type] and at the very top of my [multiplayer], but the result is the same: units are always hidden regardless of their moves or the value of the flag variable they contain.

The position of the preload event doesn't matter. As long as you don't get an error message like "attempt to call a nil value", it has been taken into account.

The fact that the units are always hidden is disturbing; it means that the function is always returning true. Are you sure you haven't defined another version of the function in another file. As a quick test, you can replace the last line of the function by "return false"; if the units are still hidden after that, you messed bad.

You should write a small testcase and post it. If the Lua filter never matches for you, it means that either your units don't have a "flag" attribute equal to "0" in [variables] or they don't have a "stealth" attribute in [variables] or their "stealth" attribute is not an integer smaller than the unit remaining move points.

How would I do that? Is it the same as:

Disregard my comment. I thought your issue was that units are never hidden (and therefore that the filter never matched).

The debug line (to be put before the return line of the function) could look like:

Code: Select all

if variables then wesnoth.message(string.format("Unit has flag=%d, moves=%d, stealth=%d.", variables.flag, unit.moves, variables.stealth)) end

[Dixie]

Code: Select all

        description= _ "Stealth:
This unit can hide in all terrains as long as it has {VALUE} or more moves left, and will remain undetected by its enemies.

Unrelated to your issues, but never use macro arguments inside translatable strings. They prevent strings from being translated.

Well, since I don't want to create a new ability for each value of Stealth (which, along with flexibility, is the whole point of the trouble we're going through all the trouble of that lua filtering variables), I had to make the description dynamic, somehow. I tried stuff like "$unit.variables.stealth", but I guess it just didn't recognise the container "unit". I haven't tried "this_unit", mind you, but since it isn't a filter or anything, I figured it wouldn't return the number I want either. It's not really that important an issue, imo (for the time being, at least), but if you have any suggestions, go ahead.

The fact that the units are always hidden is disturbing; it means that the function is always returning true. Are you sure you haven't defined another version of the function in another file. As a quick test, you can replace the last line of the function by "return false"; if the units are still hidden after that, you messed bad.

Well I did what you said, and now the unit never hid, so I guess this at least is good news. I also tested with the debug line you supplied me, and I must say i get a pretty funny result: every time the function is called, it first returns the correct values, and then it immediately returns the same values EXCEPT for the moves... which return the max_moves this time. I've tried increasing the max_moves in play, and the second value changed to match it, so I'm fairly certain that's what is happenning. Don't ask me why the function does this, though

Edit: further constatations:
The thing seems to happen when the unit ends its move. For some reason, when it starts its move, the variable filter correctly, and when it ends it, it filters the max_moves, which always give higher than variables.stealth. I figured this out by just selecting (clicking on) the unit after it had ended a move with insufficient moves to be still hidden, but still hid. When selected, the function returns the current moves and unhides the unit.

[silene]

Code: Select all

        description= _ "Stealth:
This unit can hide in all terrains as long as it has {VALUE} or more moves left, and will remain undetected by its enemies.

It's not really that important an issue, imo (for the time being, at least), but if you have any suggestions, go ahead.

No suggestion; I don't think it is possible to have dynamic description. (They are used in the help, which isn't tied to any particular unit.) Just remove the "_" in front of your string, it gives additional work to translators for nought.

Well I did what you said, and now the unit never hid, so I guess this at least is good news. I also tested with the debug line you supplied me, and I must say i get a pretty funny result: every time the function is called, it first returns the correct values, and then it immediately returns the same values EXCEPT for the moves... which return the max_moves this time. I've tried increasing the max_moves in play, and the second value changed to match it, so I'm fairly certain that's what is happenning. Don't ask me why the function does this, though

Right, from time to time, the unit will be tested with its max moves. It happens whenever the engine updates sight/fog/shroud or when the AI computes reach of enemy units, since they all happen on max moves. But none of them should change the hidden status of the unit. I tested it on trunk and everything was working fine. (I didn't have a 1.8 binary at hand, so I'm not saying there isn't an engine bug there.)

[Dixie]

No suggestion; I don't think it is possible to have dynamic description. (They are used in the help, which isn't tied to any particular unit.) Just remove the "_" in front of your string, it gives additional work to translators for nought.

Oh, I didn't know that's what it meant! I really wondered why that underscore was all over some files, but seemed like it made no difference! I'll remove them, thanks!

Right, from time to time, the unit will be tested with its max moves. It happens whenever the engine updates sight/fog/shroud or when the AI computes reach of enemy units, since they all happen on max moves. But none of them should change the hidden status of the unit. I tested it on trunk and everything was working fine. (I didn't have a 1.8 binary at hand, so I'm not saying there isn't an engine bug there.)

Well... I think I'm still on 1.8.2, so I'll download the most recent version of Wesnoth and see if it fixes the problem. If not, I guess I'll accept it as a temporary engine bug over which I have no power and move on (and warn people about the bug if they download the add-on).

[Dixie]

A few hours later: the bug was apparently fixed with 1.8.3, it now works top-notch. Yay! Thanks!

Now there's really only a thing or two that I'm busting my ass off with so that this paintball package will be releasable. One of the game modes I have coded is a capture the flag. When a unit captures a flag, I place an overlay on him so that he is easily spotted. But I am currently having a hell of a time removing that overlay!

Let me go more in depth: this overlay is a flag icon, which I would ideally like to match the color of the captured flag. Easy solution: make it not match the color. Meh, sure, I can do that, and I can even remove the overlay. But I'd really like if the overlay could be colored. So I tried two methods. Note that with both methods, there is no problem applying the overlay, it's removing it that poses a problem.

First method: I have hand-colored the overlays and numbered them from 1 to 9, and match them through a macro like this:

Code: Select all

[unit_overlay]
  x,y=${UNIT}.x,${UNIT}.y
  image=flags/overlay{FLAG_TEAM}.png
[/unit_overlay]

No problem placing the overlay. But the same method won't remove the overlay, no matter what. I tried debug_msg to see if the problem was the removing macro's {FLAG_TEAM}, but no, it returns the right value. I have also been very careful that the overlay would be removed AFTER unstoring the unit, but no.

Second method: I have a single team-colored overlay which I alter using ImagePathFunction (or whatever the real name is), like this:

Code: Select all

[unit_overlay]
  x,y=${UNIT}.x,${UNIT}.y
  image=flags/overlay.png~RC(magenta>{FLAG_TEAM})
[/unit_overlay]

Once again, the overlay is applied, team color is applied, everything is top notch. But there's no way in hell the overlay will be removed. I tried remove the "~RC(magenta>{FLAG_TEAM})" in the [remove_unit_overlay]'s image path, but it didn't change naught.

So, does any body have any idea about this matter? I've looked at a few add-ons that I knew used overlays (that's how I came up with the ImagePath idea, actually), but I have so far not succeeded in finding a succesful overlay removal. If you know of any campaign, scenari or whatever that uses such altered overlays succesfully, I'd appreciate.

---

There is a second thing I was wondering about, although this second point is for utlerior development and is quite moot right now. It's about changing some of the core game values trough the game_config Lua tables:

wesnoth.game_config

Contrarily to the other values of the wesnoth table, game_config is simply a proxy table. Its fields offer an interface to the global settings of Wesnoth:

* version: string (read only)
* base_income: integer (read/write)
* village_income: integer (read/write)
* poison_amount: integer (read/write)
* rest_heal_amount: integer (read/write)
* recall_cost: integer (read/write)
* kill_experience: integer (read/write)
* debug: boolean (read only)

-- Healing, poison, and regeneration, are a bit weak? Let's boost them!
wesnoth.game_config.poison_amount = 15

So basically, I wondered how this would look in a Lua code. I suppose it surely isn't as simple as:

Code: Select all

[lua]
  code= <<
wesnoth.game_config.base_income = 0
wesnoth.game_config.village_income = 0
>>
[/lua]

Also, is there a string to modify the amount of hitpoints a village heals? Like setting it to 2 or 4 only?

[silene]

So, does any body have any idea about this matter? I've looked at a few add-ons that I knew used overlays (that's how I came up with the ImagePath idea, actually), but I have so far not succeeded in finding a succesful overlay removal.

I just checked and [remove_unit_overlay] works fine (as long the name of the image is exactly the same). So you will have to debug a bit more on your side.

So basically, I wondered how this would look in a Lua code. I suppose it surely isn't as simple as:

Code: Select all

wesnoth.game_config.base_income = 0
wesnoth.game_config.village_income = 0

Yes it is as simple as that.

Note that the values are not persistent: they are lost when saving/reloading, I think. So you have to set the values in a preload event.

Also, is there a string to modify the amount of hitpoints a village heals? Like setting it to 2 or 4 only?

Yes and no. It's hardcoded as the poison value.

[Dixie]

@ Overlays:

I tried some more stuff, including one I was convinced I had tried a few times at least, but this time it worked. Huh, oh well, all the better, I guess.

@ Changing poison value to change village value:

I really don't mind changing the value of poison. I tried changing the value of poison like the wiki says to, though, and villages still heal 8 hitpoints. I have tried poisonning a unit, and the poison effectively only did 2 damage, however. Could the code have changed in recent version/values been separated/whatever else?

Here's the code I use, just for the sake of reference:

Code: Select all

      [lua]
	code= <<
	wesnoth.game_config.base_income = 0
	wesnoth.game_config.village_income = 0
	wesnoth.game_config.poison_amount = 2
	>>
      [/lua]

[Exasperation]

It looks like it has changed; [terrain_type] now uses heals=<number> instead of a boolean value. You should, however, be able to define your own terrains with different healing amounts and use those instead.

[silene]

It looks like it has changed

Right, looking at the code, it seems that poison amount is used only for poisoning nowadays.