The Battle for Wesnoth Forums

Iirc it was a intentional choice not to add an option for it, because it makes cheating easier (because it used deterministic rng) and also because it changes balance (for example elvish shamans have a 100% (instead of 75%) chance to slow the enemy on 50% defense. On add-ons I'm not sure, there prob...

I don't think so

alternativeley you could ask the author of the umc reousrce pack to include a [resource] in your addon that your add-on can then load with [load_resource] which will let the engien know that your scenario uses that other addons stuff. This of course needs the involvement of the other addons author, ...

hmm did allthe warnign disapearor after you added auto_remove or is it judt less spammy?

the (c++ from ravanas link) code is still strange tho, firstly it _seems_? to even give this warning if the leader has no moves left which on first sight seems to be a common sceanrio that shouldnt give a warning, also in case that there are actually no leaders the warning is not given since it retu...

I think it's a known issue, but we don't know what causes it. It would be very helpful if you could give us a way to reproduce. Especially if it happens again

Also: what Wesnoth version and operating system are you using?

i wonder why we even mention [on_redo] in the wiki, it wasn't supported in any stable release

yes that correct, only the "orignal" action is put on the unit stack

(actually i see little reason why it shoul dbe that way, i think we could drather easily make for examle [move_unit] call [on_undo] internally to add itself to the undo stack)

Regardless of the value of first_time_only and presence or absence of [allow_undo] this event was resolutely undoable, probably because the [move_unit] command inside {MOVE_UNIT ... clears the undo stack? I dont think move_unit cleaers the undo stack, its imo much more likeley that since the moveme...

So what that means in general is that only events with first_time_only=no (and which never remove themselves) should be undoable. This is only partly true, very simple events that only show messages can be undoable (and mainline does that, thinkof messages like "this sign reads 'swamp ahead' w...

When undoing an action, the game stores the players action in that stack and also all "choic-type" actions (like which [option] the player chose) that were recorded while excuting the action. Then the redo code is basicially the same as the replay code, so it takes these actions and "...

When running the original code undo didn't work. When I disabled allow_undo (IIRC, I did a lot of testing and rewriting and am not clear now what changed when) undo worked (for later actions IIRC) but doing several actions, undoing them then redoing them crashed Wesnoth. pre-crash.png After this sc...

In was actually thinking of moving it into the "side x turn 1" event and adding a "view-map" button to it (I did something like that in my "PYR no preparation turn" add-on once.or maaybe ad eitger anither event or add a Lua/emo function to show the objectives dialog. So...

Wouldn't it be better to have the bonuses picked before recruiting? Or if there is some obscure reason for this mechanic at least create the recruit after picking bonuses. It's a small thing but it irritates. As does the interruption of the recruit sequence. I mean you go to recruit and BAM you sud...

OK, then this would work (assuming all the units are on the map)? local function compare_hp(a, b) if a.hitpoints > b.hitpoints then return true elseif a.hitpoints < b.hitpoints then return false elseif a.x < b.x then return true elseif a.x > b.x then return false elseif a.y < b.y then return true e...