--- Log opened Tue Jul 14 00:00:00 2009
20090714 00:00:14< Crab_> Dragonking: well, note than even on 'random' map we can just generate the 'hints' by simulating ai-vs-ai
20090714 00:00:50< Crab_> Dragonking: but, I suppose that it will be very good to allow ai to calculate it itself
20090714 00:01:10< Dragonking> Yes
20090714 00:01:37< Crab_> Dragonking: for example, if the AI will be able to figure out 'where the battle will be', it can be instructed to project power on that part on the map, by moving units there
20090714 00:01:59< Crab_> this will allow to implement a 'move/targeting' phase based on this info.
20090714 00:02:08< Dragonking> Crab_: I'm talking about this because I find it useful for recruting, but also it may be useful in other places
20090714 00:02:24< Dragonking> So we may want to somehow 'unify' the way how/when it is calcualted
20090714 00:02:24< Crab_> yes, you are right about 'useful in other places;
20090714 00:02:45< Crab_> at first, lets think about 'what the result will be' ?
20090714 00:03:20< Dragonking> Simplest solution: 4 locations that represent rectangle in a map
20090714 00:04:10< Crab_> ( Another (not simple) solution: 'std::set <map_location, std::vector<int> >'  (for each square of map, a vector of scores assigned to this location) )
20090714 00:04:39< Dragonking> Not simple and expensive in terms of calculating it
20090714 00:04:41< Crab_> I suppose that the AI will need something more like a 'front line'
20090714 00:05:47< Crab_> what about std::vector< map_location > - a list of map locations which will be the 'line of conflict ?
20090714 00:06:17< Crab_> and then, consider 'map locations which are near to that front line'
20090714 00:06:33< Dragonking> Ok
20090714 00:06:38< Dragonking> It may be this way too
20090714 00:06:56< Crab_> it will be something like 'supposed front line'
20090714 00:08:32< Crab_> can we base on default_ai_context_impl::power_projection implementation ?
20090714 00:09:02< Crab_> s/implementation/idea
20090714 00:09:03< Dragonking> We just brainstormed about it with grzywacz (we talk right now about that too ) ;)
20090714 00:09:26< Dragonking> I'm not too fammiliar with poer_projection
20090714 00:09:29< Crab_> it takes a location and says 'how much firepower can the enemy bring on location next turn'
20090714 00:10:21< grzywacz> That brings you back to evaluating it for every location.
20090714 00:10:26< Dragonking> What about 1st turn and when map is nearly empty?
20090714 00:10:30< Crab_> grzywacz: yes, once per turn
20090714 00:10:45< grzywacz> Crab_, number of locations * number of enemy units?
20090714 00:12:14< silene> grzywacz: the complexity is much less than that, but it is called a lot of time (since it takes into account zoc, it has to be recomputed after each move)
20090714 00:12:27< grzywacz> silene, pathfinding as well, right?
20090714 00:12:33< grzywacz> well, stupid question
20090714 00:15:19< Dragonking> "Weighted" approach is really accurate, but slow. I doubt we reely need so accurate approach.
20090714 00:15:22< Crab_> so, if we make a similar power_projection routine to 'approximate the amount of firepower the enemy can bring on location in next few turns', and  'approximate the amount of firepower we can bring on location in next few turns', will it allow us to find maps spots where the battle will be ?
20090714 00:15:37-!- Doppp|EeePC [n=aasdasd@c-67-171-96-240.hsd1.pa.comcast.net] has joined #wesnoth-dev
20090714 00:16:56< Crab_> note that this is needed for out-of-combat purposes (recruitment and strategic-level unit movement), so 1-calculation-per-turn will be enough
20090714 00:18:12< Dragonking> And we could maybe even re-use data so calcualte it only once, not for each AI side
20090714 00:18:30< Dragonking> But also we don't need to calculatei t for each hex 
20090714 00:18:37< Dragonking> We can make some 'grid'
20090714 00:18:50< silene> Crab_: seems complicated, and i'm not sure it correctly answers the question; why not just consider the hexes that are at half distance between the keep and an enemy unit
20090714 00:18:51< Dragonking> With lower 'resolution' that depends on size of a map
20090714 00:19:35< Crab_> silene: different units have different 'power' and different movement rates in different terrains
20090714 00:20:09< Crab_> silene: if we measure 'distance' in 'turns to get there', we'll take movement rate into account
20090714 00:20:18-!- ABCD [n=ABCD@wikipedia/ABCD] has quit [Read error: 104 (Connection reset by peer)]
20090714 00:21:06< silene> Crab_: yes, that's what i meant: consider the hexes where opposing units will meet
20090714 00:21:08< Crab_> Dragonking: afair, you calculate some kind of 'effectiveness' rating for all possible recruits ?
20090714 00:21:13-!- ABCD [n=ABCD@wikipedia/ABCD] has joined #wesnoth-dev
20090714 00:21:23< Crab_> Dragonking: (combat effectiveness)
20090714 00:21:29< Dragonking> Crab_: Yes, it's WIP but I do few ratings for units
20090714 00:22:08< Dragonking> Yes, simple combat effectivness
20090714 00:22:54< Crab_> silene: well, we need to take unit power/qty into account, as well. if 1 wolf rider (fast) meets 3 dwarven lords (slow), the place where they 'meet' will not be a 'front line' :)
20090714 00:24:26< silene> i don't understand, how are quantity and power related to movement rate? they only matter once the units are in range
20090714 00:25:10< Crab_> silene: well, the underlying problem is 'i want to recruit units which will be effective in the place where the battle will be'
20090714 00:26:04< Crab_> silene: but, calculating "where the battle will be?" based only on movement rates, will give bad results if enemy has very fast (but not very combat-capable) scouts.
20090714 00:26:23< silene> why does it give bad results?
20090714 00:29:25< Crab_> silene: because calculating based on movement rate will give us the location of the '1st skirmish if both sides are aggressive', not the location of 'the big battle'.  those scouts will be slaughtered fast, and the 'real' battle will be somewhere else.
20090714 00:31:23< silene> if there are only scouts and they are slaughtered fast, there won't be another battle; if there are other units than scouts, then there are also other hexes to consider and these other hexes are the location of the real battle; so i'm still not convinced it gives bad results
20090714 00:33:05< Ivanovic> off to bed, n8
20090714 00:33:29< Crab_> 'if there are other units than scouts, then there are also other hexes to consider' - I agree. But I say that the results for these 'other units' should be 'weighted' by unit 'combat effectiveness'.
20090714 00:34:18< silene> Crab_: but they are, aren't they? since you will perform a simulation of the fight against these units
20090714 00:34:19< Crab_> if a enemy archmage can move to the hex in 2 turns, it's, imo, more important then the 'enemy bat can move to the hex in 2 turns'
20090714 00:36:43< Crab_> silene: I wasn't thinking of 'combat simulations' , through this is an interesting idea...
20090714 00:38:57< Crab_> I was thinking about something like 'for each unit , for each hex, calculate the number of turns to reach this hex and add (to that hex) the info about (pre-cached) combat effectiveness of that unit on that hex'. then, attempt to divide the battlefield into 'spheres of influence' for each side.
20090714 00:41:48-!- kitty_ [n=kitty@wesnoth/artist/kitty] has quit []
20090714 00:44:33< Dragonking> Sounds ok, except that for 60x60 map with 100 units we would have quite a lot calcualtions...
20090714 00:45:35< grzywacz> Crab_, I've been thinking about that as well, but it sounds prohibitively expensive
20090714 00:45:40< grzywacz> Crab_, a prototype would be in order :)
20090714 00:45:47< Crab_> Dragonking, grzywacz: maybe start from the other end ?
20090714 00:45:59< Crab_> 1) 'draw a arbitrary line between us and enemies'
20090714 00:46:20< Crab_> 2) 'calculate a 'pressure' on elements of that line from both sides ('us' and 'then')
20090714 00:46:38< Crab_> 3) move the line a bit, in the direction given by '2'
20090714 00:47:13< grzywacz> Yes, we've been talking about such approach as well. '3' is where it gets difficult.
20090714 00:47:20< Crab_> 4) if the line changed to something new, goto 2
20090714 00:47:32< Crab_> grzywacz: what are the difficulties ?
20090714 00:48:06< grzywacz> Crab_, coming up with a reasonable algorithm :)
20090714 00:48:18< grzywacz> Like, it's not obvious.
20090714 00:51:08-!- thespaceinvader [n=chatzill@wesnoth/artist/thespaceinvader] has quit ["night all"]
20090714 00:54:47< grzywacz> Crab_, are you drawing something at this very moment as well? :P
20090714 00:54:54< Crab_> grzywacz: +
20090714 00:55:06< Dragonking> ;)
20090714 00:57:36-!- Espreon [n=espreon@wesnoth/developer/espreon] has joined #wesnoth-dev
20090714 00:58:00< Crab_> grzywacz: well (imagine that there exists a place in line where side 1 has a serious advantage) : 1) find 'hex A' - the place in that line where side1 has most advantage over side2  
20090714 00:58:04< grzywacz> http://hyperphysics.phy-astr.gsu.edu/hbase/electric/imgele/equiv5.gif
20090714 00:58:05< Crab_> 2) pick R, let R=3  3) for each hex within R hexes of A, calculate the said advantage. 4) pick a line fragment 'within R hexes of A' which will give minimum advantage for side1 over side2
20090714 00:58:08< grzywacz> Looks familiar? :P
20090714 00:58:30< Crab_> yes
20090714 00:59:12< Crab_> so, my idea is to 'relax' those parts of the line where one of the sides has the advantage.
20090714 00:59:37< Crab_> re-route the line near the point of greatest advantage, to minimize it
20090714 01:01:32< grzywacz> I follow so far. ;)
20090714 01:01:43< Crab_> that's all with 3 :)
20090714 01:03:44< grzywacz> Well, basically the task is to calculate the lines of equal potential. Seems like there should be solutions for similar physical problems, but I don't know if they are directly applicable to Wesnoth. ;-)
20090714 01:04:37< Crab_> also note that the time to 'add some numbers' for 60 hexes x 60 hexes x 100 units is small compared to the time to actually calculate those numbers
20090714 01:05:27< Crab_> since there are, afaik, combat simulations done to calculate the 'unit potential'. Dragonking ?
20090714 01:05:43-!- silene [n=plouf@wesnoth/developer/silene] has quit ["Leaving."]
20090714 01:06:30< esr> Espreon: You probaly want to see this - http://wesnoth.pastebin.com/m3fe354d9
20090714 01:06:31< Dragonking> We have quite a few combat calcualtions available, also we can think up any one we need
20090714 01:06:51-!- Sirp [n=me@wesnoth/developer/dave] has joined #wesnoth-dev
20090714 01:07:49< Espreon> esr: Thanks.
20090714 01:07:54-!- loonycyborg [n=sergey@wesnoth/developer/loonycyborg] has quit ["Zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz"]
20090714 01:08:04< Dragonking> Crab_: Thing is one unit has different comban value against different units
20090714 01:08:25-!- loonybot [n=loonybot@wesnoth/bot/loonybot] has quit [Remote closed the connection]
20090714 01:08:31< Dragonking> So we just can't probably set up 'fixed' evaluation, unless we just average it against all enemy possible recruit/units
20090714 01:08:55< Crab_> what about doing a test about a time it takes to evaluate a 'full' move map ?
20090714 01:09:22< Crab_> by 'full' I mean 'for each hex, write down the number of turns it takes for each of present units to reach it'
20090714 01:09:44< Crab_> for that '60 hexes x 60 hexes x 100 units' case
20090714 01:10:08< Crab_> (the number doesn't need to be exact)
20090714 01:11:14< Crab_> and this doesn't need to use A* - since we want to get to all hexes.
20090714 01:12:16< Crab_> this also (probably) doesn't need to take ZOC/units into account
20090714 01:14:19< grzywacz> I'd give it a try.
20090714 01:14:29< grzywacz> Wel...
20090714 01:14:32< grzywacz> Well even.
20090714 01:14:50< grzywacz> Without A* you can get fooled by unpassable terrain.
20090714 01:15:12< Crab_> grzywacz: movement cost on terrain should be taken into account of course :)
20090714 01:15:57< Crab_> so, there will be pathfinding, but not A*
20090714 01:17:00< grzywacz> Why not? A* is terrain cost + heuristics. ZOC is not needed of course.
20090714 01:17:38< grzywacz> Time for me, night.
20090714 01:17:44< Crab_> we need 'least path cost from one node to all other nodes'
20090714 01:17:56< Crab_> A* gives us 'least path cost from one node to target node'
20090714 01:18:15< Crab_> 'for each of other nodes, do A*(node)' is not optimal
20090714 01:18:57-!- cjhopman [n=chris@wesnoth/developer/cjhopman] has joined #wesnoth-dev
20090714 01:19:07< Crab_> grzywacz: btw, note that, if we want to speed things up, we can rewrite 'movement cost for unit type A on map hex B' to be o(1)    (requires a big CAM)
20090714 01:19:50< Dragonking> It's geting intersting, but it is time for me to go to sleep too :)
20090714 01:19:51< grzywacz> Crab_, A* but with a stop condition defined by "no more hexes to try" instead of by an end point
20090714 01:20:25< Crab_> then you don't need heuristics :)
20090714 01:20:47< grzywacz> Fine. A breadth-first search then. ;)
20090714 01:20:56< Crab_> hehe :)
20090714 01:21:07< Crab_> ok
20090714 01:21:35< Dragonking> Good night everyone
20090714 01:21:40< Crab_> Dragonking: night
20090714 01:21:41< grzywacz> Yeah, night.
20090714 01:21:54< Crab_> night :)
20090714 01:22:01-!- grzywacz [n=grzywacz@wesnoth/developer/grzywacz] has quit [Remote closed the connection]
20090714 01:22:15-!- Crab_ [i=crab@wesnoth/developer/crab] has quit ["Leaving."]
20090714 01:23:08< cjhopman> we have something already for shortest path to all other hexes
20090714 01:29:59< cjhopman> Crab_: the paths struct finds all shortest paths for a unit via djikstra's, it appears to allow ignoring zoc
20090714 01:37:23-!- allefant [n=allefant@allegro/developer/allefant] has quit ["Leaving"]
20090714 01:44:47-!- mjs-de [n=mjs-de@wh.Uni-Dortmund.DE] has quit [Read error: 113 (No route to host)]
20090714 01:54:47-!- mjs-de [n=mjs-de@vpw.wh.Uni-Dortmund.DE] has joined #wesnoth-dev
20090714 01:57:09-!- Turuk [n=Turuk@wesnoth/forumsith/turuk] has joined #wesnoth-dev
20090714 02:01:40-!- Espreon [n=espreon@wesnoth/developer/espreon] has quit ["WRYYYYYYYYYYYYYYYYYYYY!"]
20090714 02:52:55< Bob_The_Mighty> could anyone help me with some wml questions?
20090714 02:53:40< Bob_The_Mighty> the hero ellipse seems not to be team-coloured, is this a feature or bug? or must it be set somewhere specially...
20090714 02:54:23-!- Elvish_Pillager [n=eli@71-10-231-36.dhcp.oxfr.ma.charter.com] has quit ["Hi! I'm a quit message virus vaccine. If you see a quit message virus, don't replace your quit message with it!"]
20090714 02:55:44-!- Blarumyrran [n=Blarumyr@81-20-159-197.levira.ee] has joined #wesnoth-dev
20090714 02:59:35-!- Blueblaze [n=nick@c-98-199-143-139.hsd1.tx.comcast.net] has joined #wesnoth-dev
20090714 03:15:41-!- ABCD_ [n=ABCD@wikipedia/ABCD] has joined #wesnoth-dev
20090714 03:16:30-!- ABCD [n=ABCD@wikipedia/ABCD] has quit [Read error: 104 (Connection reset by peer)]
20090714 03:21:34-!- MJ999 [n=msflower@80.154.28.81] has quit [Read error: 54 (Connection reset by peer)]
20090714 03:21:42-!- MJ999 [n=msflower@80.154.28.81] has joined #wesnoth-dev
20090714 03:32:09-!- Sapient [n=sapien-x@adsl-211-221-43.asm.bellsouth.net] has joined #wesnoth-dev
20090714 03:32:34< Sapient> ah, finally got the DSL setup at my new place
20090714 03:35:41-!- Sapient [n=sapien-x@wesnoth/developer/sapient] has quit [Nick collision from services.]
20090714 03:35:46-!- Sapient [n=sapien-x@wesnoth/developer/sapient] has joined #wesnoth-dev
20090714 03:35:56< Sapient> darn... spoke too soon :p
20090714 03:41:50-!- Sapient [n=sapien-x@wesnoth/developer/sapient] has quit [Nick collision from services.]
20090714 03:41:56-!- Sapient [n=sapien-x@wesnoth/developer/sapient] has joined #wesnoth-dev
20090714 03:46:07-!- Bob_The_Mighty [n=chatzill@cpc3-brig15-0-0-cust558.3-3.cable.virginmedia.com] has quit [Read error: 104 (Connection reset by peer)]
20090714 03:50:57-!- mjs-de [n=mjs-de@vpw.wh.Uni-Dortmund.DE] has quit ["On the road again"]
20090714 04:03:46-!- Sapient [n=sapien-x@wesnoth/developer/sapient] has quit [Read error: 110 (Connection timed out)]
20090714 04:16:30-!- BenUrban [n=benurban@68.55.19.224] has joined #wesnoth-dev
20090714 04:22:29-!- Ivanovic_ [n=ivanovic@dtmd-4db2ba6e.pool.einsundeins.de] has joined #wesnoth-dev
20090714 04:32:11-!- Turuk [n=Turuk@wesnoth/forumsith/turuk] has quit [Read error: 110 (Connection timed out)]
20090714 04:37:57-!- Ivanovic [n=ivanovic@wesnoth/developer/ivanovic] has quit [Read error: 113 (No route to host)]
20090714 04:38:27-!- Ivanovic_ is now known as Ivanovic
20090714 05:04:20-!- Espreon [n=espreon@wesnoth/developer/espreon] has joined #wesnoth-dev
20090714 05:04:20-!- Espreon [n=espreon@wesnoth/developer/espreon] has quit [Client Quit]
20090714 05:05:38-!- Espreon [n=espreon@wesnoth/developer/espreon] has joined #wesnoth-dev
20090714 05:11:47-!- Kenpachi_ [n=chatzill@CPE-58-170-83-213.sa.bigpond.net.au] has joined #wesnoth-dev
20090714 05:18:02-!- Aethaeryn [n=Michael@wesnoth/umc-dev/developer/aethaeryn] has quit ["'night"]
20090714 05:25:56-!- Blueblaze2 [n=nick@c-98-199-143-139.hsd1.tx.comcast.net] has joined #wesnoth-dev
20090714 05:28:51-!- elias [n=allefant@allegro/developer/allefant] has joined #wesnoth-dev
20090714 05:30:47-!- Kenpachi [n=chatzill@CPE-58-169-212-134.sa.bigpond.net.au] has quit [Read error: 110 (Connection timed out)]
20090714 05:32:12-!- Espreon [n=espreon@wesnoth/developer/espreon] has quit ["WRYYYYYYYYYYYYYYYYYYYY!"]
20090714 05:33:24-!- ancestral [n=ancestra@166.205.5.12] has joined #wesnoth-dev
20090714 05:36:32-!- Blueblaze [n=nick@c-98-199-143-139.hsd1.tx.comcast.net] has quit [Read error: 110 (Connection timed out)]
20090714 06:09:14-!- wesbot changed the topic of #wesnoth-dev to: 1.7.2 planned for next Sunday (July 19th) | 64 bugs, 241 feature requests, 13 patches | logs: http://irclogs.wesnoth.org/ | Don't paste on IRC! Use a pastebin: http://wesnoth.pastebin.com | http://imagebin.org
20090714 06:16:47-!- elias [n=allefant@allegro/developer/allefant] has quit [Remote closed the connection]
20090714 06:33:25-!- crimson_penguin [n=ben@wesnoth/developer/crimsonpenguin] has quit []
20090714 06:40:11-!- ancestral [n=ancestra@166.205.5.12] has quit ["Get Colloquy for iPhone! http://mobile.colloquy.info/"]
20090714 06:40:57-!- ancestral [n=ancestra@97-116-127-39.mpls.qwest.net] has joined #wesnoth-dev
20090714 07:08:20-!- zookeeper [n=l@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20090714 07:58:23< corn> Ivanovic: oops, I missed the deadline
20090714 07:58:35< corn> I haven't been on in 3 days so I screwed up ):
20090714 07:58:59< corn> dfranke: did you submit your part of the eval?
20090714 07:59:19< corn> I am getting it sorted out in the #gsoc channel right now
20090714 08:08:03-!- Sirp [n=me@wesnoth/developer/dave] has quit [Read error: 113 (No route to host)]
20090714 08:13:37-!- ancestral [n=ancestra@97-116-127-39.mpls.qwest.net] has quit ["And that’s the end of THAT chapter."]
20090714 08:14:43-!- Blueblaze2 is now known as Blueblaze
20090714 08:22:19-!- testing_xyz [n=johnTriv@87-126-108-161.btc-net.bg] has joined #wesnoth-dev
20090714 08:39:52-!- Kenpachi [n=chatzill@CPE-58-170-83-213.sa.bigpond.net.au] has joined #wesnoth-dev
20090714 08:43:57-!- loonybot [n=loonybot@79.139.138.33] has joined #wesnoth-dev
20090714 08:46:49-!- stikonas [n=and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20090714 08:46:55-!- loonycyborg [n=sergey@79.139.138.33] has joined #wesnoth-dev
20090714 08:47:16-!- silene [n=plouf@wesnoth/developer/silene] has joined #wesnoth-dev
20090714 08:47:20< silene> hi
20090714 08:49:27-!- mordocai [n=Administ@66.119.9.243] has joined #wesnoth-dev
20090714 08:59:12-!- Kenpachi_ [n=chatzill@CPE-58-170-83-213.sa.bigpond.net.au] has quit [Read error: 110 (Connection timed out)]
20090714 09:03:02-!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Read error: 104 (Connection reset by peer)]
20090714 09:04:55-!- stikonas [n=and@ctv-79-132-177-212.vinita.lt] has joined #wesnoth-dev
20090714 09:05:15-!- xyz_test [n=testing_@95-42-210-64.btc-net.bg] has joined #wesnoth-dev
20090714 09:06:31-!- Doppp|EeePC [n=aasdasd@c-67-171-96-240.hsd1.pa.comcast.net] has quit ["Leaving."]
20090714 09:12:33-!- silene1 [n=plouf@ASte-Genev-Bois-152-1-12-23.w82-121.abo.wanadoo.fr] has joined #wesnoth-dev
20090714 09:13:13-!- silene [n=plouf@wesnoth/developer/silene] has quit [Read error: 110 (Connection timed out)]
20090714 09:16:33-!- busfahrer [n=busfahre@unixboard/user/busfahrer] has joined #wesnoth-dev
20090714 09:20:22-!- ilor [n=user@wesnoth/developer/ilor] has joined #wesnoth-dev
20090714 09:21:25-!- Appleman1234 [n=Appleman@c122-104-135-239.kelvn2.qld.optusnet.com.au] has joined #wesnoth-dev
20090714 09:30:59-!- silene1 is now known as silene
20090714 09:47:47-!- noy [n=Noy@wesnoth/developer/noy] has quit []
20090714 10:17:34-!- Appleman1234 [n=Appleman@c122-104-135-239.kelvn2.qld.optusnet.com.au] has quit [Remote closed the connection]
20090714 10:26:21-!- Bob_The_Mighty [n=chatzill@cpc3-brig15-0-0-cust558.3-3.cable.virginmedia.com] has joined #wesnoth-dev
20090714 10:44:35-!- melinath [n=melinath@stud243151.studentenheim.uni-tuebingen.de] has joined #wesnoth-dev
20090714 10:46:59< Ivanovic> corn: dfranke filled out the survey and i already pinged leslie yesterday that you seemed to be lated with filling out your survey and that we got no idea what happened
20090714 10:47:19< Ivanovic> corn: so you should probably write her and/or ellen a mail off list
20090714 10:47:35< Ivanovic> (they should both have posted on the student ml, so their addresses should be known)
20090714 10:51:18-!- grzywacz [n=grzywacz@wesnoth/developer/grzywacz] has joined #wesnoth-dev
20090714 10:53:27< grzywacz> hi
20090714 10:53:51< Ivanovic> hi grzywacz
20090714 10:54:04< Ivanovic> moin
20090714 10:57:18-!- Appleman1234 [n=Appleman@c122-104-135-239.kelvn2.qld.optusnet.com.au] has joined #wesnoth-dev
20090714 11:13:32-!- Crab_ [i=crab@wesnoth/developer/crab] has joined #wesnoth-dev
20090714 11:24:35-!- Blueblaze [n=nick@c-98-199-143-139.hsd1.tx.comcast.net] has quit [Remote closed the connection]
20090714 11:26:26< ilor> mordante: I intend to work some on serverside stuff now so you're free to fiddle with the lobby ui
20090714 11:34:15-!- Bob_The_Mighty [n=chatzill@cpc3-brig15-0-0-cust558.3-3.cable.virginmedia.com] has quit [Read error: 104 (Connection reset by peer)]
20090714 11:39:13-!- melinath [n=melinath@stud243151.studentenheim.uni-tuebingen.de] has quit [Read error: 60 (Operation timed out)]
20090714 11:39:29-!- Kenpachi [n=chatzill@CPE-58-170-83-213.sa.bigpond.net.au] has quit ["ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]"]
20090714 11:45:39-!- busfahrer [n=busfahre@unixboard/user/busfahrer] has quit ["leaving"]
20090714 11:48:51-!- EdB [n=edb@248.12.95-79.rev.gaoland.net] has joined #wesnoth-dev
20090714 12:01:16< esr> Everybody: Am about to go to Michigan to train with my sword-kin.  Won't have reliable Internet until returning Monday.
20090714 12:23:32< Ivanovic> esr: your stuff should be ready for 1.7.2?
20090714 12:25:18< esr> Ivanovic: Yes.  All I'm currently waiting on is Kitty's final version of the New Writing glyphs, and that's for the wiki. All a my ptrojects in the svn tree are in a stable, reasdy-to-ship state.
20090714 12:26:55< Ivanovic> great
20090714 12:27:06< Ivanovic> then all that i can say is: have fun!
20090714 12:27:11< Ivanovic> ;)
20090714 12:55:02-!- EdB [n=edb@248.12.95-79.rev.gaoland.net] has quit [Remote closed the connection]
20090714 13:08:20< corn> Ivanovic: ah, alright. thanks for the info
20090714 13:08:28-!- Crab_ [i=crab@wesnoth/developer/crab] has quit ["Leaving."]
20090714 13:09:10-!- melinath [n=melinath@stud243151.studentenheim.uni-tuebingen.de] has joined #wesnoth-dev
20090714 13:17:00-!- mjs-de [n=mjs-de@vpw.wh.uni-dortmund.de] has joined #wesnoth-dev
20090714 13:29:21-!- xyz_test [n=testing_@95-42-210-64.btc-net.bg] has quit [Client Quit]
20090714 13:38:23-!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Remote closed the connection]
20090714 13:38:48-!- Sapient [n=patrickp@wesnoth/developer/sapient] has joined #wesnoth-dev
20090714 13:43:05-!- stikonas [n=and@ctv-79-132-177-212.vinita.lt] has joined #wesnoth-dev
20090714 13:48:49-!- ilor [n=user@wesnoth/developer/ilor] has quit []
20090714 13:49:56-!- Appleman1234 [n=Appleman@c122-104-135-239.kelvn2.qld.optusnet.com.au] has quit [Read error: 110 (Connection timed out)]
20090714 13:55:57-!- Appleman1234 [n=Appleman@c122-104-135-239.kelvn2.qld.optusnet.com.au] has joined #wesnoth-dev
20090714 14:07:09-!- lizard_r [n=Miranda@wesnoth/umc-dev/developer/lizard] has joined #wesnoth-dev
20090714 14:27:16-!- Turuk [n=Turuk@wesnoth/forumsith/turuk] has joined #wesnoth-dev
20090714 14:46:42-!- melinath [n=melinath@stud243151.studentenheim.uni-tuebingen.de] has quit [Read error: 110 (Connection timed out)]
20090714 14:52:06-!- Appleman1234 [n=Appleman@c122-104-135-239.kelvn2.qld.optusnet.com.au] has quit [Read error: 110 (Connection timed out)]
20090714 14:59:00-!- melinath [n=melinath@stud243151.studentenheim.uni-tuebingen.de] has joined #wesnoth-dev
20090714 14:59:11-!- melinath [n=melinath@stud243151.studentenheim.uni-tuebingen.de] has left #wesnoth-dev []
20090714 14:59:13-!- melinath [n=melinath@stud243151.studentenheim.uni-tuebingen.de] has joined #wesnoth-dev
20090714 14:59:15-!- melinath [n=melinath@stud243151.studentenheim.uni-tuebingen.de] has left #wesnoth-dev []
20090714 14:59:28-!- melinath [n=melinath@stud243151.studentenheim.uni-tuebingen.de] has joined #wesnoth-dev
20090714 15:14:40-!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Remote closed the connection]
20090714 15:16:22-!- BenUrban [n=benurban@unaffiliated/benurban] has quit ["Power failu"]
20090714 15:19:08-!- stikonas [n=and@ctv-79-132-177-212.vinita.lt] has joined #wesnoth-dev
20090714 15:19:12< CIA-53> turuk * r36886 /trunk/data/core/units/ (7 files in 2 dirs): Changed weapon descriptions and images to reflect actual weapon used by the units.
20090714 15:21:30-!- YogiHH [i=d4ca9d15@wesnoth/developer/yogihh] has joined #wesnoth-dev
20090714 15:23:24-!- Sirp [n=me@pool-173-74-23-130.dllstx.fios.verizon.net] has joined #wesnoth-dev
20090714 15:35:13-!- allefant [n=allefant@allegro/developer/allefant] has joined #wesnoth-dev
20090714 15:35:47-!- maxy [n=maxy@80.219.1.128] has joined #wesnoth-dev
20090714 16:04:00< CIA-53> silene * r36887 /trunk/src/ (game_events.cpp game_events.hpp): Cleaned code for setting terrain and exported it.
20090714 16:04:06< CIA-53> silene * r36888 /trunk/src/scripting/lua.cpp: Factored code for pushing translatable strings.
20090714 16:04:10< CIA-53> silene * r36889 /trunk/src/scripting/lua.cpp: Added Lua accessors for terrain locations and info.
20090714 16:04:47-!- Kenpachi [n=chatzill@CPE-58-170-83-213.sa.bigpond.net.au] has joined #wesnoth-dev
20090714 16:09:49-!- ABCD_ [n=ABCD@wikipedia/ABCD] has quit [Read error: 104 (Connection reset by peer)]
20090714 16:10:04-!- ABCD [n=ABCD@wikipedia/ABCD] has joined #wesnoth-dev
20090714 16:17:48-!- Turuk [n=Turuk@wesnoth/forumsith/turuk] has quit [Read error: 110 (Connection timed out)]
20090714 16:21:43-!- Sirp [n=me@pool-173-74-23-130.dllstx.fios.verizon.net] has quit [Read error: 110 (Connection timed out)]
20090714 16:28:03-!- Doppp|EeePC [n=aasdasd@CMU-326818.WV.CC.CMU.EDU] has joined #wesnoth-dev
20090714 16:28:03-!- Doppp|EeePC [n=aasdasd@CMU-326818.WV.CC.CMU.EDU] has quit [Read error: 104 (Connection reset by peer)]
20090714 16:29:12-!- Doppp|EeePC1 [n=aasdasd@CMU-326818.WV.CC.CMU.EDU] has joined #wesnoth-dev
20090714 16:29:54-!- Doppp|EeePC1 [n=aasdasd@CMU-326818.WV.CC.CMU.EDU] has left #wesnoth-dev []
20090714 16:38:57< lizard_r> (C++) Hi, I try to calculate the cost of all units you lost. The losses are mapped with a str_int_map so I don't know how to get the cost of a Unit (i can't just use .cost() because I have a string). Could someone give me a hint?
20090714 16:41:06< YogiHH> lizard_r: the string is a unit_type?
20090714 16:41:37< lizard_r> I hope so, but I don't know for sure
20090714 16:43:17< Dragonking> If it is so, then you could lookup unit_type_data::types().find_unit_type(string)
20090714 16:43:23< YogiHH> lizard_r: well, in that case there is a global unit_type manager object (not sure about the name, i think it was "unit_types", but i don't have the code in front of me). It provides a find-method, which gives you access to all you need, including the cost.
20090714 16:43:30< lizard_r> I'll try that
20090714 16:43:42< YogiHH> DK beat me :-)
20090714 16:44:32< Dragonking> ;)
20090714 16:50:47-!- ardesh [n=ardesh@port-92-206-106-242.dynamic.qsc.de] has joined #wesnoth-dev
20090714 16:51:09-!- crimson_penguin [n=ben@64.201.60.211] has joined #wesnoth-dev
20090714 16:53:36-!- YogiHH [i=d4ca9d15@wesnoth/developer/yogihh] has quit ["Page closed"]
20090714 17:02:47-!- Sapient [n=patrickp@wesnoth/developer/sapient] has left #wesnoth-dev []
20090714 17:05:44-!- Crab_ [i=crab@wesnoth/developer/crab] has joined #wesnoth-dev
20090714 17:07:12< lizard_r> thanks, that seems to work :-)
20090714 17:09:19< Blarumyrran> Should i expect you to recruit endless units in mp for 0 gold now?
20090714 17:09:44< lizard_r> no
20090714 17:10:49< lizard_r> well, now that you mention it that seems like a good idea
20090714 17:12:15 * Blarumyrran is full of good ideas, always
20090714 17:15:42< CIA-53> silene * r36890 /trunk/src/scripting/lua.cpp: Added Lua accessors for village ownership.
20090714 17:42:44-!- Blarumyrran [n=Blarumyr@81-20-159-197.levira.ee] has quit []
20090714 17:46:27-!- melinath [n=melinath@stud243151.studentenheim.uni-tuebingen.de] has quit ["Leaving"]
20090714 17:50:04-!- busfahrer [n=busfahre@unixboard/user/busfahrer] has joined #wesnoth-dev
20090714 17:53:36-!- noy [n=Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20090714 17:58:40< CIA-53> dragonking * r36891 /trunk/src/formula_tokenizer.cpp: Speedup formula parsing by changing the order in which parser looks for regexps
20090714 18:02:18< CIA-53> silene * r36892 /trunk/src/scripting/lua.cpp: Added Lua accessor for map size.
20090714 18:05:18< CIA-53> dragonking * r36893 /trunk/src/formula_tokenizer.cpp: Small fix to previous commit
20090714 18:07:43 * Dragonking disappears
20090714 18:25:53-!- gabm [n=gabm@64.235.200.224] has joined #wesnoth-dev
20090714 18:25:55-!- gabm [n=gabm@64.235.200.224] has left #wesnoth-dev []
20090714 18:28:53-!- lizard_r [n=Miranda@wesnoth/umc-dev/developer/lizard] has quit ["Saurian Augur - I'll heal you by 4 hp if you leave next to me"]
20090714 18:32:59< CIA-53> silene * r36894 /trunk/ (53 files in 3 dirs): Fixed three typos in Delfador's Memoirs and updated pofix accordingly.
20090714 18:42:40-!- loktor [n=quassel@AAubervilliers-151-1-9-42.w83-114.abo.wanadoo.fr] has joined #wesnoth-dev
20090714 18:53:04-!- Aethaeryn [n=Michael@wesnoth/umc-dev/developer/aethaeryn] has joined #Wesnoth-dev
20090714 19:13:07< Crab_> Dragonking: around ?
20090714 19:13:38-!- thespaceinvader [n=chatzill@wesnoth/artist/thespaceinvader] has joined #wesnoth-dev
20090714 19:35:45< CIA-53> silene * r36895 /trunk/ (5 files in 3 dirs): Added cost of units recruited, recalled, killed, and lost, to the statistics window (patch #1190 by lizard).
20090714 19:35:53< CIA-53> silene * r36896 /trunk/src/addon_management.cpp: Improved dependency text when downloading addon (bug #13432, patch #1184 by ancestral).
20090714 20:03:53-!- AnMaster is now known as AnMaster_ipv6
20090714 20:08:18-!- lizard_r [n=Miranda@wesnoth/umc-dev/developer/lizard] has joined #wesnoth-dev
20090714 20:18:21-!- YogiHH [n=chatzill@d052091.adsl.hansenet.de] has joined #wesnoth-dev
20090714 20:21:14-!- Kenpachi [n=chatzill@CPE-58-170-83-213.sa.bigpond.net.au] has quit [Read error: 54 (Connection reset by peer)]
20090714 20:28:36-!- maxy [n=maxy@80.219.1.128] has quit []
20090714 20:34:19-!- EdB [n=edb@248.12.95-79.rev.gaoland.net] has joined #wesnoth-dev
20090714 20:36:53-!- loktor [n=quassel@AAubervilliers-151-1-9-42.w83-114.abo.wanadoo.fr] has quit [Remote closed the connection]
20090714 20:41:37< Crab_> how can I find the cause of "Error while reading the WML: Mandatory WML child missing yet untested for. Please report." message ?
20090714 20:44:38< Crab_> (ok, found out)
20090714 20:44:57< Soliton> would be good to mention the missing child in the error.
20090714 20:45:36< corn> Ivanovic: I emailed Leslie Hawthorne, she said she'll have instructions shortly regarding my survey and payment... it will probably be ok
20090714 20:45:48< Crab_> Soliton: yes, that would be good.  nevertheless, gdb helped me.
20090714 20:47:14< corn> Crab_: regarding my killmap idea, how do you think I should grab the map data
20090714 20:47:22< corn> I was thinking about it
20090714 20:47:31< corn> and lets say for example a user wants to see data for svn version 1.7
20090714 20:47:45< corn> then I need to find the svn revision of the map for 1.7
20090714 20:48:13< Soliton> Crab_: what was the issue?
20090714 20:48:40< Crab_> Soliton: my own local changes in ai config format :)
20090714 20:50:14< corn> so I am thinking that there will have to be a config file defining what revision of a map to use for a release version
20090714 20:50:34< corn> and every time there is a new release, someone will have to change the config file
20090714 20:50:36< Crab_> corn: imo: 1) make the system tolerant to small changes in maps  2) create a script to export all maps to pictures  3) integrate  this script with the release procedure..
20090714 20:50:59< corn> how do you suggest to do #1?
20090714 20:51:33< Crab_> 'ignore invalid data', such as 'off-map kills'
20090714 20:52:09< corn> hm
20090714 20:52:56< Crab_> another way is to get map data each time.
20090714 20:53:07< Crab_> only terrain info will be needed
20090714 20:53:23< corn> and you only need to store one copy
20090714 20:53:29< corn> once you transfer, you can compare to existing copies in the DB
20090714 20:53:56< Crab_> yes
20090714 20:54:10< Crab_> how much overhead this will bring ?
20090714 20:54:31< corn> a map is only a few kb I think
20090714 20:54:38-!- busfahrer [n=busfahre@unixboard/user/busfahrer] has quit ["leaving"]
20090714 20:54:41< corn> let me double check that
20090714 20:54:44< Crab_> another way is to transmit a crypto-checksum of the  map each time.
20090714 20:55:11< corn> yes, maps are from 10kb to 30kb
20090714 20:55:18< Crab_> so, if your 'server' part knows about all 'well-known' maps, it will only need the checksum to find 'what revision of the map it is'
20090714 20:55:48< corn> ideally it should work on all maps
20090714 20:56:01< corn> including non-mainline
20090714 20:56:02< Crab_> including generated maps ? :)
20090714 20:56:18< corn> no
20090714 20:56:25< corn> well
20090714 20:56:47< corn> there also has to be some way of preventing a user from flooding the DB with imaginary maps
20090714 20:56:50< corn> thats a security issue
20090714 20:57:17< corn> but I think I like the idea of just transmitting the entire map, since it is so small
20090714 20:57:38< corn> it will probably even come out to a disk saving on the HD because you don't need multiple copies of the same tile
20090714 20:57:41< Crab_> well, if you have the script to export a map to picture, you can run it on addons.wesnoth.org, as well
20090714 20:58:03< Crab_> to get those 'non-mainline' maps, as well
20090714 20:58:37< Crab_> also note that gzipped map will be smaller
20090714 20:58:44< Crab_> since terrain repeats
20090714 20:58:57< silene> Soliton: it's impossible to display the missing child in the error message, since the error happens much later; it's like experiencing a segfault and wondering who created the null pointer (and it's really like that, the error message is just there to recover from a null pointer)
20090714 20:58:58< corn> yep
20090714 21:00:57< Crab_> corn: btw, what about a 1) client-to-server: I've got a map with md5 'aabbbcc...' 2) server-to-client: interested, give entire map to me          or 1) client-to-server: I've got a map with md5 'aabbdd' 3) server-to-client: oh, I know it already, just give me the killmap.
20090714 21:01:21-!- Aethaeryn [n=Michael@wesnoth/umc-dev/developer/aethaeryn] has quit ["<Insert witty phrase here.>"]
20090714 21:01:36< corn> it is not worth it since the files are actually so tiny
20090714 21:02:38< corn> I just compressed a 6.6 kb map to 639 bytes
20090714 21:02:46< Crab_> why 'not worth' ? md5 is 16 bytes, map is 639 bytes
20090714 21:03:23< corn> right now the uploads have no communication back from server to client
20090714 21:03:53< Crab_> corn: if it's by tcp, then the communication channel is present :)
20090714 21:04:17< Crab_> but, I understand that it might be easier to just 'compress that map'.
20090714 21:04:23< corn> well
20090714 21:04:28< corn> what you are recommending is
20090714 21:04:32< corn> 1. send checksum
20090714 21:04:36< corn> 2. server gives OK
20090714 21:04:43< corn> 3. send map and killmap, or just killmap
20090714 21:04:49< corn> I just want to
20090714 21:04:52< corn> 1. send map and killmap
20090714 21:05:19< corn> more bandwidth but you don't have to create a communication protocol between server and client
20090714 21:05:23< Crab_> ok
20090714 21:05:34< corn> in both cases, all binary data is still gzipped
20090714 21:05:53< corn> well, binary and text
20090714 21:06:02< corn> ok
20090714 21:06:29< corn> thanks, this was helpful :)
20090714 21:06:33< Crab_> and add a special flag to a map which will say 'please send killmaps of game on this map'
20090714 21:07:05< Crab_> to avoid polluting the db with generated maps / beta versions of maps / etc
20090714 21:07:11< corn> ah
20090714 21:07:14< corn> that's a good idea
20090714 21:07:26< Crab_> or just drop those maps with not enough results in the db, from time to time
20090714 21:07:46< corn> yes I was thinking something along those lines
20090714 21:07:47< corn> really
20090714 21:07:50-!- lizard_r [n=Miranda@wesnoth/umc-dev/developer/lizard] has quit ["Saurian Augur - I'll heal you by 4 hp if you leave next to me"]
20090714 21:07:52< corn> the db will store a filepath
20090714 21:08:04< corn> I have not really heard of people storing binary data inside the db
20090714 21:08:13< corn> so it will have a filepath and a checksum
20090714 21:08:36< corn> columns will be: mapname, filepath, checksum
20090714 21:09:13< corn> and the table that stores killgraph data will be matched against the checksum so you can just examine things with a JOIN
20090714 21:09:58< corn> columns will probably be map checksum, game # (a column in the general game info table)
20090714 21:10:10< corn> and the actual killgraph data
20090714 21:10:22< corn> anyway, be back in a little while
20090714 21:10:25< corn> thanks a lot
20090714 21:10:36< Crab_> will you include the unit type in the killgraph ?
20090714 21:10:39< corn> yes
20090714 21:10:40< Crab_> or just counts ?
20090714 21:10:44< Crab_> ok
20090714 21:11:21< crimson_penguin> people do store binary data in DBs sometimes... not sure why though
20090714 21:12:04< Crab_> crimson_penguin: it gives more consistency and less potential for corruption. you can always put a cache on the filesystem, and get the same speed.
20090714 21:12:37< Crab_> if the binary data is included in transactions, for example..
20090714 21:14:03< corn> except that you will lock tables when doing a transaction with a big piece of data for a long time
20090714 21:14:47< CIA-53> jhinrichs * r36897 /trunk/src/gui/widgets/window.cpp: Silence a vc++ compiler warning
20090714 21:14:47< Crab_> corn: why lock ? if the db has mvcc, locking is not always needed.
20090714 21:16:03< corn> heh
20090714 21:16:34< corn> I am not sure if I am using the good db engine for mysql that does correct transaction support
20090714 21:16:45< corn> the default engine is myISAM, the other is innoDB
20090714 21:16:47< corn> I will check now
20090714 21:17:04< CIA-53> jhinrichs * r36898 /trunk/src/gui/widgets/ (text.cpp text.hpp): Provide ttext_ with a text_changed event to be able to grab the text of a textbox after it got changed by keystrokes.
20090714 21:17:34 * Crab_ is a postgresql user, so don't know exactly what mysql does...
20090714 21:17:49< corn> there are two DB engines
20090714 21:17:54-!- mordante [n=mordante@wesnoth/developer/mordante] has joined #wesnoth-dev
20090714 21:18:01-!- mordante [n=mordante@wesnoth/developer/mordante] has quit [Read error: 54 (Connection reset by peer)]
20090714 21:18:03< corn> myISAM is the older one and doesn't support atomic transactions or a lot of nice features
20090714 21:18:13-!- mordante [n=mordante@wesnoth/developer/mordante] has joined #wesnoth-dev
20090714 21:18:26< mordante> servus
20090714 21:21:18< Crab_> hi, mordante
20090714 21:21:28< mordante> hi Crab_ 
20090714 21:22:32< CIA-53> jhinrichs * r36899 /trunk/ (3 files in 2 dirs): Add the filter functionality for the savegame list of the load-game dialog.
20090714 21:23:02< Crab_> mordante: a small question: I want to add a two-column table to the statistics dialog, where I can find an example of 'adding a table to a dialog' ?
20090714 21:23:29< mordante> Crab_, for gui2 or the old gui?
20090714 21:23:58< CIA-53> jhinrichs * r36900 /trunk/src/savegame.cpp: Show the gui2 game-load dialog if wesnoth is started with --new-widgets.
20090714 21:24:02< Crab_> mordante: it's a new feature idea, so I think it's better to go with gui2
20090714 21:24:11< CIA-53> mordante * r36901 /trunk/po/CMakeLists.txt: Add a bug entry to the pot files for cmake.
20090714 21:24:15< mordante> Ivanovic, ^
20090714 21:24:37< mordante> Crab_, yes I prefer to have new dialogs in gui2 
20090714 21:25:02< CIA-53> jhinrichs * r36902 /trunk/ (5 files in 3 dirs): Add new files for the delete-game-confirmation dialog.
20090714 21:25:43< Crab_> mordante: I want to add a small table listing the values of some counters, which will be calculated by calling formula ai formulas
20090714 21:26:20< mordante> Crab_, data/gui/default/window/mp_server_list.cfg has an example of two columns
20090714 21:26:30< Crab_> ok, thanks
20090714 21:28:01< CIA-53> jhinrichs * r36903 /trunk/src/ (CMakeLists.txt SConscript): Add game_delete.cpp to the build scripts.
20090714 21:28:24< YogiHH> hi mordante, just the man i was looking for ;-)
20090714 21:28:29< mordante> hi YogiHH 
20090714 21:28:43< mordante> Crab_, if you run into problems just let me know
20090714 21:28:54< Crab_> ok
20090714 21:29:38< silene> mordante: there is this message at startup, does that ring a bell? "error gui/parse: horizontal_grow and horizontal_alignment can't be combined, alignment is ignored."
20090714 21:29:50-!- Netsplit hubbard.freenode.net <-> irc.freenode.net quits: silene, EdB, loonycyborg
20090714 21:29:55-!- loonycyborg [n=sergey@79.139.138.33] has joined #wesnoth-dev
20090714 21:30:12-!- Netsplit over, joins: EdB
20090714 21:30:12< YogiHH> mordante: i have something for you to look at. You can reproduce with latest svn if you start wesnoth with --new-widgets, click "load game", type "h" in the filter textbox (the scrollbar must be kept, so you might have to add some saves) and then scroll.
20090714 21:30:12< mordante> YogiHH, regarding r36903 did you already add it to Makefile.am ?
20090714 21:30:24< YogiHH> uh, no, will do
20090714 21:30:46< mordante> and we can leave it to Ivanovic to add it to the POTFILES.in, nice test-case for the new cmake script ;-)
20090714 21:30:52-!- silene [n=plouf@ASte-Genev-Bois-152-1-12-23.w82-121.abo.wanadoo.fr] has joined #wesnoth-dev
20090714 21:31:04< silene> (by the way, shouldn't that be a warning instead?)
20090714 21:31:36< mordante> silene, that rings a bell, it's an error in the WIP new lobby config
20090714 21:31:52< mordante> no it's an error to combine those flags
20090714 21:32:35-!- Noyga [n=lame-z@wesnoth/developer/noyga] has joined #wesnoth-dev
20090714 21:32:57-!- mordocai is now known as mordocai_afk
20090714 21:33:00< CIA-53> jhinrichs * r36904 /trunk/src/Makefile.am: Add new dialog source files to Makefile.am
20090714 21:33:57< mordante> YogiHH, it will take some time to finish compilation, need to finish my kernel rebuild first
20090714 21:34:12-!- yann [n=dwitch@nan92-1-81-57-214-146.fbx.proxad.net] has joined #wesnoth-dev
20090714 21:34:54< silene> mordante: that's not what i meant; what i meant is that, contrarily to all the other things (or almost) at the error level, everything still works after this one
20090714 21:35:20< YogiHH> mordante: sure, take your time. It's not a critical bug, just a display anomaly
20090714 21:38:17-!- Elvish_Pillager [n=eli@71-10-231-36.dhcp.oxfr.ma.charter.com] has joined #wesnoth-dev
20090714 21:40:03< mordante> silene, it still can cause a dialog to misbehave and I like to see those errors so I can expect a dialog to misbehave
20090714 21:40:16< mordante> but they should be fixed and I'm working on that code
20090714 21:40:22< YogiHH> mordante: i have another problem, i want to call a dialog out of another dialog and i need a video instance for that. However, the only time that the video instance is available is either in the constructor or in pre_show, but i need it somewhere else.
20090714 21:40:42< CIA-53> loonycyborg * r36905 /trunk/src/gui/dialogs/game_load.cpp: Fixed a compile warning.
20090714 21:40:49< mordante> YogiHH, store it as a member in the pre_show
20090714 21:41:11< YogiHH> mordante: no getter for twindow.video_?
20090714 21:41:14< mordante> I do that in several dialogs
20090714 21:43:29< mordante> YogiHH, no but I'll add it
20090714 21:44:04< YogiHH> mordante: that did surely confuse me now :-)
20090714 21:45:29< grzywacz> ;)
20090714 21:45:56< grzywacz> Ivanovic, I sent an email to Sam, let's see if he responds this time. ;)
20090714 21:46:41< silene> YogiHH: anything wrong with game_display::get_singleton()->video()?
20090714 21:46:49< CIA-53> mordante * r36906 /trunk/src/gui/widgets/window.hpp: Add twindow::video().
20090714 21:46:52< mordante> YogiHH, ^
20090714 21:54:26< Crab_> zookeeper: can a time of day be changed instantly via WML ?
20090714 21:55:02< silene> Crab_: yes
20090714 21:55:49< Crab_> silene: thanks
20090714 22:00:48-!- Blueblaze [n=nick@c-98-199-143-139.hsd1.tx.comcast.net] has joined #wesnoth-dev
20090714 22:07:26< Ivanovic> hi
20090714 22:08:09< mordante> hi Ivanovic 
20090714 22:09:00< Ivanovic> corn: good to know
20090714 22:09:50-!- ilor [n=user@wesnoth/developer/ilor] has joined #wesnoth-dev
20090714 22:11:03< Soliton> silene: ah, ok.
20090714 22:11:34< ilor> hi mordante
20090714 22:11:58< mordante> hi ilor 
20090714 22:12:37< mordante> ilor, haven't been around much this evening so didn't proceed on the dialog
20090714 22:13:04< ilor> mordante: I've been looking at the server side rng thing, and I've noticed some, uh, obstacles
20090714 22:13:30< mordante> bad?
20090714 22:14:08< ilor> mordante: well the most important one is that we basivally need to block and wait for a response from the server somewhere in attack resolution code
20090714 22:14:34< ilor> but there might be other messages coming so we'd need a queue to hold them
20090714 22:14:44< ilor> so other code can process them later
20090714 22:17:43< mordante> YogiHH, I see what you mean, added it to my todo list
20090714 22:18:00< silene> ilor: no, you could also decide to end prematurely the attack, and only start it for real once you receive the data from the server (similarly to what the other non-attacking clients do)
20090714 22:20:58< ilor> silene: not sure I follow
20090714 22:21:45< silene> ilor: what i mean is that you don't have to wait in the attack code, you could start the attack code only when you have received the rng values, not before
20090714 22:23:01< mordante> ilor, I'm off now, will read the log tomorrow
20090714 22:23:04< mordante> night
20090714 22:23:07< ilor> night mordante
20090714 22:23:21-!- mordante [n=mordante@wesnoth/developer/mordante] has quit ["Leaving"]
20090714 22:24:11< Crab_> silene: so, the sequence will be something like '1) send decision to attack to server 2) wait (with game-changing commands disabled, but with chat/other commands enabled) till random seed arrives from server 3) resolve the attack' ?
20090714 22:24:51< silene> Crab_: yes, and note that this is exactly the sequence for non-attacking clients, so it could also be the sequence for the attacking client
20090714 22:25:43-!- loonycyborg [n=sergey@wesnoth/developer/loonycyborg] has quit ["KVIrc 3.4.2 Shiny http://www.kvirc.net/"]
20090714 22:26:19-!- loonybot [n=loonybot@wesnoth/bot/loonybot] has quit [Remote closed the connection]
20090714 22:27:44< silene> (so this would simplify the code a lot with respect to its current state)
20090714 22:31:31-!- noy [n=Noy@wesnoth/developer/noy] has quit [Read error: 104 (Connection reset by peer)]
--- Log closed Tue Jul 14 22:37:27 2009
--- Log opened Tue Jul 14 22:37:27 2009
20090714 22:42:11-!- elias [n=allefant@allegro/developer/allefant] has joined #wesnoth-dev
20090714 22:45:55-!- allefant [n=allefant@allegro/developer/allefant] has quit [Read error: 60 (Operation timed out)]
20090714 23:05:59< Ivanovic> okay, running a pot-update using the cmake version of it...
20090714 23:06:20-!- EdB [n=edb@248.12.95-79.rev.gaoland.net] has quit [Remote closed the connection]
20090714 23:11:09-!- Blueblaze [n=nick@c-98-199-143-139.hsd1.tx.comcast.net] has quit [Remote closed the connection]
20090714 23:16:26-!- Noyga [n=lame-z@wesnoth/developer/noyga] has left #wesnoth-dev ["Quitte"]
20090714 23:21:29-!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Remote closed the connection]
20090714 23:21:36-!- Espreon [n=espreon@wesnoth/developer/espreon] has joined #wesnoth-dev
20090714 23:22:13< CIA-53> ivanovic * r36907 /trunk/po/ (983 files in 22 dirs): pot-update (now using the cmake recipe for pot-update, please report any regressions immediatly)
20090714 23:22:52< Ivanovic> everyone on a "not too broadband"-connection should rejoice when loading r36907
20090714 23:23:28-!- Aethaeryn [n=Michael@wesnoth/umc-dev/developer/aethaeryn] has joined #Wesnoth-dev
20090714 23:25:00< ilor> silene: so if I understand the code enough, this would mean:
20090714 23:25:00< ilor>  - split the attack process code from mouse_handler::attack_enemy_ and make it call it directly if in a SP game, else stop after adding the atack to recorder, request a new seed and set a flag somewhere (?) so the network code upwards knows to wait for it. Also disable further ui commands processing.
20090714 23:25:00< ilor>  - in playmp_controller::play_human_turn add code to receive and apply the new seed and run the actual attack code and reenable ui commands
20090714 23:25:00< ilor>  - update rng code to match
20090714 23:25:44-!- stikonas [n=and@ctv-79-132-177-212.vinita.lt] has joined #wesnoth-dev
20090714 23:26:21< silene> ilor: yes
20090714 23:27:20< crimson_penguin> I've been having some OOS errors with 1.6.4 :-/
20090714 23:27:52< Crab_> ilor: make sure that the network is synced before the seed is requested. everyone must see that the player first ordered an attack, and THEN requested a rng-value and used it.
20090714 23:29:54< ilor> Crab_: what do you mean by syncing? yes the attack command should be sent separetly from the results, but als the attack message is pretty much equivalent to a seed request
20090714 23:30:10-!- zookeeper [n=l@wesnoth/developer/zookeeper] has quit []
20090714 23:30:17< silene> Crab_: why "then"? i think ordering should implicitly be understood by the server as querying a rng seed
20090714 23:31:10< ilor> yes I do think ordering is already well guaranteed
20090714 23:31:24< Crab_> silene: then, when querying a rng seed, we must include a 'purpose' (details about chosen attack - attacker, defender, attacker weapon). otherwise, player can cheat by querying for seed, and then choosing the 'best' possible attack.
20090714 23:32:07-!- AnMaster [n=AnMaster@unaffiliated/anmaster] has joined #wesnoth-dev
20090714 23:32:29< silene> Crab_: no, you get it backward; the player shouldn't query a seed; the player should order an attack and the server should reply (to all) with the attack and the seed
20090714 23:32:31< Crab_> ilor: by syncing i mean that the server should 'see' that attack order before sending the rng seed.
20090714 23:32:32< Soliton> btw, dis/enabling the relevant UI commands is done by simply setting browse_ to true/false, i think.
20090714 23:32:46-!- AnMaster_ipv6 [n=AnMaster@unaffiliated/anmaster] has quit [Connection timed out]
20090714 23:35:18< Crab_> silene: yes, 'the player should order an attack and the server should reply (to all) with the attack and the seed' is good, too.
20090714 23:35:31< ilor> there's also the case of updating replay code to handle getting the random numbers separetely fom the attack info
20090714 23:35:33< Ivanovic> corn: regarding the mail about passed/failed you don't have to contact leslie again since you already did so
20090714 23:36:50< silene> ilor: no, they don't have to be separate; as i just said, the server should broadcast the attack order with the seed
20090714 23:36:57< corn> Ivanovic: ok
20090714 23:37:05< ilor> silene: ah
20090714 23:37:20< ilor> silene: ahhh
20090714 23:38:09< ilor> yes this indeed makes a lot of sense
20090714 23:38:43< Crab_> also note that recruit also needs srng (traits are random)
20090714 23:39:08< Ivanovic> corn: so somehow it will be possible to sort this out
20090714 23:39:38< Ivanovic> but next time please fill the survey earlies (you said you were away for 3 days, the survey was online for a week and i already pinged on the first day)
20090714 23:40:50-!- Bob_The_Mighty [n=chatzill@cpc3-brig15-0-0-cust558.3-3.cable.virginmedia.com] has joined #wesnoth-dev
20090714 23:41:01-!- noy [n=Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20090714 23:41:47< silene> Crab_: yes, the exact same mechanism can be used; 1. the client sends a recruit order and disable its ui, 2. the server receives it, computes a seed, and broadcast the order with the seed, 3. clients receive the order and play it (and reenable the ui if disabled)
20090714 23:42:42< ilor> silene: I wonder whether the attack decision should be added to the local replay recorder on the attacking client, or only the attack request sent to the server and then the response added
20090714 23:42:54< Bob_The_Mighty> is there any difference in wml speed between an event with a filter looking for a unit ability, or the same event with an [if] check for the ability?
20090714 23:43:35< ilor> silene: I'm thinking the latter
20090714 23:43:46< silene> ilor: i don't think the attack decision is useful, so the latter too
20090714 23:44:32< silene> Bob_The_Mighty: the filter will be definitely be faster, not necessarily by much though, it depends
20090714 23:53:01-!- noy [n=Noy@wesnoth/developer/noy] has quit ["GO, GET TO THE CHOPPAH!!!"]
20090714 23:54:15-!- AnMaster [n=AnMaster@unaffiliated/anmaster] has quit [No route to host]
20090714 23:55:38-!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Read error: 110 (Connection timed out)]
20090714 23:57:32< ilor> cjhopman: any luck with the skiplist_map / msvc barf?
20090714 23:58:19< grzywacz> Not ready to use, but maybe worth revisiting later: http://www.chriseineke.com/sdl++/index.html
--- Log closed Wed Jul 15 00:00:09 2009