Legend of the Invincibles

[fdsfsfdsjkljkl]

Funny story: hopefully this might help anyone who runs into this problem with LotI and Wesnoth 1.13.0

I got my hands on a copy of 1.13.0 to start testing out the new rules for [unit] and AMLA. I tried to get to "An Orcish Attack" to test out units with AMLA, but I ran into a Wesnoth bug which made the tutorial impossible to finish! You'll be able to craft the sword using 3 obsidian, but nothing will happen after that. You can continue to craft as many swords as you like but you won't be able to advance the scenario at all.

I've already found the cause and filed the bug ( https://gna.org/bugs/index.php?23545 ). The workaround is fairly simple: just add a [clear_menu_item] command right before redefining 3dropping with [set_menu_item]

[Dugi]

Strange, I am using a self-compiled version of wesnoth 1.13.0 ( exact version was Battle for Wesnoth v1.13.0-dev (7469c71-Clean)) and I wasn't able to replicate that issue. I am using Ubuntu, that is very similar to Debian, but no such error. But I had a similar problem in that scenario on 1.10, one message repeated itself and then it crashed, I changed the code until it ceased to happen because the cause was obviously a bug in wesnoth and I wanted to fix the erroneous version of my campaign asap, and forgot to keep a version where it could be replicated.

I have fixed that typo you mentioned previously.

[dabber]

Pure intuition here...
I think that if suck has some cap related to actual damage (25% or 50% or whatever), then further reduction in item suck numbers is not necessary. Although I haven't examined exactly what values you changed. It feels most broken to me not in normal circumstances, but in worst case circumstances - When facing a highly resistant enemy AND slowed, my damage output drops from ~20 to ~7, but suck is unaffected. If the suck amount dropped, the worst case would have a measurable impact.

Maybe do 50% cap on easy, 33% on medium, 25% on hard? Or should difficulty level not have that much impact?

Dugi, from a design perspective, how valuable do you want the weapon special leech ability to be? It is rare, it seems very good, but suck is better. (Or maybe you really don't have an opinion!) I think capping suck at 25% makes leech relatively better, while capping suck at 50% does basically nothing to the relative value of leech.


Dugi, minor bug
The code for whirlwind AoE pops the floating text for leech and drain healing even if the healed amount is 0. I see lots of floating 0s.
I also sometimes see green decimal numbers pop up (like healing), but I cannot name exact circumstances right now. But I think fixing the above (do the floating text only after calculating amount of hitpoints gained) would fix this one too.

[Whiskeyjack]

Maybe do 50% cap on easy, 33% on medium, 25% on hard? Or should difficulty level not have that much impact?

I like this quite a lot, seems like the perfect choice to me. For easy its not that much of a nerf, but if you want to play hard, you will feel it.

[Dugi]

I think that if suck has some cap related to actual damage (25% or 50% or whatever), then further reduction in item suck numbers is not necessary.

I meant it as an alternative. Either reduction in numbers or reduction in cap.

Maybe do 50% cap on easy, 33% on medium, 25% on hard? Or should difficulty level not have that much impact?

That would end up as a version of leech with a maximum value, I fear. That is why I support more the possibility to severely reduce all suck values on items.

Dugi, from a design perspective, how valuable do you want the weapon special leech ability to be? It is rare, it seems very good, but suck is better.

Leech gives you an input once for all, suck has to be built up. However, you see that because of this design issue, suck is stronger even on low levels.

The code for whirlwind AoE pops the floating text for leech and drain healing even if the healed amount is 0. I see lots of floating 0s.

That happens also if a draining attacks hits for 1 damage and heals 0 life, it's just rounding and that one is a but ugly in WML.

[nuorc]

The advancement window opens before the unit advances.

That reminds me: I'm not really happy with the AMLA-window; I often can't see all attacks and abilities, sometimes I can't even see what effect my choice has. If it's going to be worked over, maybe you could have this in mind?

I think it would help greatly if the window was scrollable and would include tool-tips like the main window; regarding the latter I also made a feature request, but haven't heard anything.

[dabber]

Dugi, I just downloaded the current server version and comparing it with my local copy I find a few things:

abilities.cfg
You removed Horror entirely. But the Deathlord unit still has an AMLA that replace Horrid with Horrid (it needed to be fixed to replace Horrid with Horror).

abilities_events.cfg
line 1827 uses the variable "has_lehargy" instead of "has_lethargy"

below edited into spoiler because it was blatantly wrong

Spoiler:

amla.cfg
Why nerf the Tome of Liches shadow wave from 21-1 to 9-2?

items
You significantly nerfed Ring of Unearthly Existence by dropping damage from 40 to {30 20 10}. Is that item actually good? Those resistance penalties are big enough I have never considered equipping it.

[Dugi]

You removed Horror entirely. But the Deathlord unit still has an AMLA that replace Horrid with Horrid (it needed to be fixed to replace Horrid with Horror).

I thought it was too strong and very similar and confusing with another ability. I have left that AMLA there accidentally, it won't be there anymore.

line 1827 uses the variable "has_lehargy" instead of "has_lethargy"

Why nerf the Tome of Liches shadow wave from 21-1 to 9-2?

You aren't very good at reading diff outputs, are you? I actually boosted it from 9-2 to 21-1. I have done this because I wanted the book to be somewhat useful to units who have shadow wave already.

You significantly nerfed Ring of Unearthly Existence by dropping damage from 40 to {30 20 10}. Is that item actually good? Those resistance penalties are big enough I have never considered equipping it.

No, I haven't. I have increased the damage to 40 from 10-30 depending on difficulty.

[dabber]

Good catch ... I'm not very good at reading diff outputs today. Maybe because I'm checking several dozen file revisions this morning (real work).

[Spirit_of_Currents]

I support more the possibility to severely reduce all suck values on items.

I agree.

I'm surprised because you didn't reply to my suggestion about whirlwind. You didn't even say "I won't implement it". I suggested to make whirlwind give the attacker the average XP it would get if it attacked a random adjacent enemy with the same attack but without whirlwind special. This way it would always get the same XP, no matter who is the primary target (unless the primary target affects number of strikes performed), and not too much XP.

[Dugi]

I'm surprised because you didn't reply to my suggestion about whirlwind. You didn't even say "I won't implement it".

I have forgotten to write about it, sorry. As a recompense, I am writing a detailed response.

That thing is quite hard to implement, changing experience deals with advancing and it's like a Pandora's box for me - I have some hacks there dealing with things that happen in quite a strange way and every time I touched that, something broke and it took me long to fix it.

Furthermore, there is a small oddity - imagine a model situation when you have a level 15 unit standing next to two level 12 units and you attack all of them with whirlwind. You'd get experience like for attacking a level 13 unit, fine. Now, imagine that a level 1 weakling approaches and stands next to the spot from which you attack these three units. The average level is now 10. Means that by having a totally neglectful unit move in the way, your experience gain drops.

[fdsfsfdsjkljkl]

I've been looking into the AMLA/save file bloat problem you mentioned. I've gotta say, you weren't kidding when you said this was a hard problem.

It seems like the major issue is that a WML save game encodes the state of the game directly, without relying on very many references to files contained in the add-on directory. Making the problem even worse is the fact that the WML save game format can include 4 different identical copies of the same game logic. In a typical mid-scenario save, the item list (all 284.5 KB of it) is stored in the [carryover_sides], [carryover_sides_start], [replay_start] and [snapshot] sections. For this specific scenario, it meant that 31% of the save game data was purely duplicated copies of the item list.

GZip compression means that the 4 copies of the item list won't use too much space, but loading the file will still require decompressing and parsing all 4 copies of the item list. I'm assuming this type of problem is what causes the major overhead in save / load times: creating the large file to pass on to be gzipped. AMLA would be even worse than the item list, since the list of all AMLA would be stored once per unit per save file section instead of once per save file section.

The AMLA solution you came up with was extremely clever. It's easy to understand and solves the problem fairly well. I don't fully understand what you mean when you said this though:

And the greatest problem is that unstore_unit discards all changes to the AMLA list the unit has on versions before 1.13.

Can you give an example of how this might cause an issue on systems before 1.13?

As far as the fix goes, I just wanted to confirm the high level strategy with you:
* Units now only have one unit type, not two (Name / Advancing Name). The new singular unit type has no AMLA.
* There is now a dummy unit type with various different AMLA stored somewhere in the add on folder. This unit is never stored in save games.
* When a unit with AMLA advances, a "pre advance" (new in 1.13) event fires. This event copies the AMLA from the dummy unit onto the advancing unit.
* The advancement occurs and the user selects the desired advancement.
* A post advance event fires and removes the AMLA choices from the advanced unit (preventing save file bloat when this unit is saved).

Also: this may not be helpful to you, but I wrote a quick python script to understand the problem with save file bloat. It's a quick hacky CLI tool which allows you to interactively inspect the contents and relative sizes of different parts of a WML save file. The only non-standard dependency is the 'tabulate' package. I've uploaded it gzipped since the .py filetype isn't allowed.

inspect-wesnoth-save.py.gz

(1.31 KiB) Downloaded 103 times

[Dugi]

I tried to run that script, but I could not find the tabulate package anywhere. I could not improvise because I have never learned python (I make scripts in C or C++, I know it's an overkill, but they're really really fast).
It's interesting what you've learned, I have never properly investigated what is there how many times, just did some haphazard research every time I had a suspicion something was not okay (bloaters are extremely easy to find there by definition). As a result, I have not noticed that the item list is placed there four times. I am thinking about finding all cases where it's used, creating it from a unit type, using it and deleting it, it's not that large, a few hundreds kilobytes and copying a megabyte in RAM takes like a millisecond anyway.

Actually, repeating the same thing over and over increases the size of the gzipped file, the algorithm seems to be sacrificing some efficiency for adaptability and does not work exactly in that way.

The problem with unstore_unit discarding all changes to the AMLA list the unit has on versions before 1.13 is that it's not possible to simply change the list of AMLAs a unit has before 1.13, because any changes to it are discarded when I try to unstore that unit. I have to change the unit_type (firing an additional advance event that has to be handled), and revert it afterwards (firing an advance event again). Furthermore, these secondary unit types have to be identical to the original unit type in all other ways, increasing their size in memory and causing mess when indexing what units advance to (there are more workarounds to handle them, but it always happens that somebody uses debug mode for whatever, breaks it and ends up reporting it to me). On 1.13 and onwards, it's possible to change the list of AMLAs the unit has.

Your confirmation is mostly correct, with one small mistake: I think it's better to create a dummy AMLA holder unit for every unit type (based on something like global_event_loader, a minimalistic nothing), not a common one, I think it's significantly faster like that for very little additional RAM occupation.

[dffou]

Dugi, I had encountered an AI problem while fighting with demons(and only demons), the game got compeletly stucked for several minutes then resultat in a <lua error>:not enough memory.
I did some tests and I found that it usually happens when a demon with 'furious' trait(who has swarm attack) decides to attack with melee weapon but will probably get killed by counterattack.

I was playing wesnoth version 1.12.2

[fdsfsfdsjkljkl]

Great news! It looks like the AMLA scheme we've been discussing will be viable in 1.13. Even better, it'll be extremely easy to maintain compatibility with older versions of Wesnoth, since the only code that needs to change is the event for handling advancements (global_events.cfg, around line 600-700ish).

I've gone ahead and made a proof of concept demo system to show how this would work. It's not ready for real use, but it shouldn't require too much work to be ready to go. I'll explain it here -- please let me know if you see any major issues.

First, you need a pre advance event to clear out any advancements that a unit has and then add in the correct advancements. Note that in the real version of this code we would use "Advancing " + the unit type. I'm using test_amla_unit just to verify that things work:

Code: Select all

    [event]
      name=pre advance
      first_time_only=no
      [store_unit]
        [filter]
          x,y=$x1,$y1
        [/filter]
        variable=advancing_unit
        kill=no
      [/store_unit]
      [lua]
      code=<<
        function clear_advancements(unit)
          for i = #unit, 1, -1 do
            v = unit[i]
            if v[1] == "advancement" then
              table.remove(unit, i)
            end
          end
          return unit
        end 

        unit = wesnoth.get_variable("advancing_unit")
        unit = clear_advancements(unit)
        local u = wesnoth.create_unit { type = "test_amla_unit" }
        for i, v in ipairs(u.__cfg) do
          if v[1] == "advancement" then
            table.insert(unit, v)
          end
        end
        wesnoth.set_variable("advancing_unit", unit)
      >>
      [/lua]
      [unstore_unit]
        variable=advancing_unit
        find_vacant=no
      [/unstore_unit]
      [fire_event]
         name=advance
         [primary_unit]
           id=$advancing_unit.id
         [/primary_unit]
      [/fire_event]
    [/event]

Second, you need a post advance event to make sure that all the advancements you added are then removed:

Code: Select all

    [event]
      name=advance
      first_time_only=no
      [store_unit]
        [filter]
          x,y=$x1,$y1
        [/filter]
        variable=advancing_unit
        kill=no
      [/store_unit]
      [lua]
      code=<<
        unit = wesnoth.get_variable("advancing_unit")
        unit = clear_advancements(unit)
        wesnoth.set_variable("advancing_unit", unit)
      >>
      [/lua]
      [unstore_unit]
        variable=advancing_unit
        find_vacant=no
      [/unstore_unit]
    [/event]

For reference, here's the dummy advancement unit I used:

Code: Select all

    [unit_type]
      id=test_amla_unit
      name="test_amla_unit"
      [advancement]
        id=amla_test_three
        description="This AMLA was pulled from a unit!"
        max_times=99
      [/advancement]
      [advancement]
        id=amla_test_four
        description="Don't choose this AMLA!"
        max_times=99
      [/advancement]
    [/unit_type]

I'm not entirely sure that this system handles advance events properly, but it definitely works for the purpose of keeping save games free of AMLA bloat. Any AMLA not selected is kept entirely out of the save game file.