Samonella's questions: currently unsolved
Moderator: Forum Moderators
Forum rules
- Please use [code] BBCode tags in your posts for embedding WML snippets.
- To keep your code readable so that others can easily help you, make sure to indent it following our conventions.
- Celtic_Minstrel
- Developer
- Posts: 2214
- Joined: August 3rd, 2012, 11:26 pm
- Location: Canada
- Contact:
Re: Samonella's questions: currently solved
So I guess what's needed is a way for
[unit]
to override the unit type's attack list with an empty list...?Re: Samonella's questions: currently unsolved
Sorry to interrupt again, but I have already run into another problem. Do feel free to keep discussing the previous topics, and thanks for all the help!
I have an attack special that doesn't do anything, it's only purpose is to help me sort attacks in code. In the 'units' tab of the inspect window, it looks like this:So it's always inactive and shouldn't show up to the user. It's working well for sorting, and the special doesn't show up in the column at the right of the screen, but the attack dialog shows this:Is there something I can do about this? The wiki mentions that dummy specials need an id to display so I tried adding one, but it didn't change anything.
I have an attack special that doesn't do anything, it's only purpose is to help me sort attacks in code. In the 'units' tab of the inspect window, it looks like this:
Code: Select all
[specials]
[armorymod_checked]
name="armorymod_checked"
name_inactive=""
[filter_self]
type="this_type_does_not_exist"
[/filter_self]
[/armorymod_checked]
[/specials]
Image:
The last few months have been nothing but one big, painful reminder that TIMTLTW.
Creator of Armory Mod, The Rising Underworld, and Voyage of a Drake: an RPG
Creator of Armory Mod, The Rising Underworld, and Voyage of a Drake: an RPG
- Celtic_Minstrel
- Developer
- Posts: 2214
- Joined: August 3rd, 2012, 11:26 pm
- Location: Canada
- Contact:
Re: Samonella's questions: currently unsolved
I can't think of any reason why that would happen, unless there's actually a bug in the attack dialog making it not ignore specials that should be ignored.
Regarding your attacks issue, I was curious about one other thing. If you remove all melee attacks from a unit with both ranged and melee attacks, it works, right? Now, what if you then attempt to remove all ranged attacks from the same unit? Do they get their melee attacks back, or does it just have no effect at all?
Regarding your attacks issue, I was curious about one other thing. If you remove all melee attacks from a unit with both ranged and melee attacks, it works, right? Now, what if you then attempt to remove all ranged attacks from the same unit? Do they get their melee attacks back, or does it just have no effect at all?
Re: Samonella's questions: currently unsolved
Good question... looks like it gets back all attacks.Celtic_Minstrel wrote:Regarding your attacks issue, I was curious about one other thing. If you remove all melee attacks from a unit with both ranged and melee attacks, it works, right? Now, what if you then attempt to remove all ranged attacks from the same unit? Do they get their melee attacks back, or does it just have no effect at all?
The last few months have been nothing but one big, painful reminder that TIMTLTW.
Creator of Armory Mod, The Rising Underworld, and Voyage of a Drake: an RPG
Creator of Armory Mod, The Rising Underworld, and Voyage of a Drake: an RPG
Re: Samonella's questions: currently unsolved
Found a solution to my latest problem, I just use the id for my sorting purposes and put both name and name_inactive to an empty string. The name showing in the attack dialog still seems to be a bug though, I'm just working around it.
The last few months have been nothing but one big, painful reminder that TIMTLTW.
Creator of Armory Mod, The Rising Underworld, and Voyage of a Drake: an RPG
Creator of Armory Mod, The Rising Underworld, and Voyage of a Drake: an RPG
Re: Samonella's questions: currently solved
We were unable to reproduce that. None of the attacks got removed.Samonella wrote:Not meaning to interrupt the current discussion, I have another question. Unless I'm doing something wrong, it seems that [effect]apply_to=remove_attacks cannot leave a unit with 0 attacks? My code is like this:I know I'm filtering correctly, because if it targets a unit that originally had 2 attacks it will end up with 1, but I can't figure out how to remove all of them. Storing the unit, clearing its "attack" array and unstoring it has the same effect.Code: Select all
[modify_unit] [filter] < filter > [/filter] [effect] apply_to=remove_attacks [/effect] [/modify_unit]
When you use [modify_unit][effect], it doesn't store the modification in unit.modifications (which is what happens with [modify_unit][object]). So when you use it to remove attacks as you do, the attacks get restored based on the unit type. It's expected behaviour, it's just poorly documented in [modify_unit][effect]. In your case, you should simply use an [object] instead.
Re: Samonella's questions: currently solved
Hm, I can't either. That was my first post about it, when I was just messing with it instead of seriously testing; I must have gotten mixed up with a time I tried some filter. I'm still confident with the tests in my next post (which agree that no filter in [effect] = no attacks removed).zookeeper wrote:We were unable to reproduce that. None of the attacks got removed.Samonella wrote:I know I'm filtering correctly, because if it targets a unit that originally had 2 attacks it will end up with 1, but I can't figure out how to remove all of them. Storing the unit, clearing its "attack" array and unstoring it has the same effect.
Sounds good, thanks!zookeeper wrote:When you use [modify_unit][effect], it doesn't store the modification in unit.modifications (which is what happens with [modify_unit][object]). So when you use it to remove attacks as you do, the attacks get restored based on the unit type. It's expected behaviour, it's just poorly documented in [modify_unit][effect]. In your case, you should simply use an [object] instead.
The last few months have been nothing but one big, painful reminder that TIMTLTW.
Creator of Armory Mod, The Rising Underworld, and Voyage of a Drake: an RPG
Creator of Armory Mod, The Rising Underworld, and Voyage of a Drake: an RPG
Re: Samonella's questions: currently unsolved
Here's a quick question: you know how in 1.13.8 the unit sprites in the unit descriptions look different, almost like they were painted? Does that happen to be an Image Path Function that just hasn't been documented yet? It would be very convenient.
The last few months have been nothing but one big, painful reminder that TIMTLTW.
Creator of Armory Mod, The Rising Underworld, and Voyage of a Drake: an RPG
Creator of Armory Mod, The Rising Underworld, and Voyage of a Drake: an RPG
Re: Samonella's questions: currently unsolved
They're upscaled using XBRZ.Samonella wrote:Here's a quick question: you know how in 1.13.8 the unit sprites in the unit descriptions look different, almost like they were painted? Does that happen to be an Image Path Function that just hasn't been documented yet? It would be very convenient.
Re: Samonella's questions: currently solved
Perfect, thanks! Dunno how I missed it before.zookeeper wrote:They're upscaled using XBRZ.
The last few months have been nothing but one big, painful reminder that TIMTLTW.
Creator of Armory Mod, The Rising Underworld, and Voyage of a Drake: an RPG
Creator of Armory Mod, The Rising Underworld, and Voyage of a Drake: an RPG
Re: Samonella's questions: currently unsolved
Hello again. I'm having trouble with [message]side_for in online multiplayer (part of a sp-mp hybrid mod). In the following code, the message often displays for the wrong side (usually side 1) even though I can see plainly from the DEBUG_MSG that {SIDE} is the right value. Can anyone spot a typo or something? Or maybe it's a wesnoth bug?
{OPTIONS} is wml code containing 0 or more [option] tags. The message always displays to the correct side when there's an option or two, but it is usually wrong when there are none. So I could work around this by always having at least one option ("continue" or something when I wouldn't have otherwise had one) but if someone can tell me what's going wrong I'd appreciate it.
Code: Select all
{DEBUG_MSG "Side for is {SIDE} and side_number is $side_number|"}
[message]
speaker=narrator
side_for={SIDE}
image=${WEAPON_VAR}.icon|~XBRZ(3)
caption=${WEAPON_VAR}.description|
message=_"Damage: <b>${WEAPON_VAR}.damage| x ${WEAPON_VAR}.number|</b>
Range: <b>${WEAPON_VAR}.range|</b>
Damage type: <b>${WEAPON_VAR}.type|</b>$armorymod.display_specials|$armorymod.weapon_note|"
{OPTIONS}
[/message]
The last few months have been nothing but one big, painful reminder that TIMTLTW.
Creator of Armory Mod, The Rising Underworld, and Voyage of a Drake: an RPG
Creator of Armory Mod, The Rising Underworld, and Voyage of a Drake: an RPG
Re: Samonella's questions: currently unsolved
1.13.x(3?)-1.13.8 cannot tell difference between network human, and local player.
I thought that side_for is specifically ignored for dialogs that ask for user input.
I thought that side_for is specifically ignored for dialogs that ask for user input.
Re: Samonella's questions: currently unsolved
It has a is_local flag though that can be queried.Ravana wrote:1.13.x(3?)-1.13.8 cannot tell difference between network human, and local player.
in 1.13.8 side_for= is iirc no longer ignored for message with options, but unlike messages without options it onyl supports single sides, no lists of sides. Be aware though that most users don't expect the game to query them off-turn, so using side_for with options should be avoided if possible.Ravana wrote: I thought that side_for is specifically ignored for dialogs that ask for user input.
This coudl be a known bug in wesnoth 1.13.8, in that case it's already fixed in master and will be in 1.13.9 . I could update my "lua_fixes" addon to include that fix but since 1.13.9 is planned soon probably won't bother.Samonella wrote: The message always displays to the correct side when there's an option or two, but it is usually wrong when there are none. So I could work around this by always having at least one option ("continue" or something when I wouldn't have otherwise had one) but if someone can tell me what's going wrong I'd appreciate it.
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.
- Celtic_Minstrel
- Developer
- Posts: 2214
- Joined: August 3rd, 2012, 11:26 pm
- Location: Canada
- Contact:
Re: Samonella's questions: currently unsolved
I seem to recall that I added the is_local flag specifically in order to fix a bug related to side_for?
Re: Samonella's questions: currently solved
Sounds good, I'll use dummy options for now and hopefully will remove them in the next version.
The last few months have been nothing but one big, painful reminder that TIMTLTW.
Creator of Armory Mod, The Rising Underworld, and Voyage of a Drake: an RPG
Creator of Armory Mod, The Rising Underworld, and Voyage of a Drake: an RPG