You are not logged in

It is the leader's id, not the side one's. Sides don't normally have an id, unless the wml author explicitely specifies a save_id. We could make specifying a non-empty save_id for persistent sides mandatory. If it's not given, stderr message and exit. wmllint could also check it for existance. (For my own campaign I decided that it's mandatory long ago.) This could potentially avoid bugs such as http://forums.wesnoth.org/viewtopic.php?f=6&t=38774&

I recall someone adding [side][leader] but it's not documented in the wiki.

No, I didn't notice that. From what Crab_ said, I understood that patch such as the first of mine (and probably ayne's patch?) is duplication of the carryover code to other places, and it should be handled just there to avoid maintenance problems.

Judging by the code, I think that we already rely on one of those tags being non-empty. For example:
-transfer_all_to (gamestatus.cpp) checks save_id or id
-teaminfo::read does the same

However, if there are so many ways to just set the side id, then what would you suggest instead?

Did you notice that meanwhile ayne committed a different fix, probably without knowing about this ? (commit 0d2eeeeeefaa8fa87d2861d0ed1011574fda5495)

I think one can't rely on at least one of [side]save_id= or [side]id= not being empty. The leader could also be given by [side][leader]. Perhaps even [side][unit] would work. Or not giving the leader a manual id at all (which is bad of course, since you then cannot reference it).

Thanks for the patch, but I'd prefer this fixed in a different way. Carryover code should be responsible for setting the gold to default value. That code is located in gamestatus.cpp, and it has the 'set gold to default value' logic. The problem is that this carryover-to-next-scenario code is NOT called before first scenario, but, I'd say that it should be called.

"I also added gold=100 for SoF:1 for clarity."
I rather wouldn't want that (from the UMC author point of view). Using conventions in mainline tends to outsource workload onto UMC authors, since their addons have the more unusual wml then. Only the fact that this wasn't there made it possible to discover and reproduce the bug with a mainline scenario.

Copyright (C) 2004-2006, the Gna! people. Posted items are owned by whoever posted them.
Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.