1.4 Bad Moon Rising (obsolete)

[gnurob]

I just tired your campaign using 1.3 from SVN and get an error: unknown unit type 'XE Footpad'.

Extended Era was added using the Wesnoth add-ons feature and again using the python script.

Code: Select all

user@host:~/bin> ./campaigns_client.py -p 1.3.x -f /home/user/.wesnoth-1.3-svn/data/campaigns/
Opening socket to campaigns.wesnoth.org:15003 for 1.3.x
Connected as 53968.
 - cp - is installed but not on server.
   Attack_of_the_Undead - is up to date.
   DotG - is up to date.
   Rise - is up to date.
   Alfhelm - is up to date.
   The_Unstoppable_Legion - is up to date.
   RPG_era - is up to date.
   Invasion_from_the_Unknown - is up to date.
   Hunt_the_Dragon - is up to date.
   Heroes_Arena - is up to date.
   Random_Invasion - is up to date.
   PickYourRecruits_Era - is up to date.
   Flight_Freedom_1_3 - is up to date.
   AgeOfLegends_Era - is up to date.
   the_tribe - is up to date.
   Temples_Of_The_Nagas - is up to date.
   qesicans_era - is up to date.
   Saving_Elensefar - is up to date.
   Abilities_Era - is up to date.
   Imperial_Era - is up to date.
   The_Fall_of_Wesnoth - is up to date.
   ConquerNations - is up to date.
   Eliador - is up to date.
   Living_Villages - is up to date.
   Story_of_Wose - is up to date.
   Legend_of_Wesmere - is up to date.
   Isars_Cross_Forever - is up to date.
   The_Labyrinth_Of_Champions - is up to date.
   The_Dark_Hordes - is up to date.
   The_Fall_Of_Trent - is up to date.
   Hall_of_Lame - is up to date.
   Napoleonnoth - is up to date.
   Extended_Era - is up to date.
   Era_of_Myths - is up to date.
   The_Heist - is up to date.
   Fall_of_Silvium - is up to date.
Closing socket.
user@host:~/bin>

[doofus-01]

Ugh. I read your message, updated my version of Extended Era, and now I have the same problem. I also get similar errors on any savefile that calls for an XE unit. This looks like it could be a pretty serious problem, so I'm pulling the campaign off the server until I get this fixed.

Apologies.

[Beefy]

Just removing the "XE " solves the problem for me.

[doofus-01]

Some XE outlaws were dropped because the L3 units are now shipped default in 1.3.13, so that makes sense. However, I had the same error when I called for a Chaos unit, so I'm thinking there are more id and directory changes that I need to accommodate.

Maybe it's not as broken as I thought, I'll put the campaign back up soon.

Edit: I think it's fixed, just needed to delete one word in _main.cfg. Guess I overreacted...

You can fix the _main.cfg file by deleting the "/standard" in

Code: Select all

{@campaigns/Extended_Era/units/standard}

near the bottom of the file.
And if you delete the "XE" in the unit types for the rioters in the first secenario .cfg, the campaign should work again.

Or you can just re-download the campaign, it's back up.

[gnurob]

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.

[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]

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.

[tillea]

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.

I just sent 0.1.2 to the server.

I'll test it the next couple of days.

Kind regards

Andreas.

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

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

[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)

[tillea]

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.

[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]

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.

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