wesnoth.theme_items.unit_alignment

Discussion of Lua and LuaWML support, development, and ideas.

Moderators: Forum Moderators, Developers

Post Reply
Rodrom
Posts: 41
Joined: March 4th, 2017, 7:00 am
Location: Reach me here: Orwell64123@gmail.com

wesnoth.theme_items.unit_alignment

Post by Rodrom » June 30th, 2017, 12:38 pm

For a while now I've been working on an "element"-themed multiplayer era for Wesnoth 1.13. It seemed like I knew how to use the LUA script up until now, when I noticed a problem that I can't figure out how to solve. There are four LUA scripts being used:

The first is this script, shown here.

Code: Select all

	[event]
        name=preload
        first_time_only=no
        [lua]
            code=<<
				local old_unit_alignment = wesnoth.theme_items.unit_alignment
                function wesnoth.theme_items.unit_alignment()
                    local u = wesnoth.get_displayed_unit()
                    if not u then return {} end
                    local s = old_unit_alignment()
					if u.status.subarctic or u.status.tropical or u.status.weathered or u.status.grounded then
						if u.status.subarctic and u.status.sweaty then
							table.insert(s, { "element", {                            
								text = ",W<span color='#FF9933' size='small'>(-25%)</span>",
								tooltip = "water: Water/ice units have a 25% damage increase in cool areas, and a 25% damage decrease in warm areas."
							} })
						elseif u.status.subarctic and u.status.frigid then
							table.insert(s, { "element", {                            
								text = ",W<span color='#00ff00' size='small'>(+25%)</span>",
								tooltip = "water: Water/ice units have a 25% damage increase in cool areas, and a 25% damage decrease in warm areas."
							} })
						elseif u.status.subarctic then
							table.insert(s, { "element", {                            
								text = ",W(+0%)",
								tooltip = "water: Water/ice units have a 25% damage increase in cool areas, and a 25% damage decrease in warm areas."
							} })
						end
						return s
					end
                end
            >>
        [/lua]
    [/event]
water-themed display
water-themed display
The other three are very similar:

Code: Select all

	[event]
        name=preload
        first_time_only=no
        [lua]
            code=<<
				local old_unit_alignment = wesnoth.theme_items.unit_alignment
                function wesnoth.theme_items.unit_alignment()
                    local u = wesnoth.get_displayed_unit()
                    if not u then return {} end
                    local s = old_unit_alignment()
					if u.status.subarctic or u.status.tropical or u.status.weathered or u.status.grounded then
						if u.status.grounded and u.status.windy then
							table.insert(s, { "element", {                            
								text = ",E<span color='#FF9933' size='small'>(-25%)</span>",
								tooltip = "earth: Earthen units have a 25% damage increase in dusty areas, and a 25% damage decrease in windy areas."
							} })
						elseif u.status.grounded and u.status.dusty then
							table.insert(s, { "element", {                            
								text = ",E<span color='#00ff00' size='small'>(+25%)</span>",
								tooltip = "earth: Earthen units have a 25% damage increase in dusty areas, and a 25% damage decrease in windy areas."
							} })
						elseif u.status.grounded then
							table.insert(s, { "element", {                            
								text = ",E(+0%)",
								tooltip = "earth: Earthen units have a 25% damage increase in dusty areas, and a 25% damage decrease in windy areas."
							} })
						end
						return s
					end
                end
            >>
        [/lua]
    [/event]
	
earth-themed display
earth-themed display

Code: Select all

	[event]
        name=preload
        first_time_only=no
        [lua]
            code=<<
				local old_unit_alignment = wesnoth.theme_items.unit_alignment
                function wesnoth.theme_items.unit_alignment()
                    local u = wesnoth.get_displayed_unit()
                    if not u then return {} end
                    local s = old_unit_alignment()
					if u.status.subarctic or u.status.tropical or u.status.weathered or u.status.grounded then
						if u.status.tropical and u.status.frigid then
							table.insert(s, { "element", {                           
								text = ",F<span color='#FF9933' size='small'>(-25%)</span>",
								tooltip = "heat: Sun/heat/fire units have a 25% damage increase in warm areas, and a 25% damage decrease in cool areas."
							} })
						elseif u.status.tropical and u.status.sweaty then
							table.insert(s, { "element", {                            
								text = ",F<span color='#00ff00' size='small'>(+25%)</span>",
								tooltip = "heat: Sun/heat/fire units have a 25% damage increase in warm areas, and a 25% damage decrease in cool areas."
							} })
						elseif u.status.tropical then
							table.insert(s, { "element", {                            
								text = ",F(+0%)",
								tooltip = "heat: Sun/heat/fire units have a 25% damage increase in warm areas, and a 25% damage decrease in cool areas."
							} })
						end
						return s
					end
				end
            >>
        [/lua]
    [/event]
fire-themed display
fire-themed display

Code: Select all

	[event]
        name=preload
        first_time_only=no
        [lua]
            code=<<
				local old_unit_alignment = wesnoth.theme_items.unit_alignment
                function wesnoth.theme_items.unit_alignment()
                    local u = wesnoth.get_displayed_unit()
                    if not u then return {} end
                    local s = old_unit_alignment()
					if u.status.subarctic or u.status.tropical or u.status.weathered or u.status.grounded then
						if u.status.weathered and u.status.dusty then
							table.insert(s, { "element", {                            
								text = ",A<span color='#FF9933' size='small'>(-25%)</span>",
								tooltip = "air: Air units have a 25% damage increase in windy areas, and a 25% damage decrease in dusty areas."
							} })
						elseif u.status.weathered and u.status.windy then
							table.insert(s, { "element", {                            
								text = ",A<span color='#00ff00' size='small'>(+25%)</span>",
								tooltip = "air: Air units have a 25% damage increase in windy areas, and a 25% damage decrease in dusty areas."
							} })
						elseif u.status.weathered then
							table.insert(s, { "element", {                            
								text = ",A(+0%)",
								tooltip = "air: Air units have a 25% damage increase in windy areas, and a 25% damage decrease in dusty areas."
							} })
						end
						return s
					end
                end
            >>
        [/lua]
    [/event]
wind-themed display
wind-themed display
The problem is that any units that do not have a "themed" ability and status have their alignment obscured on the right-hand panel, like this
n_template.png
I want to be able to use regular units and my themed units together if possible.

There are two ideas I had that seemed like they could be solutions:

#1 add a unique status to "regular" units and then have a fifth LUA script represent them:

I'd use this

Code: Select all

[event]
  name=new turn
  first_time_only=no
	  [store_unit]		
			[filter]
				[not]
					ability=tropical,subarctic,freebound,earthbound
				[/not]
			[/filter]
		 variable=icon_store
		 kill=yes
	  [/store_unit]
  {FOREACH icon_store i}
	 [set_variable]
		name=icon_store[$i].status.mild
		value=yes   
	 [/set_variable]
   [unstore_unit]
	  variable=icon_store[$i]
   [/unstore_unit]
  {NEXT i}
  {CLEAR_VARIABLE icon_store}
[/event]
[event]
  name=prerecruit
  first_time_only=no
	  [store_unit]		
			[filter]
				[not]
					ability=tropical,subarctic,freebound,earthbound
				[/not]
			[/filter]
		 variable=icon_store
		 kill=yes
	  [/store_unit]
  {FOREACH icon_store i}
	 [set_variable]
		name=icon_store[$i].status.mild
		value=yes   
	 [/set_variable]
   [unstore_unit]
	  variable=icon_store[$i]
   [/unstore_unit]
  {NEXT i}
  {CLEAR_VARIABLE icon_store}
[/event]
[event]
  name=prerecall
  first_time_only=no
	  [store_unit]		
			[filter]
				[not]
					ability=tropical,subarctic,freebound,earthbound
				[/not]
			[/filter]
		 variable=icon_store
		 kill=yes
	  [/store_unit]
  {FOREACH icon_store i}
	 [set_variable]
		name=icon_store[$i].status.mild
		value=yes   
	 [/set_variable]
   [unstore_unit]
	  variable=icon_store[$i]
   [/unstore_unit]
  {NEXT i}
  {CLEAR_VARIABLE icon_store}
[/event]
and then something like this. I know it's wrong, but I couldn't figure out how to represent the normal alignment in this situation.

Code: Select all

	[event]
        name=preload
        first_time_only=no
        [lua]
            code=<<
				local old_unit_alignment = wesnoth.theme_items.unit_alignment
                function wesnoth.theme_items.unit_alignment()
                    local u = wesnoth.get_displayed_unit()
                    if not u then return {} end
                    local s = old_unit_alignment()
					if u.status.mild then s = u.old_unit_alignment

					end
					return s
				end
			>>
		[/lua]
	[/event]
#2 Change the first four scripts so that they don't obscure the alignment for "normal" units in the first place. Not sure how to do that.

gfgtdf
Developer
Posts: 1184
Joined: February 10th, 2013, 2:25 pm

Re: wesnoth.theme_items.unit_alignment

Post by gfgtdf » July 10th, 2017, 8:38 pm

I didn't read your whole post so i migth be wrong, but if you use codes like this:

Code: Select all

local old_unit_alignment = wesnoth.theme_items.unit_alignment
function wesnoth.theme_items.unit_alignment()
	local u = wesnoth.get_displayed_unit()
	if not u then return {} end
	local s = old_unit_alignment()
	if u.status.subarctic or u.status.tropical or u.status.weathered or u.status.grounded then
		if u.status.subarctic and u.status.sweaty then
			table.insert(s, { "element", {                           
				text = ",W<span color='#FF9933' size='small'>(-25%)</span>",
				tooltip = "water: Water/ice units have a 25% damage increase in cool areas, and a 25% damage decrease in warm areas."
			} })
		elseif u.status.subarctic and u.status.frigid then
			table.insert(s, { "element", {                           
				text = ",W<span color='#00ff00' size='small'>(+25%)</span>",
				tooltip = "water: Water/ice units have a 25% damage increase in cool areas, and a 25% damage decrease in warm areas."
			} })
		elseif u.status.subarctic then
			table.insert(s, { "element", {                           
				text = ",W(+0%)",
				tooltip = "water: Water/ice units have a 25% damage increase in cool areas, and a 25% damage decrease in warm areas."
			} })
		end
		return s
	end
end
(i just reindented that one), then if u.status.subarctic or u.status.tropical or u.status.weathered or u.status.grounded evaluatess to false then the return s line is never reached, and if wesnoth.theme_items.unit_alignment returns nothing the the game will just print nothing in the aligment panel in that case. The solution is then so move the return s line out of that if block so that it is called unconditionallly.


A good code indention really helps you to find these type of errors. Since you are using wesnoth 1.13 where 'requireing download' of addons isn't that much of a problem anymore i really reccomend to put your lua code in external .lua files that are then loaded vial wesnoth.dofile or wesnoth.require . If you then us an editor with autoindention for lua files you don't really need to do much anymore.
Scenario with Robots SP scenario (1.11/1.12), allows you to build your units with components, PYR No preperation turn 1.12 mp-mod that allows you to select your units immideately after the game begins.

Rodrom
Posts: 41
Joined: March 4th, 2017, 7:00 am
Location: Reach me here: Orwell64123@gmail.com

Re: wesnoth.theme_items.unit_alignment

Post by Rodrom » July 11th, 2017, 3:00 am

Thanks gfgtdf. Changed the LUA scripts and they work fine now! Auto-indentation for LUA in Notepad++ should be doable since there are guides online.

Code: Select all

local old_unit_alignment = wesnoth.theme_items.unit_alignment
function wesnoth.theme_items.unit_alignment()
   local u = wesnoth.get_displayed_unit()
   if not u then return {} end
   local s = old_unit_alignment()
   if u.status.subarctic or u.status.tropical or u.status.weathered or u.status.grounded then
      if u.status.subarctic and u.status.sweaty then
         table.insert(s, { "element", {                           
            text = ",W<span color='#FF9933' size='small'>(-15%)</span>",
            tooltip = "water: Water/ice units have a 15% damage increase in cool areas, and a 15% damage decrease in warm areas."
         } })
      elseif u.status.subarctic and u.status.frigid then
         table.insert(s, { "element", {                           
            text = ",W<span color='#00ff00' size='small'>(+15%)</span>",
            tooltip = "water: Water/ice units have a 15% damage increase in cool areas, and a 15% damage decrease in warm areas."
         } })
      elseif u.status.subarctic then
         table.insert(s, { "element", {                           
            text = ",W(+0%)",
            tooltip = "water: Water/ice units have a 15% damage increase in cool areas, and a 15% damage decrease in warm areas."
         } })
      end
   end
return s
end
   
   
local old_unit_alignment = wesnoth.theme_items.unit_alignment
function wesnoth.theme_items.unit_alignment()
   local u = wesnoth.get_displayed_unit()
   if not u then return {} end
   local s = old_unit_alignment()
   if u.status.subarctic or u.status.tropical or u.status.weathered or u.status.grounded then
      if u.status.grounded and u.status.windy then
         table.insert(s, { "element", {                           
            text = ",E<span color='#FF9933' size='small'>(-15%)</span>",
            tooltip = "earth: Earthen units have a 15% damage increase in dusty areas, and a 15% damage decrease in windy areas."
         } })
      elseif u.status.grounded and u.status.dusty then
         table.insert(s, { "element", {                           
            text = ",E<span color='#00ff00' size='small'>(+15%)</span>",
            tooltip = "earth: Earthen units have a 15% damage increase in dusty areas, and a 15% damage decrease in windy areas."
         } })
      elseif u.status.grounded then
         table.insert(s, { "element", {                           
            text = ",E(+0%)",
            tooltip = "earth: Earthen units have a 15% damage increase in dusty areas, and a 15% damage decrease in windy areas."
         } })
      end
   end
return s
end
   
local old_unit_alignment = wesnoth.theme_items.unit_alignment
function wesnoth.theme_items.unit_alignment()
   local u = wesnoth.get_displayed_unit()
   if not u then return {} end
   local s = old_unit_alignment()
   if u.status.subarctic or u.status.tropical or u.status.weathered or u.status.grounded then
      if u.status.tropical and u.status.sweaty then
         table.insert(s, { "element", {                           
            text = ",F<span color='#00ff00' size='small'>(+15%)</span>",
            tooltip = "heat: Sun/heat/fire units have a 15% damage increase in warm areas, and a 15% damage decrease in cool areas."
         } })
      elseif u.status.tropical and u.status.frigid then
         table.insert(s, { "element", {                           
            text = ",F<span color='#FF9933' size='small'>(-15%)</span>",
            tooltip = "heat: Sun/heat/fire units have a 15% damage increase in warm areas, and a 15% damage decrease in cool areas."
         } })
      elseif u.status.tropical then
         table.insert(s, { "element", {                           
            text = ",F(+0%)",
            tooltip = "heat: Sun/heat/fire units have a 15% damage increase in warm areas, and a 15% damage decrease in cool areas."
         } })
      end
   end
return s
end
   
local old_unit_alignment = wesnoth.theme_items.unit_alignment
function wesnoth.theme_items.unit_alignment()
   local u = wesnoth.get_displayed_unit()
   if not u then return {} end
   local s = old_unit_alignment()
   if u.status.subarctic or u.status.tropical or u.status.weathered or u.status.grounded then
      if u.status.weathered and u.status.dusty then
         table.insert(s, { "element", {                           
            text = ",A<span color='#FF9933' size='small'>(-15%)</span>",
            tooltip = "air: Air units have a 15% damage increase in windy areas, and a 15% damage decrease in dusty areas."
         } })
      elseif u.status.weathered and u.status.windy then
         table.insert(s, { "element", {                           
            text = ",A<span color='#00ff00' size='small'>(+15%)</span>",
            tooltip = "air: Air units have a 15% damage increase in windy areas, and a 15% damage decrease in dusty areas."
         } })
      elseif u.status.weathered then
         table.insert(s, { "element", {                           
            text = ",A(+0%)",
            tooltip = "air: Air units have a 15% damage increase in windy areas, and a 15% damage decrease in dusty areas."
         } })
      end
   end
return s
end

gfgtdf
Developer
Posts: 1184
Joined: February 10th, 2013, 2:25 pm

Re: wesnoth.theme_items.unit_alignment

Post by gfgtdf » July 13th, 2017, 7:22 pm

Rodrom wrote:Thanks gfgtdf. Changed the LUA scripts and they work fine now! Auto-indentation for LUA in Notepad++ should be doable since there are guides online.
for notepadd++ you could for example use the indent-by-fold addon. It unfortunatley adds too muhc indention to lines that begin with else though. So you need to do a \telse -> else replace after auto indention if you use that.
Scenario with Robots SP scenario (1.11/1.12), allows you to build your units with components, PYR No preperation turn 1.12 mp-mod that allows you to select your units immideately after the game begins.

time_area
Posts: 2
Joined: March 1st, 2019, 9:39 pm

Re: wesnoth.theme_items.unit_alignment

Post by time_area » March 5th, 2019, 11:53 pm

This is Rodrom, posting from a new account. The good news is that my WML is working well, and I've gotten better at understanding it. I'm close to releasing a multiplayer era whose game mechanics do almost everything I wanted for it to do. The bad news is that while my WML does what I want it to, it runs really slowly in playtesting, and works even more slowly when I try to run it with other downloads in the add-ons folder at the same time. I don't think many people will try out a new multiplayer era if it makes Wesnoth 1.14 pause for 30-90 seconds every single turn. I've heard translating WML to LUA scripts can make them run faster, and I would like to write event WML as LUA if possible.

This is an example of the sort of WML I would like to learn to translate to LUA. This is part of a weapon macro that changes the time area of the hexes adjacent to the active unit. The various units all have abilities that change their stats based on whether or not they have been placed on a hex with the changed time area.

Code: Select all

[event]
        name=attacker hits
        first_time_only=no
		[filter_attack] 
			special=HF_winter_solstice
		[/filter_attack] 
		[filter]		
			[filter_location]
			time_of_day_id=dawn,Hdawn,Cdawn
			[/filter_location]
		[/filter]
	   [time_area]
		 x,y=$unit.x,$unit.y
		 radius=1
		 {COLD_SCHEDULE}
	   [/time_area]			  
    [/event]
This was my attempt to write the previous WML as LUA instead. I know it's wrong, but there aren't many examples of the "on_event(" LUA for me to practice with, and I'm not sure that I'm including filters or the "wesnoth.add_time_area" table elements properly.

Code: Select all

[event]
        name=preload
        first_time_only=no
		[lua]
			code = << 

		local utils = wesnoth.require "wml-utils"
		
local event_handlers = {}

	on_event("attacker hits", function()
	local filter = helper.get_child(cfg, "filter_attack")
	local filter = helper.get_child(cfg, "filter") and helper.get_child(cfg, "filter_location") 
	for special in wml.child_range(attack, 'specials') and time_area in wml.child_range(location, 'time_of_day_id')
		if wml.get_child(special, "HF_winter_solstice") and wml.get_child(location, "time_of_day_id=dawn,Cdawn,Hdawn") then
			wesnoth.add_time_area(cfg)
			table.insert(s, { "element", {                           
			x,y = "$unit.x,$unit.y",
			radius = 1
			current_time = "{COLD_SCHEDULE}"
			} })
		end
	end)

return on_event

		 >>
		[/lua]
	[/event]

User avatar
Celtic_Minstrel
Developer
Posts: 1499
Joined: August 3rd, 2012, 11:26 pm
Location: Canada
Contact:

Re: wesnoth.theme_items.unit_alignment

Post by Celtic_Minstrel » March 6th, 2019, 4:08 am

You don't necessarily need to use on_event in order to write events in Lua. Your attempt at doing so is rather nonsensical as well. (gfgtdf: does on_event even provide a way for you to set filters for the event?) Generally I wouldn't expect on_event to speed things up much, though I suppose it could if it's an event that's triggered many, many times.

Converting your example event to Lua without on_event would mean replacing the time_area tag with something similar to the following:

Code: Select all

[lua]
	code=<<
		wesnoth.add_time_area{
			x = wesnoth.current.event_context.x1,
			y = wesnoth.current.event_context.y1,
			radius = 1,
			... # The three dots inserts the contents of the [args] tag at this location
		}
	>>
	[args]
		{COLD_SCHEDULE}
	[/args]
[/lua]
I wouldn't expect that alone to save much execution time, but who knows, I could be missing something. I'm not sure what would be the correct way to do it with on_event; I suggest waiting for gfgtdf on that topic. Note that for this example you leave the filters exactly as you already had them, only the one tag is substituted. The [args] tag is helpful for passing any data you want to the Lua code; in particular, if you need to include the contents of a macro anywhere in the Lua, it's the only way to do it. I replaced your $unit.x and $unit.y with the simpler $x1 and $y1 since they're (I think?) a bit easier to get from Lua and are the same in 99% of cases (off the top of my head, I think the only exception is in enter and/or exit hex events).
Author of The Black Cross of Aleron campaign and Default++ era.
Maintainer of Steelhive.

time_area
Posts: 2
Joined: March 1st, 2019, 9:39 pm

Re: wesnoth.theme_items.unit_alignment

Post by time_area » March 6th, 2019, 10:23 am

Thank you for your time.

gfgtdf
Developer
Posts: 1184
Joined: February 10th, 2013, 2:25 pm

Re: wesnoth.theme_items.unit_alignment

Post by gfgtdf » March 6th, 2019, 1:39 pm

Celtic_Minstrel wrote:
March 6th, 2019, 4:08 am
You don't necessarily need to use on_event in order to write events in Lua. Your attempt at doing so is rather nonsensical as well. (gfgtdf: does on_event even provide a way for you to set filters for the event?)
No it doesn't, you have to use things like unit:matches or wesnoth.eval_conditional as in for example local u = wesnoth.get_unit(cx.x1, cx.y1) ; if not u or not u:matches( whatever) then return end in the handler body. See the feding implementation for example https://github.com/wesnoth/wesnoth/blob ... ng.lua#L17 filtering on attacks is a little tricky because there is afaik no direct way in SUF to filter the currently used attack, but i think at least filtering for used weapon specials is possible.
Celtic_Minstrel wrote:
March 6th, 2019, 4:08 am
Generally I wouldn't expect on_event to speed things up much, though I suppose it could if it's an event that's triggered many, many times.

Converting your example event to Lua without on_event would mean replacing the time_area tag with something similar to the following:

Code: Select all

[lua]
	code=<<
		wesnoth.add_time_area{
			x = wesnoth.current.event_context.x1,
			y = wesnoth.current.event_context.y1,
			radius = 1,
			... # The three dots inserts the contents of the [args] tag at this location
		}
	>>
	[args]
		{COLD_SCHEDULE}
	[/args]
[/lua]
I wouldn't expect that alone to save much execution time, but who knows, I could be missing something. I'm not sure what would be the correct way to do it with on_event; I suggest waiting for gfgtdf on that topic.
Hmm yes i don't expect performance improvements from porting this speific wml code either , since its basicially doing the same thing as the underlying wml tags would do and none of these involved wml tags have much overheat afaik. Of course if this is part of a plan to port the whole addon to lua i woudl probably do it anyways.
Celtic_Minstrel wrote:
March 6th, 2019, 4:08 am
Note that for this example you leave the filters exactly as you already had them, only the one tag is substituted. The [args] tag is helpful for passing any data you want to the Lua code; in particular, if you need to include the contents of a macro anywhere in the Lua, it's the only way to do it. I replaced your $unit.x and $unit.y with the simpler $x1 and $y1 since they're (I think?) a bit easier to get from Lua and are the same in 99% of cases (off the top of my head, I think the only exception is in enter and/or exit hex events).

@time_area

Im sorry to say this but your code is wrong on many levels (syntax erros, using nonexistent vairables, usless lines, using wesnoth api wrongly ) that its impossible for me to give you a direct hint for it. I reccomend to read an online totorial about basic lua concepts,about googeling it suggested this one https://www.tutorialspoint.com/lua/lua_overview.htm although i dont realyl know what its prerequisites are though.
Scenario with Robots SP scenario (1.11/1.12), allows you to build your units with components, PYR No preperation turn 1.12 mp-mod that allows you to select your units immideately after the game begins.

User avatar
Celtic_Minstrel
Developer
Posts: 1499
Joined: August 3rd, 2012, 11:26 pm
Location: Canada
Contact:

Re: wesnoth.theme_items.unit_alignment

Post by Celtic_Minstrel » March 6th, 2019, 1:52 pm

gfgtdf wrote:
March 6th, 2019, 1:39 pm
filtering on attacks is a little tricky because there is afaik no direct way in SUF to filter the currently used attack,
Uhh, what does SUF have to do with it? If you want to filter on the weapon you'd be checking wesnoth.current.event_context.weapon for example. I think that would be the active attack's WML, but I'm not sure, it might identify the attack in some other way.
gfgtdf wrote:
March 6th, 2019, 1:39 pm
Im sorry to say this but your code is wrong on many levels (syntax erros, using nonexistent vairables, usless lines, using wesnoth api wrongly ) that its impossible for me to give you a direct hint for it. I reccomend to read an online totorial about basic lua concepts,about googeling it suggested this one https://www.tutorialspoint.com/lua/lua_overview.htm although i dont realyl know what its prerequisites are though.
Yeah, his Lua sample is pretty nonsensical, but the WML version preceding it seems more or less correct, so maybe you could give some outline of how that would be written with on_event? Or perhaps I can do it now that you've basically confirmed that there's no built-in filter support (don't have time right at this moment though).
Author of The Black Cross of Aleron campaign and Default++ era.
Maintainer of Steelhive.

User avatar
Ravana
Forum Moderator
Posts: 2209
Joined: January 29th, 2012, 12:49 am
Location: Estonia
Contact:

Re: wesnoth.theme_items.unit_alignment

Post by Ravana » March 6th, 2019, 4:30 pm

I suggest leaving event declarations and smaller filters to WML, and moving event actions and complex filters to Lua (lua_function).

gfgtdf
Developer
Posts: 1184
Joined: February 10th, 2013, 2:25 pm

Re: wesnoth.theme_items.unit_alignment

Post by gfgtdf » March 7th, 2019, 2:02 am

Celtic_Minstrel wrote:
March 6th, 2019, 1:52 pm
Uhh, what does SUF have to do with it? If you want to filter on the weapon you'd be checking wesnoth.current.event_context.weapon for example. I think that would be the active attack's WML, but I'm not sure, it might identify the attack in some other way.
Yes it is the currently active weapons wml but afaik you cannot easily use filters on it. Most of the time when you want to implement a new weapon special in lua you actually want 'special_active' which would then also need to check the filter conditions for the given weapon special
Celtic_Minstrel wrote:
March 6th, 2019, 1:52 pm
Yeah, his Lua sample is pretty nonsensical, but the WML version preceding it seems more or less correct, so maybe you could give some outline of how that would be written with on_event? Or perhaps I can do it now that you've basically confirmed that there's no built-in filter support (don't have time right at this moment though).
well what i'd do for the filters would probably look like this:

Code: Select all

local on_event = wesnoth.require("on_event")
on_event("attacker_hits", function(cx)
	local u = wesnoth.get_unit(cx.x1, cx.y1)
	if not u or not u:matches { wml.tag.has_attack { special_active = "HF_winter_solstice"} }  then
		return
	end
	if not u:matches { wml.tag.filter_location { time_of_day_id= "dawn,Hdawn,Cdawn" }} then
		return
	end
	wesnoth.add_time_area{
	 --- more code
	}
end)

For technical reasons this requires you to put an empty [filter_self] tag in your ability wml definition (if there is no such tag yet )to make special_active work, i admit its a bit of a hack though.
Scenario with Robots SP scenario (1.11/1.12), allows you to build your units with components, PYR No preperation turn 1.12 mp-mod that allows you to select your units immideately after the game begins.

User avatar
Celtic_Minstrel
Developer
Posts: 1499
Joined: August 3rd, 2012, 11:26 pm
Location: Canada
Contact:

Re: wesnoth.theme_items.unit_alignment

Post by Celtic_Minstrel » March 7th, 2019, 2:08 am

Also, if you can use a formula instead of a Lua function, I'd generally recommend that, since formulas can't accidentally produce unwanted side-effects (provided you don't use the dice operator). That said... the filters in your example are extremely simple, so it's probably not worth converting them to either WFL or Lua.

I'm wondering a couple of things about what you're trying to do here... first, it seems like you claim that it slows things down. Can you be more specific about the kind of slowdown you're seeing? The other thing is, have you tried doing this with an [illuminates] ability instead of an event-based ability? Without seeing the content of {COLD_SCHEDULE} I can't be certain that this would be possible; however, given that you're spawning a time area around the targeted creature, it seems plausible that there might be a way to do it with [illuminates].
gfgtdf wrote:
March 7th, 2019, 2:02 am
Celtic_Minstrel wrote:
March 6th, 2019, 1:52 pm
Uhh, what does SUF have to do with it? If you want to filter on the weapon you'd be checking wesnoth.current.event_context.weapon for example. I think that would be the active attack's WML, but I'm not sure, it might identify the attack in some other way.
Yes it is the currently active weapons wml but afaik you cannot easily use filters on it.
I suppose you could pass the WML to wesnoth.create_weapon if you need to run a filter on it though? Still, I don't think special_active would work then. We should try to change it so that these are assigned the actual userdata reference to the weapon instead of just the WML, when possible. And make sure the specials context is active during attack events if it's not already.
Author of The Black Cross of Aleron campaign and Default++ era.
Maintainer of Steelhive.

gfgtdf
Developer
Posts: 1184
Joined: February 10th, 2013, 2:25 pm

Re: wesnoth.theme_items.unit_alignment

Post by gfgtdf » March 7th, 2019, 2:13 am

Celtic_Minstrel wrote:
March 7th, 2019, 2:08 am
I suppose you could pass the WML to wesnoth.create_weapon if you need to run a filter on it though? Still, I don't think special_active would work then. We should try to change it so that these are assigned the actual userdata reference to the weapon instead of just the WML, when possible. And make sure the specials context is active during attack events if it's not already.
Yes this won't work very well, in fact it doesn't even work well for standard [filter_attack] tags for the very same reason, see https://github.com/wesnoth/wesnoth/issu ... -402582024 (assuming that this was not somehow fixed during the last 3/4 year)
Scenario with Robots SP scenario (1.11/1.12), allows you to build your units with components, PYR No preperation turn 1.12 mp-mod that allows you to select your units immideately after the game begins.

Post Reply