Campaign: Saving Elensefar

Discussion and development of scenarios and campaigns for the game.

Moderator: Forum Moderators

Post Reply
marat
Posts: 46
Joined: November 21st, 2012, 9:12 am

Re: Campaign: Saving Elensefar

Post by marat »

Russian translation of campaign for BfW 1.13
Attachments
wesnoth-Saving_Elensefar_BfW_1_13.zip
.MO+.PO for BfW 1.13 (30.07.2015)
(114.86 KiB) Downloaded 568 times
Pags
Posts: 39
Joined: January 19th, 2016, 5:56 pm

Re: Campaign: Saving Elensefar

Post by Pags »

In the othello (swamplands) game, I have all the enemy's pieces (31:0), thus no one can move. No winner is declared, regardless of if I move the character or just immediately hit "end turn". I tried to add chips to the board one at a time, but obviously all moves would be invalid. Nor does the game end if the turns are advanced beyond 32 "moves" each.
Version: 1.12.6
SE-The_Swampland_replayOthello.gz
(36.1 KiB) Downloaded 546 times
SE-The_Swampland_Turn_15ergssreg.gz
savegame...finished
(80.09 KiB) Downloaded 511 times
User avatar
singalen
iOS Port Maintainer
Posts: 314
Joined: January 3rd, 2007, 10:18 am
Location: bay

Re: Campaign: Saving Elensefar

Post by singalen »

This campaign is present on 1.13 server, but is not 1.13 compatible.
Is there anyone who supports it now?
Thanks.
User avatar
James_The_Invisible
Posts: 533
Joined: October 28th, 2012, 1:58 pm
Location: Somewhere in the Northlands, fighting dark forces
Contact:

Re: Campaign: Saving Elensefar

Post by James_The_Invisible »

The add-ons server says that it is maintained by trewe (it is written in author field). His last post is from 2015 but you can try to PM him.
Salex
Posts: 20
Joined: October 15th, 2017, 4:52 pm

Re: Campaign: Saving Elensefar

Post by Salex »

Their are also ERA's that break Era's example Era of Chaos breaks Era of Myths.

I download era of myth and play it, I download era of chaos then I can't the add-on dissapeers from the multiplayer screen
zx_specy_gamer
Posts: 7
Joined: April 2nd, 2017, 4:04 pm

Campaign: Saving Elensefar (upkeep not right)

Post by zx_specy_gamer »

Hi. I wanted to ask if anyone else is getting a problem with the upkeep costs that make it impossible to finish the campaign without "cheating" by amending the gold.

As an example, I just finished the "fire island" scenario with the 7 starting units and no recalls. When the battle ended it said I had ran out of money (I had 274 gold at the time). So I edited the save file and gave myself 10000 gold. loaded it back up finished the scenario and it said that my upkeep was "745 for 0 soldiers".

I am sure that the cost for the battles can't be calculating and are probably cumulative somehow. Its been costing me 100 gold to land on a "village" and I have reduced each hero's recall list to 3 units. I've only been recalling 2-3 units per hero on each map.

The recall list also shows units I can't recruit, like a load of ghouls and soulless.

It's a bit annoying because the campaign is really good.

I am playing on 1.12.6.
I've attached the unedited save in case anyone is interested.
Attachments
SE-Fire_Island-Auto-Save16.gz
(193.75 KiB) Downloaded 443 times
ImperatorS79
Posts: 11
Joined: April 22nd, 2015, 4:55 pm

Re: Campaign: Saving Elensefar

Post by ImperatorS79 »

I also noticed that the scenario when you play a game with a necromancer does not work: your unit spawn next to you instead of on the board !

It could also be nice if someone with some art skills could draw some ships for this campaign, like in Secret of the Ancient ;-).

EDIT: The scenario on the Alduin Island is also full of bugs, and the french translation isterrible.
EDIT 2: Indeed The alduin scenario runs fine, despite a lua error in modify_side.lua=45: bad argument #3 to '__newindex'
Last edited by ImperatorS79 on July 5th, 2019, 9:08 pm, edited 2 times in total.
ImperatorS79
Posts: 11
Joined: April 22nd, 2015, 4:55 pm

Re: Campaign: Saving Elensefar

Post by ImperatorS79 »

I got a problem in the abilities.cfg file when trying to update the french translations. The error is:

error: Saving_Elensefar\utils\abilities.cfg:29: unexpected closing tag '[/abilities]' outside any scope.

which can be seen in this file -> https://github.com/ImperatorS79/Saving_ ... lities.cfg

Could anyone that know WML give me an advice ? ^^
User avatar
octalot
General Code Maintainer
Posts: 777
Joined: July 17th, 2010, 7:40 pm
Location: Austria

Re: Campaign: Saving Elensefar

Post by octalot »

Add a few lines to abilities.cfg, with wmlxgettext comments. The lines to add are the ones that start with a +.

Code: Select all

 # wmllint: unbalanced-on
+# wmlxgettext: [abilities]
 #define ABILITY_BLITZ
     [leadership]
         id=blitz

Code: Select all

 [/event]
 [+abilities]
 #enddef
+# wmlxgettext: [/abilities]
+# wmllint: unbalanced-off
 
 #define WEAPON_SPECIAL_BATTLETUTOR
     [drains]
ImperatorS79
Posts: 11
Joined: April 22nd, 2015, 4:55 pm

Re: Campaign: Saving Elensefar

Post by ImperatorS79 »

Thanks; it worked just fine !
User avatar
egallager
Posts: 568
Joined: November 19th, 2020, 7:27 pm
Location: Concord, New Hampshire
Contact:

Re: Campaign: Saving Elensefar

Post by egallager »

So, I am attempting to port this campaign to 1.14; my work-in-progress may be found here: https://github.com/cooljeanius/Saving_Elensefar
Unfortunately, the nonlinear structure of the campaign and the fact that it has a multiplayer mode are going to make it hard for me to test on my own, so if anyone wants to help me test it, please let me know.
eletar
Posts: 4
Joined: October 20th, 2020, 7:20 pm

Re: Campaign: Saving Elensefar

Post by eletar »

Hello, if you are still there, I'm testing the last scenario for some special case which seems incongruent.

The problematic code as will be described below, does not change that much since version 1.10.7.
The (new) macros make the playthrought consistent (well, not intensive testing, mostly just comparing WML against both versions 1.6.x and yours), so it is a good port so far. I had to create (adapt) a replaysave from an old version (1.10.7) which I had stored, for the new versions 1.14.xx, as somewhere inbetween version change, WML for replaysaves changed so much to the point of making replaysaves incompatible from 1.11.xx onwards (from memory, not enought patience to test replaysaves for ALL versions, and also I just came to replay again from nearly 8 years).

The special case in which I'm having problem is: the output of events (visible ones vs. expected ones) for when "Meneldur" (canrecruit=yes) kills an enemy leader ([event]name="die"[filter]id=...) using the "eye of basilisk" ([special]..."petrifies", [event]name="petrified").

In the past replaysave, for some reason, after "Meneldur" (canrecruit=yes) kills a leader, either while active (attack, "unit") or passive (defend, "second_unit"), the dialog/messages after the [conditional] WML for their respective "die" [event](s) are all said by the dying unit, already petrified!, so second_unit.id equals unit.id equals the id of the petrified unit NOT the killer unit, which also makes impossible to receive the money reward.

Could you please update that segment of the code to circunvent this nonconsistent outcome.

The code which I think would have to be revised are in: /scenarios/04_Saving_Elensefar.cfg (the triplet "name=die" events for the enemy leaders), and /utils/deaths.cfg ([event]name=petrified). I ask this because I'm out of ideas, not any clue to circunvent/solve this.
User avatar
egallager
Posts: 568
Joined: November 19th, 2020, 7:27 pm
Location: Concord, New Hampshire
Contact:

Re: Campaign: Saving Elensefar

Post by egallager »

eletar wrote: March 13th, 2021, 7:31 am Hello, if you are still there, I'm testing the last scenario for some special case which seems incongruent.

The problematic code as will be described below, does not change that much since version 1.10.7.
The (new) macros make the playthrought consistent (well, not intensive testing, mostly just comparing WML against both versions 1.6.x and yours), so it is a good port so far. I had to create (adapt) a replaysave from an old version (1.10.7) which I had stored, for the new versions 1.14.xx, as somewhere inbetween version change, WML for replaysaves changed so much to the point of making replaysaves incompatible from 1.11.xx onwards (from memory, not enought patience to test replaysaves for ALL versions, and also I just came to replay again from nearly 8 years).

The special case in which I'm having problem is: the output of events (visible ones vs. expected ones) for when "Meneldur" (canrecruit=yes) kills an enemy leader ([event]name="die"[filter]id=...) using the "eye of basilisk" ([special]..."petrifies", [event]name="petrified").

In the past replaysave, for some reason, after "Meneldur" (canrecruit=yes) kills a leader, either while active (attack, "unit") or passive (defend, "second_unit"), the dialog/messages after the [conditional] WML for their respective "die" [event](s) are all said by the dying unit, already petrified!, so second_unit.id equals unit.id equals the id of the petrified unit NOT the killer unit, which also makes impossible to receive the money reward.

Could you please update that segment of the code to circunvent this nonconsistent outcome.

The code which I think would have to be revised are in: /scenarios/04_Saving_Elensefar.cfg (the triplet "name=die" events for the enemy leaders), and /utils/deaths.cfg ([event]name=petrified). I ask this because I'm out of ideas, not any clue to circunvent/solve this.
Who was this directed at? If me, I haven't gotten past the branching point (where it becomes nonlinear) yet, so I don't know what to tell you...
eletar
Posts: 4
Joined: October 20th, 2020, 7:20 pm

Re: Campaign: Saving Elensefar

Post by eletar »

Well, greetings, I think I solved my issue in a way, somehow.

As WML sentences here have not changed very much since 1.10.x, I think it's safe to put these lines in .cfg for the updated campaign revision. The file to modify is "/scenarios/04_Saving_Elensefar.cfg". (I applied these modifications to my replaysaves too.)

The issue described in my last post appears whenever ANY unit that has "petrify" attack hits the enemy leader. I think this is more a case of simultaneous "second-second_uniting" the attacker, because "petrify" event calls for another [event] ("die" in this case) even when that is still unfinished/running, i.e. a convergence/ overlapping of events. AFAICT, this only affects the "pretify" event; I do not know some other [special] that behaves in the same manner as petrify.

At [event]name="start", after [switch] tag of messages, I put a custom search for the unit which has "petrify" attack. (It defaults to "0" when none found, iirc.) This is for v1.10.7 in my case; for 1.13+ use [has_attack]name, according to wiki (?).

So, for up to 1.13.4:

Code: Select all

[store_unit]
	variable=has_eye_of_basilisk
	[filter]
		side=1
		[and]
			has_weapon="eye_of_basilisk"	## Only one in existence, so only one unit to filter.
		[/and]
	[/filter]
[/store_unit]
And for 1.13.5 and later:

Code: Select all

[store_unit]
	variable=has_eye_of_basilisk
	[filter]
		side=1
		[and]
			[has_attack]
				name="eye_of_basilisk"
			[/has_attack]
		[/and]
	[/filter]
[/store_unit]

At [event]name="die" events, I modified some lines and put new ones. They are valid for all versions, after reviewing tags in the wiki. Text should be like this (example for orc leader):

Code: Select all

	[event]
		name="die"
		[filter]
			id="Pakch-Glun"
		[/filter]
		[if]
			[have_unit]
				id="Leowyn"
			[/have_unit]
			[then]
				[message]
					id="Meneldur"
					message=_"Elensefar may be ours, but there are still enemies to defeat. Onwards!"
				[/message]
			[/then]
			[else]
				[if]
					[have_unit]
						id="Galiyonia"
					[/have_unit]
					[then]
						[message]
							id="Meneldur"
							message=_"We have taken Elensefar and defeated the Wesnothians, but these Elves need attending to."
						[/message]
					[/then]
					[else]
						[message]
							id="Madru"
							message=_"There are no enemies left - we have succeeded in retaking Elensefar."
						[/message]
					[/else]
				[/if]
			[/else]
		[/if]
		[if]		## These are the custom added lines; this conditional is the same for these 3 "die" events,...
			[variable]
				name="second_unit.id"
				not_equals="Pakch-Glun"		## ... except just change the name of enemy leader here.
			[/variable]
			[then]
				[set_variable]
					name="assasin_of_leader.id"
					value="$second_unit.id"			## If no eye_of_basilisk is used, there's no overlapping of events, so id's are ok.
				[/set_variable]
			[/then]
			[else]		## When using the eye_of_basilisk to kill leader, "second_unit" gets replaced by "unit" ("petrify" overlapping bug in 1.10.7 ?);...
				[set_variable]
					name="assasin_of_leader.id"
					value="$has_eye_of_basilisk.id"		## ...that's why eye_of_basilisk's owner is reserved in order to restore "second_unit" for this special case...
				[/set_variable]
			[/else]
		[/if]
		[message]
			message=_"The orcs had ransacked the city's coffers - now it's time for us to return the favor."
			speaker="$assasin_of_leader.id"			## ...an thus, this dialog finally gets shown for it.
		[/message]
		[message]
			image="wesnoth-icon.png"
			message=_"You find 200 pieces of gold!"
			side_for="$assasin_of_leader.side"
			speaker="narrator"
		[/message]
		[gold]
			amount=200
			side="$assasin_of_leader.side"
		[/gold]
		[clear_variable]
			name="assasin_of_leader"		## This tag is just for completeness. ("victory" or "enemies defeated" would have so for "has_eye_of_basilisk")
		[/clear_variable]
	[/event]
Similar edits go for angry elves & wesnothian forces's respective lines.
User avatar
MoonyDragon
Posts: 149
Joined: November 29th, 2017, 5:46 pm

Re: Campaign: Saving Elensefar

Post by MoonyDragon »

eletar wrote: March 15th, 2021, 10:51 pm Well, greetings, I think I solved my issue in a way, somehow.
For the record, I think I just found the source of the bug that you described. It appears that in line 292 of utils/deaths.cfg, there is an event that triggers whenever a unit is petrified. Its primary function is to place a grayscaled image of the petrified unit, give the killer experience and then kill the petrified unit afterwards. And that [kill] tag is what causes the confusion about who exactly killed the petrified unit. Without a [secondary_unit] tag inside, it's as if we killed it via :debug. There is an easy fix for it appended below:

Code: Select all

[kill]
    x,y=$x1,$y1
    animate=no
    fire_event=yes

    # add the following:
    [secondary_unit]
        id=$second_unit.id
    [/secondary_unit]
    # end of patch
[/kill]
Default L0 Era - Level 1 leaders with level 0 recruits!
Post Reply