1.4 Bad Moon Rising (obsolete)
Moderator: Forum Moderators
Yes, the units shipping with 1.3.13 rings a bell. I installed the latest version of your campaign and got past the error. Thanks very much for being so quick to maintain your campaign!doofus-01 wrote:Some XE outlaws were dropped because the L3 units are now shipped default in 1.3.13, so that makes sense.
...
Or you can just re-download the campaign, it's back up.
On another note, I ran into all sorts of problems getting the update. They're worth mentioning because some issues can be avoided with managing the campaign development:
- The following command did not update the campaign because (I assume) info.cfg did not have an updated version number(Using version 0.1.2.1 may have been an easy fix.)
Code: Select all
campaigns_client.py -p 1.3.x -d "." -c ~/.wesnoth/data/campaigns
- I couldn't delete the campaign in the list of add-ons because I did not see the name "Bad Moon Rising"
(Having every era/campaign/map installed makes for a big list.) - Installing over the installed campaign did not fix the XE Footpad error
(This is a wesnoth.org issue but worth mentioning just for the experience.)
That seems kind of important and is something I will keep in mind from now on.On another note, I ran into all sorts of problems getting the update. They're worth mentioning because some issues can be avoided with managing the campaign development:
1. The following command did not update the campaign because (I assume) info.cfg did not have an updated version number
Code:
campaigns_client.py -p 1.3.x -d "." -c ~/.wesnoth/data/campaigns
Thanks.
No, it is definitely a different bug. I checked SVN which lat me continue thedoofus-01 wrote:I was able to finish that scenario from your savefile without crashing, and there were no helpful hints from std i/o. Maybe this is the same bug?
two campaigns that caused the trouble I reported, but this problem remains.
I'll test it the next couple of days.doofus-01 wrote: I just sent 0.1.2 to the server.
Kind regards
Andreas.
I updated to 1.3.13 and now I have the same problem as tillea. The segmentation fault happens whenever I try to make the side 6 or 7 leader disappear in an attack event, using [kill] or [store_unit]. It worked in 1.3.11, but no longer...
Here's a .cfg that appears to work. It's not quite what I wanted but it'll have to do for now.
I want to re-write it before sending out 0.1.3
Edit: I was going to try to recreate the crash to send a bug report, but found that it was possible to "[kill]" the leaders in an attack event after all. If the event is "attacker_hits" -> crash. If the event is "attacks" it seems OK. Edit:The scenario is fixed in 0.1.3
The earlier bug occurs in the scenarios that "[recall]" more than one unit and prevents them from loading on the released 1.3.13. But as tillea pointed out above, that issue has been fixed so I'm not rewriting those scenarios. Also, the animations are messed up, but it's not unique to this campaign and it looks like the developers have it under control (see bug #10713).
Here's a .cfg that appears to work. It's not quite what I wanted but it'll have to do for now.
I want to re-write it before sending out 0.1.3
Edit: I was going to try to recreate the crash to send a bug report, but found that it was possible to "[kill]" the leaders in an attack event after all. If the event is "attacker_hits" -> crash. If the event is "attacks" it seems OK. Edit:The scenario is fixed in 0.1.3
The earlier bug occurs in the scenarios that "[recall]" more than one unit and prevents them from loading on the released 1.3.13. But as tillea pointed out above, that issue has been fixed so I'm not rewriting those scenarios. Also, the animations are messed up, but it's not unique to this campaign and it looks like the developers have it under control (see bug #10713).
Last edited by doofus-01 on January 16th, 2008, 5:20 pm, edited 1 time in total.
The differences between 1.3.13 and 1.3.14 are quite minor for WML.
Unless you still use the obsolete format in some map (its support was droppen in 1.3.14), it will likely work.
Btw 1.3.14 use a different addon server now (this one will become the addon server for the 1.4.x stable releases)
Unless you still use the obsolete format in some map (its support was droppen in 1.3.14), it will likely work.
Btw 1.3.14 use a different addon server now (this one will become the addon server for the 1.4.x stable releases)
"Ooh, man, my mage had a 30% chance to miss, but he still managed to hit! Awesome!" -- xtifr
Re: Bad Moon Rising (0.1.3 - 13 scenarios)
I tried a SVN checkout from short before 1.3.14 release (last Friday) and nothing changed. If I either successfully attack General Maskov or Duval both claim to have better things to do than fighting and then wesnoth crashes. This is true for Bad Moon Rising 0.1.2 and 0.1.3. I also tried the changed config file you posted here. I might try official wesnoth 1.3.14 but I'd like to wait for prebuilded Debian packages. My slow conncetion makes it not really funny to download several versions of wesnoth.doofus-01 wrote:I'm about to send 0.1.3 to the server. I just got it to work with 1.3.13 but now 1.3.14 is out. So it goes...
Ahh, I forgot to mention that since 0.1.2 Duval stops recruiting anybody and just stands
still in his camp.
Kind regards
Andreas.
It did not occur to me the AI might get broken, I just checked to see that he would disappear when attacked and not cause a crash by creating a (debug) unit next to him. I'll look at it all again.
You can try this to see if it prevents the seg fault:
Delete the these lines around row 355 of H_Rumble.cfg
Then try to kill him. If it still crashes, try deleting the {THUNDER( & )} lines bracketing it.
If that gets you past the crash, there is identical code for "description=Maskov" around row 370.
By the way, you're using the scenario start file, not an old auto-save or in-game save from 0.1.2, correct? There might be a way to fix in-game saves, but I don't know how to do that.
You can try this to see if it prevents the seg fault:
Delete the these lines around row 355 of H_Rumble.cfg
Code: Select all
[kill]
description=Scarrion
[/kill]
If that gets you past the crash, there is identical code for "description=Maskov" around row 370.
By the way, you're using the scenario start file, not an old auto-save or in-game save from 0.1.2, correct? There might be a way to fix in-game saves, but I don't know how to do that.
No, I always used my last savegames right before I was able to attack those enemies. It might be another chance to verify whether things might have changed to start from the end of the previous scenario.doofus-01 wrote: By the way, you're using the scenario start file, not an old auto-save or in-game save from 0.1.2, correct? There might be a way to fix in-game saves, but I don't know how to do that.
Kind regards
Andreas.
It appears the segmentation fault is not fixed after all. You can get around it by running wesnoth in debug mode and attacking Maskov & Scarrion with cheating/debug units (which is why I thought it was fixed). If you use a real unit, wesnoth will crash. The debug and real units can be the same type, so I doubt it has anything to do with a bad unit .cfg.
I think this is a true bug, not broken WML. I'll try submitting a bug report if I, tillea, or someone else runs into the same problem using 1.3.14. The developers may not look at it because this is UMC, but the odds would improve if I could give them a gdb backtrace from the latest BfW release.
The AI did continue to recruit, so I think that's OK. If you were using an in-game savefile from 0.1.2, that might have been the cause.
Edit: It looks like other people have this seg fault problem too. See bug #10801 at gna.
I think this is a true bug, not broken WML. I'll try submitting a bug report if I, tillea, or someone else runs into the same problem using 1.3.14. The developers may not look at it because this is UMC, but the odds would improve if I could give them a gdb backtrace from the latest BfW release.
The AI did continue to recruit, so I think that's OK. If you were using an in-game savefile from 0.1.2, that might have been the cause.
Edit: It looks like other people have this seg fault problem too. See bug #10801 at gna.
Wesnoth 1.3.13+SVN bails when I kill Duval with a regular recruit or unit added via debug.doofus-01 wrote:It appears the segmentation fault is not fixed after all. You can get around it by running wesnoth in debug mode and attacking Maskov & Scarrion with cheating/debug units (which is why I thought it was fixed). If you use a real unit, wesnoth will crash. The debug and real units can be the same type, so I doubt it has anything to do with a bad unit .cfg.
I made a typo, should have caught it myself before uploading. Change "Vassak" to "Varrak" at row 174 of the I_Chase.cfg file.In the Chase scenario nothing happens after defeating the leader and its recruits in the first keep and the guard next to the stash. No other units were found.
Code: Select all
[event]
name=die
[filter]
description=Vassak
[/filter]
How did you get past Royal Rumble? Were you able to do it without removing lines from the .cfg?
Hate to disappoint... I just skipped over:doofus-01 wrote:How did you get past Royal Rumble? Were you able to do it without removing lines from the .cfg?
Code: Select all
:debug
:n
The gate at 21,48 doesn't stop units. Its not working if you meant for an event trigger to open the gate, or to attack it as a normal unit. Also, there's a little bit of an expectation to find something more substantial than a note given the gate and boxes.
The trash pile at 8,19 may be trash... or not. It looks like one of those things that should do something but doesn't.
Looking good otherwise!