Wesnoth 1.11.15 (1.12 beta 5)

[AI]

Bisect says this was fixed in 1e5d58af6a5143f37cd1768f4967bac5b075ccaa.
I'll leave it to someone else to figure out why that is.

[AI]

Fixed by iceiceice in 089ba15ad5f78e8f283f and 0f2777e1679fd09e6.

[GbDorn]

It seems there is useless WML code in AOI scenarios 06_A_Detour_through_the_Swamp.cfg and 07_Showdown.cfg : the variable "difficulty" is defined but not used

Code: Select all

#ifdef EASY
        [set_variable]
            name="difficulty"
            value="0"
        [/set_variable]
#endif
#ifdef NORMAL
        [set_variable]
            name="difficulty"
            value="1"
        [/set_variable]
#endif
#ifdef HARD
        [set_variable]
            name="difficulty"
            value="2"
        [/set_variable]
#endif

This was reported in 2009 along with other useless WML ([ai] code for human side & redundant elvish recruit lists). Those were fixed by Vultraz in master only a few weeks ago. I guess 'Mainline Campaign Feedback' isn't the best place to report bugs.

[Crow_T]

Is this https://gna.org/bugs/?22088 fixed in the latest trunk? Playing with skip AI moves enabled makes the enemy invisible once they move.

[beetlenaut]

Is this https://gna.org/bugs/?22088 fixed in the latest trunk?

Yes. At the bottom of the first page of this thread you can find the exact commit that fixes it.

[Crow_T]

Great news thanks! (it still says "open" on the GNA page hence my question)

[Iris]

You should really be looking at the bug’s Status field (None, Fixed, Ready For Test, Invalid, etc.), not the Open/Closed field. That said, in this case it was indeed not properly marked as Fixed, so I prodded AI0867 about it and it’s all done now.

Also, “latest trunk” doesn’t really mean much anymore, since the development branch is now called ‘master’ and not ‘trunk’. Since 1.11.x development is taking place in the 1.12 branch instead of master, I suspect you didn’t mean master either, which is for 1.13.0 and definitely unsuitable for players at the moment.

[GbDorn]

About petrified units and orbs:
Mainline scenarios TRoW 09 and UtBS 09 use [petrify] and [unpetrify]. Era of Magic has a temporary petrify ability and other UMC also use petrified as a reversible status rather than a way to get cool decorative statues.
So I think petrified enemy units should keep their orbs, as it could lead players to overlook them. They are still potential threats.
Basically everything that can be unpetrified should keep its orb. For units owned by the viewing side, always use 'moved_orb'.

To get decorative statues without orb: maybe implement something like no_orb=yes as WML somewhere ([unit] and [effect]) to override player's preferences.

Also statues should not have a ZoC (I think it's handled by the engine?) nor an ellipse (nor other icons/overlays).
MP scenarios 2p_Caves_of_the_Basilisk.cfg and 2p_Thousand_Stings_Garrison.cfg could use something like:

Code: Select all

[effect]
    apply_to=ellipse
    ellipse=misc/blank
[/effect]

[iceiceice]

IMO, based on my experience with campaigns and umc, it's perhaps not a good idea to treat petrified units the same as other units.

In all mainline mp maps, petrified units are used as statues -- impassable decorations on maps that have some nice fluff when you mouse over them.
In UtBS and the other campaigns you mention, petrified units are not "active" or a threat, and there is no possibility that they can move or attack or be attacked on your turn if they are not unpetrified already.

Petrified units already have very strong visual clues that they are "rocks" and not units. I think it would be perfectly reasonable for orbs only to apply to unpetrified units. If there is UMC where units can be petrified or unpetrified, then fine the orbs may appear when they are unpetrified. I think in most cases this is what would be most useful, even if you like to play with fancy orb settings.

The patch which I wrote (and AI0867 committed) was much more limited than this -- *enemy* statues will not be displayed with orbs. Friendly or allied statues still will. I think its a reasonable middle ground, and it preserves backwards compatibility quite nicely.

You are welcome to your own opinion of course though.

I think for backwards compatibility, it would make more sense to have "orb with statue=yes" as a niche option, rather than "no_orb=yes", since I really think the default should be not to have orbs on a statue. This way not only will we not be forced to edit mainline mp, but umc maintainers won't be forced to either. Please see: http://forums.wesnoth.org/viewtopic.php ... 15#p568600

Alternatively it could be yet another preference setting.

[tekelili]

To compesate bug reports, a congratulation post
I could see the complete replay of a scenario played in my campaign World Conquest II withouth any bug. As my campaign uses lot of WML "dangerous" for replays, that was really unexpected. Good job guys.

[Chief_Chasso]

I've noticed a minor little thing, and I don't know if it's always been this way...

If you're playing a scenario with fog of war, and you open up the status table, under current status, you see whatever enemy leader(s) shown as "unknown" without any of their gold info, etc (assuming you haven't yet discovered the enemy leader). But if you click "more", under scenario settings, the enemy leader(s) names are displayed along with starting gold info, etc. Has it always been this way? Shouldn't the starting info be "unknown" as well?

[SkyOne]

This is not a huge issue, so I just post here:

- it seems error messages point out differently on 1.11.15. In a few days ago, each of errors, missing closing tag and unexpected character, points out unknown unit type error (on mine). And today, I accidentally forgot installing "/" (closing tag) in a [side] tag, but the scenario loaded. I realized something was incorrect on the scenario because the prestart event did not trigger.

I have been creating campaigns since BfW 1.4, so those do not disturb me finding errors myself, but they may make new creators confuse.
I think checking the part is necessary.


thanks

[Iris]

That issue is rather concerning, mostly because it doesn’t make sense unless the files are crossing add-on boundaries. Could you post a zip file with a test case to reproduce it?

EDIT: I got a test case of my own, I’m currently looking further into the issue.

[Turuk]

I had the same thing happen to me last night. I forgot a / in a closing tag and caught it because the action didn't occur.

Shadowm, it was the close of the unstore_unit tag in the event you helped me sort out. Scenario loaded and ran fine, it just didn't run that piece at all.

[Iris]

I may or may not have forgotten to rebuild the server binaries on server2 and server3 after the protocol changes in previous versions, so that is probably why you can’t host games there. I’ll try to get to it sometime this week.

—snip—

Thanks for the report! In the end I didn’t need an elaborate test case like I originally expected, and the issue is now fixed for the next release (commit 0751431d7d310c6e8df71c88c99d6d4d09d159e9 in the 1.12 branch).