ghype's Problems:

The place to post your WML questions and answers.

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.
Post Reply
User avatar
josteph
Inactive Developer
Posts: 741
Joined: August 19th, 2017, 6:58 pm

Re: ghype's Coding Problems - Modify Xp Reward

Post by josteph »

No, you can't use enemy.level instead of second_unit.level unless you explicitly do [store_unit] variable=enemy.
enclave
Posts: 936
Joined: December 15th, 2007, 8:52 am

Re: ghype's Coding Problems - Modify Xp Reward

Post by enclave »

you put variable change after you unstored the unit.. so it doesnt affect anything, it just changes the second_unit array.. without putting that modified unit on map:

Code: Select all

[unstore_unit]
        variable=second_unit
        find_vacant=no
        animate=no
        fire_event=no
    [/unstore_unit]
    {CLEAR_VARIABLE fightrew}

    {VARIABLE second_unit.name testname}
should be {VARIABLE second_unit.name testname} before [unstore_unit], then it will change after you unstore (if code works)

Code: Select all

 {VARIABLE second_unit.name testname}
 [unstore_unit]
        variable=second_unit
        find_vacant=no
        animate=no
        fire_event=no
    [/unstore_unit]
    {CLEAR_VARIABLE fightrew}

   
User avatar
ghype
Posts: 1069
Joined: December 13th, 2016, 4:43 pm
Location: Berlin, Germany

Re: ghype's Coding Problems - Modify Xp Reward

Post by ghype »

thanks for the suggestions. I indeed forgot the filters, hence no events were used for my abilities. Also I used the [message] key in order to see which event comes through and which don't.
(1) for {ABILITY_NO_XP}, which is used for gate, only the second event (name=die) got through.The first one (name=attack end) however did not came through.
code:

(2) for {ABILITY_REDUCE_XP}, which is used for the attacker, it is the exact opposite. the first event (name=attack) got through.The second one (name=die) however did not came through.
code:

What I remark is that if I use for (1) on the first event name=attack instead of name=attack end , there might be a chance that both event come through as name=attack did for (2). But even if so, none of these four events actually did something. No experience was reduced or denied...
so I am still at the same place.
enclave
Posts: 936
Joined: December 15th, 2007, 8:52 am

Re: ghype's Coding Problems - Modify Xp Reward

Post by enclave »

I think this is a mistake here:
{VARIABLE_OP $unit.experience sub enemy.level}
you dont need to use dollar sign before unit.experience, but you need to use $ sign before enemy.level :)
you have couple of them.. or maybe im tired.. idk
User avatar
Ravana
Forum Moderator
Posts: 2934
Joined: January 29th, 2012, 12:49 am
Location: Estonia
Contact:

Re: ghype's Coding Problems - Modify Xp Reward

Post by Ravana »

For attack events, unit and second_unit depend on who starts attack. For some cases you might want [filter_second].
User avatar
ghype
Posts: 1069
Joined: December 13th, 2016, 4:43 pm
Location: Berlin, Germany

Re: ghype's Coding Problems - Auto-defeat/Confusing Unit ID

Post by ghype »

For the "Modify Xp Reward" thing i will wait till 1.15 and take a look again at the situation.

I just came up with two smaller issues.
(1) In my campaign scenarion, I used to have an auto-defeat on start up because i forgot to add recruit= in order to make my main character not being able to recruit. This fixed the auto-defeat back than. Now I added a couple more ai sides and I get an auto-defeat on start up again.
There must be something I quite have't figured out yet, what am I missing in my [side]'s ?
code:
(2) I have a small PLACE_UNIT macro which I allows me to place unit of any type. For the type i need to use the ID. But for units with two words (such as Giant Rat, Giant Scorpion, Vampire Bat) it will not recognise the given ID.
Spoiler:
User avatar
Ravana
Forum Moderator
Posts: 2934
Joined: January 29th, 2012, 12:49 am
Location: Estonia
Contact:

Re: ghype's Coding Problems - Auto-defeat/Confusing Unit ID

Post by Ravana »

1) there should be some key that makes side never defeated
2) it is recognized as problem https://github.com/wesnoth/wesnoth/issues/1847 but for now you need to use it as https://wiki.wesnoth.org/PreprocessorRe ... inclusions
enclave
Posts: 936
Joined: December 15th, 2007, 8:52 am

Re: ghype's Coding Problems - Auto-defeat/Confusing Unit ID

Post by enclave »

ghype wrote: November 28th, 2018, 3:47 pm (2) I have a small PLACE_UNIT macro which I allows me to place unit of any type. For the type i need to use the ID. But for units with two words (such as Giant Rat, Giant Scorpion, Vampire Bat) it will not recognise the given ID.

Code: Select all

{PLACE_UNIT side Vampire Bat X Y}
{PLACE_UNIT side Vampire_Bat X Y}
{PLACE_UNIT side VAMPIRE BAT X Y}
{PLACE_UNIT side VAMPIRE_BAT X Y}
for these as far as I can see you just need to use it like this:
a) {PLACE_UNIT side "Vampire Bat" X Y}
b) {PLACE_UNIT side (Vampire Bat) X Y}
Otherwise your macro thinks that Bat is the next variable (X), then for x, it thinks its Y, and then for the last one it thinks it's an extra one.. so I'm sure it gives you error something like that "you have 5 variables but is expected 4", so you need to show macro that "Vampire Bat" is a single variable, not 2 variables..

For the recruit thing.. if it was working before 1.14 and now on 1.14 it doesnt work anymore, then..
have you tried to change Recruit= into something else? For example Recruit="" or just remove it completely.. 1.14 had too many changes that affect too many things.. comparing to 1.12.. otherwise i have no idea..
User avatar
ghype
Posts: 1069
Joined: December 13th, 2016, 4:43 pm
Location: Berlin, Germany

Re: ghype's Coding Problems - Modify Xp Reward

Post by ghype »

thanks ravana & enclave.

(1) defeat_condition=never will do it temporarily, since I do not know what exactly I want with the sides.
(2) {PLACE_UNIT side "Vampire Bat" X Y} worked just as fine
User avatar
ghype
Posts: 1069
Joined: December 13th, 2016, 4:43 pm
Location: Berlin, Germany

Re: ghype's Coding Problems - Ability Work Only On Hit

Post by ghype »

So here is was thinking to use UtbS weapon special Shock, but I have one problem with it lore-wise. The ability assumes the unit is so shocked, that it cannot attack with its full strike, but with one less. The problem is, how can the unit be be "shocked" if the user misses every time? That's why I want to make this ability work only on hit, like slow or poison. I cannot find the default coding for slow but i guess I wouldn have to add more then just a line.

What do I have to do in order to make this special work only on slow?

Here is the code:

Code: Select all

#define WEAPON_SPECIAL_SHOCK
    # Canned definition of the Shock ability to be included in a
    # [specials] clause.
    [attacks]
        id=shock
        name= _ "shock"
        description= _ "When this attack is used on offense, the opponent will retaliate with one less strike than normally, to a minimum of one strike."
        sub=1
        active_on=offense
        apply_to=opponent
        [filter_base_value]
            greater_than=1
        [/filter_base_value]
    [/attacks]
#enddef
User avatar
Ravana
Forum Moderator
Posts: 2934
Joined: January 29th, 2012, 12:49 am
Location: Estonia
Contact:

Re: ghype's Coding Problems - Ability Work Only On Hit

Post by Ravana »

Should not be possible.
User avatar
ghype
Posts: 1069
Joined: December 13th, 2016, 4:43 pm
Location: Berlin, Germany

Re: ghype's Coding Problems - Ability Work Only On Hit

Post by ghype »

You mean it's not possible with adding only one line? That you would need more then just one line?

I can imagine that this could work with some sort of filter that controls wether the opponent unit has a different hp count as before the hit, that should be possible though, right?
User avatar
Ravana
Forum Moderator
Posts: 2934
Joined: January 29th, 2012, 12:49 am
Location: Estonia
Contact:

Re: ghype's Coding Problems - Ability Work Only On Hit

Post by Ravana »

It might be possible with adding one line (stateful lua_function), but I expect you would instead need to simulate entire combat for that.
User avatar
sergey
Posts: 475
Joined: January 9th, 2015, 9:25 pm

Re: ghype's Coding Problems - Ability Work Only On Hit

Post by sergey »

I cannot find the default coding for slow

Here is slow and poison weapon specials. The logic is not coded in WML.

Code: Select all

[slow]
    id=slow
    name= _ "slows"
    description= _ "This attack slows the target until it ends a turn. Slow halves the damage caused by attacks and the movement cost for a slowed unit is doubled. A unit that is slowed will feature a snail icon in its sidebar information when it is selected."
[/slow]

[poison]
    id=poison
    name= _ "poison"
    description= _ "This attack poisons living targets. Poisoned units lose 8 HP every turn until they are cured or are reduced to 1 HP. Poison cannot, of itself, kill a unit."
[/poison]
how can the unit be be "shocked" if the user misses every time?
The unit may be shocked not because it is hit by the weapon. But because the weapon is dreadful. UtbS shock is much more predictable than yours, maybe just use it as is?

If you still want the shock applied only on hit, I can try to code it using events.
Author of SP scenario Dragon Fight and SP campaign Captured by a Nightmare.
Created The Rise of Wesnoth (alternative mechanics) version of the mainline campaign.
User avatar
ghype
Posts: 1069
Joined: December 13th, 2016, 4:43 pm
Location: Berlin, Germany

Re: ghype's Coding Problems - Ability Work Only On Hit

Post by ghype »

hey sergey,
yes i found these and was referring to the logic.
sergey wrote: March 4th, 2019, 9:11 pm If you still want the shock applied only on hit, I can try to code it using events.
that would be awesome. it would save us some time.
Post Reply