Wesband, MP dungeon-crawler (now for Wesnoth 1.9.14+ !)

Discussion of all aspects of multiplayer development: unit balancing, map development, server development, and so forth.

Moderators: Forum Moderators, Developers

Post Reply
User avatar
Dugi
Posts: 4960
Joined: July 22nd, 2010, 10:29 am
Location: Carpathian Mountains
Contact:

Re: Wesband, MP dungeon-crawler (now for Wesnoth 1.9.14+ !)

Post by Dugi »

xudojnik wrote:Tell me, please. Which version of Wesnoth do I need to play latest Wesband?
Quick reply:
It is on 1.10.
I think an older version is also on 1.8.
daniel.santos
Posts: 26
Joined: May 22nd, 2008, 2:45 am

Re: Wesband very slow

Post by daniel.santos »

I've tried Wesband on 1.9.something and 10.2 now and it is unplayably slow. If I only have one character, it's not too bad, but if I have all four and I right click on one to do anything, there's a very long delay (I think 7-10 seconds). Then ending the turn takes about 20 seconds.

I'm running Gentoo AMD64 USE="dbus nls server -dedicated -doc"
Phenom 9850
8G DDR2 (800MHz in dual-channel)
NVidia 260 GT video card
3x 1.5TB SATA HDs in a raid 5 configuration

I know that AMD is slower per-thread than Intel, but this alone can't account for such a drastic slow-down. Perhaps this is simply a flaw in Wesnoth -- their scripting language just doesn't seem to scale well when you want to do very elaborate things.

Any ideas or info please?
User avatar
Sapient
Inactive Developer
Posts: 4453
Joined: November 26th, 2005, 7:41 am
Contact:

Re: Wesband, MP dungeon-crawler (now for Wesnoth 1.9.14+ !)

Post by Sapient »

Post your savegame so that it may be analyzed please.
http://www.wesnoth.org/wiki/User:Sapient... "Looks like your skills saved us again. Uh, well at least, they saved Soarin's apple pie."
daniel.santos
Posts: 26
Joined: May 22nd, 2008, 2:45 am

Re: Wesband, MP dungeon-crawler (now for Wesnoth 1.9.14+ !)

Post by daniel.santos »

I would be glad to, but it's a new game.

If it helps at all, wesnoth was built with gcc 4.5.3 and -O3. I'm re-building it right now with gcc 4.7.1 using -O3 -fwhole-program and if that's not better, I'll give -O2 a shot as well to try to rule out compiler issues.
build options:
Minor correction: The delay for right-clicking is aproximately 3 seconds. The same is true for movement. After my avatar moves, the mouse is frozen for 3 seconds and nothing is possible for that time. The time may have been slightly different before (sorry, not sure) as this is with wesnoth 10.3 buillt with gcc 4.7.1 and -O2. Ending the turn (when the AI moves) takes 37 seconds.
Attachments
Wesband_Dungeon_Turn_2-too-slow.gz
Game I created yesterday.
(448 KiB) Downloaded 242 times
Last edited by Sapient on June 23rd, 2012, 3:38 pm, edited 1 time in total.
Reason: Merged triple-post
User avatar
Sapient
Inactive Developer
Posts: 4453
Joined: November 26th, 2005, 7:41 am
Contact:

Re: Wesband, MP dungeon-crawler (now for Wesnoth 1.9.14+ !)

Post by Sapient »

I tried running it and got the same issue. However, I can guess why the right-click is probably taking so long to appear.

If you open the save file and search for "[menu_item]", you will see all the menu items. Within each one is a [show_if] and/or a [filter_location] that must be processed.

Some of these [show_if] are using [have_unit], which requires filtering upon every unit in the game. If there is an $x1,$y1 being used within the [show_if], then it probably should have been written using [filter_location] instead.

Take this for example:

Code: Select all

[menu_item]
	id="use_other_adj"
	image="commands/cast.png"
	description="Use/Cast on Unit"
	needs_select=no
	[show_if]
		[have_unit]
			canrecruit=yes
			side="$side_number"
			[filter_location]
				radius=1
				x="$x1"
				y="$y1"
			[/filter_location]
		[/have_unit]
	[/show_if]
Instead this could have been written much more efficiently as:

Code: Select all

[menu_item]
  id="use_other_adj"
  image="commands/cast.png"
  description="Use/Cast on Unit"
  needs_select=no
  [filter_location]
    [filter]
      canrecruit=yes
      side="$side_number"
    [/filter]
    radius=1
  [/filter_location]
The improved version only needs to filter against adjacent units.
As an experiment, I tried replacing every [show_if] with [show_if_fail], and the right-click menu appeared quite speedily.
http://www.wesnoth.org/wiki/User:Sapient... "Looks like your skills saved us again. Uh, well at least, they saved Soarin's apple pie."
User avatar
Xudo
Posts: 561
Joined: April 3rd, 2009, 5:26 pm

Re: Wesband, MP dungeon-crawler (now for Wesnoth 1.9.14+ !)

Post by Xudo »

Sapient wrote: As an experiment, I tried replacing every [show_if] with [show_if_fail], and the right-click menu appeared quite speedily.
Add information about it on the wiki, please. :augh:
User avatar
Sapient
Inactive Developer
Posts: 4453
Joined: November 26th, 2005, 7:41 am
Contact:

Re: Wesband, MP dungeon-crawler (now for Wesnoth 1.9.14+ !)

Post by Sapient »

xudojnik wrote:
Sapient wrote: As an experiment, I tried replacing every [show_if] with [show_if_fail], and the right-click menu appeared quite speedily.
Add information about it on the wiki, please. :augh:
... it's not a real tag. I just made the game ignore it... :annoyed:
http://www.wesnoth.org/wiki/User:Sapient... "Looks like your skills saved us again. Uh, well at least, they saved Soarin's apple pie."
daniel.santos
Posts: 26
Joined: May 22nd, 2008, 2:45 am

Re: Wesband, MP dungeon-crawler (now for Wesnoth 1.9.14+ !)

Post by daniel.santos »

ooh, would you pretty please post the patch so I can try it? I really used to enjoy this back in 1.8 when it was fast. In fact, if you can post a patch to both the add-on & the game, that would be great, but I would mostly need the patch to the game (since I don't know any of the wesnoth code).

Thankee!!
User avatar
Sapient
Inactive Developer
Posts: 4453
Joined: November 26th, 2005, 7:41 am
Contact:

Re: Wesband, MP dungeon-crawler (now for Wesnoth 1.9.14+ !)

Post by Sapient »

daniel.santos wrote:ooh, would you pretty please post the patch so I can try it? I really used to enjoy this back in 1.8 when it was fast. In fact, if you can post a patch to both the add-on & the game, that would be great, but I would mostly need the patch to the game (since I don't know any of the wesnoth code).

Thankee!!
No, that is a task for the add-on maintainer (Exasperation, I believe). However, if anyone needs help optimizing the [set_menu_item][show_if] conditions, feel free to post specific questions in the WML Workshop. As for the slowness at the end of turn, that is due to AI evaluation time. You may be able to fix that by setting enemies to be idle_ai (or stoned, or some other dumb ai) until they are within a certain range of the player.
http://www.wesnoth.org/wiki/User:Sapient... "Looks like your skills saved us again. Uh, well at least, they saved Soarin's apple pie."
daniel.santos
Posts: 26
Joined: May 22nd, 2008, 2:45 am

Re: Wesband, MP dungeon-crawler (now for Wesnoth 1.9.14+ !)

Post by daniel.santos »

Sapient wrote:No, that is a task for the add-on maintainer (Exasperation, I believe).
Perhaps there's a misunderstanding. I thought you meant that you added support for a tag called [show_if_fail] (in the wesnoth code). Perhaps you just meant that you changed the [show_if] to [show_if_fail] and let wesnoth ignore the tag it didn't recognize.
Sapient wrote:As for the slowness at the end of turn, that is due to AI evaluation time. You may be able to fix that by setting enemies to be idle_ai (or stoned, or some other dumb ai) until they are within a certain range of the player.
I thought the Add-On author already did that.

I may be a programmer, but sometimes, I just want to play a game. :)
daniel.santos
Posts: 26
Joined: May 22nd, 2008, 2:45 am

Re: Wesband, MP dungeon-crawler (now for Wesnoth 1.9.14+ !)

Post by daniel.santos »

Thanks for your help Sapient, I made a small mod, but right-clicking is still slow (faster with only two characters however)
patch to speed up right-clicking:
Any ideas on the huge delay after moving the avatar?
User avatar
Xudo
Posts: 561
Joined: April 3rd, 2009, 5:26 pm

Re: Wesband, MP dungeon-crawler (now for Wesnoth 1.9.14+ !)

Post by Xudo »

daniel.santos wrote:Any ideas on the huge delay after moving the avatar?
In this addon used "continue movement" mechanic.
In short, it means, that character gets additional movement points after movement, if no enemies nearby.
May be there is bad solution in moveto event handler.
User avatar
Sapient
Inactive Developer
Posts: 4453
Joined: November 26th, 2005, 7:41 am
Contact:

Re: Wesband, MP dungeon-crawler (now for Wesnoth 1.9.14+ !)

Post by Sapient »

xudojnik wrote:
daniel.santos wrote:Any ideas on the huge delay after moving the avatar?
In this addon used "continue movement" mechanic.
In short, it means, that character gets additional movement points after movement, if no enemies nearby.
May be there is bad solution in moveto event handler.
This delay is caused mainly by the inefficient implementation of the function wml_actions.unpetrify(cfg) in file data\lua\wml-tags.lua

I suggest filing a bug report at bugs.wesnoth.org

To avoid the extra screen refreshes that are being triggered in that function, you can remove the [filter] and [/filter] lines inside the [unpetrify] tag so that the filtering works as intended.

However, the unit filtering is also running extremely slow, so that won't entirely alleviate the problem. For reasons that are currently unknown to me, this code was running very slow when I tried replacing unpetrify in the rousing event:
Spoiler:
This is a pretty simple filter and it should not be taking two seconds to run, but it tells me "it took 3202 milliseconds to store 1 unit", so that may be another bug.
http://www.wesnoth.org/wiki/User:Sapient... "Looks like your skills saved us again. Uh, well at least, they saved Soarin's apple pie."
Anonymissimus
Inactive Developer
Posts: 2460
Joined: August 15th, 2008, 8:46 pm
Location: Germany

Re: Wesband, MP dungeon-crawler (now for Wesnoth 1.9.14+ !)

Post by Anonymissimus »

Sapient wrote:This delay is caused mainly by the inefficient implementation of the function wml_actions.unpetrify(cfg) in file data\lua\wml-tags.lua
I see nothing inefficient in there other than the redraw calls. I had put it there since the previous C++ code was apparently doing it like this. However, I didn't notice any obvious reason for it so we can just kill it I suppose.

radius= in SLFs is a known CPU sucker - well, known to me. And I think the only thing where I ever actually noticed such kind of performance impact upon coding wml. 14 is also rather high for it I think.
(silene computed its complexity (O(n^2*log(n))) - I think you remember it ?: http://forums.wesnoth.org/viewtopic.php ... 30#p387330)
projects (BfW 1.12):
A Simple Campaign: campaign draft for wml startersPlan Your Advancements: mp mod
The Earth's Gut: sp campaignSettlers of Wesnoth: mp scenarioWesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign
User avatar
Sapient
Inactive Developer
Posts: 4453
Joined: November 26th, 2005, 7:41 am
Contact:

Re: Wesband, MP dungeon-crawler (now for Wesnoth 1.9.14+ !)

Post by Sapient »

Anonymissimus - there is also the problem that it triggers screen refreshes when units matching the filter were not petrified in the first place. I don't think the screen refreshes should be there at all, though.

Regarding complexity... thanks for reminding me!

If we take n as radius in hexes then, much like the area of a circle is pi*n^2, this means that checking x and y for every hex in that circle would have a complexity O(n^2). Unfortunately, the implementation of get_tiles_radius is very suboptimal, so every time we need to get the set of tiles within a radius of (x,y), that has the added complexity of O(n^(2*log(n))), which is probably what silene was referring to in that thread. Combined this makes O(n^(2*log(n)+n^2)) for terrain_filter::match with a simple x, y,radius filter. I agree that's pretty bad, but considering the operations required are fast ones and there is a limit on radius due to fixed map size, it should still be pretty fast.

However, what I forgot was that since my location filter code is also inside a unit filter of store_unit, that greatly increases complexity to O(n^(2u*log(n)+n^(2u)) where u is the total number of units on the map. And that is going to be very bad when you have a large radius times a large number of units.

The solution as we discovered in the other thread (and as I had forgotten), is to put the unit filter inside a store_locations instead of putting the location filter inside a store_unit. Then, once you have the locations, you can set status.petrified=no in a loop (avoiding [unpetrify] due to all the screen refreshes that would trigger).
http://www.wesnoth.org/wiki/User:Sapient... "Looks like your skills saved us again. Uh, well at least, they saved Soarin's apple pie."
Post Reply