1.16 Campaign: A Rough Life - version 1.2.9

[Elvish_Hunter]

Hi. I like this campaign.

Me too

< #textdomain=A_Rough_Life > is missing from the first scenario file and prevents the text from displaying in BfW version 1.10.x. I don’t know what else has to be done to bring the campaign up to porting standards, but I am able to play through without encountering other serious bugs. Are there plans to port? Is anyone working on this?

That's strange... the copy that I uploaded has that line. Unless... you didn't attempt to download and install the 1.6 version on 1.10, did you? And yes, I'm the maintainer and I ported it to 1.9/1.10 some time ago, although the campaign right now is pretty much in a stable situation.
Anyway, to avoid such situations in future, I edited the topic title.

I would be very happy to work up some rewrites if you are interested.

Why not? You are free to work on it, if you want.

[Jamie]

Ack- you're right, I had the wrong version. I just re-downloaded the update. Sorry.

What should I do with edited files? It might be a little while until I have any, but it shouldn't be too long. I do have time now, and desire to work on this.

[Elvish_Hunter]

What should I do with edited files? It might be a little while until I have any, but it shouldn't be too long. I do have time now, and desire to work on this.

Do whatever you want. You can attach them in this topic compressed into a zip file, or you can put the corrected strings into a LibreOffice Writer file and attach it. For me, either way it's OK.

[Jamie]

OK, cool. I'll attach them. I feel I should have thought through this a little better. Hope I'm not annoying you, but I have another question.

I have two sets of amended files now. One set includes just the minimum changes needed for story and dialog re-write (first three scenarios so far). The other includes some additional minor code changes, mostly formatting. These are: added quote marks where missing from non-numerical attribute values, changed 'id=' to 'speaker=' in some message blocks, relocated some attributes and '[story]' code blocks for readability and changed scenario file names to reflect 01_, 02_, etc instead of 1_, 2_ etc. (according to mainline conventions).

I completely understand if you don't want me messing with your stable code. I will happily upload only the bare re-write files. However, if you're open to it, I'd like to offer you the more extensively edited files.

[Jamie]

Something else has come up as I play test my changes.

Spoiler:

In the 5th scenario (More_Hard_Labor) there are three separate moveto events triggering different branches of the dialog tree, but they all share the same name ("moveto"). The result of this is that the same dialog can be triggered over and over by multiple visits to the oasis. It's not too bad to receive instructions for scorpion hunting more than once, but it is disconcerting to have Arbor attempt to clear the already cleared "impassable" peaks. I intend to poke around and see if I can find a solution to this (perhaps the [fire_event] tag in combination with a set of conditionals and a variable counter that keeps track of how many oasis visits occur...

I'm just learning the wml so I'm not sure what would be best. Which is why I'm posting this... do you have any ideas? (I don't know if you're a coder.) I might post the question in the wml workshop, but wanted to ask here first in case this has been discussed and thought about already.

[Lord-Knightmare]

I'm just learning the wml so I'm not sure what would be best. Which is why I'm posting this... do you have any ideas? (I don't know if you're a coder.) I might post the question in the wml workshop, but wanted to ask here first in case this has been discussed and thought about already.

A solution might be to change

Code: Select all

first_time_only=no

to

Code: Select all

first_time_only=yes

. These found within the moveto

Code: Select all

event

tags.

[Jamie]

Thanks for the suggestion. That was my thought at first, but when I changed the value to "yes" the event didn't fire at all. I think that's because there were several separate events with the same name and moveto condition, even though they had other different conditions. I'm not sure, 'cause the documentation is kinda spare. I think I fixed it though by changing an if/then conditional to a "filter_condition" and adding a couple new variables. Seems to work now. I think the code coud be further streamlined if it were put into a switch/case tag set, but that's maybe a task for later.

[Elvish_Hunter]

However, if you're open to it, I'd like to offer you the more extensively edited files.

I'll gladly take a look at your suggestions.

Something else has come up as I play test my changes.

I won't quote the spoiler here. However, are you referring to the moveto event at line 546? If yes, I think that the best solution will be to add an additional variable, that will be checked by [filter_condition] to avoid firing the dialogue more than once. Maybe I should replay the scenario and attempt to trigger every dialogue several times, just to be sure. In the meantime, you can post your fix.

[Jamie]

Elvish_Hunter wrote:

In the meantime, you can post your fix.

OK Here it is:
All line numbers are from the original untouched file.
At:

Code: Select all

    [event]                                             #line 134
        name="start"                                    #line 135
	
	# We already have two variables:
        {VARIABLE arbor_met no}                         #line 141
        {VARIABLE triggered_scorpion no}                #line 142
	
	# I added: - didn't see a way to do it with just one var
        {VARIABLE peaks_clear no}
        {VARIABLE scorpion_dead no}

    # at Scorpion Queen's death:
    [event] 					     #line 514
        name=die 				   #line 515
...
            [else]    			 #line 536
			# I added:
		        [set_variable]
        		    name="scorpion_dead"
        		    value="yes"
        		[/set_variable]

    # at return to oasis:
    [event]    				   #line 545
        name=moveto    		 #line 546

	# I deleted:
        [if]    					          #line 554
            [have_unit]    			     #line 555
                id=Hatrox    			   #line 556
            [/have_unit]    			    #line 557
            [not]				            #line 558
                [have_unit]		        #line 559
                	id=Scorpion Queen     #line 560
                [/have_unit]    		   #line 561
            [/not]    				       #line 562
            [then]    				       #line 563

	    # and
            [/then]    				#line 613
        [/if]    					   #line 614

	# and replaced with
        [filter_condition]
            [variable]
                name="peaks_clear"
                equals="no"
            [/variable]
            [and]
            [variable]
                name="scorpion_dead"
                equals="yes"
            [/variable]
            [/and]
        [/filter_condition]

Elvish_Hunter wrote:

I'll gladly take a look at your suggestions.

I have attached the first scenario to give you an idea of what I'm talking about and the kinds of changes I am recommending, both for story and for formatting. Understand I do not consider this file to be finished. I have a list of things to review and have not run it through wmllint or wmlindent. But you should be able to play it (you may have to remove the leading zero from the file name). I expect most of the comments and original lines will be stripped out before release. The original lines are there so you can easily revert specific lines if you want.

I am working on the last three files now (15a_, 15b_ and 16_ —story elements only) and when I complete them I will post a longish list of other things I want to change, file by file, and some questions I have about some things I don't understand. Then I will begin my review process (for style, dialect and last minute dialog changes), run the wml filters and perhaps make other changes we might agree on to the code (I want to put some of the oft repeated lines into macros and have a few other suggestions). Some of my story edits might seem extreme to some people, but I consider this to be minimal editing. I tried to follow the original plot and tone as closely as possible while punching up the language a bit and fixing a few awkward turns of phrase (except in later files where Kyoko's character is introduced—I tried to make her more interesting).

The formatting changes are all simply to convenience me. Given the editor I use they make the files much easier for me to work with.

[Jamie]

About that fix, I see now that only one variable is needed. My variable "scorpion_dead" merely reproduces what the game already knows and is already encoded in the "not - have unit" condition. Don't know why I didn't see it before. I can't believe it was right there and I deleted it. I guess I was more focused on the wrapper and not looking at the contents. It just came to me as I was falling asleep.

[Elvish_Hunter]

Thank you, I downloaded the file and I'll take a look at it as soon as I can.

I see now that only one variable is needed. My variable "scorpion_dead" merely reproduces what the game already knows and is already encoded in the "not - have unit" condition. Don't know why I didn't see it before. I can't believe it was right there and I deleted it. I guess I was more focused on the wrapper and not looking at the contents

Don't worry. However, from what you posted (I haven't yet looked at the file), it seems like the effect of this block

Code: Select all

            [variable]
                name="peaks_clear"
                equals="no"
            [/variable]

is equivalent to

Code: Select all

[not]
            [have_unit]
                id=Hatrox
            [/have_unit]  
[/not]

or

Code: Select all

            [have_unit]
                id=Hatrox
                count=0
            [/have_unit]

because you just need to kill Hatrox there, not all the units that he recruits.

[Jamie]

Spoiler:

The variable "peaks_clear" is used to distinguish before Arbor transforms the landscape from afterwards so that his dialog can change based on whether the mountains are impassable or not: "clear" here does not mean "clear of units" but "clear for passage" (it could as well be called "pass_open" or "mountains_passable" or some other less ambiguous string).

The code I'm now suggesting for the filter:

Code: Select all

        [filter_condition]
            [not]
                [have_unit]
                    id=Scorpion Queen
                [/have_unit]
            [/not]
            [and]
            [variable]
                name="peaks_clear"
                equals="no"
            [/variable]
            [/and]
        [/filter_condition]

Spoiler:

This filter now prevents Arbor from offering to transform the peaks while the Scorpion Queen is still alive (moving to the oasis will not trigger the event) *and* by setting the variable "peaks_clear" to "yes" at the conclusion of the event, prevents Arbor from making the mountains passable more than once (moving to the oasis once the mountains are passable will not re-trigger the event—the thing that originally drew my attention).

I have been combing through the files assembling a list of things I don't understand that I want to ask about, some things I would like help deciding, and a few suggestions that might improve the code. I had intended to post about this after looking at all the files, but I am bogging down in file 08_The_Shadowlands and it may be some time before I get through them all. I think I will put together a post of remarks about the first 7 files and try to get it up by the end of the day today, or failing that by the end of this week, and resume with 08_ after that. I want to get the process of discussion started because I know it may take quite a long time. I appreciate your encouragement and the time you have already invested in this. I think this could be a great mainline campaign someday!

[Jamie]

Remarks that apply to multiple files or the campaign as a whole:
For starters, a few important questions about the story:
Locating the story in Wesnoth time and space would bring it closer to mainline standards and could be woven into the story line to give it depth. I would love suggestions or votes on the following:

Where is Mosh? It could be anyplace near the coast. We could assume the island is small enough to not show on the general map of Wesnoth. It could be too far south to show on the map, in which case it might be south or south west of the Aethen Forest (Aethenwood), somewhere south of the River Aethen —we wouldn't have to specify exactly where. (The Aethen Forest is said to continue much further south than is currently shown on the map.) Or it could be on the peninsula that forms the northwest coast of the Bay of Pearls, a nice isolated spot off the beaten path with several small un-named islands nearby (in which case we might want to place it on the map). Or it could be to the far north (which might make sense depending on the time period —see next question).

When does this story take place?

Spoiler:

We know only that all races are present and that Arbor and Ruphulus (and the kingdom) have been around for generations (hundreds of years?).

1) The era Taming of the Wild has a period at YW 121 when it is said orcish raids on human settlements resume at the close of an orcish civil war. This would fit the story, but would also mean Bambasan's kingdom was established long before Wesnoth proper or is not as old as it seems.

2) In the era The Turmoil of Asheviere in YW 470 Great Chief Zorlan begins extensive raiding (with orcs and undead). It could be said that the slaving in ARL was to fund Zorlan's war. That would allow the kingdom to have been established during the The Golden Age of Wesnoth (begins YW 200), an age of prosperity and presumably expansion. The kingdom could then be about 200-300 years old at the time of the story. Or its establishment could precede Wesnoth proper and be any age. Somehow I imagined Arbor and Ruphulus a little older than 200-300 (more like 800-900), but it could work one way or the other to place the story in this era.

3) The Silver Age of Wesnoth (about YW 650) has human settlements pushing into the north. That would justify Mosh if it were located much further north than the Bay of Pearls (it would be hard to justify goblin raids that far south during this era). The timeline says of this period:

The Northlands, aided by a second wave of colonization north from Wesnoth, become more civilised and stable. Although nowhere near as prosperous as Wesnoth was during its Golden Age. The Northlands developed towns of significant size and a thriving - if somewhat dangerous - trade network ... competition for the land grew fierce, wars smoldered between human and orcish forces.

which fits our story quite well. The kingdom could then have been established in the Golden age and be about 500 years old or it could predate Wesnoth and be even older.

4) The age of The Legacy of Black-Eye Karun, specifically sometime after YW 843 finds the orcs united and strong and organized enough to support the kind of slaving we have in our story at any point along the coast. This was

an unprecedented era of unity and prosperity for the orcs.

This would allow a span of almost 650 years from the Golden Age, a good amount though I still think of A and R as being older than this. Mosh is unlikely to survive in the far north during this era, but could be by the Bay of Pearls or off the map to the south.

5) Some later date. YW 1050 (or so) would give us a solid 800 years from the Golden Age. The story has to take place sometime before the Fall, however, or the graphics and maps for the Mosh segments would have to all be redone as desert.

What is the name of Bombasan's kingdom? It could be anything. There are many dialogs that refer to "the people who live in the caves" "Kyoko's people" etc. It would be a real help to have a name for this place. A few suggestions: "Erresuma" or "Arresuma"; "Arfordirol"; "Tanndaerol"; "Dreynas"; "Kythonia" or "Cythonia"...

Where is Bombasan's kingdom? I assume it's far to the south (assuming Wesnoth in a northern hemispere) because it would be hotter there and more likely desert, most likely on another continent entirely (there is no desert indicated on the map of Wesnoth that I can see). This could be otherwise, of course. For plot reasons, J's journey should take years (the story currently has it as weeks only), so I think it shouldn't be too close to the Wesnoth mainland. But the desert could be attributed to magic so it could be anywhere near a coast.

Code that applies to more than one file:

"#result=continue" appears in 01_, 02_, 06_, 10_, 12_, 13_, 14_, 15_, 15a, 15b and 16 (with "_no_save" appended); is this a custom "result" value that's not being used or an obsolete value the game used to recognize but no longer does? (The documentation I have seen only recognizes "victory" and "defeat" as predefined "result" values.) Is there a reason to keep this in the files? Obviously the game works with this commented out as it is.

{ai/aliases/stable_singleplayer.cfg} exists in 01_-05_; 07_-09_; 11_ and 13_-15_, but not the other files. No such inclusion of "stable_singleplayer.cfg" is utlilized in mainline campaign scenarios or other working UMC that I sampled, and I can't figure out its purpose. As far as I can tell it simply points to the CA (candidate actions) defaults (which are set anyway by default, I think). I don't really "get" the ai code... but this looks unnecessary. Does it have a function? Is it an artifact from a previous game version?

"income=0" —income defaults to zero so I think this attribute is redundant. It's not hurting anything, but could be removed. All the scenarios where J might actually have a non-zero income use {INCOME x y z} instead. (applies to 01_-04_, 06_, 07_ and 10_)

Var "Jacques_store" {VARIABLE Jacques_store 0} is defined in scenario 01_ and then does not appear again until scenario 05_ where it is cleared {CLEAR_VARIABLE Jacques_store}, but not apparently used for anything else. It is again cleared but not apparently used for anything in scenarios 09_, 11_, 13_ and 14_ and appears nowhere else in any file. Is this a persistant variable that keeps track of J's level? If so, how/when is the information used, what happens when the var is cleared and is it automatically reset to current values at each unit status change? Does it do something else altogether that I don't understand? Or is it an artifact from previous code that is no longer used?

Lt. Popper is currently modified to loyal with no random traits but could be assigned "no upkeep" with "canrecruit=yes" and allowed random traits making five lines of code into one. Is there some reason to prefer the current more verbose code given that the player never controls Popper? (applies to 02_ and 07_)

Remarks on Specific Files:

01_Led_Astray:
There is a message displayed that encourages the player to kill Jabb for a bonus. If I wait for that message to display I find it very difficult to kill Jabb for the bonus. On the other hand, I can kill Jabb easily if I move straight away on turn 1 to ambush him. Perhaps I'm just not that good a player, but when I wait, J's side is too weak and has too many opposing forces on the map to reach and kill Jabb. Jabb could abandon his patrol route and pursue Jacques after his third or fourth patrol, giving the first-time player a better chance at him. What do you think?

Two "attack" events and a "last breath" event have nested "if" statements that check two conditions, one condition per if statement. In each case this could be reduced to a single "if" statement that checks both conditions using "and" tags. The code is not broken, it works fine, but it could be less verbose and more readable.

Can Jabb's patrol code be simplified using the existing lua patrol macro from "ai/lua/patrol.lua" ? (I will look into this later if I have time and motivation.)

02_Captivity:
Add a "user_team_name" for side=1

03_Hard_Labor:
Deleted the line setting up J's insight that the caves have no bright light because he is never in the caves long enough to find this out. Unless you count the march in from the ship, which I don't, he goes immediately to sleep and then immediately outside the next morning and then immediately to sleep once again. He is never in the cavern at noon time or awake long enough to make such an observation.

04_Unrest_in_the_Ranks:
Deleted the insight J has regarding the bright light in the caverns. Jacques has been outside all day. He has only been in the caverns at night sleeping. It is not logical for him to have this insight and having it does not affect the plot.

Why is Gronar given "random_traits=no"? He just dies right away so it makes no difference so why waste a line of code on him?

Why do we give J new loyal units instead of recalling existing loyal units? does player need this many loyal units to run the campaign? (It's not a big deal, I'm just asking if this is a game balance issue that has been thought about, or is it accidental.)

05_More_Hard_Labor:
#profile="portraits/Arbor.png" -what happened to the arbor pic? Is there a reason to leave this comment in?

#ai_special=guardian —Currently neither Hatrox nor the Scorpion Queen are guardians (they move freely) as this is commented out for both of them. Allowing Hatrox this freedom makes him very easy to kill. As soon as the mountains are made passable he comes out into the desert to attack, where it is easy to surround him and finish him off. In contrast, giving the Queen this freedom makes her slightly more difficult to kill if she seeks (or is pushed to) the edge of the map where she cannot be surrounded, or flees to the fort and has to be chased. I think it is better if H stays in the mountains, but his range is so great that I don't think making him guardian will make much difference unless his range is reduced. He needs enough range to attack units approaching his nest on the path while the mountains are still impassable. I think what would work is to make him guardian and then modify him to a severely reduced range when Arbor opens the peaks. I think the guardian attribute should stay off for the Queen and the comment can be removed.

I think placing and then removing the small live pine tree in the center of the oasis is an artifact from before the shroud was removed on turn 2 and the oasis event trigger was expanded from the center hex to surrounding hexes. I don't think we need to keep this.

Why is the S. Queen placed hidden at 1,1 then unhidden and teleported to 19,18 ? Why not place her directly at 19,18 in her side tag and hide her there? Is there a problem revealing her later if a unit occupies her hex that is solved by teleporting her in?

We have already discussed the multiple triggering of the "moveto" event where Arbor transforms the peaks. I believe this is solved.

Wesnoth naming conventions prefer "Elvish" over "Elven". I have modified unit files Elven —> Elvish for the Maiden, Princess and Queen unit definitions to match the convention.

Kyoko is defined to be an Elvish Princess (level 2). I think that means the Elvish Maiden unit is not used anywhere in the campaign. I think it would be better to start her as a Maiden and let her advance in this scenario as she did in a previous campaign version. Why was it changed? I would mod Kyoko so she can fight weakly so that she can advance. I think it is frustrating to the player to have a unit that can't participate at all and I think this forces her character into an unattractive passivity and helplessness. I think her illness is adequately represented by reducing her combat stats and hitpoints. I understand there is still a potential challenge in protecting her even if she can't fight, but if she is going to be completely incapacitated, I would prefer she is simply removed from the map altogether along with Arbor. I would reduce all her combat stats to 1-1 whether she is Princess or Maiden (attacks: -2 for melee and -4 for ranged and -80% damage).

Additionally, on the subject of Kyoko, I think she should receive damage while in the desert during daylight with a mechanic similar to the one in Under the Burning Suns. I would not let her heal in this scenario since she has been ill so long (or let her heal only 1 point per turn when adjacent to an auger to counteract the ongoing harm from the daylight but keep her hitpoints very low). But in later scenarios I would let her heal normally by village and auger while she takes damage every daylight turn.

In the "post_advance" event the variable "transition" is both cleared and reset {CLEAR_VARIABLE transition} and {VARIABLE transition 0}. What's the difference between clear and reset to zero? Why do both? Why isn't the reset sufficient?

Do {CLEAR_VARIABLE Jacques_store} and {STORE_UNIT_VAR id=Jacques type Jacques_type} have anything to do with one another? I'm having trouble seeing how these variables are being used.

06_Seeing_the_Light (conversation only):
victory_when_emenies_defeated="no" - this can't be required since it's spelled wrong (emenies) so it can't be working yet the scenario works fine!

07_Confronting_the_Traitor:
Relocated R's teleport to better match narration. As it is it says he jumps instantly and then a little while later he jumps.

Changed "speaker=unit" to "speaker=Jacques" in J's last breath where he speaks his death line (just for clarity and consistency—it works fine as "unit") (Same with K's)

Unit Recall:
In "prestart", after objectives are defined, loyal units are recalled individually and placed on specific map locations; then in "start" a separate "if" statement checks to see if each loyal unit exists (was recalled) and if it wasn't, creates a new unit of similar type to take its place for that location. But since this happens in "start", the player may potentially see the map with some loyal units already recalled and watch while other new units are created. We want (I think) to move this all to "prestart". The easy way would just be to move all the "if" blocks for all the units from start to prestart with no other change. But with "search_recall_list=yes" within the [have_unit] tags of the "if" statements we can (I think) recall units that are found on the recall list or create new ones all within the same "if" statement like so:

Code: Select all

        [if]
            [have_unit]
	            search_recall_list="yes"
                id="George"
            [/have_unit]
            [then]
	        [recall]
    	        id="George"
        	    x,y=5,9
        	[/recall]
            [/then]
            [else]
                [unit]
                    side=1
                    type="Spearman"
                    x,y=5,9	# was 6,10
                [/unit]
            [/else]
        [/if]

(I think this will work; I haven't tested it yet.) The advantage is to have all the recall and placement code simplified in one location in "prestart".

Kyoko is treated the same way when recalled, but Kyoko can't not exist since her loss ends the game, so we don't need to check if she exists before recalling her, do we?

There is a stray side=1 attribute that should be inside the [objectives] tag but was left outside.

Later this happens:

Code: Select all

            type=Orcish Grunt
            message= _ "Seeing him drink the blood of Lieutenant Popper made even me cringe."

but if Carl has advanced, this won't trigger and the line is missed. That could be deliberate, but I like the line and would like advanced Carl to say it if he exists, so I suggest:

Code: Select all

        [if]
            [have_unit]
                id="Carl"
            [/have_unit]
            [then]
		        [message]
        		    speaker="Carl"
        		    message= _ "Seeing him drink the blood of Lieutenant Popper made even me cringe."
        		[/message]
        	[/then]
        	[else]
		        [message]
        		    type="Orcish Grunt"
        		    message= _ "Seeing him drink the blood of Lieutenant Popper made even me cringe."
        		[/message]
        	[/else]
        [/if]

Finally, "wardrums.ogg" is set to "repeat=5" so they will play to the end of scenario (the final message implies they are still playing), but that may not be long enough (it ran out on me at least once, when I was distracted and did't finish the scenario quickly) so I suggest:

Code: Select all

        [while]
        	[have_unit]
        		id="Jacques"
        	[/have_unit]
	        [do]
		        [sound]
		            name="ambient/wardrums.ogg"
		        [/sound]
	        [/do]
        [/while]

to ensure it continues playing until the end. (not yet tested)


Misc. Remarks:
Do we need to keep distributing the file "units/compatibility.cfg"? It has this comment:
# this file has the only purpose of allowing me to use my old savegames.
Is this yours, Elvish_Hunter or is it Jacques_Fol's?

[Elendil]

Wow, that's a nice feedback here

[Jamie]

I spent several hours reading up on the AI and I now understand what {ai/aliases/stable_singleplayer.cfg} is supposed to do, so don't waste your time trying to explain it to me.
I have decided to spend more time play-testing the first half of the campaign (and trying to answer my own questions) before looking at the second half. I did find a couple more minor points concerning ending level "01_Led_Astray":

Spoiler:

The level ends when Jacques is captured (killed), or when J kills the Goblin trader or when turns run out. The only loss is if capture happens before turn 15. If the level ends due to timeout, there is a white flash and lightening sound. I think I would expect such a dramatic effect more on the loss condition or if J is "knocked out" (captured by having hit points reduced to zero). I think I would remove the effect altogether, but if we want to keep it, I think it should apply only when J's hit points are reduced to zero. By the way, killing the Goblin Trader before turn 15 is not a loss for J. He advances immediately to the next scenario. It is possible on easy difficulty to accomplish this by turn three or four. I think killing the Goblin Trader before turn fifteen should either be a loss, or have no level ending effect. Killing him after turn 15 could advance J immediately to the next level as it does now.