1.4 Bad Moon Rising (obsolete)

Discussion and development of scenarios and campaigns for the game.

Moderators: Forum Moderators, Developers

Post Reply
gnurob
Posts: 66
Joined: June 24th, 2007, 9:49 am

Post by gnurob »

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.
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!

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: Select all

    campaigns_client.py -p 1.3.x -d "." -c ~/.wesnoth/data/campaigns
    (Using version 0.1.2.1 may have been an easy fix.)
  2. 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.)
  3. 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.)
Eventually I had to run a UNIX find and grep combination to ID the directory Rise as part of this campaign and remove it. If issues #1 or #2 are addressed that whole hoop jumping wouldn't be necessary.

User avatar
doofus-01
Art Contributor
Posts: 3878
Joined: January 6th, 2008, 9:27 pm
Location: USA

Post by doofus-01 »

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
That seems kind of important and is something I will keep in mind from now on.
Thanks.

gnurob
Posts: 66
Joined: June 24th, 2007, 9:49 am

Post by gnurob »

doofus-01 wrote:That seems kind of important and is something I will keep in mind from now on. Thanks.
Cool. Good luck with the campaign development. Looks good so far. :-D

tillea
Posts: 76
Joined: November 9th, 2006, 12:44 pm
Contact:

Post by tillea »

doofus-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?
No, it is definitely a different bug. I checked SVN which lat me continue the
two campaigns that caused the trouble I reported, but this problem remains.
doofus-01 wrote: I just sent 0.1.2 to the server.
I'll test it the next couple of days.

Kind regards

Andreas.

User avatar
doofus-01
Art Contributor
Posts: 3878
Joined: January 6th, 2008, 9:27 pm
Location: USA

Post by doofus-01 »

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).
Last edited by doofus-01 on January 16th, 2008, 5:20 pm, edited 1 time in total.

User avatar
doofus-01
Art Contributor
Posts: 3878
Joined: January 6th, 2008, 9:27 pm
Location: USA

Post by doofus-01 »

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...

User avatar
Noyga
Inactive Developer
Posts: 1790
Joined: September 26th, 2005, 5:56 pm
Location: France

Post by Noyga »

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)
"Ooh, man, my mage had a 30% chance to miss, but he still managed to hit! Awesome!" ;) -- xtifr

tillea
Posts: 76
Joined: November 9th, 2006, 12:44 pm
Contact:

Re: Bad Moon Rising (0.1.3 - 13 scenarios)

Post by tillea »

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...
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.

Ahh, I forgot to mention that since 0.1.2 Duval stops recruiting anybody and just stands
still in his camp.

Kind regards

Andreas.

User avatar
doofus-01
Art Contributor
Posts: 3878
Joined: January 6th, 2008, 9:27 pm
Location: USA

Post by doofus-01 »

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

Code: Select all

                [kill]
                description=Scarrion
                [/kill]
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.

tillea
Posts: 76
Joined: November 9th, 2006, 12:44 pm
Contact:

Post by tillea »

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.
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.

Kind regards

Andreas.

User avatar
doofus-01
Art Contributor
Posts: 3878
Joined: January 6th, 2008, 9:27 pm
Location: USA

Post by doofus-01 »

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.

gnurob
Posts: 66
Joined: June 24th, 2007, 9:49 am

Post by gnurob »

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.
Wesnoth 1.3.13+SVN bails when I kill Duval with a regular recruit or unit added via debug.

gnurob
Posts: 66
Joined: June 24th, 2007, 9:49 am

Post by gnurob »

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.

User avatar
doofus-01
Art Contributor
Posts: 3878
Joined: January 6th, 2008, 9:27 pm
Location: USA

Post by doofus-01 »

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.
I made a typo, should have caught it myself before uploading. Change "Vassak" to "Varrak" at row 174 of the I_Chase.cfg file.

Code: Select all

        [event]
        name=die
            [filter]
                description=Vassak
            [/filter]
Then you probably have to start that scenario over.


How did you get past Royal Rumble? Were you able to do it without removing lines from the .cfg?

gnurob
Posts: 66
Joined: June 24th, 2007, 9:49 am

Post by gnurob »

doofus-01 wrote: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:

Code: Select all

:debug
:n
In the pit scenario I found two possible issues.

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!

Post Reply