Campaign: Saving Elensefar
Moderator: Forum Moderators
Re: Campaign: Saving Elensefar
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 580 times
Re: Campaign: Saving Elensefar
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
Version: 1.12.6
Re: Campaign: Saving Elensefar
This campaign is present on 1.13 server, but is not 1.13 compatible.
Is there anyone who supports it now?
Thanks.
Is there anyone who supports it now?
Thanks.
- James_The_Invisible
- Posts: 536
- Joined: October 28th, 2012, 1:58 pm
- Location: Somewhere in the Northlands, fighting dark forces
- Contact:
Re: Campaign: Saving Elensefar
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.
My content: For Power series
Ports: Danse Macabre Story of the Wose
Guides: How to translate your UMC
Ports: Danse Macabre Story of the Wose
Guides: How to translate your UMC
Re: Campaign: Saving Elensefar
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
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
-
- Posts: 7
- Joined: April 2nd, 2017, 4:04 pm
Campaign: Saving Elensefar (upkeep not right)
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.
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 454 times
-
- Posts: 11
- Joined: April 22nd, 2015, 4:55 pm
Re: Campaign: Saving Elensefar
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'
It could also be nice if someone with some art skills could draw some ships for this campaign, like in Secret of the Ancient
![Wink ;-)](./images/smilies/icon_wink.gif)
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.
-
- Posts: 11
- Joined: April 22nd, 2015, 4:55 pm
Re: Campaign: Saving Elensefar
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 ? ^^
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 ? ^^
Re: Campaign: Saving Elensefar
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]
-
- Posts: 11
- Joined: April 22nd, 2015, 4:55 pm
Re: Campaign: Saving Elensefar
Thanks; it worked just fine !
Re: Campaign: Saving Elensefar
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.
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.
Wesnoth-related GitHub repos:
General mods collection, SotBEEE, AToTBWaTD, The Earth's Gut, A Little Adventure, FtF
Social media: Mastodon: @egallager@treehouse.systems, Steam: egallager
General mods collection, SotBEEE, AToTBWaTD, The Earth's Gut, A Little Adventure, FtF
Social media: Mastodon: @egallager@treehouse.systems, Steam: egallager
Re: Campaign: Saving Elensefar
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.
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.
Re: Campaign: Saving Elensefar
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 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.
Wesnoth-related GitHub repos:
General mods collection, SotBEEE, AToTBWaTD, The Earth's Gut, A Little Adventure, FtF
Social media: Mastodon: @egallager@treehouse.systems, Steam: egallager
General mods collection, SotBEEE, AToTBWaTD, The Earth's Gut, A Little Adventure, FtF
Social media: Mastodon: @egallager@treehouse.systems, Steam: egallager
Re: Campaign: Saving Elensefar
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:
And for 1.13.5 and later:
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):
Similar edits go for angry elves & wesnothian forces's respective lines.
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]
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]
- MoonyDragon
- Posts: 149
- Joined: November 29th, 2017, 5:46 pm
Re: Campaign: Saving Elensefar
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!