The Battle for Wesnoth Forums

The one thing I'd be wary of is making the new southern parts overly massive. I've noticed that when expanding maps, usually geographical features tend to get bigger and bigger; in this case, there's an absolutely gargantuan desert that's about as big as the whole previously known part of the contin...

If you're familiar with GIMP you might also be interested in this (with all the mentioned caveats withstanding).

For starters, use quotes around formula expressions: greater_than=$($henry_x-3) #no greater_than="$($henry_x-3)" #yes Otherwise you'll run into trouble with + signs being interpreted by the preprocessor as string concatenation, and possibly other issues. That might or might not be the (only) cause o...

It's a known issue, problem is that it's cumbersome to fix since we still want some of the adjacent trees to get drawn over units. It hasn't been fixed yet pretty much because it happens very rarely. Although, admittedly, we could just tweak a few of the forest images to remove the small trees that ...

You are correct, it's more or less what otzenpunk above mentioned. To quote myself Perhaps its a reason I blame the RnG, because I was frustrated at this scenario, trying to complete it with bad strategy, thinking its the scenario's RnG design that is broken, not my strategy. (well, at least now I ...

For what it's worth, I think the thread is fine; you've posted a link to the first scenario's feedback thread, so it's not like this can get magically lost in a few months. Anyway, one point in particular sounded odd: The main issue with this scenario is that it is really broken. Like, unlike the re...

I'm afraid there isn't one.

EDIT: I seem to recall that someone did paste all the mainline maps together to create a collage of sorts, but of course it's pretty rough and I'm not sure how to find it anyway.

It does. If it's a 72x72 image and you want it to get drawn behind units, use image= instead of halo=.

I'm pretty sure the reason is kind of twofold: 1) If the scenario starts with wounded units on the map, healing would/could happen immediately at scenario start (possibly including rest healing?), which would feel weird in side 1's case. And if side 1 doesn't get healing on turn 1, then no other sid...

And in this case you don't even need to store the unit yourself; in events with a primary unit (such as enter_hex etc) you have the auto-stored $unit variable/container available, so something as simple as this would do: [set_variable] name=unit.moves value=0 [/set_variable] [unstore_unit] variable=...

Shiki wrote: ↑September 13th, 2018, 3:53 pm

Code: Select all

  {VARIABLE $unit.moves 0}

Except that should be:

Your moveto event filter also includes terrain= which means nothing in a StandardUnitFilter unless wrapped in a [filter_location] tag (which is what you want to do there).

This gave me an interesting idea. Is it possible to write around this, so there's no story conflict? So, what if a large portion of the Sleepless Sea periodically receeds for several decades and the seafloor is exposed, along with the ruins there. I don't see why not, besides possible objections so...

You probably need to manually (re)set the unit.status.uncovered status to "no" as well.